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.