about summary refs log tree commit diff
path: root/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/7 - Maintenance - lang_en_vs5.srt
blob: e3d95bfdea386b1a28b5f4767bb894d67c1aa017 (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
1
00:00:00,012 --> 00:00:03,482
As we discussed before software development efforts normally result

2
00:00:03,482 --> 00:00:06,127
in the delivery of a software product that satisfies

3
00:00:06,127 --> 00:00:09,879
the user requirements. So normally our software development organization

4
00:00:09,879 --> 00:00:13,127
will release this application to its final users, however, once

5
00:00:13,127 --> 00:00:16,090
the software is in operation many things can happen.

6
00:00:16,090 --> 00:00:18,950
So, for example, the environment might change. There might be

7
00:00:18,950 --> 00:00:21,940
new libraries. There might be new systems in which

8
00:00:21,940 --> 00:00:25,070
our software has to operate. Or they may be future

9
00:00:25,070 --> 00:00:27,950
requests, so the users may find out that, guess what,

10
00:00:27,950 --> 00:00:30,370
they want to do something different with the problem that

11
00:00:30,370 --> 00:00:32,835
we gave them. Or, again, and this is one of

12
00:00:32,835 --> 00:00:35,970
the most common occurrences, users might find problems with the

13
00:00:35,970 --> 00:00:38,307
software and may file bug reports and send the bug

14
00:00:38,307 --> 00:00:42,090
reports back to the software developer. These are the reasons

15
00:00:42,090 --> 00:00:46,420
why software maintenance is a necessary phase in software development.

16
00:00:46,420 --> 00:00:50,190
Software maintenance is the activity that sustains the software product

17
00:00:50,190 --> 00:00:53,780
as it evolves throughout its life cycle, specifically

18
00:00:53,780 --> 00:00:57,350
in response to bug reports, feature requests and

19
00:00:57,350 --> 00:01:00,890
environment changes. Development organisations perform three kinds of

20
00:01:00,890 --> 00:01:04,450
maintenance activities: corrective maintenance to eliminate problems with the

21
00:01:04,450 --> 00:01:07,740
code, perfective maintenance to accommodate feature request, and

22
00:01:07,740 --> 00:01:09,730
in some cases just to improve the software, for

23
00:01:09,730 --> 00:01:12,230
example, to make it more efficient, and finally,

24
00:01:12,230 --> 00:01:15,650
adaptive maintenance, to take care of the environment changes.

25
00:01:15,650 --> 00:01:18,470
And after this activities have been performed, the software developer

26
00:01:18,470 --> 00:01:21,540
will produce a new version of the application, will release it

27
00:01:21,540 --> 00:01:24,150
and the cycle will continue through out the lifetime of

28
00:01:24,150 --> 00:01:27,440
the software. That's why maintenance is a fundamental activity and a

29
00:01:27,440 --> 00:01:30,420
very expensive one. And one of the reasons why maintenance

30
00:01:30,420 --> 00:01:34,080
is expensive, that I want to mention now, is regression testing.

31
00:01:34,080 --> 00:01:37,180
During maintenance every time you modify your application you have

32
00:01:37,180 --> 00:01:41,120
to regression test the application, where regression testing is the activity

33
00:01:41,120 --> 00:01:44,010
of retesting software after it has been modified to make sure

34
00:01:44,010 --> 00:01:47,320
that the changes you perform to the software work as expected,

35
00:01:47,320 --> 00:01:51,540
and that your changes did not introduce any unforseen effect. I'm

36
00:01:51,540 --> 00:01:53,630
pretty sure that you're familiar with the case of a new

37
00:01:53,630 --> 00:01:56,000
version of the software being released and just a couple of

38
00:01:56,000 --> 00:01:59,260
days later another version being released to fix some problems that

39
00:01:59,260 --> 00:02:02,000
occor with the new version. These problems is what we call

40
00:02:02,000 --> 00:02:04,640
regression errors and they're what regression

41
00:02:04,640 --> 00:02:06,560
testing targets and tries to eliminate

42
00:02:06,560 --> 00:02:09,240
before the new version of the software is released into the world.