diff options
Diffstat (limited to 'usth/ICT2.7/P1L2 Life Cycle Models Subtitles')
30 files changed, 0 insertions, 3030 deletions
diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/1 - Introduction with Barry Boehm - lang_en_vs7.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/1 - Introduction with Barry Boehm - lang_en_vs7.srt deleted file mode 100644 index 954db98..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/1 - Introduction with Barry Boehm - lang_en_vs7.srt +++ /dev/null @@ -1,163 +0,0 @@ -1 -00:00:00,430 --> 00:00:06,300 -Hi, in the last lesson we provided an overview of the course and motivated the - -2 -00:00:06,300 --> 00:00:09,570 -need for software engineering. In this lesson, - -3 -00:00:09,570 --> 00:00:13,090 -we will present and start discussing several traditional - -4 -00:00:13,090 --> 00:00:16,090 -software engineering life cycle models. We will - -5 -00:00:16,090 --> 00:00:18,790 -talk about their main advantages, and also about - -6 -00:00:18,790 --> 00:00:21,840 -their shortcomings. We will also talk about - -7 -00:00:21,840 --> 00:00:25,720 -classic mistakes in software engineering that is well - -8 -00:00:25,720 --> 00:00:29,530 -known ineffective development practices, that when - -9 -00:00:29,530 --> 00:00:32,590 -followed, tend to lead to better results. And - -10 -00:00:32,590 --> 00:00:35,120 -covering those, will hopefully help us to avoid - -11 -00:00:35,120 --> 00:00:38,350 -them in the future. And because in this - -12 -00:00:38,350 --> 00:00:41,290 -lesson, I will discuss some fundamental aspects of - -13 -00:00:41,290 --> 00:00:44,730 -software engineering, to suitably introduce these topics, I - -14 -00:00:44,730 --> 00:00:47,110 -went to the University of Southern California, to - -15 -00:00:47,110 --> 00:00:50,300 -interview one of the fathers of software engineering; - -16 -00:00:50,300 --> 00:00:53,070 -Professor Barry Boehm. - -17 -00:00:53,070 --> 00:00:59,060 ->> A well, a software life cycle is a sequence of, of decisions that you - -18 -00:00:59,060 --> 00:01:01,895 -make, and it's fundamentally those decisions are - -19 -00:01:01,895 --> 00:01:05,280 -going to be part of the history of the - -20 -00:01:05,280 --> 00:01:09,500 -software that. You are going to build that other people are going to use, and - -21 -00:01:09,500 --> 00:01:15,330 -the process model is basically answering the question of what do I do next and - -22 -00:01:15,330 --> 00:01:20,550 -how long shall I do it for. And again, because there are a lot of different ways - -23 -00:01:20,550 --> 00:01:24,220 -you can make that decision, you need to - -24 -00:01:24,220 --> 00:01:27,640 -figure out which models are good for which particular - -25 -00:01:27,640 --> 00:01:31,475 -situations. So, for example, we've, written a book - -26 -00:01:31,475 --> 00:01:34,846 -that's called Balancing Agility and Discipline. It says under - -27 -00:01:34,846 --> 00:01:37,835 -what conditions should you use agile methods, under - -28 -00:01:37,835 --> 00:01:40,824 -which conditions should you invest more time in analyzing - -29 -00:01:40,824 --> 00:01:44,826 -the situation and planning what you're going to do and the like. And so, - -30 -00:01:44,826 --> 00:01:49,866 -typically if the project is, is small where it's three to ten - -31 -00:01:49,866 --> 00:01:55,271 -people, agile works pretty well. If it's 300 - -32 -00:01:55,271 --> 00:02:00,545 -people, then I think we don't want to go that way. If the affect of - -33 -00:02:00,545 --> 00:02:05,960 -the defect is loss of comfort or limited funds, then agile is fine, - -34 -00:02:05,960 --> 00:02:11,184 -but if it is a loss of life, then you don't. On the other hand if, if - -35 -00:02:11,184 --> 00:02:13,776 -you have a situation where you have lot - -36 -00:02:13,776 --> 00:02:17,745 -of unpredictable change, you really don't want to spend - -37 -00:02:17,745 --> 00:02:23,439 -a lot of time writing plans and lots of documents. In some cases you may have a - -38 -00:02:23,439 --> 00:02:26,907 -project where you want to do waterfall in - -39 -00:02:26,907 --> 00:02:31,140 -some parts and agile in others. So, these are - -40 -00:02:31,140 --> 00:02:36,180 -the kind of things that, that make the choice of life cycle process - -41 -00:02:36,180 --> 00:02:41,409 -model very important and very interesting as a subject of research. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/10 - Software Process Model Introduction - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/10 - Software Process Model Introduction - lang_en_vs4.srt deleted file mode 100644 index 39d418b..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/10 - Software Process Model Introduction - lang_en_vs4.srt +++ /dev/null @@ -1,79 +0,0 @@ -1 -00:00:00,240 --> 00:00:02,600 -At this point, you know the possible activities, the - -2 -00:00:02,600 --> 00:00:06,520 -possible phases performed during the software development process. But there - -3 -00:00:06,520 --> 00:00:08,710 -this something that we still haven't discussed, which is - -4 -00:00:08,710 --> 00:00:11,910 -very important. And that is how should we put these - -5 -00:00:11,910 --> 00:00:14,990 -activities together to develop software? And this all comes - -6 -00:00:14,990 --> 00:00:18,360 -down to the concept of software process model. Also called - -7 -00:00:18,360 --> 00:00:21,520 -software lifecycle model. And what this is, is a - -8 -00:00:21,520 --> 00:00:25,470 -prescriptive model of what should happen from the very beginning - -9 -00:00:25,470 --> 00:00:28,960 -to the very end. Of a software development process. The - -10 -00:00:28,960 --> 00:00:31,360 -main function of the life cycle model is to determine - -11 -00:00:31,360 --> 00:00:34,290 -the order of the different activities so that we know - -12 -00:00:34,290 --> 00:00:37,920 -which activities should come first and which ones should follow. Another - -13 -00:00:37,920 --> 00:00:40,910 -important function of the life cycle model is to determine - -14 -00:00:40,910 --> 00:00:45,290 -the transition criteria between activities. So, when we can go from - -15 -00:00:45,290 --> 00:00:48,000 -one phase to the subsequent one. In other words, what - -16 -00:00:48,000 --> 00:00:50,840 -the model should describe is what should we do next and - -17 -00:00:50,840 --> 00:00:53,450 -how long should we continue to do it for each activity - -18 -00:00:53,450 --> 00:00:56,290 -in the model. Now lets see a few traditional software process - -19 -00:00:56,290 --> 00:00:58,920 -models. I will discuss them here at the high level and - -20 -00:00:58,920 --> 00:01:02,000 -then revisit some of these models in the different mini courses. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/11 - Waterfall Process - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/11 - Waterfall Process - lang_en_vs4.srt deleted file mode 100644 index b3d7c07..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/11 - Waterfall Process - lang_en_vs4.srt +++ /dev/null @@ -1,95 +0,0 @@ -1 -00:00:00,070 --> 00:00:02,830 -The first model we want to discuss is the grandfather of - -2 -00:00:02,830 --> 00:00:05,900 -all life cycle models. And it is the waterfall model. In - -3 -00:00:05,900 --> 00:00:08,890 -the waterfall model the project progresses to an orderly sequence of - -4 -00:00:08,890 --> 00:00:13,040 -steps. From the initial software concept, down until the final phase. - -5 -00:00:13,040 --> 00:00:16,110 -Which is system testing. And at the end of each phase - -6 -00:00:16,110 --> 00:00:18,510 -there will be a review to determine whether the project is - -7 -00:00:18,510 --> 00:00:22,120 -ready to advance to the next phase. The pure waterfall model - -8 -00:00:22,120 --> 00:00:25,340 -performs well for softer products in which there is a stable - -9 -00:00:25,340 --> 00:00:28,400 -product definition. The domain is well known and the technologies - -10 -00:00:28,400 --> 00:00:31,220 -involved are well understood. In these kind of domains, the - -11 -00:00:31,220 --> 00:00:34,350 -waterfall model helps you to find errors in the early, - -12 -00:00:34,350 --> 00:00:37,180 -local stages of the projects. If you remember what we discussed, - -13 -00:00:37,180 --> 00:00:39,950 -this is the place where we want to find errors, - -14 -00:00:39,950 --> 00:00:43,440 -not down here because finding them here will reduce the cost - -15 -00:00:43,440 --> 00:00:47,160 -of our overall software development. The main advantage of the - -16 -00:00:47,160 --> 00:00:50,930 -waterfall model is that it allows you to find errors early. - -17 -00:00:50,930 --> 00:00:53,910 -However, the main disadvantages of the waterfall model arise - -18 -00:00:53,910 --> 00:00:56,550 -from the fact that it is not flexible. Normally, - -19 -00:00:56,550 --> 00:00:59,520 -it is difficult to fully specify requirements at the - -20 -00:00:59,520 --> 00:01:02,470 -beginning of a project. And this lack of flexibility is - -21 -00:01:02,470 --> 00:01:04,800 -far from ideal when dealing with project in which - -22 -00:01:04,800 --> 00:01:07,310 -requirements change, the developers are not domain experts or - -23 -00:01:07,310 --> 00:01:11,130 -the technology used are new and evolving, that is - -24 -00:01:11,130 --> 00:01:14,440 -it is less than ideal for most real world projects. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/12 - Spiral Process - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/12 - Spiral Process - lang_en_vs4.srt deleted file mode 100644 index 2d0cdf9..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/12 - Spiral Process - lang_en_vs4.srt +++ /dev/null @@ -1,191 +0,0 @@ -1 -00:00:00,120 --> 00:00:02,600 -The next model that we will discuss is the spiral - -2 -00:00:02,600 --> 00:00:05,630 -model, which was first described by Barry Boehm, which is - -3 -00:00:05,630 --> 00:00:08,010 -the professor that we interviewed at the beginning of this - -4 -00:00:08,010 --> 00:00:12,240 -lesson. In his paper from 1986 that was entitled A Spiral - -5 -00:00:12,240 --> 00:00:15,730 -Model of Software Development and Enhancement. And one of the - -6 -00:00:15,730 --> 00:00:18,520 -main characteristics of that paper is that it was describing the - -7 -00:00:18,520 --> 00:00:21,670 -spiral model using a diagram, which is the one that - -8 -00:00:21,670 --> 00:00:25,130 -I'm showing you here, and this diagram has become very very - -9 -00:00:25,130 --> 00:00:27,950 -popular, and you probably saw it either in this - -10 -00:00:27,950 --> 00:00:30,400 -form or one of the many variations of the - -11 -00:00:30,400 --> 00:00:32,680 -diagram. So I'm not going to discuss all of - -12 -00:00:32,680 --> 00:00:34,770 -the details of the spiral model, but I just want to - -13 -00:00:34,770 --> 00:00:37,510 -give you an idea of its main characteristics. The - -14 -00:00:37,510 --> 00:00:41,580 -spiral model is an incremental risk-oriented lifecycle model that has - -15 -00:00:41,580 --> 00:00:46,330 -four main phases listed here: determine objectives, identify and - -16 -00:00:46,330 --> 00:00:51,180 -resolve risks, development and tests, and plan the next iteration. - -17 -00:00:51,180 --> 00:00:53,690 -A software project will go through these four phases in - -18 -00:00:53,690 --> 00:00:57,020 -an iterative way. In the first phase, the requirements will - -19 -00:00:57,020 --> 00:00:59,470 -be gathered. In the second phase, the risks and the - -20 -00:00:59,470 --> 00:01:04,010 -alternate solutions will be identified, and a prototype will be produced. - -21 -00:01:04,010 --> 00:01:06,190 -Software and tests for the software are produced in the - -22 -00:01:06,190 --> 00:01:09,210 -development and test phase, which is the third step of the - -23 -00:01:09,210 --> 00:01:12,830 -process. Finally, in the fourth phase, the output of the - -24 -00:01:12,830 --> 00:01:16,880 -project, so far, is evaluated, and the next iteration is planned. - -25 -00:01:16,880 --> 00:01:19,960 -So basically, what the spiral process prescribes is a - -26 -00:01:19,960 --> 00:01:23,262 -way of developing software by going through these phases in - -27 -00:01:23,262 --> 00:01:26,020 -an iterative way, in which we learn more and more - -28 -00:01:26,020 --> 00:01:29,420 -of the software, we identify more and more, and account - -29 -00:01:29,420 --> 00:01:32,250 -for, more and more risks and we go more - -30 -00:01:32,250 --> 00:01:36,000 -and more towards our final solution, our final release. There - -31 -00:01:36,000 --> 00:01:38,930 -are several advantages of using a spiral model. The first - -32 -00:01:38,930 --> 00:01:41,930 -one is that the extensive risk analysis does reduce the - -33 -00:01:41,930 --> 00:01:44,140 -chances of the project to fail. So there is a - -34 -00:01:44,140 --> 00:01:48,300 -risk reduction advantage. The second advantage is that functionality can be - -35 -00:01:48,300 --> 00:01:51,190 -added at a later phase because of the iterative nature of - -36 -00:01:51,190 --> 00:01:55,175 -the process. And finally, software is produced early in the software - -37 -00:01:55,175 --> 00:01:58,260 -lifecycle. So, at any iteration, we have something to show - -38 -00:01:58,260 --> 00:02:01,300 -for our development. We don't wait until the end before producing - -39 -00:02:01,300 --> 00:02:03,790 -something. And then of course there's also the advantage that we - -40 -00:02:03,790 --> 00:02:07,190 -can get early feedback from the customer about what we produced. - -41 -00:02:07,190 --> 00:02:09,000 -The main disadvantages on the other hand of - -42 -00:02:09,000 --> 00:02:11,870 -the spiral model, are that the risk analysis requires - -43 -00:02:11,870 --> 00:02:16,560 -a highly specific expertise. And unfortunately, the whole success - -44 -00:02:16,560 --> 00:02:19,260 -of the process is highly dependent on risk analysis. - -45 -00:02:19,260 --> 00:02:21,580 -So risk analysis has to be done right. - -46 -00:02:21,580 --> 00:02:24,510 -And finally the spiral model is way more complex - -47 -00:02:24,510 --> 00:02:27,180 -than other models, like for example, the water fall - -48 -00:02:27,180 --> 00:02:29,760 -model. And therefore it can be costly to implement. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_en_vs4.srt deleted file mode 100644 index cf068c0..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_en_vs4.srt +++ /dev/null @@ -1,167 +0,0 @@ -1 -00:00:00,080 --> 00:00:02,430 -The next process model I want to discuss is evolutionary - -2 -00:00:02,430 --> 00:00:05,786 -prototyping, which works in four main phases. We start - -3 -00:00:05,786 --> 00:00:08,393 -from an initial concept, then we design and implement - -4 -00:00:08,393 --> 00:00:11,509 -a prototype based on this initial concept, refine the prototype - -5 -00:00:11,509 --> 00:00:14,002 -until it is acceptable, and finally we complete and - -6 -00:00:14,002 --> 00:00:17,550 -release the prototype. Therefore, when developing a system using - -7 -00:00:17,550 --> 00:00:22,330 -evolutionary prototyping, the system is continually refined and rebuilt. - -8 -00:00:22,330 --> 00:00:25,340 -So it is an ideal process when not all requirements - -9 -00:00:25,340 --> 00:00:28,330 -are well understood. Which is a very common situation. So, looking - -10 -00:00:28,330 --> 00:00:30,370 -at this in a little more details, what happens is that - -11 -00:00:30,370 --> 00:00:33,760 -developers start by developing the parts of the system that they - -12 -00:00:33,760 --> 00:00:37,690 -understand, instead of working on developing a whole system, including parts - -13 -00:00:37,690 --> 00:00:40,520 -that might not be very clear at that stage. The partial - -14 -00:00:40,520 --> 00:00:43,900 -system is then shown to the customer and the customer feedback - -15 -00:00:43,900 --> 00:00:47,480 -is used to drive the next iteration, in which either changes - -16 -00:00:47,480 --> 00:00:50,340 -are made to the current features or new features are added. - -17 -00:00:50,340 --> 00:00:53,060 -So, either the current prototype is improved or the - -18 -00:00:53,060 --> 00:00:56,270 -prototype is extended. And finally, when the customer agrees that - -19 -00:00:56,270 --> 00:00:58,980 -the prototype is good enough, the developers will complete all - -20 -00:00:58,980 --> 00:01:01,410 -the remaining work on the system and release the prototype - -21 -00:01:01,410 --> 00:01:03,930 -as the final product. So let's discuss as we did - -22 -00:01:03,930 --> 00:01:06,780 -for the previous process models, what are the main advantages - -23 -00:01:06,780 --> 00:01:10,580 -and disadvantages of evolutionary prototyping. In this case, the main - -24 -00:01:10,580 --> 00:01:15,440 -advantage is the immediate feedback. Developers get feedback immediately as - -25 -00:01:15,440 --> 00:01:17,560 -soon as they produce a prototype and they show it to - -26 -00:01:17,560 --> 00:01:21,050 -the customer and therefore, the risk of implementing the wrong system is - -27 -00:01:21,050 --> 00:01:25,150 -minimized. The main negative is the fact that it's difficult to plan. - -28 -00:01:25,150 --> 00:01:29,070 -When using evolutionary prototype it is difficult to plan in advance how - -29 -00:01:29,070 --> 00:01:31,240 -long the development is going to take, because we don't know how - -30 -00:01:31,240 --> 00:01:34,550 -many iterations will be needed. And another drawback is that it can - -31 -00:01:34,550 --> 00:01:37,120 -easily become an excuse to do kind of do cut and fix - -32 -00:01:37,120 --> 00:01:40,530 -kind of approaches in which we hack something together, fix the main - -33 -00:01:40,530 --> 00:01:43,640 -issues when the customer gives us feedback, and then continue this - -34 -00:01:43,640 --> 00:01:46,780 -way, until the final product is something that is kind of - -35 -00:01:46,780 --> 00:01:49,830 -working, but it's not really a product of high quality. Something - -36 -00:01:49,830 --> 00:01:51,910 -else I want to point out before we move to the next - -37 -00:01:51,910 --> 00:01:54,490 -software process model is that there are many different kinds of - -38 -00:01:54,490 --> 00:01:56,700 -prototyping, so evolutionary prototyping is just - -39 -00:01:56,700 --> 00:01:58,010 -one of them. For example, throwaway - -40 -00:01:58,010 --> 00:02:02,100 -prototyping is another kind of prototyping in which the prototype is - -41 -00:02:02,100 --> 00:02:05,580 -just used to gather requirements, but is thrown away at the end - -42 -00:02:05,580 --> 00:02:08,710 -of the requirements gathering, instead of being evolved as it happens here. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_pt_vs2.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_pt_vs2.srt deleted file mode 100644 index a1fefdc..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_pt_vs2.srt +++ /dev/null @@ -1,167 +0,0 @@ -1 -00:00:00,080 --> 00:00:02,430 -O próximo modelo que eu quero discutir é prototipagem - -2 -00:00:02,430 --> 00:00:05,786 -evolutiva, que funciona em quatro fases principais. Nós começamos - -3 -00:00:05,786 --> 00:00:08,393 -por um conceito inicial, então nós desenhamos e criamos - -4 -00:00:08,393 --> 00:00:11,509 -um protótipo baseado neste conceito inicial, refinamos o protótipo - -5 -00:00:11,509 --> 00:00:14,002 -até que ele se torne aceitável e finalmente nós completamos e - -6 -00:00:14,002 --> 00:00:17,550 -liberamos o protótipo. Desta maneira, quando desenvolvemos um sistema usando - -7 -00:00:17,550 --> 00:00:22,330 -prototipagem evolutiva, o sistema é constantemente refinado e refeito. - -8 -00:00:22,330 --> 00:00:25,340 -Então este é o processo ideal quando nem todos os requisitos - -9 -00:00:25,340 --> 00:00:28,330 -estão bem compreendidos. O que é uma situação bastante usual. Então, olhando - -10 -00:00:28,330 --> 00:00:30,370 -para isso um pouco mais detalhadamente, o que ocorre é que - -11 -00:00:30,370 --> 00:00:33,760 -os desenvolvedores começam no desenvolvimento das partes do sistema que eles - -12 -00:00:33,760 --> 00:00:37,690 -compreendem, ao invés de trabalhar no desenvolvimento do sistema com um tido, incluindo as - -13 -00:00:37,690 --> 00:00:40,520 -parte que não estão ainda muito claras. O sistema - -14 -00:00:40,520 --> 00:00:43,900 -parcial é então mostrado ao cliente e a opinião do cliente - -15 -00:00:43,900 --> 00:00:47,480 -é usada para guiar a próxima iteração, na qual tanto modificações - -16 -00:00:47,480 --> 00:00:50,340 -são feitas nas atuais feições, como novas feições são adicionadas. - -17 -00:00:50,340 --> 00:00:53,060 -Assim, ou o protótipo atual é melhorado ou o - -18 -00:00:53,060 --> 00:00:56,270 -protótipo é aumentado. E finalmente, quando o cliente concorda de - -19 -00:00:56,270 --> 00:00:58,980 -que o protótipo está suficientemente bom, os desenvolvedores irão completar todo - -20 -00:00:58,980 --> 00:01:01,410 -o trabalho faltante no sistema e liberar o protótipo - -21 -00:01:01,410 --> 00:01:03,930 -como o produto final. Então vamos discutir como fizemos - -22 -00:01:03,930 --> 00:01:06,780 -para os modelos de processos anteriores, quais são as principais vantagens - -23 -00:01:06,780 --> 00:01:10,580 -e desvantagens de prototipagem evolutiva. Neste caso, a principal - -24 -00:01:10,580 --> 00:01:15,440 -vantagem é apreciação imediada. Os desenvolvedores recebem a opinião imediatamente, - -25 -00:01:15,440 --> 00:01:17,560 -tão logo eles produziram o protótipo e o mostraram para o - -26 -00:01:17,560 --> 00:01:21,050 -cliente e desta maneira, o risco de implementar erradamente o sistema é - -27 -00:01:21,050 --> 00:01:25,150 -minimizado. O principal ponto negativo é que isso é difícil de planejar. - -28 -00:01:25,150 --> 00:01:29,070 -Quando é usada a prototipagem evolutiva é difícil de antecipar por - -29 -00:01:29,070 --> 00:01:31,240 -quanto tempo o desenvolvimento irá levar, porquê nós não sabemos quantas - -30 -00:01:31,240 --> 00:01:34,550 -iterações serão necessárias. E outro inconveniente é que isso pode facilmente - -31 -00:01:34,550 --> 00:01:37,120 -se tornar uma desculpa para começar a fazer aquele tipo de abordagem de - -32 -00:01:37,120 --> 00:01:40,530 -"corte-e-correção" na qual nós começamos a enjambrar as coisas, corrigir os - -33 -00:01:40,530 --> 00:01:43,640 -principais defeitos quando o cliente nos dá sua opinião e então continuamos desta - -34 -00:01:43,640 --> 00:01:46,780 -maneira, até que o produto final se torne tipo algo que - -35 -00:01:46,780 --> 00:01:49,830 -funciona, mas que não é de fato um produto de alta qualidade. Outra coisa - -36 -00:01:49,830 --> 00:01:51,910 -que eu quero apontar antes de irmos ao próximo - -37 -00:01:51,910 --> 00:01:54,490 -modelo de criação de software é que existem diversas maneiras de - -38 -00:01:54,490 --> 00:01:56,700 -prototipagem, então a prototipagem evolutiva é apenas - -39 -00:01:56,700 --> 00:01:58,010 -uma delas. Por exemplo, prototipagem - -40 -00:01:58,010 --> 00:02:02,100 -descartável é outra maneira de prototipagem na qual o protótipo é - -41 -00:02:02,100 --> 00:02:05,580 -usado apenas para coletar requisitos, mas é descartado ao final - -42 -00:02:05,580 --> 00:02:08,710 -da coleta de requisitos, ao invés de ser evoluído, como ocorre aqui. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_en_vs5.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_en_vs5.srt deleted file mode 100644 index 8bc6db8..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_en_vs5.srt +++ /dev/null @@ -1,111 +0,0 @@ -1 -00:00:00,070 --> 00:00:02,969 -There are two more software process models that I want to cover, so - -2 -00:00:02,969 --> 00:00:06,120 -bear with me. The first one is the Rational Unified software Process - -3 -00:00:06,120 --> 00:00:09,500 -or IUP, which is s a very popular one based on UML. - -4 -00:00:09,500 --> 00:00:12,620 -RUP works in an iterative way, which means it that it performs different - -5 -00:00:12,620 --> 00:00:16,360 -iterations. And at each iteration, it performs four phases. So what I'm - -6 -00:00:16,360 --> 00:00:19,030 -showing you here, is a high level view of the process. And I - -7 -00:00:19,030 --> 00:00:21,630 -don't want you to focus on all the different details, because we - -8 -00:00:21,630 --> 00:00:25,170 -will discuss these details later on, in a lesson that is actually dedicated - -9 -00:00:25,170 --> 00:00:27,470 -to RUP. What I want to give you now, is just the - -10 -00:00:27,470 --> 00:00:31,020 -gist of how this works. So, in each one of these four - -11 -00:00:31,020 --> 00:00:34,680 -phases, which I'm going to describe in a second. We perform standard software - -12 -00:00:34,680 --> 00:00:38,060 -engineering activities, the ones that we just discussed. And we do them - -13 -00:00:38,060 --> 00:00:41,320 -to different extent, based on the phase in which we are. - -14 -00:00:41,320 --> 00:00:44,841 -In particular, in the inception phase the work is mostly to sculpt - -15 -00:00:44,841 --> 00:00:47,940 -the system. So basically figuring out what is the scope of the - -16 -00:00:47,940 --> 00:00:50,220 -work, what is the scope of the project, what is the domain. - -17 -00:00:50,220 --> 00:00:52,670 -So that we can be able to perform initial cost - -18 -00:00:52,670 --> 00:00:56,190 -and budget estimates. The operational phase is the phase in which - -19 -00:00:56,190 --> 00:00:59,910 -we focus on the domain analysis and define the basic architecture - -20 -00:00:59,910 --> 00:01:03,030 -for the system. So this is a phase in which analysis - -21 -00:01:03,030 --> 00:01:06,290 -and design are particularly paramount. Then there is a construction phase, - -22 -00:01:06,290 --> 00:01:09,250 -which is where the bulk of the development actually occurs. And - -23 -00:01:09,250 --> 00:01:11,640 -as you can see here, is where most of the implementation - -24 -00:01:11,640 --> 00:01:15,280 -happens. And finally, the transition phase is the phase in which - -25 -00:01:15,280 --> 00:01:18,090 -the system goes from development into production, so that - -26 -00:01:18,090 --> 00:01:20,380 -it becomes available to users. And of course, this is - -27 -00:01:20,380 --> 00:01:22,480 -the phase in which the other activities in software - -28 -00:01:22,480 --> 00:01:25,710 -development become less relevant and deployment becomes the main one. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_pt_vs1.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_pt_vs1.srt deleted file mode 100644 index cb089cb..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_pt_vs1.srt +++ /dev/null @@ -1,111 +0,0 @@ -1 -00:00:00,070 --> 00:00:02,969 -Existem ainda dois outros processos de modelagem de software que eu gostaria de tratar, então - -2 -00:00:02,969 --> 00:00:06,120 -me acompanhem. O primeiro é o Processo Unificado Racional - -3 -00:00:06,120 --> 00:00:09,500 -ou RUP que é um dos mais populares baseados em UML. - -4 -00:00:09,500 --> 00:00:12,620 -RUP opera de uma maneira iterativa, o que significa que ocorrem diversas - -5 -00:00:12,620 --> 00:00:16,360 -iterações. E em cada iteração, são desenvolvidas quatro fases. Então o que eu - -6 -00:00:16,360 --> 00:00:19,030 -estou lhe mostrando aqui, é uma vista panorâmica do processo. E eu - -7 -00:00:19,030 --> 00:00:21,630 -não quero que você foque em todos os detalhes, porquê nós - -8 -00:00:21,630 --> 00:00:25,170 -iremos discutir estes detalhes mais tarde, numa lição que é de fato dedicada - -9 -00:00:25,170 --> 00:00:27,470 -ao RUP. O que eu quero lhe dar agora, é apenas a - -10 -00:00:27,470 --> 00:00:31,020 -essência de como isso funciona. Então, em cada um dessas quatro - -11 -00:00:31,020 --> 00:00:34,680 -fases, que eu irei descrever em breve... Nós desenvolvemos atividades - -12 -00:00:34,680 --> 00:00:38,060 -de engenharia de software padrões, as que nós já discutimos. E nós as fazemos - -13 -00:00:38,060 --> 00:00:41,320 -para diferentes amplitudes, baseadas na fase em que nos encontramos. - -14 -00:00:41,320 --> 00:00:44,841 -Em particular, na fase de Concepção (Iniciação) o trabalho será sobretudo de esculpir - -15 -00:00:44,841 --> 00:00:47,940 -o sistema. E basicamente ilustrando o escopo do - -16 -00:00:47,940 --> 00:00:50,220 -trabalho, qual será o escopo do projeto, qual é o domínio. - -17 -00:00:50,220 --> 00:00:52,670 -E então nós seremos capazes de saber o custo inicial - -18 -00:00:52,670 --> 00:00:56,190 -e fazer um orçamento. A fase de Elaboração é a fase na qual - -19 -00:00:56,190 --> 00:00:59,910 -nós focamos na análise de domínio e definimos a arquitetura de base - -20 -00:00:59,910 --> 00:01:03,030 -do sistema. Então esta é a fase na qual a análise - -21 -00:01:03,030 --> 00:01:06,290 -e o projeto se tornam proeminentes. E então ocorre a fase de Construção, - -22 -00:01:06,290 --> 00:01:09,250 -na qual o desenvolvimento massivo de fato ocorre. E - -23 -00:01:09,250 --> 00:01:11,640 -como você pode ver aqui, é onde a maior parte da implementação - -24 -00:01:11,640 --> 00:01:15,280 -ocorre. E finalmente, a fase de Transição é a fase na qual - -25 -00:01:15,280 --> 00:01:18,090 -o sistema passa do desenvolvimento para a produção, e então - -26 -00:01:18,090 --> 00:01:20,380 -ele se torna disponível aos usuários. E é claro, esta é - -27 -00:01:20,380 --> 00:01:22,480 -a fase na qual as outras atividades em desenvolvimento de - -28 -00:01:22,480 --> 00:01:25,710 -software se tornam menos relevantes e a entrega se torna a principal. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_en_vs3.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_en_vs3.srt deleted file mode 100644 index 70ef200..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_en_vs3.srt +++ /dev/null @@ -1,123 +0,0 @@ -1 -00:00:00,150 --> 00:00:02,300 -The next type of software process models that I - -2 -00:00:02,300 --> 00:00:06,300 -want to discuss are Agile Software Development Processes. And this - -3 -00:00:06,300 --> 00:00:08,470 -is a group of software development methods that are - -4 -00:00:08,470 --> 00:00:12,620 -based on highly iterative and incremental development. And in particular, - -5 -00:00:12,620 --> 00:00:16,000 -I'm going to discuss Test Driven Development or TDD. The - -6 -00:00:16,000 --> 00:00:18,490 -space on the iteration of three main phases. In - -7 -00:00:18,490 --> 00:00:20,970 -the first one that we mark as red, we - -8 -00:00:20,970 --> 00:00:25,350 -write test cases that encode our requirements, and for which - -9 -00:00:25,350 --> 00:00:29,180 -we haven't written code yet. And therefore, they will fail, obviously. - -10 -00:00:29,180 --> 00:00:31,800 -So we're in this sort of red or fail phase. From - -11 -00:00:31,800 --> 00:00:34,830 -this phase, we move to this phase, in which after we - -12 -00:00:34,830 --> 00:00:37,970 -write the just enough code to make the test cases pass. - -13 -00:00:37,970 --> 00:00:40,670 -We have a set of test cases that are all passing. - -14 -00:00:40,670 --> 00:00:43,810 -And therefore, we can consider this as the green phase. We - -15 -00:00:43,810 --> 00:00:46,930 -had enough code to make the test cases pass because the - -16 -00:00:46,930 --> 00:00:50,520 -test cases encode our requirements. We have just written enough code to - -17 -00:00:50,520 --> 00:00:53,940 -satisfy our requirements. When we do this over time though, - -18 -00:00:53,940 --> 00:00:57,080 -what happens is that the structure of the code deteriorates, because - -19 -00:00:57,080 --> 00:00:59,100 -we keep adding pieces. So that's why we have the - -20 -00:00:59,100 --> 00:01:02,540 -first step, which is refactoring. In this step, we modify the - -21 -00:01:02,540 --> 00:01:05,724 -code, and we will talk about refactoring extensively. We'll devote - -22 -00:01:05,724 --> 00:01:08,190 -one lesson to it. We modify the code to make it - -23 -00:01:08,190 --> 00:01:12,650 -more readable, more maintainable. In general, we modify to improve the - -24 -00:01:12,650 --> 00:01:15,560 -design of the code. And after this phase, we will go - -25 -00:01:15,560 --> 00:01:17,670 -back to writing more test cases for - -26 -00:01:17,670 --> 00:01:19,730 -new requirements, write code that makes these - -27 -00:01:19,730 --> 00:01:24,870 -test cases pass, and so on. So we'll continue to iterate among these phases. And - -28 -00:01:24,870 --> 00:01:26,500 -also, in this case, we will talk - -29 -00:01:26,500 --> 00:01:29,390 -about Agile Software Processes. And in particular, - -30 -00:01:29,390 --> 00:01:32,250 -about extreme programming, or XP, and Scrum - -31 -00:01:32,250 --> 00:01:35,349 -in more details, in minor course number four. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_pt_vs1.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_pt_vs1.srt deleted file mode 100644 index b2224ea..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_pt_vs1.srt +++ /dev/null @@ -1,123 +0,0 @@ -1 -00:00:00,150 --> 00:00:02,300 -O próximo tipo de modelos de processo para software que eu - -2 -00:00:02,300 --> 00:00:06,300 -gostaria de discutir são os Processos Ágil de Desenvolvimento de Software. E este - -3 -00:00:06,300 --> 00:00:08,470 -é um grupo de métodos de desenvolvimento de software que são - -4 -00:00:08,470 --> 00:00:12,620 -baseados em desenvolvimento incremental e altamente iterativo. E em particular, - -5 -00:00:12,620 --> 00:00:16,000 -eu irei discutir é o Desenvolvimento Orientado a Testes, ou TDD. O - -6 -00:00:16,000 --> 00:00:18,490 -espaço na interação de três fases principais. Na - -7 -00:00:18,490 --> 00:00:20,970 -primeira delas que iremos marcar em vermelho, nós - -8 -00:00:20,970 --> 00:00:25,350 -escrevemos casos de teste que codificam nossos requisitos, e para os quais - -9 -00:00:25,350 --> 00:00:29,180 -nós ainda não escrevemos o código. E obviamente, em seguida eles irão falhar. - -10 -00:00:29,180 --> 00:00:31,800 -E então nós iremos cair neste tipo de fase vermelha, ou de falha. Desta - -11 -00:00:31,800 --> 00:00:34,830 -fase, nós passamos para esta outra fase, a qual ocorre depois de nós - -12 -00:00:34,830 --> 00:00:37,970 -escrevermos código suficiente para que os casos de teste aprovem. - -13 -00:00:37,970 --> 00:00:40,670 -Nós temos um conjunto de casos de testes em que todos aprovaram. - -14 -00:00:40,670 --> 00:00:43,810 -E em segunda, nós podemos considerar isso como a fase verde. Nós - -15 -00:00:43,810 --> 00:00:46,930 -temos código suficiente para fazer os casos de teste aprovarem porquê os - -16 -00:00:46,930 --> 00:00:50,520 -casos de teste codificam nossos requisitos. Nós escrevemos código suficiente para - -17 -00:00:50,520 --> 00:00:53,940 -satisfazer nossos requisitos. Quando nós seguimos com isso ao longo do tempo, - -18 -00:00:53,940 --> 00:00:57,080 -o que ocorre é que a estrutura do código deteriora, porquê - -19 -00:00:57,080 --> 00:00:59,100 -nós continuamos adicionando partes! E esta é a razão de nós termos o - -20 -00:00:59,100 --> 00:01:02,540 -primeiro passo, que é a Refatoração. Neste passo, nós modificamos o - -21 -00:01:02,540 --> 00:01:05,724 -código, e nós iremos falar extensamente sobre refatoração. Nós iremos dedicar - -22 -00:01:05,724 --> 00:01:08,190 -uma aula para isso. Nós modificamos o código para o tornar mais - -23 -00:01:08,190 --> 00:01:12,650 -legível, mais fácil de dar manutenção. Em geral, nós modificamos para aprimorar a - -24 -00:01:12,650 --> 00:01:15,560 -concepção do código. E depois desta fase, nós iremos tornar a - -25 -00:01:15,560 --> 00:01:17,670 -escrever mais casos de teste para - -26 -00:01:17,670 --> 00:01:19,730 -novos requisitos... escrever código que faz com que - -27 -00:01:19,730 --> 00:01:24,870 -esses casos de teste aprovem e assim em diante. E então nós iremos continuar a iterar ao entre essas fases. E - -28 -00:01:24,870 --> 00:01:26,500 -também, neste caso, nós iremos falar - -29 -00:01:26,500 --> 00:01:29,390 -sobre Processos Ágil de Desenvolvimento de Software. E em particular, em - -30 -00:01:29,390 --> 00:01:32,250 -Programação Extrema, ou XP e SCRUM - -31 -00:01:32,250 --> 00:01:35,349 -mais detalhadamente, no subcurso número quatro. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/16 - Choosing a Model - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/16 - Choosing a Model - lang_en_vs4.srt deleted file mode 100644 index d898337..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/16 - Choosing a Model - lang_en_vs4.srt +++ /dev/null @@ -1,179 +0,0 @@ -1 -00:00:00,100 --> 00:00:02,860 -We just saw several software process models, and there - -2 -00:00:02,860 --> 00:00:06,330 -are many, many more. And because these process models define - -3 -00:00:06,330 --> 00:00:09,330 -the master plan for our project, the specific process - -4 -00:00:09,330 --> 00:00:12,220 -model that we choose has as much influence over a - -5 -00:00:12,220 --> 00:00:15,700 -project's success as any other major planning decision that - -6 -00:00:15,700 --> 00:00:18,610 -we make. Therefore, it is very important that we pick - -7 -00:00:18,610 --> 00:00:22,100 -the appropriate model for our development process. Picking an appropriate - -8 -00:00:22,100 --> 00:00:25,100 -model can ensure the success of a project. On the - -9 -00:00:25,100 --> 00:00:27,830 -contrary, if we choose the wrong model, that can be a - -10 -00:00:27,830 --> 00:00:31,010 -constant source of problems and ultimately, it can make the project - -11 -00:00:31,010 --> 00:00:33,830 -fail. So how can we choose the right model for a - -12 -00:00:33,830 --> 00:00:36,310 -project? To be able to do so, we have to take into - -13 -00:00:36,310 --> 00:00:40,490 -consideration many factors. In particular, we need to be aware of - -14 -00:00:40,490 --> 00:00:44,390 -what level of understanding we have of the requirements. Do we understand - -15 -00:00:44,390 --> 00:00:46,720 -all the requirements? Are we going to be able to collect all - -16 -00:00:46,720 --> 00:00:50,430 -the requirements in advance, or collecting requirements is going to be hard and - -17 -00:00:50,430 --> 00:00:53,460 -therefore, we might want to follow a process that is more flexible - -18 -00:00:53,460 --> 00:00:57,470 -with that respect. Another important point is the expected lifetime of the - -19 -00:00:57,470 --> 00:01:00,300 -project. Is this a quick project that we are putting together for - -20 -00:01:00,300 --> 00:01:03,100 -a specific purpose or something that's going to last for for a number - -21 -00:01:03,100 --> 00:01:05,910 -of years and that we're going to maintain over all those years? - -22 -00:01:05,910 --> 00:01:08,380 -That's going to make a difference in the way we decide to develop - -23 -00:01:08,380 --> 00:01:12,190 -that project. Also, what is the level of risk involved? Do we - -24 -00:01:12,190 --> 00:01:15,530 -know the domain very well? Do we know exactly the technologies involved? - -25 -00:01:15,530 --> 00:01:19,100 -Well, if so, we might go with a more traditional process. Otherwise, - -26 -00:01:19,100 --> 00:01:21,902 -we might want to be more agile, more flexible. It is also - -27 -00:01:21,902 --> 00:01:24,900 -very important to know the schedule constraints. How much time, how many - -28 -00:01:24,900 --> 00:01:28,640 -resources do we have for this project? What is the expected interaction - -29 -00:01:28,640 --> 00:01:31,870 -with the management and the customer? In particular for this ladder, there - -30 -00:01:31,870 --> 00:01:34,840 -are many processes that rely on the fact that there can be - -31 -00:01:34,840 --> 00:01:38,310 -a continuous interaction with the customer. If that interaction is not there, - -32 -00:01:38,310 --> 00:01:41,230 -there's no way we are going to be able to use these processes. - -33 -00:01:41,230 --> 00:01:44,580 -Conversely, there are processes that don't require the presence of the customer - -34 -00:01:44,580 --> 00:01:47,868 -at all, except for the initial phase and maybe some checking points and - -35 -00:01:47,868 --> 00:01:51,020 -so if the customer is very inaccessible, we might want to follow - -36 -00:01:51,020 --> 00:01:53,740 -one of those processes, instead of one of the more demanding ones in - -37 -00:01:53,740 --> 00:01:57,340 -terms of customer's time. Finally, it is important to take into account - -38 -00:01:57,340 --> 00:02:00,450 -the level of the expertise of the people involved. Do we have people - -39 -00:02:00,450 --> 00:02:02,730 -that know the technologies that we're using? Do we know people that - -40 -00:02:02,730 --> 00:02:04,590 -know a specific kind of process? - -41 -00:02:04,590 --> 00:02:06,930 -Some processes require some specific expertise and - -42 -00:02:06,930 --> 00:02:09,320 -we're not going to be able to follow that process if we don't - -43 -00:02:09,320 --> 00:02:12,410 -have the right expertise. So we need to take into account all of - -44 -00:02:12,410 --> 00:02:15,570 -these aspects, and sometimes more, in order to be able to make - -45 -00:02:15,570 --> 00:02:19,560 -the right decision and pick the right software process model for our project. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/17 - Choosing a Model Quiz - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/17 - Choosing a Model Quiz - lang_en_vs4.srt deleted file mode 100644 index 9f733ac..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/17 - Choosing a Model Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,35 +0,0 @@ -1 -00:00:00,090 --> 00:00:02,080 -Now before we move to the last part of the lesson, let's - -2 -00:00:02,080 --> 00:00:04,939 -have a quick quiz on software process models to make sure that - -3 -00:00:04,939 --> 00:00:06,640 -we are all on the same page. So I am going to - -4 -00:00:06,640 --> 00:00:10,320 -ask you two questions. The first question is which of the following models - -5 -00:00:10,320 --> 00:00:14,330 -is most suitable to develop a software control system? And when you - -6 -00:00:14,330 --> 00:00:17,700 -think about the software control system, you can think about for example - -7 -00:00:17,700 --> 00:00:21,150 -the control system for the software in an airplane. Would you rather - -8 -00:00:21,150 --> 00:00:22,860 -use a pure waterfall model? Test - -9 -00:00:22,860 --> 00:00:25,840 -driven development? Or an evolutionary prototyping approach? diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/18 - Choosing a Model Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/18 - Choosing a Model Quiz Solution - lang_en_vs5.srt deleted file mode 100644 index 01a444c..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/18 - Choosing a Model Quiz Solution - lang_en_vs5.srt +++ /dev/null @@ -1,47 +0,0 @@ -1 -00:00:00,080 --> 00:00:02,980 -This is the context in which, typically, a pure - -2 -00:00:02,980 --> 00:00:06,310 -waterfall process will work well. Why? Well, because it's a - -3 -00:00:06,310 --> 00:00:10,160 -context in which requirements are usually well understood. The - -4 -00:00:10,160 --> 00:00:13,020 -domain is well understood, so that kind of system has - -5 -00:00:13,020 --> 00:00:15,900 -been built many times before. And also, it's a - -6 -00:00:15,900 --> 00:00:19,510 -system in which we don't expect requirements to change dramatically - -7 -00:00:19,510 --> 00:00:23,180 -over time. Therefore, a waterfall model, in which we collect - -8 -00:00:23,180 --> 00:00:25,140 -all the requirements at the beginning and then we move - -9 -00:00:25,140 --> 00:00:28,280 -to the subsequent phases might be the most appropriate one. Probably - -10 -00:00:28,280 --> 00:00:30,800 -we don't want to do evolutionary prototyping in the case of - -11 -00:00:30,800 --> 00:00:34,130 -the control system for an airplane. Same thing holds for TDD, - -12 -00:00:34,130 --> 00:00:36,460 -so we want to be a little more rigorous in those cases. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/19 - Choosing a Model Quiz - lang_en_vs5.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/19 - Choosing a Model Quiz - lang_en_vs5.srt deleted file mode 100644 index 570d146..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/19 - Choosing a Model Quiz - lang_en_vs5.srt +++ /dev/null @@ -1,11 +0,0 @@ -1 -00:00:00,110 --> 00:00:03,580 -The second question I want to ask you is which model is the most suitable if you - -2 -00:00:03,580 --> 00:00:06,660 -expect mid-course corrections? Would you rather use a - -3 -00:00:06,660 --> 00:00:10,430 -pure waterfall model, a spiral model, or evolutionary prototyping? diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/2 - Traditional Software Phases - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/2 - Traditional Software Phases - lang_en_vs4.srt deleted file mode 100644 index cc522f0..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/2 - Traditional Software Phases - lang_en_vs4.srt +++ /dev/null @@ -1,75 +0,0 @@ -1 -00:00:00,160 --> 00:00:02,650 -As we just heard from Professor Bohem, software - -2 -00:00:02,650 --> 00:00:05,970 -engineering is an important and critical discipline, concerned - -3 -00:00:05,970 --> 00:00:09,100 -with cost effective software development. We also heard - -4 -00:00:09,100 --> 00:00:11,170 -that this is based on a systematic approach - -5 -00:00:11,170 --> 00:00:14,580 -that uses appropriate tools and techniques, operates under - -6 -00:00:14,580 --> 00:00:18,130 -specific development constraints. And most importantly, follows a - -7 -00:00:18,130 --> 00:00:20,890 -process. As we discussed in the previous lesson, - -8 -00:00:20,890 --> 00:00:25,770 -the software development process contains fundamental activities, or phases. - -9 -00:00:25,770 --> 00:00:28,480 -Since we will discuss several processes, I'm going to remind - -10 -00:00:28,480 --> 00:00:31,150 -you what these phases are. We start with requirements - -11 -00:00:31,150 --> 00:00:33,630 -engineering, followed by design, - -12 -00:00:33,630 --> 00:00:36,980 -implementation, verification and validation, and - -13 -00:00:36,980 --> 00:00:40,950 -finally maintenance. Note that we will revisit each of - -14 -00:00:40,950 --> 00:00:43,940 -these phases and devote an entire lesson or more - -15 -00:00:43,940 --> 00:00:46,160 -to each phase. So what I want to do next - -16 -00:00:46,160 --> 00:00:48,210 -is simply to give you a quick overview of - -17 -00:00:48,210 --> 00:00:51,020 -what these phases are. Note also that for now - -18 -00:00:51,020 --> 00:00:54,330 -I will follow a very traditional take on these topics. Later on in the - -19 -00:00:54,330 --> 00:00:58,260 -class we will see how things can change and did change over the years. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/20 - Choosing a Model Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/20 - Choosing a Model Quiz Solution - lang_en_vs4.srt deleted file mode 100644 index 7ea0e4f..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/20 - Choosing a Model Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,67 +0,0 @@ -1 -00:00:00,150 --> 00:00:02,860 -In this case, I think about the spiral model, - -2 -00:00:02,860 --> 00:00:06,610 -and evolutionary prototyping model will work. Definitely you don't want to - -3 -00:00:06,610 --> 00:00:09,110 -have a pure water from water. Why? Well because it - -4 -00:00:09,110 --> 00:00:11,940 -is very expensive with a pure waterfall model to make - -5 -00:00:11,940 --> 00:00:15,460 -changes during the course of the project, especially changes - -6 -00:00:15,460 --> 00:00:17,860 -that involve requirements. Why? Because we saw that it can - -7 -00:00:17,860 --> 00:00:20,440 -be very expensive. Whereas with the spiral model, we saw - -8 -00:00:20,440 --> 00:00:25,220 -that being iterative, we can actually make correction throughout development. - -9 -00:00:25,220 --> 00:00:28,840 -Similarly, with evolutionary prototyping, we keep evolving our system - -10 -00:00:28,840 --> 00:00:32,170 -based on the customer feedback. And therefore, if something changes, - -11 -00:00:32,170 --> 00:00:33,810 -we will get feedback right away, and we will - -12 -00:00:33,810 --> 00:00:36,230 -be able to adapt. So the key thing here is - -13 -00:00:36,230 --> 00:00:39,060 -that anything that is iterative works better in the - -14 -00:00:39,060 --> 00:00:43,400 -case of changing environments. So, situations in which your requirements, - -15 -00:00:43,400 --> 00:00:46,720 -the situation, the project might change. Whereas waterfall is - -16 -00:00:46,720 --> 00:00:50,410 -more appropriate for situations in which the requirements are stable, - -17 -00:00:50,410 --> 00:00:53,760 -we know the domain, and possibly we also know the technologies involved. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/21 - Lifecycle Documents - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/21 - Lifecycle Documents - lang_en_vs4.srt deleted file mode 100644 index 20e1102..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/21 - Lifecycle Documents - lang_en_vs4.srt +++ /dev/null @@ -1,67 +0,0 @@ -1 -00:00:00,070 --> 00:00:02,650 -Now that we discussed softer process models, there is - -2 -00:00:02,650 --> 00:00:05,100 -another important point I want to cover, because it's going to - -3 -00:00:05,100 --> 00:00:08,970 -be useful for your projects. Documenting the activities carried out - -4 -00:00:08,970 --> 00:00:11,660 -during the different phases of the softer lifecycle, is a - -5 -00:00:11,660 --> 00:00:14,960 -very important task. The documents that we produce are used - -6 -00:00:14,960 --> 00:00:18,270 -for different purposes, such as communicative details of the software - -7 -00:00:18,270 --> 00:00:21,650 -systems. To difference the colors, ensure the correct implementation of - -8 -00:00:21,650 --> 00:00:25,630 -the system, facilitate maintenance, and so on. There are standardized - -9 -00:00:25,630 --> 00:00:29,230 -document that are provided by IEEE that you can use - -10 -00:00:29,230 --> 00:00:32,680 -for this purpose. However, they're kind of heavyweight. So for the - -11 -00:00:32,680 --> 00:00:35,090 -project in this class, when we will need them, I will - -12 -00:00:35,090 --> 00:00:38,760 -rather use this lightweight documents. That we created by modifying the - -13 -00:00:38,760 --> 00:00:41,730 -original ones, and make them a little simpler. In this, - -14 -00:00:41,730 --> 00:00:44,700 -our documents are actually used, while teaching this class in the - -15 -00:00:44,700 --> 00:00:47,600 -past. So they're well tested and work well for the kind - -16 -00:00:47,600 --> 00:00:50,730 -of projects that we will perform. I provide information on how - -17 -00:00:50,730 --> 00:00:52,880 -to access these documents in the class notes. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/22 - Classic Mistakes: People - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/22 - Classic Mistakes: People - lang_en_vs4.srt deleted file mode 100644 index 7edb042..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/22 - Classic Mistakes: People - lang_en_vs4.srt +++ /dev/null @@ -1,163 +0,0 @@ -1 -00:00:00,120 --> 00:00:02,000 -Now we get to the final part of the lesson. - -2 -00:00:02,000 --> 00:00:04,810 -And in this part I want to talk about well known, - -3 -00:00:04,810 --> 00:00:09,230 -ineffective development practices. These practices, when followed, tend to lead - -4 -00:00:09,230 --> 00:00:13,245 -to predictably bad results. So let's look at some examples of - -5 -00:00:13,245 --> 00:00:17,130 -these classic mistakes. And we're going to start with mistakes - -6 -00:00:17,130 --> 00:00:20,660 -involving people. And notice that there is a long list. So - -7 -00:00:20,660 --> 00:00:23,100 -I'm going to discuss just a few of those mistakes. - -8 -00:00:23,100 --> 00:00:25,215 -And I'm going to point you to more information on this - -9 -00:00:25,215 --> 00:00:27,550 -topic in the class notes. And some of these mistakes are - -10 -00:00:27,550 --> 00:00:30,020 -actually kind of entertaining. So I'll recommend that you look at - -11 -00:00:30,020 --> 00:00:33,210 -the class notes and go in more depth in this list. - -12 -00:00:33,210 --> 00:00:35,550 -So the first people mistake I want to mention is the - -13 -00:00:35,550 --> 00:00:38,945 -one that I define, heroics. And this refers to too much - -14 -00:00:38,945 --> 00:00:43,480 -emphasis on can do attitudes, so this idea that one person - -15 -00:00:43,480 --> 00:00:46,330 -by himself or by herself can do everything and can make - -16 -00:00:46,330 --> 00:00:50,422 -the difference in the whole project. And unfortunately, this encourages extreme - -17 -00:00:50,422 --> 00:00:53,950 -risk taking and discourages cooperation, which is plain bad for - -18 -00:00:53,950 --> 00:00:56,610 -the project. For example, it might force people not to - -19 -00:00:56,610 --> 00:00:59,600 -report schedule slips. It might force people to take on - -20 -00:00:59,600 --> 00:01:02,210 -on too much responsibility. And normally, and I saw it - -21 -00:01:02,210 --> 00:01:05,600 -happen many times, the final result is a failure. So - -22 -00:01:05,600 --> 00:01:08,410 -what you want when you're developing a larger project, is - -23 -00:01:08,410 --> 00:01:11,710 -actually to apply soft engineering principles. Have teams, have team - -24 -00:01:11,710 --> 00:01:15,580 -work, and have cooperation among the different team members, without pointing - -25 -00:01:15,580 --> 00:01:18,830 -too much on single individuals. Another classic mistake - -26 -00:01:18,830 --> 00:01:22,140 -is to not create the right working environment. We - -27 -00:01:22,140 --> 00:01:24,900 -all like to work in nice environments. And there - -28 -00:01:24,900 --> 00:01:27,790 -is strong evidence that the working environments can play - -29 -00:01:27,790 --> 00:01:30,670 -a big role in productivity. There is evidence - -30 -00:01:30,670 --> 00:01:34,280 -that productivity increases when the workplace is nice, quiet, - -31 -00:01:34,280 --> 00:01:37,950 -warm, and welcoming. Finally, some of the most important - -32 -00:01:37,950 --> 00:01:41,480 -people relating mistakes are due to poor people management. - -33 -00:01:41,480 --> 00:01:44,540 -For example, lack of leaderships, or leadership that is - -34 -00:01:44,540 --> 00:01:47,920 -exercised using the wrong means in the wrong way, which - -35 -00:01:47,920 --> 00:01:50,280 -can lead to very unhappy personnel and therefore, low - -36 -00:01:50,280 --> 00:01:54,190 -productivity, or even people leaving teams. Another classic example of - -37 -00:01:54,190 --> 00:01:57,370 -poor management is adding people to a project that - -38 -00:01:57,370 --> 00:02:01,600 -is behind schedule, which never works. Why it doesn't work? - -39 -00:02:01,600 --> 00:02:03,440 -Because these new people need to be brought up to - -40 -00:02:03,440 --> 00:02:06,520 -speed, and that causes further delays rather than improving the - -41 -00:02:06,520 --> 00:02:08,280 -situation with the project schedule. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/23 - Classic Mistakes: Process - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/23 - Classic Mistakes: Process - lang_en_vs4.srt deleted file mode 100644 index 83720a0..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/23 - Classic Mistakes: Process - lang_en_vs4.srt +++ /dev/null @@ -1,79 +0,0 @@ -1 -00:00:00,080 --> 00:00:03,770 -Another type of classic mistakes are process-related mistakes. And also - -2 -00:00:03,770 --> 00:00:05,850 -in this case, these kind of mistakes can be due - -3 -00:00:05,850 --> 00:00:08,970 -to many reasons. And they are of many types. One - -4 -00:00:08,970 --> 00:00:12,310 -typical example are scheduling issues, which are due to the fact - -5 -00:00:12,310 --> 00:00:15,180 -of being unable to come up with a realistic schedule. - -6 -00:00:15,180 --> 00:00:17,750 -So to have an overly optimistic schedule. And this can be - -7 -00:00:17,750 --> 00:00:21,230 -because we underestimate the effort involved in different parts of - -8 -00:00:21,230 --> 00:00:25,010 -the project. Because we overestimate the ability of the people involved. - -9 -00:00:25,010 --> 00:00:27,600 -Because we overestimate the importance, for example, of the use - -10 -00:00:27,600 --> 00:00:29,640 -of tools. But no matter what the reason is, the - -11 -00:00:29,640 --> 00:00:32,840 -result is typically that the projects end up being late, - -12 -00:00:32,840 --> 00:00:35,580 -which is a very common situation. So this is somehow - -13 -00:00:35,580 --> 00:00:39,020 -related to planning. And in general, planning is a fundamental - -14 -00:00:39,020 --> 00:00:42,720 -factor in software processes and in software development. Mistakes in - -15 -00:00:42,720 --> 00:00:46,120 -planning, such as insufficient planning or abandoning planning due to - -16 -00:00:46,120 --> 00:00:50,190 -pressure, usually lead inexorably to failure. And speaking of failures, - -17 -00:00:50,190 --> 00:00:53,040 -often there are unforeseen failures. Such as - -18 -00:00:53,040 --> 00:00:55,410 -failures on the constructor's end, for example, - -19 -00:00:55,410 --> 00:00:56,920 -that might lead to low quality or - -20 -00:00:56,920 --> 00:01:00,580 -late deliverables, which ultimately affects the downstream activities. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/24 - Classic Mistakes: Product - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/24 - Classic Mistakes: Product - lang_en_vs4.srt deleted file mode 100644 index 24972d9..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/24 - Classic Mistakes: Product - lang_en_vs4.srt +++ /dev/null @@ -1,87 +0,0 @@ -1 -00:00:00,090 --> 00:00:01,970 -The third category of mistakes that I want to - -2 -00:00:01,970 --> 00:00:04,970 -mention is product-related mistakes. A - -3 -00:00:04,970 --> 00:00:07,360 -typical example of product-related mistake - -4 -00:00:07,360 --> 00:00:11,010 -is gold plating of requirements. And what that means is - -5 -00:00:11,010 --> 00:00:13,710 -basically is that it's very common for projects to have - -6 -00:00:13,710 --> 00:00:17,230 -more requirements than they actually need. For example, marketing might - -7 -00:00:17,230 --> 00:00:19,090 -want to add more features than the ones that are - -8 -00:00:19,090 --> 00:00:21,460 -actually needed by the users. And of course having more - -9 -00:00:21,460 --> 00:00:25,720 -requirements lengthens the project's schedule in a totally unnecessary way. - -10 -00:00:25,720 --> 00:00:29,250 -Feature creep is another common mistake and consists in - -11 -00:00:29,250 --> 00:00:32,140 -adding more and more features to a product that were - -12 -00:00:32,140 --> 00:00:34,650 -not initially planned and are not really needed in most - -13 -00:00:34,650 --> 00:00:38,360 -cases. And here there is evidence that the average project - -14 -00:00:38,360 --> 00:00:41,180 -experiences about a 25% growth in the number of - -15 -00:00:41,180 --> 00:00:44,330 -features over its lifetime which can clearly highly effect The - -16 -00:00:44,330 --> 00:00:47,580 -project schedule. Finally, if you're working on a project that - -17 -00:00:47,580 --> 00:00:50,760 -strains the limits of computer science. For example, because you - -18 -00:00:50,760 --> 00:00:53,350 -need to develop new algorithms for the project, or you have - -19 -00:00:53,350 --> 00:00:56,670 -to use new techniques. Then that project might be more research than - -20 -00:00:56,670 --> 00:00:58,450 -actual development. And therefore, it - -21 -00:00:58,450 --> 00:01:00,600 -should be managed accordingly. For example, - -22 -00:01:00,600 --> 00:01:03,910 -by taking into account that you will have a highly unpredictable schedule. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/25 - Classic Mistakes: Technology - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/25 - Classic Mistakes: Technology - lang_en_vs4.srt deleted file mode 100644 index 16810ac..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/25 - Classic Mistakes: Technology - lang_en_vs4.srt +++ /dev/null @@ -1,95 +0,0 @@ -1 -00:00:00,080 --> 00:00:02,360 -The final type of classic mistakes that I want - -2 -00:00:02,360 --> 00:00:06,470 -to mention are technology related mistakes. One typical mistake - -3 -00:00:06,470 --> 00:00:09,990 -in this context is the silver-bullet syndrome. What does - -4 -00:00:09,990 --> 00:00:13,340 -that mean? Well, the silver-bullet syndrome refers to situations - -5 -00:00:13,340 --> 00:00:15,900 -in which there is too much reliance on the - -6 -00:00:15,900 --> 00:00:19,950 -advertised benefits of some previously unused technology. For example, - -7 -00:00:19,950 --> 00:00:21,980 -a new technology. And the problem here is that - -8 -00:00:21,980 --> 00:00:25,140 -we cannot expect technology alone to solve our software - -9 -00:00:25,140 --> 00:00:27,810 -development issues. So we should not rely too - -10 -00:00:27,810 --> 00:00:31,020 -much on technology alone. Another typical mistake is to - -11 -00:00:31,020 --> 00:00:33,700 -switch or add tools in the middle of - -12 -00:00:33,700 --> 00:00:36,010 -a project. And sometimes it can make sense to - -13 -00:00:36,010 --> 00:00:38,620 -upgrade a tool, but introducing new tools, which - -14 -00:00:38,620 --> 00:00:41,650 -can have a steep learning curve, has almost always - -15 -00:00:41,650 --> 00:00:46,290 -negative effects. Finally, a common unforgivable mistake is - -16 -00:00:46,290 --> 00:00:50,230 -the lack of an automated version control system for - -17 -00:00:50,230 --> 00:00:53,480 -your code and for your various artifacts. Manual and - -18 -00:00:53,480 --> 00:00:56,700 -ad hoc solutions are just not an option. It is - -19 -00:00:56,700 --> 00:00:59,270 -way too easy to make mistakes, use out of - -20 -00:00:59,270 --> 00:01:02,600 -date versions, be unable to find a previous working version, - -21 -00:01:02,600 --> 00:01:05,030 -and so on. I saw that happening many times, - -22 -00:01:05,030 --> 00:01:08,640 -and it always results in a disaster. So be warned, - -23 -00:01:08,640 --> 00:01:11,650 -use a version control system and an automated one. And - -24 -00:01:11,650 --> 00:01:14,750 -actually we will use version control systems in our projects. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/26 - Classic Mistakes Quiz - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/26 - Classic Mistakes Quiz - lang_en_vs4.srt deleted file mode 100644 index 2b4263f..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/26 - Classic Mistakes Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,23 +0,0 @@ -1 -00:00:00,060 --> 00:00:01,650 -To conclude this lesson, I'm going to have a - -2 -00:00:01,650 --> 00:00:03,650 -simple quiz and what I'm going to ask you - -3 -00:00:03,650 --> 00:00:07,950 -is, which kind of mistake adding people to a late project is? And you can pick - -4 -00:00:07,950 --> 00:00:10,540 -between a people mistake, a product mistake, a - -5 -00:00:10,540 --> 00:00:12,830 -technology mistake, or maybe this is not a - -6 -00:00:12,830 --> 00:00:16,800 -mistake at all, it is actually okay to add people to a project that is late. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/27 - Classic Mistakes Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/27 - Classic Mistakes Quiz Solution - lang_en_vs4.srt deleted file mode 100644 index 53c2485..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/27 - Classic Mistakes Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,39 +0,0 @@ -1 -00:00:00,060 --> 00:00:02,719 -You probably got this one right. The right answer is that - -2 -00:00:02,719 --> 00:00:05,330 -this is a people mistake. And despite the fact that this is - -3 -00:00:05,330 --> 00:00:07,550 -an easy answer, I just want to make sure to stress - -4 -00:00:07,550 --> 00:00:10,800 -once more. Because this is a very classic mistake. And one that - -5 -00:00:10,800 --> 00:00:14,070 -can have dire consequences. You should never add people, to a - -6 -00:00:14,070 --> 00:00:18,430 -late project. Because in 99.9% of the cases, that's only going to make - -7 -00:00:18,430 --> 00:00:21,390 -things worse. Why? Because these people have to be brought up to - -8 -00:00:21,390 --> 00:00:25,590 -speed, and also because having more also makes the communication more difficult, - -9 -00:00:25,590 --> 00:00:27,690 -the meetings more difficult and so on. So in - -10 -00:00:27,690 --> 00:00:29,980 -short, do not add people to a late project. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt deleted file mode 100644 index c541e70..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt +++ /dev/null @@ -1,175 +0,0 @@ -1 -00:00:00,230 --> 00:00:03,200 -So, let's start with requirements engineering, which is the - -2 -00:00:03,200 --> 00:00:06,560 -field within software engineering that deals with establishing the - -3 -00:00:06,560 --> 00:00:09,400 -needs of stakeholders that are to be solved by - -4 -00:00:09,400 --> 00:00:13,480 -the software. So why is this phase so important? - -5 -00:00:13,480 --> 00:00:16,350 -In general, the cost of correcting an error depends - -6 -00:00:16,350 --> 00:00:19,060 -on the number of subsequent decisions that are based - -7 -00:00:19,060 --> 00:00:22,160 -on it. Therefore, errors made in understanding requirements have - -8 -00:00:22,160 --> 00:00:25,670 -the potential for greatest cost because many other design decisions - -9 -00:00:25,670 --> 00:00:29,020 -depend on them and many other follow up decisions depend on them. - -10 -00:00:29,020 --> 00:00:31,510 -In fact, if we look at this diagram, which is again a - -11 -00:00:31,510 --> 00:00:35,210 -qualitative diagram, where we have the cost of error correction over the - -12 -00:00:35,210 --> 00:00:38,780 -phase in which the error is discovered. We can see that if we - -13 -00:00:38,780 --> 00:00:42,420 -discover an error in requirements it's going to cost us one. If - -14 -00:00:42,420 --> 00:00:45,020 -we find it in in design it's going to cost us five and - -15 -00:00:45,020 --> 00:00:47,410 -so on and so forth. And the cost grows dramatically as we - -16 -00:00:47,410 --> 00:00:50,960 -go from the requirements phase to the maintenance phase. Why? Because of course - -17 -00:00:50,960 --> 00:00:53,092 -if we discover a problem here we're left to undo a - -18 -00:00:53,092 --> 00:00:55,536 -lot of the decision that we had made before to correct the - -19 -00:00:55,536 --> 00:00:58,019 -error. Whereas if we find an error here we can correct it - -20 -00:00:58,019 --> 00:01:01,380 -right away and we don't affect the subsequent phases. So how can - -21 -00:01:01,380 --> 00:01:03,540 -we collect the right requirements. Traditional - -22 -00:01:03,540 --> 00:01:05,310 -requirements in engineering does so through - -23 -00:01:05,310 --> 00:01:08,930 -a set of steps. The first step is elicitation which is the - -24 -00:01:08,930 --> 00:01:12,840 -collection of requirements from stake holders and other sources and can be - -25 -00:01:12,840 --> 00:01:15,890 -done in a variety of ways, we will discuss some of them. - -26 -00:01:15,890 --> 00:01:19,280 -The second is requirement analysis which involved the study and - -27 -00:01:19,280 --> 00:01:23,200 -deeper understanding of the collective requirements. The third step is this - -28 -00:01:23,200 --> 00:01:26,760 -specification of requirements, in which the collective requirements are suitably - -29 -00:01:26,760 --> 00:01:30,730 -represented, organized and save so that they can be shared. Also - -30 -00:01:30,730 --> 00:01:32,530 -in his case, there are many ways to do this, - -31 -00:01:32,530 --> 00:01:34,350 -and we will see some of this ways when we talk - -32 -00:01:34,350 --> 00:01:37,550 -about the requirements engineering in the dedicated lesson. Once the - -33 -00:01:37,550 --> 00:01:40,970 -requirements have been specified, they can be validated to make sure - -34 -00:01:40,970 --> 00:01:44,420 -that they're complete, consistent, no redundant and so on. So - -35 -00:01:44,420 --> 00:01:48,460 -that they've satisfied a set of importance properties, for requirements. - -36 -00:01:48,460 --> 00:01:52,410 -Finally, the fifth step is requirements management which accounts for - -37 -00:01:52,410 --> 00:01:56,100 -changes to requirements during the lifetime of the project. And here - -38 -00:01:56,100 --> 00:01:58,330 -I talked about steps, kind of giving the impression that - -39 -00:01:58,330 --> 00:02:01,310 -we're just going from the first step to the fifth one - -40 -00:02:01,310 --> 00:02:03,300 -and that this is sort of a linear process. In - -41 -00:02:03,300 --> 00:02:05,990 -reality, as we will see, this is more of an iterative - -42 -00:02:05,990 --> 00:02:09,690 -process in which will go and cover the different phases in an - -43 -00:02:09,690 --> 00:02:12,560 -iterative fashion. We will discuss extensively - -44 -00:02:12,560 --> 00:02:15,453 -requirements engineering in our second mini-course. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/4 - Design - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/4 - Design - lang_en_vs4.srt deleted file mode 100644 index 5ddb4d1..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/4 - Design - lang_en_vs4.srt +++ /dev/null @@ -1,103 +0,0 @@ -1 -00:00:00,290 --> 00:00:02,900 -Now let's discuss the next phase of software development, - -2 -00:00:02,900 --> 00:00:06,080 -which is software design. Software design is the phase - -3 -00:00:06,080 --> 00:00:09,030 -where software requirements are analyzed in order to produce - -4 -00:00:09,030 --> 00:00:11,500 -a description of the internal structure and organization of - -5 -00:00:11,500 --> 00:00:13,900 -the system. And this description will serve as the - -6 -00:00:13,900 --> 00:00:17,550 -basis for the construction of the actual system. Traditionally, - -7 -00:00:17,550 --> 00:00:20,020 -the software design phase consists of a series of - -8 -00:00:20,020 --> 00:00:25,360 -design activities. Which normally consists of the architectural design phase, - -9 -00:00:25,360 --> 00:00:27,880 -the abstract specification, interface design, - -10 -00:00:27,880 --> 00:00:30,010 -component design, data structure and - -11 -00:00:30,010 --> 00:00:33,230 -algorithm design. And notice that this is just a possible list - -12 -00:00:33,230 --> 00:00:35,820 -of activities. But you can also characterize design activities in - -13 -00:00:35,820 --> 00:00:38,550 -many different ways. And if you're looking at different books, and - -14 -00:00:38,550 --> 00:00:41,800 -different sources, you might find different activities described. But the - -15 -00:00:41,800 --> 00:00:44,500 -core idea, the important point is that we go from sort - -16 -00:00:44,500 --> 00:00:46,940 -of a high-level view of the system, which is the - -17 -00:00:46,940 --> 00:00:50,770 -architectural design, to a low-level view, which is the algorithm design. - -18 -00:00:50,770 --> 00:00:53,100 -And these activities result in a set of design - -19 -00:00:53,100 --> 00:00:56,810 -products, which describe various characteristics of the system. For - -20 -00:00:56,810 --> 00:00:59,770 -example, they describe the architecture of the system, so - -21 -00:00:59,770 --> 00:01:02,890 -how the system is decomposed and organized into components, the - -22 -00:01:02,890 --> 00:01:06,630 -interfaces between these components. They also describe these components - -23 -00:01:06,630 --> 00:01:09,030 -into a level of details that is suitable for - -24 -00:01:09,030 --> 00:01:12,470 -allowing their construction. We will discuss the details of - -25 -00:01:12,470 --> 00:01:16,130 -software design and talk extensively about these different actives and - -26 -00:01:16,130 --> 00:01:19,200 -these different products in the third mini course of this class. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/5 - Implementation - lang_en_vs5.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/5 - Implementation - lang_en_vs5.srt deleted file mode 100644 index 465ae1b..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/5 - Implementation - lang_en_vs5.srt +++ /dev/null @@ -1,103 +0,0 @@ -1 -00:00:00,150 --> 00:00:02,719 -After we have designed our system we can implement - -2 -00:00:02,719 --> 00:00:05,900 -it. In the implementation phase what we do is basically - -3 -00:00:05,900 --> 00:00:08,410 -taking care of realizing the design of the system - -4 -00:00:08,410 --> 00:00:11,920 -that we just created and create an actual software system. - -5 -00:00:11,920 --> 00:00:15,530 -There are four fundamental principles, four pillars that can - -6 -00:00:15,530 --> 00:00:18,470 -affect the way in which software is constructed. The first - -7 -00:00:18,470 --> 00:00:21,900 -one is the reduction of complexity. This aims to build - -8 -00:00:21,900 --> 00:00:25,160 -software that is easier to understand and use. The second - -9 -00:00:25,160 --> 00:00:28,400 -pillar is the anticipation of diversity. Which takes into - -10 -00:00:28,400 --> 00:00:31,720 -account that software construction might change in various way over - -11 -00:00:31,720 --> 00:00:35,220 -time. That is that software evolves. In many cases, - -12 -00:00:35,220 --> 00:00:38,270 -it evolves in unexpected ways. And therefore, we have to - -13 -00:00:38,270 --> 00:00:41,680 -be able to anticipate some of these changes. The - -14 -00:00:41,680 --> 00:00:45,390 -third pillar is the structuring for validation. Also called design - -15 -00:00:45,390 --> 00:00:47,550 -for testability. And what this means is that we - -16 -00:00:47,550 --> 00:00:50,760 -want to build software so that it is easily testable - -17 -00:00:50,760 --> 00:00:54,890 -during the subsequent validation and verification activities. Finally, and - -18 -00:00:54,890 --> 00:00:58,040 -this is especially true within specific organizations and or - -19 -00:00:58,040 --> 00:01:00,770 -domains. It is important that the software conforms to - -20 -00:01:00,770 --> 00:01:04,330 -a set of internal or external standards. And some examples - -21 -00:01:04,330 --> 00:01:06,730 -of this might be, for example, for internal standards, - -22 -00:01:06,730 --> 00:01:10,680 -coding standards within an organization, or naming standards within an - -23 -00:01:10,680 --> 00:01:13,320 -organization. As for external standards, if for example you - -24 -00:01:13,320 --> 00:01:15,780 -are developing some medical software. There are some regulations and - -25 -00:01:15,780 --> 00:01:17,930 -some standards that you have to adhere to in - -26 -00:01:17,930 --> 00:01:20,060 -order for your software to be valid in that domain. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/6 - Verification & Validation - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/6 - Verification & Validation - lang_en_vs4.srt deleted file mode 100644 index df504a2..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/6 - Verification & Validation - lang_en_vs4.srt +++ /dev/null @@ -1,123 +0,0 @@ -1 -00:00:00,120 --> 00:00:03,550 -After we have built our system, verification and validation - -2 -00:00:03,550 --> 00:00:05,970 -is that phase of software development that aims to - -3 -00:00:05,970 --> 00:00:09,000 -check that the software system meets its specification and - -4 -00:00:09,000 --> 00:00:12,800 -fulfills its intended purpose. More precisely, we can look - -5 -00:00:12,800 --> 00:00:16,250 -at verification and validation independently. And validation is the - -6 -00:00:16,250 --> 00:00:19,100 -activity that answers the question did we build the - -7 -00:00:19,100 --> 00:00:21,420 -right system. Did we build the system that the - -8 -00:00:21,420 --> 00:00:26,030 -customer wants? That will make the customer happy. Whereas verification - -9 -00:00:26,030 --> 00:00:28,730 -answers a different question which is did we build the system - -10 -00:00:28,730 --> 00:00:31,410 -right. So given a description of the system that is the one - -11 -00:00:31,410 --> 00:00:34,280 -that we derived from the customer through the collection of requirements - -12 -00:00:34,280 --> 00:00:37,130 -and then design and so on, did we build a system that - -13 -00:00:37,130 --> 00:00:41,150 -actually implements the specification that we defined? And when we look - -14 -00:00:41,150 --> 00:00:44,600 -at verification there's many, many ways of doing verification and in fact - -15 -00:00:44,600 --> 00:00:48,430 -in the mini course number four we will cover verification extensively. The - -16 -00:00:48,430 --> 00:00:51,100 -only thing I want to mention here is the fact that verification - -17 -00:00:51,100 --> 00:00:54,110 -can be performed at different levels. In particular, it can be - -18 -00:00:54,110 --> 00:00:57,810 -performed at the unit level in which we test that the individual - -19 -00:00:57,810 --> 00:01:01,520 -units work as a expected. Can be performed in the integration level - -20 -00:01:01,520 --> 00:01:05,525 -in which what we test is the interaction between the different units. - -21 -00:01:05,525 --> 00:01:07,630 -So we want to make sure that the different modules talk - -22 -00:01:07,630 --> 00:01:10,720 -to each other in the right way. And finally, there is system - -23 -00:01:10,720 --> 00:01:13,440 -testing in which we test the system as a whole and we - -24 -00:01:13,440 --> 00:01:16,170 -want to make sure that all the system, all the different pieces - -25 -00:01:16,170 --> 00:01:18,010 -of the system work together in the right - -26 -00:01:18,010 --> 00:01:20,160 -way. And this is also the level at which - -27 -00:01:20,160 --> 00:01:22,360 -then we will apply validation and some other - -28 -00:01:22,360 --> 00:01:25,770 -testing techniques like stress testing or robustness testing and - -29 -00:01:25,770 --> 00:01:29,890 -so on. And as I said I'm not going to say anything more on this topic because - -30 -00:01:29,890 --> 00:01:32,760 -we will cover verification, and validation, and testing in - -31 -00:01:32,760 --> 00:01:35,667 -particular in great details in mini course number four. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/7 - Maintenance - lang_en_vs5.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/7 - Maintenance - lang_en_vs5.srt deleted file mode 100644 index e3d95bf..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/7 - Maintenance - lang_en_vs5.srt +++ /dev/null @@ -1,167 +0,0 @@ -1 -00:00:00,012 --> 00:00:03,482 -As we discussed before software development efforts normally result - -2 -00:00:03,482 --> 00:00:06,127 -in the delivery of a software product that satisfies - -3 -00:00:06,127 --> 00:00:09,879 -the user requirements. So normally our software development organization - -4 -00:00:09,879 --> 00:00:13,127 -will release this application to its final users, however, once - -5 -00:00:13,127 --> 00:00:16,090 -the software is in operation many things can happen. - -6 -00:00:16,090 --> 00:00:18,950 -So, for example, the environment might change. There might be - -7 -00:00:18,950 --> 00:00:21,940 -new libraries. There might be new systems in which - -8 -00:00:21,940 --> 00:00:25,070 -our software has to operate. Or they may be future - -9 -00:00:25,070 --> 00:00:27,950 -requests, so the users may find out that, guess what, - -10 -00:00:27,950 --> 00:00:30,370 -they want to do something different with the problem that - -11 -00:00:30,370 --> 00:00:32,835 -we gave them. Or, again, and this is one of - -12 -00:00:32,835 --> 00:00:35,970 -the most common occurrences, users might find problems with the - -13 -00:00:35,970 --> 00:00:38,307 -software and may file bug reports and send the bug - -14 -00:00:38,307 --> 00:00:42,090 -reports back to the software developer. These are the reasons - -15 -00:00:42,090 --> 00:00:46,420 -why software maintenance is a necessary phase in software development. - -16 -00:00:46,420 --> 00:00:50,190 -Software maintenance is the activity that sustains the software product - -17 -00:00:50,190 --> 00:00:53,780 -as it evolves throughout its life cycle, specifically - -18 -00:00:53,780 --> 00:00:57,350 -in response to bug reports, feature requests and - -19 -00:00:57,350 --> 00:01:00,890 -environment changes. Development organisations perform three kinds of - -20 -00:01:00,890 --> 00:01:04,450 -maintenance activities: corrective maintenance to eliminate problems with the - -21 -00:01:04,450 --> 00:01:07,740 -code, perfective maintenance to accommodate feature request, and - -22 -00:01:07,740 --> 00:01:09,730 -in some cases just to improve the software, for - -23 -00:01:09,730 --> 00:01:12,230 -example, to make it more efficient, and finally, - -24 -00:01:12,230 --> 00:01:15,650 -adaptive maintenance, to take care of the environment changes. - -25 -00:01:15,650 --> 00:01:18,470 -And after this activities have been performed, the software developer - -26 -00:01:18,470 --> 00:01:21,540 -will produce a new version of the application, will release it - -27 -00:01:21,540 --> 00:01:24,150 -and the cycle will continue through out the lifetime of - -28 -00:01:24,150 --> 00:01:27,440 -the software. That's why maintenance is a fundamental activity and a - -29 -00:01:27,440 --> 00:01:30,420 -very expensive one. And one of the reasons why maintenance - -30 -00:01:30,420 --> 00:01:34,080 -is expensive, that I want to mention now, is regression testing. - -31 -00:01:34,080 --> 00:01:37,180 -During maintenance every time you modify your application you have - -32 -00:01:37,180 --> 00:01:41,120 -to regression test the application, where regression testing is the activity - -33 -00:01:41,120 --> 00:01:44,010 -of retesting software after it has been modified to make sure - -34 -00:01:44,010 --> 00:01:47,320 -that the changes you perform to the software work as expected, - -35 -00:01:47,320 --> 00:01:51,540 -and that your changes did not introduce any unforseen effect. I'm - -36 -00:01:51,540 --> 00:01:53,630 -pretty sure that you're familiar with the case of a new - -37 -00:01:53,630 --> 00:01:56,000 -version of the software being released and just a couple of - -38 -00:01:56,000 --> 00:01:59,260 -days later another version being released to fix some problems that - -39 -00:01:59,260 --> 00:02:02,000 -occor with the new version. These problems is what we call - -40 -00:02:02,000 --> 00:02:04,640 -regression errors and they're what regression - -41 -00:02:04,640 --> 00:02:06,560 -testing targets and tries to eliminate - -42 -00:02:06,560 --> 00:02:09,240 -before the new version of the software is released into the world. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/8 - Software Phases Quiz - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/8 - Software Phases Quiz - lang_en_vs4.srt deleted file mode 100644 index e3fe74b..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/8 - Software Phases Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,47 +0,0 @@ -1 -00:00:00,070 --> 00:00:02,590 -Okay. Now before we jump into the next - -2 -00:00:02,590 --> 00:00:04,780 -topic, I just want to take a very quick and - -3 -00:00:04,780 --> 00:00:06,630 -simple quiz just to make sure that you - -4 -00:00:06,630 --> 00:00:09,236 -guys paid attention to what I just discussed. So - -5 -00:00:09,236 --> 00:00:10,820 -I want to ask you what are the traditional - -6 -00:00:10,820 --> 00:00:13,200 -software phases. Requirements engineering, - -7 -00:00:13,200 --> 00:00:16,079 -design, abstraction, implementation, verification and - -8 -00:00:16,079 --> 00:00:18,020 -validation. Or maybe design, - -9 -00:00:18,020 --> 00:00:20,830 -optimization, implementation verification and validation - -10 -00:00:20,830 --> 00:00:22,448 -and maintenance. Or requirements - -11 -00:00:22,448 --> 00:00:24,892 -engineering, design, implementation, verification and - -12 -00:00:24,892 --> 00:00:26,290 -validation, and maintenance. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/9 - Software Phases Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/9 - Software Phases Quiz Solution - lang_en_vs4.srt deleted file mode 100644 index ecb7a35..0000000 --- a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/9 - Software Phases Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,15 +0,0 @@ -1 -00:00:00,190 --> 00:00:04,000 -And the answer is the third one. The traditional software phases which are the - -2 -00:00:04,000 --> 00:00:05,960 -ones that we just discussed are requirements - -3 -00:00:05,960 --> 00:00:08,820 -engineering, design, implementation, verification - -4 -00:00:08,820 --> 00:00:10,630 -and validation, and maintenance. |