Download System Evolution - Lecture Slides | COE 1530 and more Exams Software Engineering in PDF only on Docsity!
CS 1530 Software Engineering Fall 2004
Software Engineering
CS / COE 1530
Maintenance
System evolution vs. decline
■ Is the cost of maintenance too high?
■ Is the system reliability unacceptable?
■ Can the system no longer adapt to further change, and
within a reasonable amount of time?
■ Can other systems do the same job better, faster or
cheaper?
■ Is the cost of maintaining the hardware great enough to
justify replacing it with cheaper, newer hardware?
■ Is system performance still beyond prescribed constraints?
■ Are system functions of limited usefulness?
CS 1530 Software Engineering Fall 2004
Laws of software evolution
■ Lehman: Laws of Software Evolution
■ Investigation started 1968
■ Based on measurement of a few (commercially -
developed) systems, most notably IBM’s OS 360
■ Originally three laws, then five, now there are eight.
■ Controversial as “ laws ”
■ Criticized for strong claims based on limited data.
■ Better term is “observations ”
■ However, it’s pioneering work on software evolution
and software engineering.
Laws of software evolution
■ Continuing change: or less utility
■ Increasing complexity (entropy): structure
deteriorates
■ Fundamental law of program evolution:
program obeys statistically-determined trends
and has invariants
■ Conservation of organizational stability: global
activity rate is invariant
■ Conservation of familiarity: release content is
invariant
CS 1530 Software Engineering Fall 2004
Four types of “maintenance”
■ Corrective
■ Fix bugs & misunderstood
requirements
■ Adaptive
■ Respond to external changes
(support other o.s./hardware)
■ Perfective
■ Improve as-delivered
software (new features,
efficiency)
■ Preventive
■ Before a failure occurs
Maintenance team
responsibilities
■ Understanding the system
■ Locating information in system
documentation
■ Keeping system documentation
up-to-date
■ Extending existing functions to
accommodate new or changing
requirements
■ Adding new functions to the
system
■ Finding the source of system
failures or problems
■ Locating and correcting faults
■ Answering questions about
the way the system works
■ Restructuring design and code
components
■ Rewriting design and code
components
■ Deleting design and code
components that are no
longer useful
■ Managing changes to the
system as they are made
CS 1530 Software Engineering Fall 2004
Modeling Maintenance Effort
■ COCOMO II:
Size = ASLOC*(AA+SU+0.4DM+0.3CM+0.3iM)/100)
■ AA = A ssessment and A ssimilation effort
■ SU = Amount of S w U nderstanding
Table 11.2. COCOMO II rating for software understanding.
Very low Low Nominal High Very high Structure Very low cohesion, high coupling, spaghetti code Moderately low cohesion, high coupling Reasonably well- structured; some weak areas High cohesion, low coupling Strong modularity, information- hiding in data and control structures Application clarity No match between program and application world views Some correlation between program and application Moderate correlation between program and application Good correlation between program and application Clear match between program and application world views Self- descriptiveness Obscure code; documentation missing, obscure or obsolete Some code commentary and headers; some useful documentation Moderate level of code commentary, headers, documentation Good code commentary and headers; useful documentation; some weak areas Self-descriptive code; documentation up-to-date, well-organized, with design rationale SU increment 50 40 30 20 10
Table 11.3. COCOMO II ratings for assessment and assimilation effort.
Assessment and assimilation increment Level of assessment and assimilation effort 0 None 2 Basic component search and documentation 4 Some component test and evaluation documentation 6 Considerable component test and evaluation documentation 8 Extensive component test and evaluation documentation
CS 1530 Software Engineering Fall 2004
Cyclomatic number
■ Number of linearly independent paths
through the code
■ Control Flow Graph: Nodes and edges
e-n+
■ Prepare test cases:
■ to force execution along each path
CS 1530 Software Engineering Fall 2004
getSum: Control-Flow Graph
1. int getSum(int i) {
int j, sum;
2. read j;
3. sum = 0;
4. while (i > 0 & i <= 10 | j<0) {
5. if (j >0)
6. sum = sum + j;
7. i= i + 1;
8. read j;
9. return sum;
T
F
T
F
Entry
Exit
CS 1530 Software Engineering Fall 2004
Maintenance Activities
CS 1530 Software Engineering Fall 2004
Rejuvenation Taxonomy
CS 1530 Software Engineering Fall 2004
Redocumentation
CS 1530 Software Engineering Fall 2004
Restructuring
CS 1530 Software Engineering Fall 2004
Reverse Engineering
CS 1530 Software Engineering Fall 2004
Reengineeering
