Maintaining The System

1
Maintaining The System

• Chapter 11

2
Lehmans system types

• S-system formally defined, derivable from a
  specification. Problem is completely defined.
• Example A system to perform matrix operations

3
P-systems

• P-system requirements based on approximate
  solution to a problem, but real-world remains
  stable.
• The problem can be defined completely, but
• real solutions may be obtained from abstract
  problems that approximate the solution.
• Example A game of chess

4
E-systems

• E-system embedded in the real world and changes
  as the world does
• Example A system to predict countrys economic
  health. It is based on how the economy functions.
  E-systems use abstraction and models to
  approximate a situation.

5
Table 11.1. Examples of change during software
development.
Activity from which initial change results
Artifacts requiring consequent change
Requirements analysis
Requirements specification
System design
Architectural design specification
Technical design specification
Program design
Program design specification
Program implementation
Program code
Program documentation
Unit testing
Test plans
Test scripts
System testing
Test plans
Test scripts
System delivery
User documentation
Training aids
Operator documentation
System guide
Programmer guide
Training classes
6
System evolution vs. decline

• To decide when to discard an old system and build
  a new one depend on the following
• 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?
• Is system performance still beyond prescribed
  constraints?
• Are system functions of limited usefulness?
• 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?

7
Laws of software evolution

• Continuing change leads to less utility
• Increasing complexity structure deteriorates-
  due to addition of patches
• Fundamental law of program evolution program
  obeys statistically-determined trends and has
  invariants

8
Laws of software cont

• Conservation of organizational stability global
  activity rate is invariant
• Conservation of familiarity release content is
  invariant- that is subsequent release make
  little difference in overall system function.

9
Maintenance aspects of evolution

• Maintaining control over the systems day to day
  functions
• Maintaining control over system modification
• Perfecting existing acceptable functions
• Preventing system performance from degrading to
  unacceptable levels

10
Types of maintenance

• Corrective maintaining control over day-to-day
  functions - fixing faults
• Adaptive maintaining control over system
  modifications making a change to suit a new
  situation. Example adding a debugger and its
  associated icons to a compiler

11
Types of Maintenance cont

• Perfective perfecting existing functions by
  making changes to improve the system when changes
  are not suggested by faults.
• Preventive preventing system performance from
  degrading to unacceptable levels by changing some
  aspects of the system to prevent failures.
  Example adding type checking

12
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

13
Maintenance problems

• Staff problems
• Limited understanding
• Management priorities Management want more
  maintenance, while users want new software.
• Morale Maintenance group considered inferior to
  designers of software.
• Technical problems
• Artifacts and paradigms Object vs procedural
  programming
• Testing difficulties While system is online

14
Factors affecting maintenance effort

• Application type
• System novelty
• Turnover and maintenance staff ability
• System life span
• Dependence on a changing environment
• Hardware characteristics
• Design quality
• Code quality
• Documentation quality
• Testing quality

15
Modeling Maintenance efforts

• Belany and Lehman equation
• M p K c-d
• p is the efforts from analysis, evaluation,
  design, and documentation
• d is degree to which maintenance team is
  familiar with software
• c is complexity caused by lack of structured
  design and documentation
• K is a some constant

16
Efforts cont. COCOMO II

• size ASLOC(AA SU 0.4DM 0.3CD
  0.31M)/100
• AA is Assessment and Assimilation next 2 page
• DM is of design to be modified
• CM is code to be modified
• IM is of external code to be integrated
• SU is a rating scale on next page

17
Table 11.2. COCOMO II rating for software
understanding.
Very low
Low
Nominal
High
Very high
Structure
Very low
Moderately low
Reasonably
High cohesion,
Strong
cohesion, high
cohesion, high
well-
low coupling
modularity,
coupling,
coupling
structured
information-
spaghetti code
some weak
hiding in data
areas
and control
structures
Application
No match
Some
Moderate
Good
Clear match
clarity
between
correlation
correlation
correlation
between
program and
between
between
between
program and
application
program and
program and
program and
application
world views
application
application
application
world views
Self-
Obscure code
Some code
Moderate level
Good code
Self-descriptive
descriptiveness
documentation
commentary
of code
commentary
code
missing,
and headers
commentary,
and headers
documentation
obscure or
some useful
headers,
useful
up-to-date,
obsolete
documentation
documentation
documentation
well-organized,
some weak
with design
areas
rationale
SU increment
50
40
30
20
10
18
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
19
Measuring maintainability

• Necessary data
• time at which problem is reported
• time lost due to administrative delay
• time required to analyze problem
• time required to specify which changes are to be
  made
• time needed to make the change
• time needed to test the change

• time needed to document the change
• Desirable data
• ratio of total change implementation time to
  total number of changes implemented
• number of unresolved problems
• time spent on unresolved problems
• percentage of changes that introduce new faults
• number of components modified to implement a
  change

20
Example for calculating cyclomatic number
21
Fog index (other measure)
22
Configuration control process

• by Configuration control board
• Problem discovered by or change requested by
  user/customer/developer, and recorded
• Change reported to the configuration control
  board
• CCB discusses problem determines nature of
  change, who should pay
• CCB discusses source of problem, scope of change,
  time to fix they assign severity/priority and
  analyst to fix
• Analyst makes change on test copy
• Analyst works with librarian to control
  installation of change
• Analyst files change report

23
Change control issues

• Synchronization When was the change made?
• Identification Who made the change?
• Naming What components of the system were
  changed?
• Authentication Was the change made correctly?
• Authorization Who authorized that the change be
  made?
• Routing Who was notified of the change?
• Cancellation Who can cancel the request for
  change?
• Delegation Who is responsible for the change?
• Valuation What is the priority of the change?

24
Impact analysis

• Workproduct any development artifact whose
  change is significant
• Horizontal traceability relationships of
  components across collections of workproducts
• Vertical traceability relationships among parts
  of a workproduct
• Will add the graphs

25
Automated maintenance tools

• Text editors
• File comparators
• Compilers and linkers
• Debugging tools
• Cross-reference generators
• Static code analyzers
• Configuration management repositories

26
Software rejuvenation

• Redocumentation static analysis adds more
  information
• Restructuring transform to improve code
  structure
• Reverse engineering recreate design and
  specification information from the code
• Reengineering reverse engineer and then make
  changes to specification and design to complete
  the logical model then generate new system from
  revised specification and design

27
Redocumentation

• Output may include
• component calling relationships
• data-interface tables
• data-dictionary information
• data flow tables or diagrams
• control flow tables or diagrams
• pseudocode
• test paths
• component and variable cross-references