[usth/ICT2.7] Engineer software

author: Nguyễn Gia Phong <mcsinyx@disroot.org> 2020-05-24 16:34:31 +0700
committer: Nguyễn Gia Phong <mcsinyx@disroot.org> 2020-05-24 16:34:31 +0700
commit: b2d80610db6beda38573890ed169815e495bc663 (patch)
tree: 176e1bca6fe644c619d53cf1c24682c244b79cf6 /usth/ICT2.7/P1L2 Life Cycle Models Subtitles
parent: 49376ab97c7427f1c1eca64072d1a934c2e52f50 (diff)
download: cp-b2d80610db6beda38573890ed169815e495bc663.tar.gz
30 files changed, 3030 insertions, 0 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
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
+&gt;&gt; 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.
author	Nguyễn Gia Phong <mcsinyx@disroot.org>	2020-05-24 16:34:31 +0700
committer	Nguyễn Gia Phong <mcsinyx@disroot.org>	2020-05-24 16:34:31 +0700
commit	b2d80610db6beda38573890ed169815e495bc663 (patch)
tree	176e1bca6fe644c619d53cf1c24682c244b79cf6 /usth/ICT2.7/P1L2 Life Cycle Models Subtitles
parent	49376ab97c7427f1c1eca64072d1a934c2e52f50 (diff)
download	cp-b2d80610db6beda38573890ed169815e495bc663.tar.gz