1 files changed, 231 insertions, 0 deletions
diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt
new file mode 100644
index 0000000..e09b6fc
--- /dev/null
+++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt
@@ -0,0 +1,231 @@
+1
+00:00:00,300 --> 00:00:02,080
+But if we are ready to go to the market,
+
+2
+00:00:02,080 --> 00:00:04,800
+if we are ready to deploy our product, then we can
+
+3
+00:00:04,800 --> 00:00:07,160
+move to the transition phase, which has mainly to do
+
+4
+00:00:07,160 --> 00:00:10,360
+with deployment and maintainence of a system. So what are the
+
+5
+00:00:10,360 --> 00:00:12,950
+main activities in the transition phase? As we discussed in
+
+6
+00:00:12,950 --> 00:00:16,280
+our initial lessons, in most real world cases, there are issues
+
+7
+00:00:16,280 --> 00:00:20,820
+that manifest themselves after deployment, when we release our software and
+
+8
+00:00:20,820 --> 00:00:22,870
+actual users interact with the
+
+9
+00:00:22,870 --> 00:00:26,230
+software. Specifically, users might report failures
+
+10
+00:00:26,230 --> 00:00:28,965
+that they experienced while using the system. So, what we call
+
+11
+00:00:28,965 --> 00:00:33,120
+bug reports. Or they might report improvements they might want to see
+
+12
+00:00:33,120 --> 00:00:36,798
+in the software. So typically these will be new feature requests. And
+
+13
+00:00:36,798 --> 00:00:40,270
+in addition, there might be issues that don't come necessarily from the
+
+14
+00:00:40,270 --> 00:00:42,734
+users but that are related to the fact that our system
+
+15
+00:00:42,734 --> 00:00:45,920
+has to operate, has to work in a new execution environment. For
+
+16
+00:00:45,920 --> 00:00:48,930
+example, the new version of an operating system, or the new version
+
+17
+00:00:48,930 --> 00:00:51,474
+of a set of libraries. When this happens, we have to address
+
+18
+00:00:51,474 --> 00:00:55,020
+these issues by performing maintenance. Specifically, corrective maintenance
+
+19
+00:00:55,020 --> 00:00:58,900
+for bug reports, perfective maintenance, for feature requests, and
+
+20
+00:00:58,900 --> 00:01:02,270
+adaptive maintenance, for environment changes. And the result of
+
+21
+00:01:02,270 --> 00:01:04,319
+this is that we will have a new release
+
+22
+00:01:04,319 --> 00:01:06,550
+of the software. Other activities that are performed in
+
+23
+00:01:06,550 --> 00:01:10,480
+this phase include training, customer service, and providing help-line
+
+24
+00:01:10,480 --> 00:01:13,350
+assistance. Finally, if you remember what we saw when
+
+25
+00:01:13,350 --> 00:01:16,810
+we were looking at the banking IT system example,
+
+26
+00:01:16,810 --> 00:01:21,300
+the cycles within a development are not necessarily completely dis-joined, but
+
+27
+00:01:21,300 --> 00:01:23,940
+they might overlap a little bit. So something else that might
+
+28
+00:01:23,940 --> 00:01:26,650
+happen in the transition phase is that a new cycle may
+
+29
+00:01:26,650 --> 00:01:29,020
+start. So there might be some activities that are related to
+
+30
+00:01:29,020 --> 00:01:32,190
+the fact that we're starting to think about the new cycle.
+
+31
+00:01:32,190 --> 00:01:35,150
+So now let's see what kind of outcome these activities will
+
+32
+00:01:35,150 --> 00:01:38,410
+produce. The first one is a complete project with all the
+
+33
+00:01:38,410 --> 00:01:41,820
+artifacts that we mentioned before. Another outcome is that the product will
+
+34
+00:01:41,820 --> 00:01:44,090
+be actually in use. So the product will be in the
+
+35
+00:01:44,090 --> 00:01:46,870
+hands of the users and the users will start using it, will
+
+36
+00:01:46,870 --> 00:01:49,760
+start interacting with it, for real, not just in a beta testing
+
+37
+00:01:49,760 --> 00:01:53,260
+setting. Another outcome will be a lesson learnt. What worked. What didn't
+
+38
+00:01:53,260 --> 00:01:56,240
+work. What should we do different in the next cycle or in
+
+39
+00:01:56,240 --> 00:01:59,446
+the next development? And this is a very important part of the
+
+40
+00:01:59,446 --> 00:02:01,651
+whole process, because it;s what provides
+
+41
+00:02:01,651 --> 00:02:04,378
+feedback between cycles, and between projects.
+
+42
+00:02:04,378 --> 00:02:07,018
+And as we said before, in case we have a next released
+
+43
+00:02:07,018 --> 00:02:09,478
+planned or a next cycle coming up, we might want to
+
+44
+00:02:09,478 --> 00:02:12,922
+start planning for the next release. So another outcome will be
+
+45
+00:02:12,922 --> 00:02:15,783
+the plan for the next release. So similar to the other
+
+46
+00:02:15,783 --> 00:02:19,147
+phases, also for the transition phase, we have a milestone, which
+
+47
+00:02:19,147 --> 00:02:21,733
+is the fourth milestone in this case. And therefore we
+
+48
+00:02:21,733 --> 00:02:25,061
+have evaluation criteria for the transition phase that will define whether
+
+49
+00:02:25,061 --> 00:02:28,530
+we've reached the milestone or not. And in this case, one
+
+50
+00:02:28,530 --> 00:02:32,040
+important assessment is whether the user is satisfied. So users are
+
+51
+00:02:32,040 --> 00:02:34,370
+actually using our product now, so we can get feedback
+
+52
+00:02:34,370 --> 00:02:36,260
+from them, we can see whether the product makes them
+
+53
+00:02:36,260 --> 00:02:40,390
+happy or not. And we continue assessing whether our expenditures
+
+54
+00:02:40,390 --> 00:02:43,460
+are fine with respect to our estimates. And in this case,
+
+55
+00:02:43,460 --> 00:02:46,882
+problems with this milestone might lead to further maintenance of
+
+56
+00:02:46,882 --> 00:02:48,840
+the system. So for example, we might need to produce
+
+57
+00:02:48,840 --> 00:02:51,460
+a new release to address some of the issues that
+
+58
+00:02:51,460 --> 00:02:54,410
+the users identified, as we discussed a couple of minutes ago.