Need to write about 350-word summary of EACH CHAPTER, so that it contains:
(part 1) important concepts of the chapter
(part 2) experience/application/opinions of the chapter.
Total 4 chapters, 350 word for each
Chapter
2
. The Maintenance
Framework
2.
1
Definitions
2.2 Components of Maintenance Frame Work
(maintenance Factors)
2.
3
Relationship between the maintenance factors
1
2.1 Definitions
Framework: a set of ideas, conditions or
assumptions that determine how some things are
approached, perceived or understood.
Software maintenance framework:
the context and environment in which software
maintenance activity is carried out.
i.e., a set of ideas, conditions or assumptions that
determine how software maintenance is approached,
perceived or understood.
2
Environment: the totality of conditions and influences which
act from outside upon entity
– Operational Environment: all software and hardware that
influence the software in any way
– Non-operational (organizational) environment: all non-
software/hardware that influence the software
Maintenance Process: any activity carried out or an action
taken, either by machine or maintenance personnel during
software maintenance
Information gap: the discrepancy between the body of
knowledge that system users/maintainer possess and the body
of knowledge that are needed to have in order to satisfy a
request for change (maintenance)
3
2.2 Components of the Software Maintenance
Frame Work (SMF)
A software maintenance framework is used to discuss the factors that
affect the maintenance activities.
In order to understand the source of software maintenance
difficulties, one needs to understand the following factors, and
their interactions.
Factor 1. User Requirements: User is any individual who uses the
software regardless of their involvement in its development or
maintenance.
Who Requests for additional functionality, refine existing functions,
better structure, better documentation, more understandable
for future maintenance
4
Factor 2. Environment (operational or non-operational)
• Operational environment: hardware and/or software
innovation
• Non-operational environment: policy change, Market
competition
Factor 3. Maintenance Process:
The maintenance process itself is the most important part in
the software maintenance framework. It covers the following
tasks:
5
• Capturing the requirement: this is the process of finding out
what changes are required
• Variation in programming practice: means the differences in
approaches used for writing and maintaining the software =>
different approaches used for writing and maintaining programs.
Basic guidelines (e.g. meaningful identifiers, no ‘GOTO’s) avoid
this problem.
• Paradigm shift: refers to an alteration in the way we develop and
maintain software, i.e., use of techniques and tools if necessary
=> There are still many systems in use developed in low-level
programming languages.
• Error detection and correction: the early an error is detected
and corrected, the cost is lower (up to several hundred fold)
6
FrpFrom
7
From Chapter 1
• “Dead” paradigms for “living” systems: refers to
difficulties to accommodate the changing needs of
the users and their organizations once the system
has been delivered to users.
“Fixed Point Theorem” leads to the development
of “dead” systems, system that are designed to
meet the needs of the users at one time but not
“living” system that are designed to “breathe”,
i.e., adapt to changes.
=> Develop software changes in mind
8
Factor 4. Software Product
software products are seldom static but continuously
subject to change. The aspects of the such challenge
include:
• Maturity and difficulty of the application domain: the
mature application domain, the easier to change
• Quality of the documentation: lack of up-to-date
documentation is one of the major problem. The better
documentation, the easier the change.
• Malleability of the program: “soft” nature of software
product makes it more vulnerable to undesirable change
(one of the inherent problems of the software – F.P. Brooks)
• Inherent quality: tendency for the system to decay as
more changes are undertaken
9
10
Factor 5. Maintenance Personnel
• Staff Turnover: Maintainers are NOT original developers
due to turnover
• Domain Expertise: lack of domain expertise can make
the changes difficult
• Working Practice: the way the changes are carried out
11
12
2.3. Relationship between the maintenance factors
Figure 1
Chapter 3. Fundamentals of Software Change
3.
1
Classification/Categorization of Changes
3.
2
Relationship between software changes
3.3 Ongoing support
3.4 Eight Lehman’s “Laws”
1
3.1 Classification/Categorization of Change
(Corrective, Adaptive, Perfective and Preventive)
Why is it important to categorize?
Some changes require a faster response than others
Understanding the nature of the changes to be implemented
allows more effective prioritization of the change request
Different changes may require different approaches.
=> different resource allocations, different time-line etc.
2
Different Prioritizations
3
Fig. 3.1
4
Corrective Change
Two kinds: Emergency and Scheduled corrective
Fig. 3.2
5Fig. 3.3
Corrective Change: refers to modification initiated
by defects in the software.
Examples are:
Design Error,
Logic error,
Coding error as well as the
documentation error,
spec errors etc.
6
Table 1
7
8
9
Adaptive Change: is a change driven by the need to
accommodate the modifications in the environment
(operating and non-operating) of the software system.
10Fig. 3.4
Perfective Change:
is used to describe changes undertaken to expand the
requirements.
Expansion refers to enhancing the existing system
functionality or improvement in computational
efficiency (fine-tuning).
Typically, the software grows in size with successive
enhancements.
11
12
Requirement
Management
Fig. 3.5
Preventive Change:
changes done to address the problem of
deteriorating structure. It is typically undertaken to
prevent malfunctions or to improve maintainability
of the software.
Similar to perfective changes,
Not all candidates will be selected
They will be evaluated and put on the queue
13
3.2 Relationship between software changes3.2 Relationship between software changes
14
Adaptive Perfective
Corrective
Preventive
For example:
Adaptive
maintenance
may lead to
Corrective and
Preventive
maintenance
Changes done to software are usually released incrementally, i.e., not all
together. Major enhancements are typically planned, announced and released
and minor changes are made at that time
Fig. 3.6
3.3 Ongoing support
Ongoing support refers to non-programming related
maintenance work
• Effective communication: Maintenance is customer-
intensive activity. Hence, to establish a good customer
relations and co-operation through effective communication
increase the customer’s satisfaction.
• Training of users (technology transfer): it is important to
equip the users with sufficient knowledge and skills to use
the changed system.
Examples of such equipping process are: manual,
online help, on-site visits, or user group training.
• Provide business information: Providing users with various
types of timely and accurate information to enable them
take strategic business decision. For examples, technical
spec for the change, cost, release time.
15
3.4 Eight Lehman’s “Laws”
(applies mostly to Perfective Maintenance)
16
Describe the principles common to “large”, “live” software
systems.
• Def: E-type system: actively used and embedded systems in a real
world domain. Once such systems are operational, they are judged by
the results (performance) they deliver, satisfaction of the users.
(vs. S-type system: Specification based system)
(vs. P-type system: Problem based system)
Lehman’s System Types
S-system: formally defined, derivable from a specification
e.g., Matrix manipulation
P-system: requirements based on approximate solution to a
problem, but real-world remains stable
e.g., Chess program
E-system: embedded in the real world and changes as the
world does
e.g., Software to predict how economy functions (but
economy is not completely understood)
17
S-System
Problem solved is related to the real world
Fig. 3.7
18
P-System
The solution produces information that is compared with the
problem
Fig. 3.8
19
E-System
It is an integral part of the world it models
The changeability depends on its real-world context
Fig. 3.9
20
• Law I (1974) Continuing Change:
E-type systems must be continually adapted else they become
progressively less satisfactory in use
Law II (1974) Increasing Complexity:
As an E-type system is evolved its complexity increases unless
work is done to maintain or reduce it.
Law III (1974) Self Regulation:
Global E-type system (system developed in wider organizational
context) evolution processes are self-regulating, i.e., Positive
and negative feedback controls within wider context
ultimately determine the way the system evolves
=> System attributes such as size, time between releases, and the
number of reported errors is approximately invariant for each
system release.
21
Law IV (1978) Conservation of Organizational
Stability (Invariant work rate):
Unless feedback mechanisms are appropriately adjusted,
average effective global activity rate in an evolving E-
type system tends to remain constant over product
lifetime (Mythical Man-month) regardless of the resources
dedicated
22
Law V (1978) Conservation of Familiarity:
In general, the incremental growth and long term growth rate
of E-type systems tend to decline
From Lehman’s paper: “One of the factors that determines the
progress of a software development is the familiarity of all
involved with its goals.
The more changes & additions [in a] particular release, the
more difficult is for all concerned to be aware, to
understand and to appreciate what is required of them…
The larger the work package the more challenging mastery of
the matter to be acquired.”
23
Law VI (1991) Continuing Growth:
The functional capability of E-type systems must be
continually increased to maintain user satisfaction
over the system lifetime
Law VII (1996) Declining Quality:
Unless rigorously adapted to take into account changes
in the operational environment, the quality of E-type
systems will appear to be declining
(the system is perceived as older and less useful)
24
Law VIII (Recognized 1971,formulated 1996)
Feedback System:
E-type evolution processes are multi-level, multi-loop, multi-agent
feedback systems.
Multi-loop means that it is an iterative process and
multi-level refers to the fact that it occurs in more than
one aspect of the software and its documentation.
25
Chapter
4
. Limitation and Economic
Implications to Software Change
1
4.1 Economic Implications of Software Change
4.2 Limitations to Software Change
4.
3
. Potential Solutions to Maintenance Problem
2
4.1 Economic Implications of Software
Change
A large portion of computing resources is spent
towards software maintenance.
Studies have shown that the cost ranges between
6
0
–
7
5
% of computing resources.
Based on the study by Lientz and Swanson,
the allocation for each maintenance type is as
follows:
Perfective (50 %),
Adaptive (25 %),
Corrective (20%)
Preventive (5%)
The actual maintenance costs may differ
based on applications and settings.
Based on the study by Lientz and Swanson,
the allocation for each maintenance type is as
follows:
Perfective (50 %),
Adaptive (25 %),
Corrective (20%)
Preventive (5%)
The actual maintenance costs may differ
based on applications and settings.
3
4.2 Limitations to Software Change
All changes requested/required cannot be
performed due to the following reasons
Resources limitation: Lack of skilled
maintainer, suitable tools and environment,
insufficient budget
Quality of the existing system: Quality
becomes so poor that change is virtually
impossible and is no longer viable
4.2 Limitations to Software Change
All changes requested/required cannot be
performed due to the following reasons
Resources limitation: Lack of skilled
maintainer, suitable tools and environment,
insufficient budget
Quality of the existing system: Quality
becomes so poor that change is virtually
impossible and is no longer viable
4
Organizational strategy: enough budget is not
allocated based on the object analysis of the
problem, rather based on the desire to be a
par with other organizations.
Inertia: the resistance to change by users
(adapt to changes)
Skilled staff: difficulty of attracting and
retaining skilled maintenance personnel
5
4.3. Potential Solutions to Maintenance
Problem
a) Budget and Effort Reallocation: Allocate less
resource to un-maintainable or difficult to
maintainable system.
More resource should be allocated to specification
and design of more maintainable system
b) Complete Replacement of the software: Develop
a new system rather than maintaining a legacy
system
4.3. Potential Solutions to Maintenance
Problem
a) Budget and Effort Reallocation: Allocate less
resource to un-maintainable or difficult to
maintainable system.
More resource should be allocated to specification
and design of more maintainable system
b) Complete Replacement of the software: Develop
a new system rather than maintaining a legacy
system
6
c) Maintenance of existing software: solutions a)
and b) are somewhat unrealistic in many cases.
E.g., Provide more cutting edge technology, use-
driven functionalities, tools, methods
=> The tool and techniques are subjects in this
course!
7
8
9
Chapter
1
. Introduction
1.0 Basic Concepts
(from Book)
1.1 History of Computing/SE
1.2 Maintenance
Problem
1.3 Types of Maintenance
1.4 Performing the Maintenance
1.
5
Concepts that helps Maintenance
1
Software maintenance is a discipline with changes related to a Software
System after delivery has been made
Changes are typically needed – to enhance the functionality and/or
to improve the performance (perfective),
– to correct errors (corrective)
– to prevent future troubles (preventive)
– to move to a different platform (adaptive)
It is a challenging task to manage and control these changes
It is estimated that these changes can take 40 –
7
0% of the entire SLC
1.0 Basic Concepts
Motivation for Maintenance
– To provide continuity of service: Maintenance activities are aimed at
keeping a system operational include bog-fixing, recovering from failure
and accommodating changes in the operating system and hardware
– To support the mandatory upgrades: e.g.,, new tax laws, competitive
edges
– To support user requests for improvements
.
– To facilitate future maintenance work
Maintenance Engineer needs a far wider range of skills than just programming.
Amongst other things, the engineer needs comprehension skills and wide
ranging analytical power.
Definitions
Evolution: process of continuous change from lower, simpler or worse
to higher, more complex and better state
Maintenance: the act of keeping an entity in an existing state of repair to
efficiency, or validity; to preserve from failure and decline.
Maintainability: the ease with which the maintenance can be carried out
Software: the programs, documentation and operating procedures by which
computers can be made useful
Software Maintenance: modification of software product after delivery, to
correct faults, to improve performance or other attributes, or to adapt
the product to a modified environment
1.1 History of Computing/SE
A. Early years of computing (1
9
40 –
19
6
0)
Electronic Numeric Integrator and Computer (ENIAC)
Eckert & Mauchly
5
Some numbers for ENIAC:
– 1
8
K Vacuum Tubes
– 30 tons
–
15
00 SQ feet
– 150 KW consumed
-yet, Performed basic functions, such as, add,
subtract, divide, multiply etc
– 5000 adds or
10
00 subtractions per second
6
1952 First compiler – A0
by Grace Hopper at UNIVAC for a simple Natural
Language
1958 ALGOL 58 Compiler and CLIP
(the First compiler / compiler)
7
1957 –1961 SAGE Sponsored by DOD.
Semi Automated Ground Environment
Detect ICBM from Russia
Characteristics:
~ $
25
0m
~ 1000 people employed
~ 1m assembly instructions
8
Problems:
• Flexibility => requirement changes
• People skills vary => “off from the
street” Organizational (structure).
• Coding does not begin until SPEC. finished
• Integration of many Codes/modules/groups
9
Solution / Suggestions:
Early spec is a must
Early system integration plan ->
precise interface among users
Early Test Planning
Lean staffing in the beginning.
Have project plan and reviews.
10
B. Middle years (1960 – mid 1980 ties)
Wave of bigger projects (>Million lines).
the manned space program (1967)
Apollo project by NASA (IBM)
Characteristics:
~300 – 600 people employed
~ more than 1 billion $
~ more than 1 mil. Fortran/Assembly code.
11
SABRE by United / American Airlines
OS
36
0 by IBM (F.P. Brooks)
Characteristics:
• Over 200 M $
• More than 1M instructions (400 Modules)
• Did not stabilize until
16
releases (up to
40% rewrites)
12
“Mythical Man-Month”
by F.P. Brooks, the manager of the OS 360
“Brook’s law”
13
Problem
•How to specify a big system
•How to produce quality software
•How to produce flexible software
(different platforms)
•How to educate of people
•=>
1st conference in Garmisch
(sponsored by NATO)
50 people from industry, Academia,
Government => “Software Crisis”
14
Solutions/Suggestions:
• Use of HLL (not Machine or Assembly)
• Use Multi-Programming (Time Sharing Operation –
TSO)
• Need to “engineer software “
=> structured techniques (1970 – )
• Use Modularity and Structured Programming
(Dijkstra)
• In this sense, SE is about
45
years old.
15
Then, What is SE?
• Definition of SE:
IEEE: SE is application of systematic and
disciplined, quantifiable approach to the
development, operation and maintenance of
software. i.e. Application of engineering of
software and the study of approaches in it.
Schach: A discipline whose aim is the production of
fault-free software that satisfies user’s needs and
is delivered on time and within budget.
(PQCT = Productivity, Quality, Cost, Time)
.
16
Foundation of SE
The process, i.e., the way we build the
software which includes life-cycle/process
models (SLC), methods, tools & management.
• SLC/process model provides how we view
the software development, operation and
maintenance (SLC steps)
• Methods provide the technical How-To for a
SLC model
• Tools provide support for realization of
methods in a semi- or full- Automated
manner
17
Software Life cycle (SLC) steps
Requirement Analysis
Specification
Preliminary/Architectural Design
Detailed Design
Implementation
Testing (Validation) correction proof
Operation
Maintenance
Retire (Kill it)
18
Why is it important to go thru steps?
19
20
Management Issues
• Hiring / firing programmer
• Interface of the people
• Education of the people
• Predicting cost (CoCoMo,
CoCoMo II) by Boehm
• Predicting time
• Technology Transfer
• Process Improvement
In short: SE Scope Includes
• Technology life cycle models
methods
Tools
• Management organizational problems
projecting cost / time
Process Improvement
21
The Idea of SE is:
Changing Software Construction
from
“Magic”(only few people can do this – Magician)
To
“Art” (some people can do this –
artists)
To
“A Science” (Many people can do this – Scientists)
22
C. Late Years (late 1980 – )
Problem (Fig.1 )?
Problem
Conjecture: The cost of HW decreases by
50% every 12-18 months.
e.g., IBM PC 1980ties ($ 3k, 164K Floppy, 64K memory, NO HDD)
23
Why?
Described in F.P. Brooks Paper
Computer Magazine 1987 24
Inherent Problems of Software
•Complexity
•Conformity
•Changeability
•Invisibility
vs.
Accidental Problem
that can be solved suing new technology, TSO,
HLL, Software Development Environment, GUI,
C++ etc.
25
Possible Silver Bullets?
NO:
Correctness Proof, ADA, AI,
Expert Systems, Automatic Programming
YES:
BUY, Rapid Prototyping,
Education of good Engineers,
Incremental Development
26
OO Technology: “Silver Bullet” ?
OOA, OOD, OOI. (1990 ~ )
Booch, Rambough, Jacobson.
• Development method using OO (UML)
• UML is a notation(including graphical)
for software development and product.
Supported by Rational Rose (1996) and
to be OMG standard (1998)
27
28
1.2 Problem with Maintenance
(Fig. 2)
M. is very expensive
29
Cost compared with Iceberg (which
shows 10 % of the Ice) (Fig. 3)
30
Wrong Estimation of Time and Cost (Fig. 4)
31
Fig. 5
What is maintenance?
– Maintenance refers to changes that are made after
the software has been delivered to customer.
– Maintainability: the ease with which the
maintenance can be carried out
– Evolution: process of continuous change from lower,
simpler or worse to higher, more complex and
better state
32
Motivation for Maintenance
To provide continuity of service:
Maintenance activities are aimed at keeping a system
operational include bog-fixing, recovering from failure and
accommodating changes in the operating system and hardware
• To support the mandatory upgrades: e.g.,, new tax laws,
competitive edges
• To support user requests for improvements.
• To facilitate future maintenance work
Maintenance Engineer needs a far wider range of skills than
just programming. Amongst other things, the engineer
needs comprehension skills and wide ranging analytical
power.
Why is it so expensive and time consuming?
Some reasons:
• No SE technology has been used
• No/little documentation (difficult to understand)
• Not Assessing the impact of change
• Little M. is thought when developing
34
Some Possible Solutions:
• Build in the maintainability when constructed
– Use SE technology to develop more docs
– Think about maintenance when developing
Ex: put all modules that may change under one
Subsystem
• Use tools for M (SCM, RE, Debugger, RT )
• More Basic Research about M Not many books
35
1.3 Types of Maintenance?
Perfective (50 – 55%) is an activity of adding new
capabilities and also making some general
enhancements.
E.g.,
• Adding/Changing requirements
• Adding on-line help features
• Enhancing the performance
• Improve the terminal dialog to make it user
friendly
• Improve the GUI etc
36
Adaptive (20-25%) is an activity that modifies
software to properly interface with changing
processing environment.
E.g.,
• Implementation of new DB
• Work with new OS
• Work on new HW (CPU, IO device…)
• Work on w new PL
37
Corrective (20%) is an activity that includes the diagnosis
and correction of defects of an existing system
E.g.,
• Program failures/aborts (execution error)
• Produces results that do not match with RA
• REQ/SPC do not match with the system (Documentation
error)
• Misleading User manual
• Major sources of defects
( logic (25%), interface(15%), I/O(15%), Computational (15%),
data manipulation (15%), DB(10%), others (5%))
38
Preventive (5%) is an activity to improve the
future maintenance or reliability, or to provide
better base for future enhancement.
E.G.,
• Upgrade the documentation
• Y2K
• Restructuring poorly designed code or otherwise
Restructuring is transformation from one
representation form to another at the same relative
abstraction level while preserving the system’s
external behavior (functionality and semantics)
39
1.4 Performing the Maintenance
A. Flow of Event based on the type
40
Fig. 6
1.5 Concepts to help maintenance
A. Software Configuration Management (SCM)
Involves the development and application of
procedures and standards for managing evolving
systems products
We need SCM to
Control the change
Access the impact analysis (side effects)
Manage versions and Revisions
Assure the quality of changes 41
SCM activities are:
identify the change (Identification)
control the change (Version and change control)
ensure the changes are properly implemented
(Auditing)
report the change (Reporting
42
Change Control
43
Fig. 7
B. Reverse Engineering (RE)
is a technique to abstract higher level of abstractions
(such as design, specification or Requirements) from
source code.
Goals and benefits of RE
The goal of RE is to facilitate change by allowing a
software system to be understood in term of what it
does, how is works and its architectural representation
(requirements, specification and design)
44
END
45
Order an Essay Now & Get These Features For Free:
Turnitin Report
Formatting
Title Page
Citation
Outline
