about summary refs log tree commit diff
path: root/usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt
diff options
context:
space:
mode:
Diffstat (limited to 'usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt')
-rw-r--r--usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt115
1 files changed, 115 insertions, 0 deletions
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt
new file mode 100644
index 0000000..83a656b
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt
@@ -0,0 +1,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.