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