Chapter Note
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