1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
|
1
00:00:00,320 --> 00:00:02,252
As I just said, today we're going to talk about the
2
00:00:02,252 --> 00:00:04,876
Rational Unified Process. And you know that I like to provide
3
00:00:04,876 --> 00:00:07,632
the historical perspective of the topics that we cover in class
4
00:00:07,632 --> 00:00:10,070
and this lesson is no exception. So let's see a little bit
5
00:00:10,070 --> 00:00:12,500
of history of RUP. To do that we have to go
6
00:00:12,500 --> 00:00:17,620
back to 1997 when Rational defined six best practices for modern software
7
00:00:17,620 --> 00:00:20,930
engineering. So let's look at what these practices were. The first
8
00:00:20,930 --> 00:00:25,330
practice involved developing in an iterative way with risk as the primary
9
00:00:25,330 --> 00:00:27,700
iteration driver. The second practice had to do
10
00:00:27,700 --> 00:00:31,375
with managing requirements, including updating them and keeping
11
00:00:31,375 --> 00:00:34,570
traceability information between requirements and other software
12
00:00:34,570 --> 00:00:37,675
artifacts. Practice number three was to employ a
13
00:00:37,675 --> 00:00:40,830
component-based architecture. What that means is to have
14
00:00:40,830 --> 00:00:43,540
a high level design that focuses on cooperating
15
00:00:43,540 --> 00:00:46,780
components that are nevertheless very cohesive and highly
16
00:00:46,780 --> 00:00:50,710
decoupled. Modeling software visually is another key aspect
17
00:00:50,710 --> 00:00:53,250
of the rational unified process. And the key concept
18
00:00:53,250 --> 00:00:56,070
here is to use visual diagrams, and in particular UML
19
00:00:56,070 --> 00:00:58,520
visual diagrams, in a very extensive way so as
20
00:00:58,520 --> 00:01:01,950
to make artifacts easier to understand and agree upon among
21
00:01:01,950 --> 00:01:04,849
stakeholders. And the fact that the process is defined
22
00:01:04,849 --> 00:01:08,510
in an iterative way, allows for performing quality assurance activities
23
00:01:08,510 --> 00:01:11,430
in a continuous way. So it allows for continuously
24
00:01:11,430 --> 00:01:13,860
verifying quality throughout the development
25
00:01:13,860 --> 00:01:16,220
process. Finally, change management and
26
00:01:16,220 --> 00:01:18,750
control were also at the center of the rational
27
00:01:18,750 --> 00:01:22,100
approach These six practices, that I just mentioned were
28
00:01:22,100 --> 00:01:24,740
the starting point for the development of the Rational
29
00:01:24,740 --> 00:01:27,300
Unified Process, which is what we're going to discuss next.
|
