From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 24 May 2020 16:34:31 +0700 Subject: [usth/ICT2.7] Engineer software --- ...Introduction with Barry Boehm - lang_en_vs7.srt | 163 ++++++++++++++++++ ...re Process Model Introduction - lang_en_vs4.srt | 79 +++++++++ .../11 - Waterfall Process - lang_en_vs4.srt | 95 ++++++++++ .../12 - Spiral Process - lang_en_vs4.srt | 191 +++++++++++++++++++++ ...lutionary Prototyping Process - lang_en_vs4.srt | 167 ++++++++++++++++++ ...lutionary Prototyping Process - lang_pt_vs2.srt | 167 ++++++++++++++++++ ...14 - Rational Unified Process - lang_en_vs5.srt | 111 ++++++++++++ ...14 - Rational Unified Process - lang_pt_vs1.srt | 111 ++++++++++++ .../15 - Agile Process - lang_en_vs3.srt | 123 +++++++++++++ .../15 - Agile Process - lang_pt_vs1.srt | 123 +++++++++++++ .../16 - Choosing a Model - lang_en_vs4.srt | 179 +++++++++++++++++++ .../17 - Choosing a Model Quiz - lang_en_vs4.srt | 35 ++++ ...hoosing a Model Quiz Solution - lang_en_vs5.srt | 47 +++++ .../19 - Choosing a Model Quiz - lang_en_vs5.srt | 11 ++ ...- Traditional Software Phases - lang_en_vs4.srt | 75 ++++++++ ...hoosing a Model Quiz Solution - lang_en_vs4.srt | 67 ++++++++ .../21 - Lifecycle Documents - lang_en_vs4.srt | 67 ++++++++ ...22 - Classic Mistakes: People - lang_en_vs4.srt | 163 ++++++++++++++++++ ...3 - Classic Mistakes: Process - lang_en_vs4.srt | 79 +++++++++ ...4 - Classic Mistakes: Product - lang_en_vs4.srt | 87 ++++++++++ ... Classic Mistakes: Technology - lang_en_vs4.srt | 95 ++++++++++ .../26 - Classic Mistakes Quiz - lang_en_vs4.srt | 23 +++ ...lassic Mistakes Quiz Solution - lang_en_vs4.srt | 39 +++++ .../3 - Requirements Engineering - lang_en_vs4.srt | 175 +++++++++++++++++++ .../4 - Design - lang_en_vs4.srt | 103 +++++++++++ .../5 - Implementation - lang_en_vs5.srt | 103 +++++++++++ ...6 - Verification & Validation - lang_en_vs4.srt | 123 +++++++++++++ .../7 - Maintenance - lang_en_vs5.srt | 167 ++++++++++++++++++ .../8 - Software Phases Quiz - lang_en_vs4.srt | 47 +++++ ...Software Phases Quiz Solution - lang_en_vs4.srt | 15 ++ 30 files changed, 3030 insertions(+) create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/1 - Introduction with Barry Boehm - lang_en_vs7.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/10 - Software Process Model Introduction - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/11 - Waterfall Process - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/12 - Spiral Process - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_pt_vs2.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_pt_vs1.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_en_vs3.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_pt_vs1.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/16 - Choosing a Model - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/17 - Choosing a Model Quiz - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/18 - Choosing a Model Quiz Solution - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/19 - Choosing a Model Quiz - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/2 - Traditional Software Phases - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/20 - Choosing a Model Quiz Solution - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/21 - Lifecycle Documents - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/22 - Classic Mistakes: People - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/23 - Classic Mistakes: Process - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/24 - Classic Mistakes: Product - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/25 - Classic Mistakes: Technology - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/26 - Classic Mistakes Quiz - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/27 - Classic Mistakes Quiz Solution - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/4 - Design - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/5 - Implementation - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/6 - Verification & Validation - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/7 - Maintenance - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/8 - Software Phases Quiz - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P1L2 Life Cycle Models Subtitles/9 - Software Phases Quiz Solution - lang_en_vs4.srt (limited to 'usth/ICT2.7/P1L2 Life Cycle Models Subtitles') 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 new file mode 100644 index 0000000..954db98 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/1 - Introduction with Barry Boehm - lang_en_vs7.srt @@ -0,0 +1,163 @@ +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 new file mode 100644 index 0000000..39d418b --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/10 - Software Process Model Introduction - lang_en_vs4.srt @@ -0,0 +1,79 @@ +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 new file mode 100644 index 0000000..b3d7c07 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/11 - Waterfall Process - lang_en_vs4.srt @@ -0,0 +1,95 @@ +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 new file mode 100644 index 0000000..2d0cdf9 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/12 - Spiral Process - lang_en_vs4.srt @@ -0,0 +1,191 @@ +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 new file mode 100644 index 0000000..cf068c0 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_en_vs4.srt @@ -0,0 +1,167 @@ +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 new file mode 100644 index 0000000..a1fefdc --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_pt_vs2.srt @@ -0,0 +1,167 @@ +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 new file mode 100644 index 0000000..8bc6db8 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_en_vs5.srt @@ -0,0 +1,111 @@ +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 new file mode 100644 index 0000000..cb089cb --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_pt_vs1.srt @@ -0,0 +1,111 @@ +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 new file mode 100644 index 0000000..70ef200 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_en_vs3.srt @@ -0,0 +1,123 @@ +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 new file mode 100644 index 0000000..b2224ea --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_pt_vs1.srt @@ -0,0 +1,123 @@ +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 new file mode 100644 index 0000000..d898337 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/16 - Choosing a Model - lang_en_vs4.srt @@ -0,0 +1,179 @@ +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 new file mode 100644 index 0000000..9f733ac --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/17 - Choosing a Model Quiz - lang_en_vs4.srt @@ -0,0 +1,35 @@ +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 new file mode 100644 index 0000000..01a444c --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/18 - Choosing a Model Quiz Solution - lang_en_vs5.srt @@ -0,0 +1,47 @@ +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 new file mode 100644 index 0000000..570d146 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/19 - Choosing a Model Quiz - lang_en_vs5.srt @@ -0,0 +1,11 @@ +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 new file mode 100644 index 0000000..cc522f0 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/2 - Traditional Software Phases - lang_en_vs4.srt @@ -0,0 +1,75 @@ +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 new file mode 100644 index 0000000..7ea0e4f --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/20 - Choosing a Model Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,67 @@ +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 new file mode 100644 index 0000000..20e1102 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/21 - Lifecycle Documents - lang_en_vs4.srt @@ -0,0 +1,67 @@ +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 new file mode 100644 index 0000000..7edb042 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/22 - Classic Mistakes: People - lang_en_vs4.srt @@ -0,0 +1,163 @@ +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 new file mode 100644 index 0000000..83720a0 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/23 - Classic Mistakes: Process - lang_en_vs4.srt @@ -0,0 +1,79 @@ +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 new file mode 100644 index 0000000..24972d9 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/24 - Classic Mistakes: Product - lang_en_vs4.srt @@ -0,0 +1,87 @@ +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 new file mode 100644 index 0000000..16810ac --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/25 - Classic Mistakes: Technology - lang_en_vs4.srt @@ -0,0 +1,95 @@ +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 new file mode 100644 index 0000000..2b4263f --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/26 - Classic Mistakes Quiz - lang_en_vs4.srt @@ -0,0 +1,23 @@ +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 new file mode 100644 index 0000000..53c2485 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/27 - Classic Mistakes Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,39 @@ +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 new file mode 100644 index 0000000..c541e70 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt @@ -0,0 +1,175 @@ +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 new file mode 100644 index 0000000..5ddb4d1 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/4 - Design - lang_en_vs4.srt @@ -0,0 +1,103 @@ +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 new file mode 100644 index 0000000..465ae1b --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/5 - Implementation - lang_en_vs5.srt @@ -0,0 +1,103 @@ +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 new file mode 100644 index 0000000..df504a2 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/6 - Verification & Validation - lang_en_vs4.srt @@ -0,0 +1,123 @@ +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 new file mode 100644 index 0000000..e3d95bf --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/7 - Maintenance - lang_en_vs5.srt @@ -0,0 +1,167 @@ +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 new file mode 100644 index 0000000..e3fe74b --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/8 - Software Phases Quiz - lang_en_vs4.srt @@ -0,0 +1,47 @@ +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 new file mode 100644 index 0000000..ecb7a35 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/9 - Software Phases Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,15 @@ +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. -- cgit 1.4.1