1 files changed, 179 insertions, 0 deletions
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/15 - Iterative Approach Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/15 - Iterative Approach Quiz Solution - lang_en_vs5.srt
new file mode 100644
index 0000000..6e69cec
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/15 - Iterative Approach Quiz Solution - lang_en_vs5.srt
@@ -0,0 +1,179 @@
+1
+00:00:00,180 --> 00:00:01,740
+Okay so let's look at the first one. Well I
+
+2
+00:00:01,740 --> 00:00:04,760
+don't think that the fact of keeping developers busy is really
+
+3
+00:00:04,760 --> 00:00:08,020
+one of the highlights or the main benefits of iterative
+
+4
+00:00:08,020 --> 00:00:12,310
+approaches. Developers are really busy without any need for additional help.
+
+5
+00:00:12,310 --> 00:00:14,950
+So I will just not mark this one. The second
+
+6
+00:00:14,950 --> 00:00:19,280
+one conversely is definitely one of the advantages of iterative approaches.
+
+7
+00:00:19,280 --> 00:00:21,710
+So the fact that iterative approaches give the developers a early
+
+8
+00:00:21,710 --> 00:00:25,890
+feedback, is a great advantage which has in turn additional advantages.
+
+9
+00:00:25,890 --> 00:00:29,340
+For example, it increases the project tempo, so it gives the developers
+
+10
+00:00:29,340 --> 00:00:32,350
+not busy but more focused. It's easier to be focused when you
+
+11
+00:00:32,350 --> 00:00:35,790
+have a short term deadline, or a short term goal
+
+12
+00:00:35,790 --> 00:00:38,670
+rather than a release that is planned in six months or even
+
+13
+00:00:38,670 --> 00:00:42,420
+later. Another advantage of this early feedback is the fact that developers
+
+14
+00:00:42,420 --> 00:00:45,390
+are rewarded for their efforts so, there is sort of an immediate
+
+15
+00:00:45,390 --> 00:00:48,360
+rewards because you can see the results of your effort instead of
+
+16
+00:00:48,360 --> 00:00:51,310
+having to wait a long time to see such results. And last,
+
+17
+00:00:51,310 --> 00:00:55,126
+but not least the fact of getting early feedback also minimizes
+
+18
+00:00:55,126 --> 00:00:58,570
+the risks of developing the wrong system. So why is that?
+
+19
+00:00:58,570 --> 00:01:01,820
+Well because getting early feedback will also allow us to find
+
+20
+00:01:01,820 --> 00:01:05,140
+out whether we're going in the wrong direction early in the development process
+
+21
+00:01:05,140 --> 00:01:08,460
+rather than at the end. And therefore, will minimize this risk.
+
+22
+00:01:08,460 --> 00:01:10,760
+Going back to the previous question, yeah, I don't think that, you
+
+23
+00:01:10,760 --> 00:01:12,960
+know, doing the same thing over and over is a great
+
+24
+00:01:12,960 --> 00:01:16,170
+advantage. And in fact, iterative approaches do not do the same thing
+
+25
+00:01:16,170 --> 00:01:18,940
+over and over. So they keep iterating, but they keep
+
+26
+00:01:18,940 --> 00:01:21,930
+augmenting the amount of functionality in the system. They don't
+
+27
+00:01:21,930 --> 00:01:24,960
+just repeat the same thing. As for improving planning, actually
+
+28
+00:01:24,960 --> 00:01:27,980
+improving planning is not really a strength of these approaches,
+
+29
+00:01:27,980 --> 00:01:30,880
+because sometimes the number of iterations is hard to predict,
+
+30
+00:01:30,880 --> 00:01:33,050
+so it's hard to do a natural planning when you
+
+31
+00:01:33,050 --> 00:01:36,440
+are using an iterative approach. So finally, are iterative approaches
+
+32
+00:01:36,440 --> 00:01:38,700
+good for accomodating evolving requirements?
+
+33
+00:01:38,700 --> 00:01:41,630
+Most definitely. First, iterative approaches, and
+
+34
+00:01:41,630 --> 00:01:44,590
+in particular, the one that we're discussing consider requirements
+
+35
+00:01:44,590 --> 00:01:47,900
+incrementally, so they can better incorporate your requirements. So if
+
+36
+00:01:47,900 --> 00:01:51,030
+there are new requirements, it's easier to accommodate them using
+
+37
+00:01:51,030 --> 00:01:55,210
+an iterative approach. Second, these approaches realize a few requirements
+
+38
+00:01:55,210 --> 00:01:57,740
+at a time. Something from the most risky ones, as
+
+39
+00:01:57,740 --> 00:02:00,600
+we said. So any problem with those risky requirements will
+
+40
+00:02:00,600 --> 00:02:04,220
+be discovered early, and suitable course corrections could be taken.
+
+41
+00:02:04,220 --> 00:02:06,850
+So in case you still have doubts about iterative approaches,
+
+42
+00:02:06,850 --> 00:02:08,460
+it might be worth it to go back to
+
+43
+00:02:08,460 --> 00:02:11,390
+mini course number one, lesson number two to discuss the
+
+44
+00:02:11,390 --> 00:02:14,620
+life cycle models. Because we talk about iterative approaches
+
+45
+00:02:14,620 --> 00:02:17,770
+and their advantages and their characteristics there in some detail.