1 files changed, 0 insertions, 231 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
deleted file mode 100644
index e09b6fc..0000000
--- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt
+++ /dev/null
@@ -1,231 +0,0 @@
-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.