1 files changed, 95 insertions, 0 deletions
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.