diff options
Diffstat (limited to 'usth/ICT2.7/P3L4 Unified Software Process Subtitles')
20 files changed, 2628 insertions, 0 deletions
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. |