From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001
From: Nguyễn Gia Phong <mcsinyx@disroot.org>
Date: Sun, 24 May 2020 16:34:31 +0700
Subject: [usth/ICT2.7] Engineer software

---
 .../1 - Lesson Overview - lang_en_vs4.srt          |  31 ++
 ...0 - Iterative and Incremental - lang_en_vs6.srt | 147 ++++++++++
 .../11 - Cycle Example - lang_en_vs6.srt           | 147 ++++++++++
 .../12 - Phases within a Cycle - lang_en_vs5.srt   | 199 +++++++++++++
 .../13 - Iterations - lang_en_vs5.srt              |  95 ++++++
 .../14 - Iterative Approach Quiz - lang_en_vs5.srt |  43 +++
 ...rative Approach Quiz Solution - lang_en_vs5.srt | 179 ++++++++++++
 .../16 - Inception Phase - lang_en_vs4.srt         | 323 +++++++++++++++++++++
 .../17 - Elaboration Phase - lang_en_vs5.srt       | 215 ++++++++++++++
 .../18 - Construction Phase - lang_en_vs5.srt      | 247 ++++++++++++++++
 .../19 - Transition Phase - lang_en_vs5.srt        | 231 +++++++++++++++
 .../2 - History of RUP - lang_en_vs6.srt           | 115 ++++++++
 .../20 - Phases and Iterations - lang_en_vs4.srt   | 107 +++++++
 .../3 - Key Features of RUP - lang_en_vs6.srt      | 103 +++++++
 .../4 - UML Quiz - lang_en_vs5.srt                 |  47 +++
 .../5 - UML Quiz Solution - lang_en_vs4.srt        |  15 +
 .../6 - UML Quiz - lang_en_vs6.srt                 |  39 +++
 .../7 - UML Quiz Solution - lang_en_vs6.srt        | 143 +++++++++
 .../8 - Use Case Driven - lang_en_vs5.srt          |  71 +++++
 .../9 - Architecture Centric - lang_en_vs5.srt     | 131 +++++++++
 20 files changed, 2628 insertions(+)
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/1 - Lesson Overview - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/10 - Iterative and Incremental - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/11 - Cycle Example - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/12 - Phases within a Cycle - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/13 - Iterations - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/14 - Iterative Approach Quiz - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/15 - Iterative Approach Quiz Solution - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/16 - Inception Phase - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/17 - Elaboration Phase - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/18 - Construction Phase - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/20 - Phases and Iterations - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/3 - Key Features of RUP - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/4 - UML Quiz - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/5 - UML Quiz Solution - lang_en_vs4.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/6 - UML Quiz - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/7 - UML Quiz Solution - lang_en_vs6.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/8 - Use Case Driven - lang_en_vs5.srt
 create mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/9 - Architecture Centric - lang_en_vs5.srt

(limited to 'usth/ICT2.7/P3L4 Unified Software Process Subtitles')

diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/1 - Lesson Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..4abf070
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/1 - Lesson Overview - lang_en_vs4.srt	
@@ -0,0 +1,31 @@
+1
+00:00:00,770 --> 00:00:02,830
+In the previous lessons of this mini-course,
+
+2
+00:00:02,830 --> 00:00:06,620
+we discussed high level design, or architecture,
+
+3
+00:00:06,620 --> 00:00:12,380
+low level design, and design patterns. Now, we're going to see how we can put
+
+4
+00:00:12,380 --> 00:00:15,380
+this and also others software engineering activities
+
+5
+00:00:15,380 --> 00:00:18,436
+together in the context of a UML-based
+
+6
+00:00:18,436 --> 00:00:21,820
+process model, the unified software process, or
+
+7
+00:00:21,820 --> 00:00:25,580
+USP. We will discuss how USP was defined,
+
+8
+00:00:25,580 --> 00:00:30,492
+its main characteristics, its phases, and how we can apply it in practice.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/10 - Iterative and Incremental - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/10 - Iterative and Incremental - lang_en_vs6.srt
new file mode 100644
index 0000000..e542660
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/10 - Iterative and Incremental - lang_en_vs6.srt	
@@ -0,0 +1,147 @@
+1
+00:00:00,190 --> 00:00:03,100
+We just saw two of the three distinguishing aspects of
+
+2
+00:00:03,100 --> 00:00:05,800
+the rational unified process. The fact that it is used
+
+3
+00:00:05,800 --> 00:00:08,810
+case driven and the fact that it is architecture centric.
+
+4
+00:00:08,810 --> 00:00:11,950
+The third and final distinguished aspect of R.U.P. is that
+
+5
+00:00:11,950 --> 00:00:15,210
+it is iterative and incremental. So let's see what that
+
+6
+00:00:15,210 --> 00:00:18,870
+means by considering the lifetime of a software project. Basically,
+
+7
+00:00:18,870 --> 00:00:22,120
+the lifetime of a rational unified process consists of a
+
+8
+00:00:22,120 --> 00:00:24,920
+series of cycles, such as the ones that are represented here.
+
+9
+00:00:24,920 --> 00:00:28,070
+Cycle one, cycle two, through cycle n. And as
+
+10
+00:00:28,070 --> 00:00:30,990
+you can see, these cycles can also be called increments.
+
+11
+00:00:30,990 --> 00:00:33,280
+And each one of the cycles involves all of
+
+12
+00:00:33,280 --> 00:00:36,700
+the main phases of software development. In addition, each cycle
+
+13
+00:00:36,700 --> 00:00:39,700
+results in a product release which can be internal
+
+14
+00:00:39,700 --> 00:00:43,210
+or external. More precisely, each cycle terminates with a product
+
+15
+00:00:43,210 --> 00:00:46,340
+release that includes a complete set of artifacts for
+
+16
+00:00:46,340 --> 00:00:50,150
+the project. That means code, manuals, use cases, non-functional
+
+17
+00:00:50,150 --> 00:00:52,840
+specification, test cases, and so on. So, I've just
+
+18
+00:00:52,840 --> 00:00:55,760
+said, that each cycle involves all of the main phases
+
+19
+00:00:55,760 --> 00:00:59,440
+of software development. Specifically, each cycle is further divided
+
+20
+00:00:59,440 --> 00:01:04,040
+in four phases. Inception, elaboration, construction and transition. In a
+
+21
+00:01:04,040 --> 00:01:06,290
+minute, we will look at each one of these
+
+22
+00:01:06,290 --> 00:01:08,840
+phases in detail and see how they relate to the
+
+23
+00:01:08,840 --> 00:01:12,150
+traditional activities of software development. Before that, I want
+
+24
+00:01:12,150 --> 00:01:15,760
+to mention the last level of these iterations, which happens
+
+25
+00:01:15,760 --> 00:01:20,330
+within these individual phases More precisely, inside each of these
+
+26
+00:01:20,330 --> 00:01:24,230
+phases, there might be multiple iterations. So what are these
+
+27
+00:01:24,230 --> 00:01:28,070
+iterations? Well, basically, each iteration corresponds to a group of
+
+28
+00:01:28,070 --> 00:01:30,550
+use cases that are selected so as to deal with
+
+29
+00:01:30,550 --> 00:01:33,200
+the most important risks first. So if you have a
+
+30
+00:01:33,200 --> 00:01:35,510
+set of use cases that you're considering, which means that
+
+31
+00:01:35,510 --> 00:01:37,450
+you have a set of features that you need to
+
+32
+00:01:37,450 --> 00:01:41,260
+implement, you will select for each iteration the most risky
+
+33
+00:01:41,260 --> 00:01:44,720
+ones that you still haven't realized, and realize them in that
+
+34
+00:01:44,720 --> 00:01:47,720
+iteration. And then continue in the following iterations with less and
+
+35
+00:01:47,720 --> 00:01:50,980
+less risky ones. So basically what happens in the end is
+
+36
+00:01:50,980 --> 00:01:52,960
+that essentially each iteration extends
+
+37
+00:01:52,960 --> 00:01:55,220
+the functionality beyond the previous iteration.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/11 - Cycle Example - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/11 - Cycle Example - lang_en_vs6.srt
new file mode 100644
index 0000000..af70543
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/11 - Cycle Example - lang_en_vs6.srt	
@@ -0,0 +1,147 @@
+1
+00:00:00,230 --> 00:00:02,590
+To make this a little more concrete, let's look at
+
+2
+00:00:02,590 --> 00:00:07,466
+an example involving cycles, phases, and iterations. Let's assume that we
+
+3
+00:00:07,466 --> 00:00:10,250
+have to develop a banking IT system. The first possible
+
+4
+00:00:10,250 --> 00:00:12,730
+cycle for such a system could be one in which we
+
+5
+00:00:12,730 --> 00:00:16,280
+implement the basic withdrawal facilities. What this means is that,
+
+6
+00:00:16,280 --> 00:00:18,400
+at the end of this cycle, there will be the release
+
+7
+00:00:18,400 --> 00:00:22,130
+of the product that implements this piece of functionality. But notice
+
+8
+00:00:22,130 --> 00:00:25,500
+that this will not be the only product release because within
+
+9
+00:00:25,500 --> 00:00:28,580
+the cycle, we will perform also the four phases that
+
+10
+00:00:28,580 --> 00:00:31,020
+we mentioned before, inception, elaboration,
+
+11
+00:00:31,020 --> 00:00:33,550
+construction, and transition. And within each
+
+12
+00:00:33,550 --> 00:00:36,980
+of these phases, we might have multiple iterations. And at the
+
+13
+00:00:36,980 --> 00:00:39,710
+end of each iteration, we will also have a product release.
+
+14
+00:00:39,710 --> 00:00:41,790
+Which in this case, will be an internal one. As
+
+15
+00:00:41,790 --> 00:00:44,690
+you can see, the iterative nature is really inherent in the
+
+16
+00:00:44,690 --> 00:00:48,030
+unified rational process. So, now let's clean up here, and let's
+
+17
+00:00:48,030 --> 00:00:50,814
+see what some other possible cycles could be for our banking
+
+18
+00:00:50,814 --> 00:00:54,070
+IT system. Here, I'm showing two possible additional ones. The first
+
+19
+00:00:54,070 --> 00:00:57,800
+one, cycle two, which will develop the account and system management. And
+
+20
+00:00:57,800 --> 00:01:00,230
+the third one, cycle three, which will develop the full account
+
+21
+00:01:00,230 --> 00:01:04,620
+management and cross selling. Similarly to cycle one, also these cycles will
+
+22
+00:01:04,620 --> 00:01:07,570
+produce a product, both at the end of the cycle, and
+
+23
+00:01:07,570 --> 00:01:10,740
+within the cycle in the different phases. And there's a few more
+
+24
+00:01:10,740 --> 00:01:13,150
+things to note. So the first one, is that each cycle
+
+25
+00:01:13,150 --> 00:01:15,900
+focuses on a different part of the system. So what you will
+
+26
+00:01:15,900 --> 00:01:19,350
+do, when you use the rational unified process, you will select a
+
+27
+00:01:19,350 --> 00:01:23,320
+subset of use cases that you want to realize within your cycle.
+
+28
+00:01:23,320 --> 00:01:26,640
+And the final product for that cycle, will be a product that
+
+29
+00:01:26,640 --> 00:01:30,190
+realizes those use cases. This is the first aspect. The second one,
+
+30
+00:01:30,190 --> 00:01:33,290
+is that these cycles, as you can see, are slightly overlapping. So
+
+31
+00:01:33,290 --> 00:01:35,880
+it is not the case that you finish a cycle, and then
+
+32
+00:01:35,880 --> 00:01:37,580
+you start the next one. So there is a little bit of
+
+33
+00:01:37,580 --> 00:01:41,250
+overlap among cycles, and we'll talk about that more. And finally,
+
+34
+00:01:41,250 --> 00:01:43,600
+I want to stress one more that each cycle
+
+35
+00:01:43,600 --> 00:01:46,960
+contains four phases, and each one of these phases might
+
+36
+00:01:46,960 --> 00:01:49,890
+be further splayed in iterations. So that's kind of a
+
+37
+00:01:49,890 --> 00:01:52,610
+high level view of how the whole process will work.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/12 - Phases within a Cycle - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/12 - Phases within a Cycle - lang_en_vs5.srt
new file mode 100644
index 0000000..c58be49
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/12 - Phases within a Cycle - lang_en_vs5.srt	
@@ -0,0 +1,199 @@
+1
+00:00:00,240 --> 00:00:02,505
+Now let's go back to the phases within a cycle.
+
+2
+00:00:02,505 --> 00:00:04,930
+because I want to show you how they relate to traditional
+
+3
+00:00:04,930 --> 00:00:08,196
+activities of software development. Because this is the first time that
+
+4
+00:00:08,196 --> 00:00:12,066
+we talk about inception, elaboration, construction and transition. So we will
+
+5
+00:00:12,066 --> 00:00:14,859
+know what they mean, in terms of the traditional software
+
+6
+00:00:14,859 --> 00:00:18,380
+development. So I'm going to first discuss these relations and then
+
+7
+00:00:18,380 --> 00:00:22,198
+I'm going to talk about each individual phase in further detail.
+
+8
+00:00:22,198 --> 00:00:25,570
+So I'm going to start by representing the four RUP phases here
+
+9
+00:00:25,570 --> 00:00:29,810
+with possible internal iterations. I1, E1 and E2, C1,
+
+10
+00:00:29,810 --> 00:00:32,490
+C2, and so on. And just as a reference, this
+
+11
+00:00:32,490 --> 00:00:34,670
+is the way in which time will progress. So we
+
+12
+00:00:34,670 --> 00:00:37,890
+will start with inception and we will finish with transition.
+
+13
+00:00:37,890 --> 00:00:39,710
+So what I'm want to do now is to show the
+
+14
+00:00:39,710 --> 00:00:43,930
+actual, traditional, software development activities here on the left. And
+
+15
+00:00:43,930 --> 00:00:46,970
+I also want to show you, using this diagram, how these
+
+16
+00:00:46,970 --> 00:00:51,610
+activities are actually performed in each of the RUP phases.
+
+17
+00:00:51,610 --> 00:00:54,540
+So, let's see what this representation means. Basically, what
+
+18
+00:00:54,540 --> 00:00:58,410
+I'm showing here, is that requirements engineering actually starts in
+
+19
+00:00:58,410 --> 00:01:00,480
+the inception phase. So, you can see the height
+
+20
+00:01:00,480 --> 00:01:03,090
+of this bar as the amount of effort devoted to
+
+21
+00:01:03,090 --> 00:01:05,890
+this activity in this specific phase. So you can
+
+22
+00:01:05,890 --> 00:01:09,950
+see that requirements engineering starts in inception phase, is mostly
+
+23
+00:01:09,950 --> 00:01:13,210
+performed in the elaboration phase, and then it continues,
+
+24
+00:01:13,210 --> 00:01:16,820
+although to a lesser extent, throughout all phases up until
+
+25
+00:01:16,820 --> 00:01:18,570
+the end of the transition. But the bulk is really
+
+26
+00:01:18,570 --> 00:01:22,940
+performed here in the elaboration phase. Similarly, if we consider analysis
+
+27
+00:01:22,940 --> 00:01:25,450
+and design, we can see that analysis and design are
+
+28
+00:01:25,450 --> 00:01:29,510
+mainly performed in the elaboration phase. But a considerable amount of
+
+29
+00:01:29,510 --> 00:01:31,900
+it also continues in the construction phase, and then it
+
+30
+00:01:31,900 --> 00:01:34,514
+kind of phases out. So there's very little of that done
+
+31
+00:01:34,514 --> 00:01:37,300
+in the transition phase. Looking now at implementation, you can see
+
+32
+00:01:37,300 --> 00:01:41,190
+that the implementation happens mostly in the construction phase, which is,
+
+33
+00:01:41,190 --> 00:01:45,460
+unsurprisingly, the phase that is mostly concerned with actual code development,
+
+34
+00:01:45,460 --> 00:01:47,620
+as we will see in a minute. Testing, on the other
+
+35
+00:01:47,620 --> 00:01:50,990
+hand, is performed throughout most phases, with, peaks in some specific
+
+36
+00:01:50,990 --> 00:01:54,260
+point, for example, at the end of some iterations, like here
+
+37
+00:01:54,260 --> 00:01:57,880
+and here. To conclude, we have the business modeling activity that
+
+38
+00:01:57,880 --> 00:02:00,160
+happens mainly in the inception and a little bit in the
+
+39
+00:02:00,160 --> 00:02:04,100
+elaboration phase and the deployment activity which happens a little bit
+
+40
+00:02:04,100 --> 00:02:06,420
+throughout, but the bulk of it is really in the transition
+
+41
+00:02:06,420 --> 00:02:08,699
+phase, which is actually the phase that has to do
+
+42
+00:02:08,699 --> 00:02:12,070
+with deployment and then maintenance. So I hope this kind
+
+43
+00:02:12,070 --> 00:02:14,970
+of high level view gives you a better understanding of
+
+44
+00:02:14,970 --> 00:02:17,940
+what is the mapping between these new phases and, the
+
+45
+00:02:17,940 --> 00:02:21,760
+typical software development activities that we are more familiar with.
+
+46
+00:02:21,760 --> 00:02:24,360
+So to further this understanding, later in the lesson, I'm
+
+47
+00:02:24,360 --> 00:02:28,220
+also going to talk about these specific phases individually. First, however,
+
+48
+00:02:28,220 --> 00:02:31,610
+I want to spend a little more time discussing what happens
+
+49
+00:02:31,610 --> 00:02:35,200
+inside each one of these iterations, just to make sure
+
+50
+00:02:35,200 --> 00:02:38,410
+that we are all understand what an iteration is exactly.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/13 - Iterations - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/13 - Iterations - lang_en_vs5.srt
new file mode 100644
index 0000000..fbdc2b0
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/13 - Iterations - lang_en_vs5.srt	
@@ -0,0 +1,95 @@
+1
+00:00:00,420 --> 00:00:03,520
+So what happens, exactly, within an iteration? In
+
+2
+00:00:03,520 --> 00:00:07,680
+almost every iteration, developers perform the following activities.
+
+3
+00:00:07,680 --> 00:00:10,830
+So they identify which pieces of functionality this
+
+4
+00:00:10,830 --> 00:00:14,450
+iteration will develop, will implement. After doing that, they
+
+5
+00:00:14,450 --> 00:00:17,240
+will create a design, for the considered use
+
+6
+00:00:17,240 --> 00:00:19,640
+cases, and they will do that guided by the
+
+7
+00:00:19,640 --> 00:00:22,334
+chosen architecture. So the set of use cases
+
+8
+00:00:22,334 --> 00:00:25,666
+plus the architectural guidelines will result in a design
+
+9
+00:00:25,666 --> 00:00:29,035
+for the selected use cases. Once the design is defined,
+
+10
+00:00:29,035 --> 00:00:32,060
+then the developers will implement the design, which will result
+
+11
+00:00:32,060 --> 00:00:35,430
+in a set of software components. They will then verify
+
+12
+00:00:35,430 --> 00:00:38,992
+the components against the use cases to make sure that the
+
+13
+00:00:38,992 --> 00:00:41,740
+components satisfy the use cases, they suitably realize the use
+
+14
+00:00:41,740 --> 00:00:43,995
+cases. And they will do that through testing or some
+
+15
+00:00:43,995 --> 00:00:47,730
+other verification and validation activity. Finally, after verifying that the
+
+16
+00:00:47,730 --> 00:00:51,320
+code actually implements the use cases, they will release a product,
+
+17
+00:00:51,320 --> 00:00:53,840
+which also represent the end of the iteration. And notice that
+
+18
+00:00:53,840 --> 00:00:56,370
+what I put here is an icon for the world,
+
+19
+00:00:56,370 --> 00:00:59,330
+in double quotes. Because in many cases the release will be
+
+20
+00:00:59,330 --> 00:01:02,050
+just an internal release or maybe a release that will just
+
+21
+00:01:02,050 --> 00:01:04,813
+go to some of the stakeholders so that they can provide
+
+22
+00:01:04,813 --> 00:01:07,040
+feedback on that. Okay. So it doesn't have to be an
+
+23
+00:01:07,040 --> 00:01:09,080
+external release. It doesn't have to be a release to the
+
+24
+00:01:09,080 --> 00:01:12,270
+world. But it is, nevertheless, a release of a software product. .
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/14 - Iterative Approach Quiz - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/14 - Iterative Approach Quiz - lang_en_vs5.srt
new file mode 100644
index 0000000..d4b7808
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/14 - Iterative Approach Quiz - lang_en_vs5.srt	
@@ -0,0 +1,43 @@
+1
+00:00:00,182 --> 00:00:02,850
+So now, since we're talking about the incremental and iterative
+
+2
+00:00:02,850 --> 00:00:05,950
+nature of the Rational Unified Process, let's have a quiz on
+
+3
+00:00:05,950 --> 00:00:09,460
+the benefits of iterative approaches. So I'd like for you to tell
+
+4
+00:00:09,460 --> 00:00:12,710
+me what are these benefits. Is one benefit the fact that
+
+5
+00:00:12,710 --> 00:00:16,129
+iterative approaches keep developers busy or maybe that they give developers
+
+6
+00:00:16,129 --> 00:00:19,480
+early feedback, that they allow for doing the same thing over
+
+7
+00:00:19,480 --> 00:00:22,930
+and over in an iterative way. Maybe they also minimize the
+
+8
+00:00:22,930 --> 00:00:25,210
+risk of developing the wrong system. Can they be used to
+
+9
+00:00:25,210 --> 00:00:27,170
+improve planning, or is it the benefit
+
+10
+00:00:27,170 --> 00:00:30,160
+that they accommodate evolving requirements. Also, in this
+
+11
+00:00:30,160 --> 00:00:34,360
+case, I would like for you to check all the answers that you think are correct.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/15 - Iterative Approach Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/15 - Iterative Approach Quiz Solution - lang_en_vs5.srt
new file mode 100644
index 0000000..6e69cec
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/15 - Iterative Approach Quiz Solution - lang_en_vs5.srt	
@@ -0,0 +1,179 @@
+1
+00:00:00,180 --> 00:00:01,740
+Okay so let's look at the first one. Well I
+
+2
+00:00:01,740 --> 00:00:04,760
+don't think that the fact of keeping developers busy is really
+
+3
+00:00:04,760 --> 00:00:08,020
+one of the highlights or the main benefits of iterative
+
+4
+00:00:08,020 --> 00:00:12,310
+approaches. Developers are really busy without any need for additional help.
+
+5
+00:00:12,310 --> 00:00:14,950
+So I will just not mark this one. The second
+
+6
+00:00:14,950 --> 00:00:19,280
+one conversely is definitely one of the advantages of iterative approaches.
+
+7
+00:00:19,280 --> 00:00:21,710
+So the fact that iterative approaches give the developers a early
+
+8
+00:00:21,710 --> 00:00:25,890
+feedback, is a great advantage which has in turn additional advantages.
+
+9
+00:00:25,890 --> 00:00:29,340
+For example, it increases the project tempo, so it gives the developers
+
+10
+00:00:29,340 --> 00:00:32,350
+not busy but more focused. It's easier to be focused when you
+
+11
+00:00:32,350 --> 00:00:35,790
+have a short term deadline, or a short term goal
+
+12
+00:00:35,790 --> 00:00:38,670
+rather than a release that is planned in six months or even
+
+13
+00:00:38,670 --> 00:00:42,420
+later. Another advantage of this early feedback is the fact that developers
+
+14
+00:00:42,420 --> 00:00:45,390
+are rewarded for their efforts so, there is sort of an immediate
+
+15
+00:00:45,390 --> 00:00:48,360
+rewards because you can see the results of your effort instead of
+
+16
+00:00:48,360 --> 00:00:51,310
+having to wait a long time to see such results. And last,
+
+17
+00:00:51,310 --> 00:00:55,126
+but not least the fact of getting early feedback also minimizes
+
+18
+00:00:55,126 --> 00:00:58,570
+the risks of developing the wrong system. So why is that?
+
+19
+00:00:58,570 --> 00:01:01,820
+Well because getting early feedback will also allow us to find
+
+20
+00:01:01,820 --> 00:01:05,140
+out whether we're going in the wrong direction early in the development process
+
+21
+00:01:05,140 --> 00:01:08,460
+rather than at the end. And therefore, will minimize this risk.
+
+22
+00:01:08,460 --> 00:01:10,760
+Going back to the previous question, yeah, I don't think that, you
+
+23
+00:01:10,760 --> 00:01:12,960
+know, doing the same thing over and over is a great
+
+24
+00:01:12,960 --> 00:01:16,170
+advantage. And in fact, iterative approaches do not do the same thing
+
+25
+00:01:16,170 --> 00:01:18,940
+over and over. So they keep iterating, but they keep
+
+26
+00:01:18,940 --> 00:01:21,930
+augmenting the amount of functionality in the system. They don't
+
+27
+00:01:21,930 --> 00:01:24,960
+just repeat the same thing. As for improving planning, actually
+
+28
+00:01:24,960 --> 00:01:27,980
+improving planning is not really a strength of these approaches,
+
+29
+00:01:27,980 --> 00:01:30,880
+because sometimes the number of iterations is hard to predict,
+
+30
+00:01:30,880 --> 00:01:33,050
+so it's hard to do a natural planning when you
+
+31
+00:01:33,050 --> 00:01:36,440
+are using an iterative approach. So finally, are iterative approaches
+
+32
+00:01:36,440 --> 00:01:38,700
+good for accomodating evolving requirements?
+
+33
+00:01:38,700 --> 00:01:41,630
+Most definitely. First, iterative approaches, and
+
+34
+00:01:41,630 --> 00:01:44,590
+in particular, the one that we're discussing consider requirements
+
+35
+00:01:44,590 --> 00:01:47,900
+incrementally, so they can better incorporate your requirements. So if
+
+36
+00:01:47,900 --> 00:01:51,030
+there are new requirements, it's easier to accommodate them using
+
+37
+00:01:51,030 --> 00:01:55,210
+an iterative approach. Second, these approaches realize a few requirements
+
+38
+00:01:55,210 --> 00:01:57,740
+at a time. Something from the most risky ones, as
+
+39
+00:01:57,740 --> 00:02:00,600
+we said. So any problem with those risky requirements will
+
+40
+00:02:00,600 --> 00:02:04,220
+be discovered early, and suitable course corrections could be taken.
+
+41
+00:02:04,220 --> 00:02:06,850
+So in case you still have doubts about iterative approaches,
+
+42
+00:02:06,850 --> 00:02:08,460
+it might be worth it to go back to
+
+43
+00:02:08,460 --> 00:02:11,390
+mini course number one, lesson number two to discuss the
+
+44
+00:02:11,390 --> 00:02:14,620
+life cycle models. Because we talk about iterative approaches
+
+45
+00:02:14,620 --> 00:02:17,770
+and their advantages and their characteristics there in some detail.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/16 - Inception Phase - lang_en_vs4.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/16 - Inception Phase - lang_en_vs4.srt
new file mode 100644
index 0000000..60ab80a
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/16 - Inception Phase - lang_en_vs4.srt	
@@ -0,0 +1,323 @@
+1
+00:00:00,175 --> 00:00:03,510
+Let's talk a little bit more about phases. The rational unified
+
+2
+00:00:03,510 --> 00:00:07,050
+process phases are fundamental aspects of this process and which just touched
+
+3
+00:00:07,050 --> 00:00:09,200
+on them so we just give a quick overview. And I want to
+
+4
+00:00:09,200 --> 00:00:12,010
+look at these phases in a little more detail. So, what I'm
+
+5
+00:00:12,010 --> 00:00:14,960
+going to do is, for each phase, I'm going to discuss what it is,
+
+6
+00:00:14,960 --> 00:00:18,310
+what it produces and how is the result of the phase suppose
+
+7
+00:00:18,310 --> 00:00:21,910
+to be,. Assessed, and what are the consequences of this assessment. So
+
+8
+00:00:21,910 --> 00:00:25,350
+let's start with the first phase, the inception phase. The first phase
+
+9
+00:00:25,350 --> 00:00:27,920
+goes from the idea of the product to the
+
+10
+00:00:27,920 --> 00:00:30,990
+vision of the end product. What this involves is basically
+
+11
+00:00:30,990 --> 00:00:34,230
+to delimiting the project scope. And making the business case
+
+12
+00:00:34,230 --> 00:00:37,040
+for the product presented. Why is it worth doing? What
+
+13
+00:00:37,040 --> 00:00:39,870
+are the success criteria? What are the main risks? What
+
+14
+00:00:39,870 --> 00:00:43,690
+resources will be needed? And so on, specifically these phases
+
+15
+00:00:43,690 --> 00:00:47,310
+answer three main questions. The first one is, what are
+
+16
+00:00:47,310 --> 00:00:51,330
+the major users or actors, to use the UML terminology.
+
+17
+00:00:51,330 --> 00:00:53,450
+And what will the system do for them? To
+
+18
+00:00:53,450 --> 00:00:56,780
+answer this, these phases produce a simplified use-case model where
+
+19
+00:00:56,780 --> 00:01:00,480
+only a few use-cases are represented and described. So this
+
+20
+00:01:00,480 --> 00:01:03,390
+is a sort of initial use-case model. The second question
+
+21
+00:01:03,390 --> 00:01:05,610
+is about the architecture, what could be an architecture
+
+22
+00:01:05,610 --> 00:01:08,370
+for the system? So in this phase we will normally
+
+23
+00:01:08,370 --> 00:01:12,420
+also develop a tentative architecture. So an initial architecture that
+
+24
+00:01:12,420 --> 00:01:16,540
+describes the most crucial subsystems. Finally this phase also answers
+
+25
+00:01:16,540 --> 00:01:18,890
+the question, what is the plan and how much
+
+26
+00:01:18,890 --> 00:01:21,620
+will it cost? To answer this question. This phase will
+
+27
+00:01:21,620 --> 00:01:24,930
+identify the main risks for the project and also produce
+
+28
+00:01:24,930 --> 00:01:28,600
+a rough plan with estimates for resources, initial planning for
+
+29
+00:01:28,600 --> 00:01:32,820
+the phases and dates and milestones. Specifically, the inception phase
+
+30
+00:01:32,820 --> 00:01:36,370
+generates several deliverables. It is very important that you pay
+
+31
+00:01:36,370 --> 00:01:39,600
+attention so that you understand what this deliberate approach are.
+
+32
+00:01:39,600 --> 00:01:42,320
+Starting from the first one, which is the vision document.
+
+33
+00:01:42,320 --> 00:01:44,800
+And this is a document that provides a general
+
+34
+00:01:44,800 --> 00:01:48,420
+vision of the core projects requirements, key features and main
+
+35
+00:01:48,420 --> 00:01:51,890
+constraints. Together with this, the inception phase also produces an
+
+36
+00:01:51,890 --> 00:01:54,900
+initial use case model, as I just mentioned. So this
+
+37
+00:01:54,900 --> 00:01:57,720
+is a use case model that includes an initial set
+
+38
+00:01:57,720 --> 00:02:00,670
+of use cases, and then will be later refined. Two
+
+39
+00:02:00,670 --> 00:02:04,300
+additional variables are the initial project glossary, which describes the
+
+40
+00:02:04,300 --> 00:02:07,330
+main terms, using the project and their meaning, and the
+
+41
+00:02:07,330 --> 00:02:10,229
+initial business case which includes business context. And
+
+42
+00:02:10,229 --> 00:02:13,470
+success criteria. Yet another deliverable for the inception phase
+
+43
+00:02:13,470 --> 00:02:15,770
+is the initial project plan, which shows the
+
+44
+00:02:15,770 --> 00:02:20,650
+phases, iterations, roles of the participants, schedule and initial
+
+45
+00:02:20,650 --> 00:02:23,610
+estimates. In addition, the inception phase also produces
+
+46
+00:02:23,610 --> 00:02:26,810
+a risk assessment document, which describes the main risks
+
+47
+00:02:26,810 --> 00:02:29,970
+and counters measures for this risk. Finally, and this
+
+48
+00:02:29,970 --> 00:02:32,430
+is an optional deliverable, in the sense that it,
+
+49
+00:02:32,430 --> 00:02:34,990
+it might or might not be produced, depending on the specific
+
+50
+00:02:34,990 --> 00:02:37,870
+project. As part of the inception phase we might also generate
+
+51
+00:02:37,870 --> 00:02:41,780
+1 or more prototypes. For example, we might develop prototypes to
+
+52
+00:02:41,780 --> 00:02:45,590
+address some specific risks that we have identified or to show some
+
+53
+00:02:45,590 --> 00:02:48,380
+specific aspect of the system of which we are unsure to
+
+54
+00:02:48,380 --> 00:02:51,910
+the stakeholders. So basically all the typical users of prototypes that
+
+55
+00:02:51,910 --> 00:02:54,600
+we discussed before. So when we're done with the inception phase
+
+56
+00:02:54,600 --> 00:02:58,300
+we hit the first milestone for the cycle we are currently performing.
+
+57
+00:02:58,300 --> 00:03:00,600
+And so there are some evaluation criteria that will tell
+
+58
+00:03:00,600 --> 00:03:03,640
+us whether we can consider the inception phase concluded or not.
+
+59
+00:03:03,640 --> 00:03:06,840
+And the first of this criteria is stakeholder concurrence, which
+
+60
+00:03:06,840 --> 00:03:10,510
+means that all the stakeholders must agree on the scope, definition,
+
+61
+00:03:10,510 --> 00:03:13,510
+and cost schedule estimates for the projects. The second criteria
+
+62
+00:03:13,510 --> 00:03:17,040
+needs requirements understanding, out of the initial primary use cases that
+
+63
+00:03:17,040 --> 00:03:20,380
+we have identified so far, the right one for our system.
+
+64
+00:03:20,380 --> 00:03:23,760
+And other criteria is the credibility of the cost schedule estimates,
+
+65
+00:03:23,760 --> 00:03:28,280
+the priorities, defined the risks identifies and the countermeasures for
+
+66
+00:03:28,280 --> 00:03:31,590
+those risks, and the development process that we're following. Finally, in
+
+67
+00:03:31,590 --> 00:03:34,000
+the case we produce prototypes as part of the inceptional
+
+68
+00:03:34,000 --> 00:03:37,520
+phase, this will also be evaluated and assessed to judge the
+
+69
+00:03:37,520 --> 00:03:39,960
+overall outcome of the phase. So what happens if the
+
+70
+00:03:39,960 --> 00:03:43,170
+project fails to pass this milestone? So if the outcome of
+
+71
+00:03:43,170 --> 00:03:46,020
+the inception phase is considered to be inadequate with respect
+
+72
+00:03:46,020 --> 00:03:48,642
+to one or more of these criteria. Well at this point,
+
+73
+00:03:48,642 --> 00:03:51,240
+since we're kind of an initial phase of the cycle
+
+74
+00:03:51,240 --> 00:03:54,370
+the project may be cancelled or considerably re-thought. So to
+
+75
+00:03:54,370 --> 00:03:57,610
+summarize all of these in one sentence the Inception Phase
+
+76
+00:03:57,610 --> 00:04:00,320
+is the phase in which we produce. Then you shall vision,
+
+77
+00:04:00,320 --> 00:04:04,750
+used case model, project plan, risk assessment and possibly, prototypes
+
+78
+00:04:04,750 --> 00:04:07,290
+for the project. And we have to make sure, that
+
+79
+00:04:07,290 --> 00:04:10,680
+all of this deliverables satisfy a set of criteria, so
+
+80
+00:04:10,680 --> 00:04:13,770
+that we can continue on the project. And otherwise, we'll either
+
+81
+00:04:13,770 --> 00:04:17,160
+cancel the project or rethink its scope, or other aspects of it.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/17 - Elaboration Phase - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/17 - Elaboration Phase - lang_en_vs5.srt
new file mode 100644
index 0000000..1025b2c
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/17 - Elaboration Phase - lang_en_vs5.srt	
@@ -0,0 +1,215 @@
+1
+00:00:00,350 --> 00:00:02,400
+Now that we've discussed the inception phase, let's move
+
+2
+00:00:02,400 --> 00:00:04,180
+on to the second phase of RUP, which is
+
+3
+00:00:04,180 --> 00:00:07,280
+the elaboration phase. And there are four main goals
+
+4
+00:00:07,280 --> 00:00:10,900
+and activities for the elaboration phase. Analyzing the problem domain
+
+5
+00:00:10,900 --> 00:00:13,690
+to get a better understanding of the domain. Establishing
+
+6
+00:00:13,690 --> 00:00:17,840
+a solid architectural foundation for the project. Eliminating the highest
+
+7
+00:00:17,840 --> 00:00:21,454
+risk elements which basically means addressing the most critical
+
+8
+00:00:21,454 --> 00:00:25,590
+use cases. And finally, refine the plan of activities and estimates
+
+9
+00:00:25,590 --> 00:00:28,250
+of resources to complete the project. The outcome
+
+10
+00:00:28,250 --> 00:00:31,310
+of the elaboration phase reflects these activities and also
+
+11
+00:00:31,310 --> 00:00:34,440
+in this case produces several artifacts. The first one
+
+12
+00:00:34,440 --> 00:00:38,700
+is an almost complete use case model with all use cases
+
+13
+00:00:38,700 --> 00:00:42,560
+and actors identified and most use case descriptions developed.
+
+14
+00:00:42,560 --> 00:00:44,070
+As part of this phase we also identify a
+
+15
+00:00:44,070 --> 00:00:47,550
+set of what we called supplementary requirements. So these
+
+16
+00:00:47,550 --> 00:00:50,685
+are basically all the requirements that are not associated
+
+17
+00:00:50,685 --> 00:00:53,483
+with a use case. And these sets includes in particular all
+
+18
+00:00:53,483 --> 00:00:56,110
+non-functional requirements such as security,
+
+19
+00:00:56,110 --> 00:00:58,630
+reliability, maintainability and so on. So
+
+20
+00:00:58,630 --> 00:01:00,770
+all the ones that are relevant for the system that
+
+21
+00:01:00,770 --> 00:01:02,280
+you're developing. We mentioned before
+
+22
+00:01:02,280 --> 00:01:04,410
+that the software architecture is developed
+
+23
+00:01:04,410 --> 00:01:07,220
+in an incremental way, so it's not created at once.
+
+24
+00:01:07,220 --> 00:01:09,650
+And this is exactly what happens in the elaboration phase, that
+
+25
+00:01:09,650 --> 00:01:12,990
+we take the initial architecture that was defined in the inception
+
+26
+00:01:12,990 --> 00:01:16,280
+phase and we refine it until we get to a software
+
+27
+00:01:16,280 --> 00:01:19,400
+architecture which is complete. And that is part of the
+
+28
+00:01:19,400 --> 00:01:22,410
+deliverables for this phase. And the list continues, so let
+
+29
+00:01:22,410 --> 00:01:25,020
+me make some room. In addition to producing a complete
+
+30
+00:01:25,020 --> 00:01:28,270
+architecture for our system, in the elaboration phase we also
+
+31
+00:01:28,270 --> 00:01:32,130
+define the lower-level design for the system. And, therefore, as
+
+32
+00:01:32,130 --> 00:01:35,560
+part of this phase, we produce as deliverables a design
+
+33
+00:01:35,560 --> 00:01:38,000
+model, and together with that, a complete set of test
+
+34
+00:01:38,000 --> 00:01:41,770
+cases, and an executable prototype. We also produce a revised
+
+35
+00:01:41,770 --> 00:01:44,390
+project plan. Now that we have more information about the
+
+36
+00:01:44,390 --> 00:01:47,120
+project we can refine the various estimates and the various
+
+37
+00:01:47,120 --> 00:01:50,020
+pieces of information in the project plan. And also an
+
+38
+00:01:50,020 --> 00:01:54,160
+updated risk assessment document. Finally, in this phase we also generate
+
+39
+00:01:54,160 --> 00:01:57,680
+a preliminary user manual that describes to the users how
+
+40
+00:01:57,680 --> 00:02:00,350
+the system can be used and should be used. So now
+
+41
+00:02:00,350 --> 00:02:03,630
+let's see what are the evaluation criteria for the elaboration
+
+42
+00:02:03,630 --> 00:02:06,880
+phase which is our second milestone. So I'm just going to list
+
+43
+00:02:06,880 --> 00:02:09,400
+them here. The first one is whether the vision
+
+44
+00:02:09,400 --> 00:02:12,620
+and the architecture are stable or they're still changing so
+
+45
+00:02:12,620 --> 00:02:15,680
+did we converge into a final complete vision for the
+
+46
+00:02:15,680 --> 00:02:18,620
+system? Does the prototype show that the major risks that
+
+47
+00:02:18,620 --> 00:02:22,090
+we have identified have been resolved or at least addressed
+
+48
+00:02:22,090 --> 00:02:25,390
+in this phase? Is the project plan sufficiently detailed and
+
+49
+00:02:25,390 --> 00:02:29,030
+accurate? Do all stakeholders agree that the vision can be
+
+50
+00:02:29,030 --> 00:02:32,320
+achieved with the current plan? Is the actual resource expenditure
+
+51
+00:02:32,320 --> 00:02:35,840
+versus the planned expenditure acceptable? So now we study consumer
+
+52
+00:02:35,840 --> 00:02:39,120
+resources and therefore we can check whether our estimates were
+
+53
+00:02:39,120 --> 00:02:41,964
+correct. And also in this case the project might be
+
+54
+00:02:41,964 --> 00:02:45,730
+cancelled or considerably reshaped if it fails to pass this milestone.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/18 - Construction Phase - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/18 - Construction Phase - lang_en_vs5.srt
new file mode 100644
index 0000000..70051fd
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/18 - Construction Phase - lang_en_vs5.srt	
@@ -0,0 +1,247 @@
+1
+00:00:00,230 --> 00:00:03,170
+So if the elaboration phase is successful, we then move
+
+2
+00:00:03,170 --> 00:00:06,560
+to the construction phase, which is our third phase. And
+
+3
+00:00:06,560 --> 00:00:09,550
+the construction phase is basically the phase in which most
+
+4
+00:00:09,550 --> 00:00:13,860
+of the actual development occurs. In short, all the features considered
+
+5
+00:00:13,860 --> 00:00:17,360
+are developed. So we'll continue with our car metaphor that
+
+6
+00:00:17,360 --> 00:00:19,310
+we used for the prototype. And in this case we
+
+7
+00:00:19,310 --> 00:00:22,390
+will have our complete car ready. Not only the features
+
+8
+00:00:22,390 --> 00:00:25,940
+are developed but they're also thoroughly tested. So we have performed
+
+9
+00:00:25,940 --> 00:00:29,490
+quality assurance. We have verified and validated the software,
+
+10
+00:00:29,490 --> 00:00:32,580
+the system and we know that it works correctly. Or
+
+11
+00:00:32,580 --> 00:00:34,620
+at least that it works correctly as far as
+
+12
+00:00:34,620 --> 00:00:37,850
+we can tell. So, in general, the construction phase is
+
+13
+00:00:37,850 --> 00:00:39,760
+the phase in which there is a shift in
+
+14
+00:00:39,760 --> 00:00:42,640
+emphasis from intellectual property development
+
+15
+00:00:42,640 --> 00:00:45,460
+to product development. From ideas
+
+16
+00:00:45,460 --> 00:00:47,650
+to products. So, what is the outcome of the
+
+17
+00:00:47,650 --> 00:00:51,250
+construction phase? Well, basically the construction phrase produces a product
+
+18
+00:00:51,250 --> 00:00:54,520
+that is ready to be deployed to the users. Specifically,
+
+19
+00:00:54,520 --> 00:00:57,570
+the phase generates the following outcomes. First of all, at the
+
+20
+00:00:57,570 --> 00:01:00,150
+end of this phase, all the use cases have been
+
+21
+00:01:00,150 --> 00:01:03,220
+realized with traceability information. What does that mean? It means that
+
+22
+00:01:03,220 --> 00:01:06,640
+not only all the functionality expressed by the use cases
+
+23
+00:01:06,640 --> 00:01:10,240
+have been implemented, but also that we have traceability information from
+
+24
+00:01:10,240 --> 00:01:13,530
+the use cases, to the different artifacts. So for example,
+
+25
+00:01:13,530 --> 00:01:16,780
+we know which part of the design realizes which use case.
+
+26
+00:01:16,780 --> 00:01:19,230
+We know which part of the implementation is related to a
+
+27
+00:01:19,230 --> 00:01:22,150
+given use case. Which use cases were derived from a use
+
+28
+00:01:22,150 --> 00:01:24,390
+case, and so on and so forth. And in this way
+
+29
+00:01:24,390 --> 00:01:28,310
+we can trace our requirements throughout the system. Throughout the different
+
+30
+00:01:28,310 --> 00:01:32,162
+artifacts that were developed during the software process. As we were
+
+31
+00:01:32,162 --> 00:01:35,790
+saying, we also have complete software product here, which is integrated
+
+32
+00:01:35,790 --> 00:01:39,240
+on all the needed platforms. Since the system, the software product,
+
+33
+00:01:39,240 --> 00:01:42,200
+has to be thoroughly tested, we will also have a complete
+
+34
+00:01:42,200 --> 00:01:44,900
+set of results for our tests. As part of this
+
+35
+00:01:44,900 --> 00:01:47,980
+phase, we will also finalize the user manual, so you'll have
+
+36
+00:01:47,980 --> 00:01:51,050
+a user manual ready to be provided to the users, and
+
+37
+00:01:51,050 --> 00:01:53,700
+ready to be used. And finally, we will have a complete
+
+38
+00:01:53,700 --> 00:01:58,370
+set of artifacts that include design documents, code, test cases, and
+
+39
+00:01:58,370 --> 00:02:00,440
+so on and so forth, so basically all of the artifacts
+
+40
+00:02:00,440 --> 00:02:04,240
+that have been produced during the development process. So roughly speaking,
+
+41
+00:02:04,240 --> 00:02:07,280
+we can consider the product that is produced at the end
+
+42
+00:02:07,280 --> 00:02:10,570
+of this phase as a typical beta release. So in case
+
+43
+00:02:10,570 --> 00:02:12,920
+you're not familiar with that, a beta release is an initial
+
+44
+00:02:12,920 --> 00:02:16,050
+release normally meant for a selected subset of users. So it
+
+45
+00:02:16,050 --> 00:02:19,250
+is something that is not quite yet ready for primetime, but
+
+46
+00:02:19,250 --> 00:02:22,540
+almost. So let's see also in this case, what are the evaluation
+
+47
+00:02:22,540 --> 00:02:25,740
+criteria for the construction phase. So how do we assess, that
+
+48
+00:02:25,740 --> 00:02:29,620
+this third milestone has been accomplished, successfully? We pretty much have
+
+49
+00:02:29,620 --> 00:02:32,510
+a complete product ready to be shipped right? So the first question
+
+50
+00:02:32,510 --> 00:02:35,260
+we want to ask is, whether the product is stable and mature
+
+51
+00:02:35,260 --> 00:02:37,910
+enough to be deployed to users. At the end of this
+
+52
+00:02:37,910 --> 00:02:40,510
+phase it has to be. Are the stakeholders ready for the
+
+53
+00:02:40,510 --> 00:02:44,160
+transition into the user community? Are we ready to go from development
+
+54
+00:02:44,160 --> 00:02:45,450
+to production? Are the actual
+
+55
+00:02:45,450 --> 00:02:48,060
+resource expenditures versus the planned expenditures
+
+56
+00:02:48,060 --> 00:02:50,890
+still acceptable? So what this means is that at this point we
+
+57
+00:02:50,890 --> 00:02:54,660
+can really assess whether our estimates were accurate enough with respect
+
+58
+00:02:54,660 --> 00:02:57,740
+to what we actually spent for the project up to this point.
+
+59
+00:02:57,740 --> 00:03:00,390
+So unless we can answer in a positive way to
+
+60
+00:03:00,390 --> 00:03:03,790
+all these questions, the transition might be postponed by one release.
+
+61
+00:03:03,790 --> 00:03:05,930
+Because that means that we're still not ready to go
+
+62
+00:03:05,930 --> 00:03:08,660
+to the market. We're still not ready to deploy our product.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt
new file mode 100644
index 0000000..e09b6fc
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt	
@@ -0,0 +1,231 @@
+1
+00:00:00,300 --> 00:00:02,080
+But if we are ready to go to the market,
+
+2
+00:00:02,080 --> 00:00:04,800
+if we are ready to deploy our product, then we can
+
+3
+00:00:04,800 --> 00:00:07,160
+move to the transition phase, which has mainly to do
+
+4
+00:00:07,160 --> 00:00:10,360
+with deployment and maintainence of a system. So what are the
+
+5
+00:00:10,360 --> 00:00:12,950
+main activities in the transition phase? As we discussed in
+
+6
+00:00:12,950 --> 00:00:16,280
+our initial lessons, in most real world cases, there are issues
+
+7
+00:00:16,280 --> 00:00:20,820
+that manifest themselves after deployment, when we release our software and
+
+8
+00:00:20,820 --> 00:00:22,870
+actual users interact with the
+
+9
+00:00:22,870 --> 00:00:26,230
+software. Specifically, users might report failures
+
+10
+00:00:26,230 --> 00:00:28,965
+that they experienced while using the system. So, what we call
+
+11
+00:00:28,965 --> 00:00:33,120
+bug reports. Or they might report improvements they might want to see
+
+12
+00:00:33,120 --> 00:00:36,798
+in the software. So typically these will be new feature requests. And
+
+13
+00:00:36,798 --> 00:00:40,270
+in addition, there might be issues that don't come necessarily from the
+
+14
+00:00:40,270 --> 00:00:42,734
+users but that are related to the fact that our system
+
+15
+00:00:42,734 --> 00:00:45,920
+has to operate, has to work in a new execution environment. For
+
+16
+00:00:45,920 --> 00:00:48,930
+example, the new version of an operating system, or the new version
+
+17
+00:00:48,930 --> 00:00:51,474
+of a set of libraries. When this happens, we have to address
+
+18
+00:00:51,474 --> 00:00:55,020
+these issues by performing maintenance. Specifically, corrective maintenance
+
+19
+00:00:55,020 --> 00:00:58,900
+for bug reports, perfective maintenance, for feature requests, and
+
+20
+00:00:58,900 --> 00:01:02,270
+adaptive maintenance, for environment changes. And the result of
+
+21
+00:01:02,270 --> 00:01:04,319
+this is that we will have a new release
+
+22
+00:01:04,319 --> 00:01:06,550
+of the software. Other activities that are performed in
+
+23
+00:01:06,550 --> 00:01:10,480
+this phase include training, customer service, and providing help-line
+
+24
+00:01:10,480 --> 00:01:13,350
+assistance. Finally, if you remember what we saw when
+
+25
+00:01:13,350 --> 00:01:16,810
+we were looking at the banking IT system example,
+
+26
+00:01:16,810 --> 00:01:21,300
+the cycles within a development are not necessarily completely dis-joined, but
+
+27
+00:01:21,300 --> 00:01:23,940
+they might overlap a little bit. So something else that might
+
+28
+00:01:23,940 --> 00:01:26,650
+happen in the transition phase is that a new cycle may
+
+29
+00:01:26,650 --> 00:01:29,020
+start. So there might be some activities that are related to
+
+30
+00:01:29,020 --> 00:01:32,190
+the fact that we're starting to think about the new cycle.
+
+31
+00:01:32,190 --> 00:01:35,150
+So now let's see what kind of outcome these activities will
+
+32
+00:01:35,150 --> 00:01:38,410
+produce. The first one is a complete project with all the
+
+33
+00:01:38,410 --> 00:01:41,820
+artifacts that we mentioned before. Another outcome is that the product will
+
+34
+00:01:41,820 --> 00:01:44,090
+be actually in use. So the product will be in the
+
+35
+00:01:44,090 --> 00:01:46,870
+hands of the users and the users will start using it, will
+
+36
+00:01:46,870 --> 00:01:49,760
+start interacting with it, for real, not just in a beta testing
+
+37
+00:01:49,760 --> 00:01:53,260
+setting. Another outcome will be a lesson learnt. What worked. What didn't
+
+38
+00:01:53,260 --> 00:01:56,240
+work. What should we do different in the next cycle or in
+
+39
+00:01:56,240 --> 00:01:59,446
+the next development? And this is a very important part of the
+
+40
+00:01:59,446 --> 00:02:01,651
+whole process, because it;s what provides
+
+41
+00:02:01,651 --> 00:02:04,378
+feedback between cycles, and between projects.
+
+42
+00:02:04,378 --> 00:02:07,018
+And as we said before, in case we have a next released
+
+43
+00:02:07,018 --> 00:02:09,478
+planned or a next cycle coming up, we might want to
+
+44
+00:02:09,478 --> 00:02:12,922
+start planning for the next release. So another outcome will be
+
+45
+00:02:12,922 --> 00:02:15,783
+the plan for the next release. So similar to the other
+
+46
+00:02:15,783 --> 00:02:19,147
+phases, also for the transition phase, we have a milestone, which
+
+47
+00:02:19,147 --> 00:02:21,733
+is the fourth milestone in this case. And therefore we
+
+48
+00:02:21,733 --> 00:02:25,061
+have evaluation criteria for the transition phase that will define whether
+
+49
+00:02:25,061 --> 00:02:28,530
+we've reached the milestone or not. And in this case, one
+
+50
+00:02:28,530 --> 00:02:32,040
+important assessment is whether the user is satisfied. So users are
+
+51
+00:02:32,040 --> 00:02:34,370
+actually using our product now, so we can get feedback
+
+52
+00:02:34,370 --> 00:02:36,260
+from them, we can see whether the product makes them
+
+53
+00:02:36,260 --> 00:02:40,390
+happy or not. And we continue assessing whether our expenditures
+
+54
+00:02:40,390 --> 00:02:43,460
+are fine with respect to our estimates. And in this case,
+
+55
+00:02:43,460 --> 00:02:46,882
+problems with this milestone might lead to further maintenance of
+
+56
+00:02:46,882 --> 00:02:48,840
+the system. So for example, we might need to produce
+
+57
+00:02:48,840 --> 00:02:51,460
+a new release to address some of the issues that
+
+58
+00:02:51,460 --> 00:02:54,410
+the users identified, as we discussed a couple of minutes ago.
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.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/20 - Phases and Iterations - lang_en_vs4.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/20 - Phases and Iterations - lang_en_vs4.srt
new file mode 100644
index 0000000..01689f9
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/20 - Phases and Iterations - lang_en_vs4.srt	
@@ -0,0 +1,107 @@
+1
+00:00:00,170 --> 00:00:02,210
+So now I would like to wrap up this lesson
+
+2
+00:00:02,210 --> 00:00:05,720
+by going back to our discussion of rational unified process
+
+3
+00:00:05,720 --> 00:00:08,630
+phases and iterations. So to do that I'm going to bring
+
+4
+00:00:08,630 --> 00:00:12,480
+back the presentation that I used before, the summary representation
+
+5
+00:00:12,480 --> 00:00:16,840
+about phases and traditional software engineering activities. And I want to
+
+6
+00:00:16,840 --> 00:00:19,720
+use this representation to stress and discuss a couple of
+
+7
+00:00:19,720 --> 00:00:22,140
+things. Mainly I want to recap it because I think
+
+8
+00:00:22,140 --> 00:00:25,480
+it is very important. What is the relation between the rational
+
+9
+00:00:25,480 --> 00:00:29,270
+unified process, and the traditional software engineering phases, and software
+
+10
+00:00:29,270 --> 00:00:31,540
+engineering activities? And I like to do it now that
+
+11
+00:00:31,540 --> 00:00:33,648
+we have discussed the phases in a little more detail.
+
+12
+00:00:33,648 --> 00:00:35,920
+So I want to make sure that it is clear by now
+
+13
+00:00:35,920 --> 00:00:39,660
+how and when the traditional software engineering activities, the ones
+
+14
+00:00:39,660 --> 00:00:42,620
+listed here, take place in the context of the RUP
+
+15
+00:00:42,620 --> 00:00:45,850
+phases, the four listed up here. For instance, it should
+
+16
+00:00:45,850 --> 00:00:50,410
+be clear why implementation takes place mainly in the construction phase.
+
+17
+00:00:50,410 --> 00:00:54,140
+Why requirements engineering is prominent in the elaboration phase
+
+18
+00:00:54,140 --> 00:00:58,290
+and why deployment activities occur mostly in the transition phase,
+
+19
+00:00:58,290 --> 00:01:00,120
+and so on. So it should be clear now
+
+20
+00:01:00,120 --> 00:01:03,930
+why the activities are so distributed in the four phases.
+
+21
+00:01:03,930 --> 00:01:06,130
+It should also be clear that although there is
+
+22
+00:01:06,130 --> 00:01:09,350
+normally one main phase for each activity, the activities really
+
+23
+00:01:09,350 --> 00:01:12,550
+span multiple phases. Which is actually one of the interesting
+
+24
+00:01:12,550 --> 00:01:15,580
+aspect of RUP. So the fact that you're not really
+
+25
+00:01:15,580 --> 00:01:19,700
+done with an activity even in later phases. Why? Well, because that allows
+
+26
+00:01:19,700 --> 00:01:22,070
+you, in subsequent iterations, to address
+
+27
+00:01:22,070 --> 00:01:24,370
+problems that came up in previous iterations.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/3 - Key Features of RUP - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/3 - Key Features of RUP - lang_en_vs6.srt
new file mode 100644
index 0000000..74dc52a
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/3 - Key Features of RUP - lang_en_vs6.srt	
@@ -0,0 +1,103 @@
+1
+00:00:00,300 --> 00:00:03,450
+So let's start by seeing how these activities and principles
+
+2
+00:00:03,450 --> 00:00:06,640
+are reflected in the key features of the Rational Unified
+
+3
+00:00:06,640 --> 00:00:10,010
+Process. First of all, the Rational Unified Process is a
+
+4
+00:00:10,010 --> 00:00:13,700
+software process model. So if you recall our introductory lessons,
+
+5
+00:00:13,700 --> 00:00:16,670
+that means two main things. The first one is that
+
+6
+00:00:16,670 --> 00:00:19,200
+it defines an order of phases that have to be
+
+7
+00:00:19,200 --> 00:00:21,970
+followed in the software process. And the second thing is
+
+8
+00:00:21,970 --> 00:00:25,420
+that it also prescribes transition criteria, so when to go
+
+9
+00:00:25,420 --> 00:00:28,030
+from one phase to the next. The second key
+
+10
+00:00:28,030 --> 00:00:31,290
+feature of RUP is that it is component based. And
+
+11
+00:00:31,290 --> 00:00:33,810
+also in this case, this implies two main things.
+
+12
+00:00:33,810 --> 00:00:36,410
+The first one is that a software system is defined
+
+13
+00:00:36,410 --> 00:00:39,420
+and built as a set of software components. So
+
+14
+00:00:39,420 --> 00:00:43,110
+software components are the building blocks of our software system.
+
+15
+00:00:43,110 --> 00:00:45,550
+And the second one is that there must be well-defined
+
+16
+00:00:45,550 --> 00:00:48,440
+interfaces between these components, interfaces
+
+17
+00:00:48,440 --> 00:00:50,750
+through which these components communicate.
+
+18
+00:00:50,750 --> 00:00:53,020
+In addition, the Rational Unified Process is
+
+19
+00:00:53,020 --> 00:00:56,080
+tightly related to UML. And in particular, it
+
+20
+00:00:56,080 --> 00:00:58,820
+relies extensively on UML for its notation, and
+
+21
+00:00:58,820 --> 00:01:02,120
+with respect to its basic principles. Finally, the
+
+22
+00:01:02,120 --> 00:01:05,140
+three main distinguishing aspects of the Rational Unified
+
+23
+00:01:05,140 --> 00:01:09,830
+Process are that it is use-case driven, architecture-centric
+
+24
+00:01:09,830 --> 00:01:12,680
+and iterative and incremental. So let's now look
+
+25
+00:01:12,680 --> 00:01:15,565
+in more detail at these three distinguishing aspects,
+
+26
+00:01:15,565 --> 00:01:17,540
+and we're going to look at each one of them individually.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/4 - UML Quiz - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/4 - UML Quiz - lang_en_vs5.srt
new file mode 100644
index 0000000..4f4af17
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/4 - UML Quiz - lang_en_vs5.srt	
@@ -0,0 +1,47 @@
+1
+00:00:00,160 --> 00:00:03,440
+Before doing that though, let's have a quiz to check whether you remember
+
+2
+00:00:03,440 --> 00:00:07,160
+the basics of UML. Since we're going to talk about use cases, I want
+
+3
+00:00:07,160 --> 00:00:10,040
+to ask you, what is the difference between a use case and a
+
+4
+00:00:10,040 --> 00:00:13,330
+use case model. So here are the possible answers, and you can mark
+
+5
+00:00:13,330 --> 00:00:16,710
+more than one. First one is that only use case models include actors.
+
+6
+00:00:16,710 --> 00:00:19,150
+The second is that they are the same thing. The third one is
+
+7
+00:00:19,150 --> 00:00:22,000
+that a use case model is a set of use cases. The fourth
+
+8
+00:00:22,000 --> 00:00:24,950
+one says that a use case is a set of use case models.
+
+9
+00:00:24,950 --> 00:00:26,520
+Finally, the last one says that use cases
+
+10
+00:00:26,520 --> 00:00:29,650
+are a dynamic representation, whereas use case models
+
+11
+00:00:29,650 --> 00:00:31,880
+are a static representation of a system. So
+
+12
+00:00:31,880 --> 00:00:33,810
+mark all the answers that you think are correct.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/5 - UML Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/5 - UML Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..c107545
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/5 - UML Quiz Solution - lang_en_vs4.srt	
@@ -0,0 +1,15 @@
+1
+00:00:00,150 --> 00:00:02,350
+And the correct answer, in this case it's only one,
+
+2
+00:00:02,350 --> 00:00:04,720
+is that a use case model is a set of use
+
+3
+00:00:04,720 --> 00:00:07,390
+cases. So a use case model is simply a collection of
+
+4
+00:00:07,390 --> 00:00:10,790
+use cases that represent different pieces of functionality for the system.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/6 - UML Quiz - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/6 - UML Quiz - lang_en_vs6.srt
new file mode 100644
index 0000000..c2627aa
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/6 - UML Quiz - lang_en_vs6.srt	
@@ -0,0 +1,39 @@
+1
+00:00:00,330 --> 00:00:02,650
+So, since we are talking about use case diagrams, I also want
+
+2
+00:00:02,650 --> 00:00:05,593
+to ask you, what are use case diagrams used for? So, what
+
+3
+00:00:05,593 --> 00:00:08,600
+are they good for? Why are they useful within a software process?
+
+4
+00:00:08,600 --> 00:00:12,130
+Also in this case, I'm providing several possible answers. They are not really
+
+5
+00:00:12,130 --> 00:00:15,420
+used for anything. Or, they can be used to prioritize requirements. Or,
+
+6
+00:00:15,420 --> 00:00:18,220
+maybe they can be used for user interface design. They can be
+
+7
+00:00:18,220 --> 00:00:20,280
+used during requirements elicitation. They can
+
+8
+00:00:20,280 --> 00:00:21,890
+be used for code optimization. And
+
+9
+00:00:21,890 --> 00:00:25,570
+finally, they can be used for test case design. Also, in this case,
+
+10
+00:00:25,570 --> 00:00:28,650
+I would like you to mark all the answers that you think are correct.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/7 - UML Quiz Solution - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/7 - UML Quiz Solution - lang_en_vs6.srt
new file mode 100644
index 0000000..c201e96
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/7 - UML Quiz Solution - lang_en_vs6.srt	
@@ -0,0 +1,143 @@
+1
+00:00:00,140 --> 00:00:02,910
+In this case there are multiple, correct answers. So you should have
+
+2
+00:00:02,910 --> 00:00:05,800
+marked several of those. So let's go through the list. Well this
+
+3
+00:00:05,800 --> 00:00:08,970
+is definitely not true. They are used for something. The second answer,
+
+4
+00:00:08,970 --> 00:00:11,880
+is a correct one, because you can order, the use cases that
+
+5
+00:00:11,880 --> 00:00:13,320
+you planned to realize, according to
+
+6
+00:00:13,320 --> 00:00:15,580
+your prioritization criteria. So basically what
+
+7
+00:00:15,580 --> 00:00:19,100
+you're doing you're prioritizing either in terms of functionality. So you, you
+
+8
+00:00:19,100 --> 00:00:21,680
+can decide which piece of functionality you want to realize first in
+
+9
+00:00:21,680 --> 00:00:25,430
+your system. Or you can also prioritize based on the actors involved.
+
+10
+00:00:25,430 --> 00:00:27,530
+Maybe there are some actors, maybe there are some user
+
+11
+00:00:27,530 --> 00:00:30,580
+roles that you want to support before others, and we'll
+
+12
+00:00:30,580 --> 00:00:33,580
+see some examples of that. The next correct question is
+
+13
+00:00:33,580 --> 00:00:37,190
+that they can be used for requirements elicitation. Why? Well
+
+14
+00:00:37,190 --> 00:00:40,130
+because used cases express what the system is supposed to
+
+15
+00:00:40,130 --> 00:00:43,490
+do for each user. They're an ideal way to collect,
+
+16
+00:00:43,490 --> 00:00:47,110
+represent, and check functional requirements. And we'll also get back
+
+17
+00:00:47,110 --> 00:00:50,700
+to this. And finally, use cases can definitely be used
+
+18
+00:00:50,700 --> 00:00:54,160
+for test case design. So why is that? Because each
+
+19
+00:00:54,160 --> 00:00:58,500
+use case represents a scenario of interaction between users and the
+
+20
+00:00:58,500 --> 00:01:03,470
+system. So testers can very naturally construct test cases based
+
+21
+00:01:03,470 --> 00:01:06,570
+on use cases. And in addition, and most importantly, they can
+
+22
+00:01:06,570 --> 00:01:09,320
+do that even in the absence of code that realizes
+
+23
+00:01:09,320 --> 00:01:11,490
+a use case. So they can do it as soon as
+
+24
+00:01:11,490 --> 00:01:13,740
+they have the requirements. They don't have to wait until the
+
+25
+00:01:13,740 --> 00:01:16,150
+code is ready. So this is not very a important point.
+
+26
+00:01:16,150 --> 00:01:18,400
+So you can have your test cases ready even before
+
+27
+00:01:18,400 --> 00:01:21,150
+writing the code. And now for completeness. Even though this is
+
+28
+00:01:21,150 --> 00:01:23,787
+not listed in the quiz. I also want to mention two
+
+29
+00:01:23,787 --> 00:01:27,040
+additional uses for use cases. The first one is that use
+
+30
+00:01:27,040 --> 00:01:30,080
+cases can be used to estimate effort as we will discuss
+
+31
+00:01:30,080 --> 00:01:32,710
+in more detail in mini course four, when we talk about
+
+32
+00:01:32,710 --> 00:01:35,770
+agile software development. And they can also be used by
+
+33
+00:01:35,770 --> 00:01:38,290
+customers to assess requirements. Which
+
+34
+00:01:38,290 --> 00:01:41,170
+is another fundamentally important role of
+
+35
+00:01:41,170 --> 00:01:44,640
+the use cases. They provide a common language between the customers
+
+36
+00:01:44,640 --> 00:01:47,850
+and the developers which makes it easier to collect the right requirements.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/8 - Use Case Driven - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/8 - Use Case Driven - lang_en_vs5.srt
new file mode 100644
index 0000000..14ddaab
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/8 - Use Case Driven - lang_en_vs5.srt	
@@ -0,0 +1,71 @@
+1
+00:00:00,150 --> 00:00:02,370
+Now let's go back to the distinguishing aspects of
+
+2
+00:00:02,370 --> 00:00:04,710
+RUP, starting from the first one. That is, that the
+
+3
+00:00:04,710 --> 00:00:08,170
+rational unified process is use-case driven. So let's see what
+
+4
+00:00:08,170 --> 00:00:11,310
+that means. Generally speaking, we can see a system as
+
+5
+00:00:11,310 --> 00:00:14,500
+something that performs a sequence of actions in response to
+
+6
+00:00:14,500 --> 00:00:18,100
+user inputs. So the user submits some requests, or requests
+
+7
+00:00:18,100 --> 00:00:22,140
+some functionality, and the system responds to those requests. Use
+
+8
+00:00:22,140 --> 00:00:25,750
+cases, as we just said, capture exactly this interaction and
+
+9
+00:00:25,750 --> 00:00:28,620
+answer the question, what is the system supposed to do
+
+10
+00:00:28,620 --> 00:00:32,150
+for each user? So, this is a very important point.
+
+11
+00:00:32,150 --> 00:00:34,160
+So they can represent what a system can do for
+
+12
+00:00:34,160 --> 00:00:37,240
+each of the different types of users of the system.
+
+13
+00:00:37,240 --> 00:00:39,430
+For this reason, and as we will see in more
+
+14
+00:00:39,430 --> 00:00:42,430
+detail, in the rational unified process, use cases are a
+
+15
+00:00:42,430 --> 00:00:46,680
+central element of the whole development life cycle. From requirements
+
+16
+00:00:46,680 --> 00:00:51,360
+engineering, all the way through the process until testing and maintenance.
+
+17
+00:00:51,360 --> 00:00:54,620
+So, once more, use cases are used to support and
+
+18
+00:00:54,620 --> 00:00:58,162
+help each one of these phases in the rational unified process.
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/9 - Architecture Centric - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/9 - Architecture Centric - lang_en_vs5.srt
new file mode 100644
index 0000000..b0f5487
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/9 - Architecture Centric - lang_en_vs5.srt	
@@ -0,0 +1,131 @@
+1
+00:00:00,180 --> 00:00:02,760
+The second distinguishing aspect of RUP is that it
+
+2
+00:00:02,760 --> 00:00:06,290
+is architecture-centric. As we saw in the first lesson
+
+3
+00:00:06,290 --> 00:00:09,340
+of this mini-course, a software architecture is a view
+
+4
+00:00:09,340 --> 00:00:12,740
+of the entire system that represents all high level
+
+5
+00:00:12,740 --> 00:00:15,710
+principal design decisions. Another way to see this is
+
+6
+00:00:15,710 --> 00:00:18,640
+by saying that use cases define the function of
+
+7
+00:00:18,640 --> 00:00:22,220
+the system, where as architecture defines the form of
+
+8
+00:00:22,220 --> 00:00:25,260
+the system. Use cases give the functionality, architecture tells
+
+9
+00:00:25,260 --> 00:00:28,670
+you how the system should be structured to provide the functionality.
+
+10
+00:00:28,670 --> 00:00:31,000
+So how do we define a software architecture in the rational
+
+11
+00:00:31,000 --> 00:00:33,730
+unified process. Also in this case this happens through
+
+12
+00:00:33,730 --> 00:00:37,340
+a sort of a iterative process. We start by creating a rough
+
+13
+00:00:37,340 --> 00:00:40,070
+outline of the system. And in this case we do it
+
+14
+00:00:40,070 --> 00:00:44,260
+independently from the functionality. So this is just the general structure
+
+15
+00:00:44,260 --> 00:00:46,770
+of the system. For example, we model aspects such as the
+
+16
+00:00:46,770 --> 00:00:50,840
+platform on which the system will run, the overall style. For example,
+
+17
+00:00:50,840 --> 00:00:52,780
+whether it's a client server or a peer to peer
+
+18
+00:00:52,780 --> 00:00:56,450
+system and so on. We then use the key use cases
+
+19
+00:00:56,450 --> 00:01:00,550
+in our use case diagram to define the main subsystems of
+
+20
+00:01:00,550 --> 00:01:03,470
+my architecture. For example, in the case of a banking IT
+
+21
+00:01:03,470 --> 00:01:07,150
+system, one of these subsystems might be the withdrawal system. So
+
+22
+00:01:07,150 --> 00:01:09,410
+what will happen in that case is that we will have
+
+23
+00:01:09,410 --> 00:01:13,240
+some use case that refers to the withdrawal activity, and by
+
+24
+00:01:13,240 --> 00:01:16,470
+analyzing that use case, we'll realize that we need a subsystem
+
+25
+00:01:16,470 --> 00:01:19,810
+that implements that piece of functionality. So again, we use
+
+26
+00:01:19,810 --> 00:01:22,680
+the key use cases to identify and define the key
+
+27
+00:01:22,680 --> 00:01:26,290
+subsystems for my architecture. So once we have that we
+
+28
+00:01:26,290 --> 00:01:30,510
+keep refining the architecture by using additional use cases. So
+
+29
+00:01:30,510 --> 00:01:33,030
+considering more and more pieces of functionality that will help
+
+30
+00:01:33,030 --> 00:01:35,430
+us to refine the architecture of the system and also
+
+31
+00:01:35,430 --> 00:01:39,260
+leveraging our increasing understanding of the system that we're modeling.
+
+32
+00:01:39,260 --> 00:01:41,470
+And this will continue until we are happy with the
+
+33
+00:01:41,470 --> 00:01:42,550
+architecture that we define.
-- 
cgit 1.4.1