diff options
Diffstat (limited to 'usth/ICT2.7/P3L4 Unified Software Process Subtitles')
20 files changed, 0 insertions, 2628 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 deleted file mode 100644 index 4abf070..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/1 - Lesson Overview - lang_en_vs4.srt +++ /dev/null @@ -1,31 +0,0 @@ -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 deleted file mode 100644 index e542660..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/10 - Iterative and Incremental - lang_en_vs6.srt +++ /dev/null @@ -1,147 +0,0 @@ -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 deleted file mode 100644 index af70543..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/11 - Cycle Example - lang_en_vs6.srt +++ /dev/null @@ -1,147 +0,0 @@ -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 deleted file mode 100644 index c58be49..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/12 - Phases within a Cycle - lang_en_vs5.srt +++ /dev/null @@ -1,199 +0,0 @@ -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 deleted file mode 100644 index fbdc2b0..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/13 - Iterations - lang_en_vs5.srt +++ /dev/null @@ -1,95 +0,0 @@ -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 deleted file mode 100644 index d4b7808..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/14 - Iterative Approach Quiz - lang_en_vs5.srt +++ /dev/null @@ -1,43 +0,0 @@ -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 deleted file mode 100644 index 6e69cec..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/15 - Iterative Approach Quiz Solution - lang_en_vs5.srt +++ /dev/null @@ -1,179 +0,0 @@ -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 deleted file mode 100644 index 60ab80a..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/16 - Inception Phase - lang_en_vs4.srt +++ /dev/null @@ -1,323 +0,0 @@ -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 deleted file mode 100644 index 1025b2c..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/17 - Elaboration Phase - lang_en_vs5.srt +++ /dev/null @@ -1,215 +0,0 @@ -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 deleted file mode 100644 index 70051fd..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/18 - Construction Phase - lang_en_vs5.srt +++ /dev/null @@ -1,247 +0,0 @@ -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 deleted file mode 100644 index e09b6fc..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt +++ /dev/null @@ -1,231 +0,0 @@ -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 deleted file mode 100644 index 83a656b..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt +++ /dev/null @@ -1,115 +0,0 @@ -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 deleted file mode 100644 index 01689f9..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/20 - Phases and Iterations - lang_en_vs4.srt +++ /dev/null @@ -1,107 +0,0 @@ -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 deleted file mode 100644 index 74dc52a..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/3 - Key Features of RUP - lang_en_vs6.srt +++ /dev/null @@ -1,103 +0,0 @@ -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 deleted file mode 100644 index 4f4af17..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/4 - UML Quiz - lang_en_vs5.srt +++ /dev/null @@ -1,47 +0,0 @@ -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 deleted file mode 100644 index c107545..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/5 - UML Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,15 +0,0 @@ -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 deleted file mode 100644 index c2627aa..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/6 - UML Quiz - lang_en_vs6.srt +++ /dev/null @@ -1,39 +0,0 @@ -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 deleted file mode 100644 index c201e96..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/7 - UML Quiz Solution - lang_en_vs6.srt +++ /dev/null @@ -1,143 +0,0 @@ -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 deleted file mode 100644 index 14ddaab..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/8 - Use Case Driven - lang_en_vs5.srt +++ /dev/null @@ -1,71 +0,0 @@ -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 deleted file mode 100644 index b0f5487..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/9 - Architecture Centric - lang_en_vs5.srt +++ /dev/null @@ -1,131 +0,0 @@ -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. |