Systems Quality and Maintenance Principles Quiz

Software Maintenance

• Software change is unavoidable due to evolving requirements, changing business environments, error corrections, new equipment needs, and performance/reliability improvements.

• Legacy systems pose a significant challenge in implementing and managing changes.

Software Change Strategies

• Software Maintenance: Modifications are made in response to changes in requirements, but the underlying software structure remains stable. Maintenance typically doesn't involve significant changes to the system architecture.

• Software Re-engineering: No new functionality is added, but the system is restructured and reorganized to ease future changes.

• Architectural Transformation: The system's architecture is modified, often from centralized to distributed.

• These strategies can be used separately or together.

Program Evolution Dynamics

• Program evolution dynamics studies the empirical process of system changes.

• Lehman and Belady's research identified several "laws" applying to system evolution, but these laws are more observations than strict rules, particularly for large systems developed by large organizations. Applicability may be limited to other cases.

Lehman's System Types

• S-system: Formally defined, derived from specifications (e.g., matrix manipulation).

• P-system: Requirements based on approximate solutions, with a stable real-world environment (e.g., Chess).

• E-system: Embedded in a real-world environment that continuously changes, with incompletely understood elements (e.g., software predicting economic functions).

Changes During the System Life Cycle

• S-system: Unchanged.

• P-system: Incremental change (e.g., fixing discrepancies).

• E-system: Constant change.

Examples of Changes During Software Development

• Changes in requirements analysis, system design, program design, program implementation, unit testing, system testing, and system delivery will require updates to artifacts such as requirements, architectural specifications, technical specifications, program code and documentation, test plans, user documentation, operator documentation, system guides, and training materials.

Lehman's Laws

• Continuing Change: A program in a real-world environment needs to constantly adapt or become progressively less useful.

• Increasing Complexity: As a program evolves, its structure generally becomes more complex.

• Large Program Evolution: System attributes (e.g., size, release timing, error reports) are roughly constant during a system's evolution.

• Organizational Stability: The rate of development over a system's lifetime is often constant and independent of the resources devoted.

• Conservation of Familiarity: Incremental changes in each release are roughly consistent.

• Continuing Growth: Systems' functionality generally must increase to maintain user satisfaction.

• Declining Quality: The quality of a system can seem to decline unless it's appropriately adapted to environmental changes.

• Feedback System: Evolution processes incorporate multi-agent, multi-loop feedback mechanisms that must be considered as system components for significant improvement.

System Maintenance vs. Decline

• Is the maintenance cost too high?
• Is the system's reliability unacceptable?
• Can the system adapt to further changes within a reasonable timeframe?
• Is the system's performance still within prescribed constraints?
• Are the system functions useful enough?
• Are other systems better, faster, or cheaper choices?
• Is maintaining the hardware cost-effective compared to replacing it?

Types of Maintenance

• Corrective: Controlling day-to-day functions.

• Adaptive: Controlling system modifications.

• Perfective: Improving existing functions.

• Preventive: Preventing performance degradation.

Who Performs Maintenance

• Separate maintenance team: More objective view; distinguish intended system behavior from actual.

• Part of development team: Easier to integrate with the system but potential for ignoring documentation.

Skills of the Maintainer

• Novice: Basic skills.

• Expert: Language, domain, comprehension strategies, program expertise are critical.

Information Needs

• Domain expert's view: Domain concepts, relationships, program scope/boundaries, goals.

• User's view: Constraints (e.g., size, timing), program operations, installation requirements.

• Programmer's view: Dependency graphs, program components, algorithms, representations, resource allocation.

Information Sources

• Programmer's knowledge, code, documentation, colleagues.

Maintenance Team Responsibilities

• Program comprehension

• Traceability (locating information)

• Perform required changes (extending, adding functions, resolving failures)

• Locating and correcting faults

• Restructuring, rewriting, and deleting design/code components

• Keeping documentation up-to-date

• Answering questions about the modified system.

Maintenance Problems

• Staff problems (limited understanding, conflicting priorities, low morale).
• Technical problems (legacy artifacts, testing difficulties.)

Causes of Maintenance Problems

• Unstructured code
• Insufficient system/domain knowledge
• Poor documentation
• Negative perception of the maintenance team.

Maintenance Costs

• Usually greater than development costs.
• Affected by technical and non-technical factors.
• Increases as software is maintained due to the corrupting effects of maintenance.
• Ageing software often results in high support costs.

Development/Maintenance Costs

• Costs for Systems 1 and 2 are presented in a bar chart.
• Development cost is significantly compared to maintenance costs in System 1 and System 2.

Development/Maintenance Effort Ratios

• Parikh and Zvegintzov (1983): Development = 2 years; Maintenance = 5–6 years.
• Fjedstad and Hamlen (1979): 39% of effort is typically in initial development; 61% is in maintenance.
• 80–20 rule: 20% of effort in devlopement, 80% in maintanance.

Maintenance Cost Factors

• Team stability: Reduced costs with consistent staff.
• Contractual responsibility: No incentive to design for future change.
• Staff skills: Experienced staff with domain knowledge crucial.
• Program age and structure: Degraded structure increases maintenance complexity.

Factors Affecting Maintenance Effort

• Application type
• System novelty
• Turnover of maintenance staff
• System lifespan
• Dependence on a changing environment
• Hardware characteristics
• Design quality
• Code quality
• Documentation quality
• Testing quality