about summary refs log tree commit diff
path: root/usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt
blob: e09b6fcdbc16d24e85edb6f1f0e835b3dfb7eaed (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
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.