1
0
Fork 0
cp/usth/ICT2.7/P1L2 Life Cycle Models Subt.../7 - Maintenance - lang_en_v...

168 lines
4.0 KiB
Plaintext

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.