Software Evolution and Development Models

Software Evolution

• Software change is inevitable due to new user requirements, evolving business needs, error fixes, new hardware, and performance improvements.
• Managing and implementing changes to existing software systems is a key challenge for organizations.
• Maintaining the value of software systems requires continuous change and updates.
• Most of the software budget is spent on changing and evolving existing software rather than developing new software.

A Spiral Model of Development and Evolution

• The spiral model is a cyclical process for software development and evolution.
• The process involves multiple iterations with successive releases, including specification, implementation, validation, and operation.
• Each iteration builds on the previous one, progressing towards a final product.

Evolution and Servicing

• The software life cycle involves three phases: evolution, servicing, and phase-out.
• Evolution: The active use and continuous improvement of software, incorporating new requirements, features, and performance enhancements.
• Servicing: Maintaining existing functionality without adding new features, focusing on bug fixes, updates, and environment adaptations.
• Phase-out: The cessation of development and ongoing support, where the software might be gradually replaced or retired.

Evolution Processes

• Software evolution processes depend on the type of software (e.g., application, system, embedded).
• Application software evolves through feature additions, UI improvements, and system integration.
• System software focuses on performance enhancements, security updates, and supporting hardware.
• Embedded software prioritizes hardware constraints and real-time requirements.
• Development processes like Agile and DevOps facilitate iterative and continuous changes, while Waterfall offers a structured approach.

Evolution Processes - Skills and Experience

• Experienced teams can effectively manage changes.
• Skill gaps can lead to challenges in assessing and managing software changes.
• Change proposals are triggered by: new requirements, feedback, or deficiencies.
• Proposals should be well-documented.
• Impact analysis links proposals to components to estimate costs and assess impacts on functionality.
• Continuous process monitoring, feedback, impact assessment, and controlled implementation of changes are crucial.

Change Identification and Evolution Processes

• A cyclical process involving: change identification, change proposals, and the software evolution process.
• This iterative process manages new system implementation and change requests.

The Software Evolution Process

• Change requests initiate the process.
• Impact analysis assesses the effects of the changes.
• Release planning precedes deployment.
• Change implementation follows, encompassing fault repair, platform adaptation, and system enhancement.
• System release concludes the software evolution cycle.

Change Implementation

• The process is akin to a mini-development cycle, involving designing, implementing, and testing the change.
• Understanding the existing system is crucial (e.g., structure, functionality, impact).

Urgent Change Requests

• Immediate action is required for some change requests.
• Issues include: system faults, environment changes, and business needs.
• Quick fixes and responses are necessary.

The Emergency Repair Process

• Steps include analyzing source code, modifying source code, and delivering the modified system.

Agile Methods and Evolution

• Agile facilitates continuous development and evolution.
• Automated regression testing ensures new changes don't disrupt existing functionality.
• User stories are used to document and integrate new changes.

Handover Problems

• Issues can arise between Agile and Plan-based approaches when expectations for documentation are different.
• Similarly, transitions from Plan-based to Agile can face challenges in creating tests and dealing with code that hasn't been refactored or simplified.

Program Evolution Dynamics

• Lehman and Belady's Laws provide observations about software evolution, based on empirical studies.
• Sensible observations rather than strict laws.
• Primarily relevant to large systems developed by big organizations.

Change is Inevitable

• Evolving requirements and environment interactions necessitate continuous adaptations and updates.

Lehman's Laws

• Continuing change is essential to remain relevant in a dynamic environment.
• Complexity naturally increases during program evolution.
• Large program evolution is a self-regulating process.
• Organizational stability is observed as approximately constant throughout a program's lifetime.
• Laws relating to the conservation of familiarity, continuing growth, and declining quality of systems.
• Feedback systems influence product quality.

Applicability of Lehman's Laws

• Lehman's laws generally apply to large custom systems but may need adjustments for different types of software like packaged, COTS, small and medium-sized organizations.

Software Maintenance

• Software maintenance is a crucial aspect of the software's lifecycle.
• It focuses on changing existing software to fix bugs, enhance features, adapt to new environments, and handle adjustments for new requirements.
• Maintenance work is distinct from new development.
• Maintenance usually targets existing components rather than creating new architecture.

Types of Maintenance

• Corrective maintenance fixes defects in the software.
• Adaptive maintenance updates the software for new environments or hardware/software.
• Perfective maintenance enhances existing features or adds new ones to improve performance or usability.
• Preventive maintenance addresses potential future problems to improve update simplicity.

Maintenance Effort Distribution

• Fault repair, environmental adaptation, and functionality addition/modifications are important aspects in determining maintenance effort.

Maintenance Costs

• Maintenance costs frequently exceed initial development expenses.
• Technical factors include complexity, code quality, and significant architecture impact.
• Non-technical factors involve team skills, documentation, and project management.
• Maintenance corruption can complicate future updates.

Development and Maintenance Costs

• Maintenance often exceeds initial development costs.

Maintenance Cost Factors

• Team stability reduces costs due to familiarity with the system.
• Contractual responsibility impacts maintenance design.
• Staff skills affect the scope and cost of maintenance projects.
• Program age/structure impacts maintainability and increases costs.

Maintenance Prediction

• Aims to identify components likely to require high maintenance costs.
• Acceptance and impact of changes affect maintainability.
• The cost increases with the number of changes and their complexity.

Change Prediction

• Predicts future changes.
• Tightly coupled systems are highly dependent on environmental changes.

Complexity Metrics

• Evaluating maintainability requires analyzing complexity factors like control structure, data structure, and module size.

Process Metrics

• Metrics indicate the frequency and duration of maintenance requests and activities to measure maintainability.

System Re-engineering

• Restructuring or rewriting parts of a legacy system without altering functionality.
• Useful for subsystems with frequent maintenance but not for the entire system.
• Improves maintainability.
• Often less expensive than rewriting the entire system.

Reengineering Process Activities

• Steps include: source code translation, reverse engineering, program structure improvements, program modularization, and data reengineering.

Reengineering Cost Factors

• Includes software quality, tool support, data conversion requirements, and expert staff availability.

Preventative Maintenance by Refactoring

• Refactoring is a process to improve code to prevent issues in future changes.
• It modifies the program to enhance structural quality without altering its functionality.
• Preventing future problems simplifies updates.

Refactoring and Reengineering

• Reengineering occurs when maintenance costs rise.
• Refactoring is a continuous improvement process during development.

"Bad Smells" in Program Code

• Lists potential issues in code like duplicate code, long methods, switch statements, data clumping, and speculative generality.
• Identifying these code smells helps to improve program structure, readability, and maintainability.

Legacy System Management

• Organizations need a strategy for legacy systems: scrap, maintain, transform, or replace.
• The strategy should consider the system's quality and business value.

Legacy System Categories

• Categorizes legacy systems by quality and business value: low quality / low value, scrap; low quality / high value, reengineer/replace; high quality / low value, replace/scrap/maintain; high quality / high value, maintain.

An Example of a Legacy System Assessment

• Diagram shows a quadrant assessment grid for legacy systems based on system quality and business importance.
• Provides illustrative examples for each quadrant.

Business Value Assessment

• Stakeholders are essential for a comprehensive assessment.
• System use, supported processes, system dependability, and output are key assessment areas.

System Quality Assessment

• Business process assessment evaluates current processes' alignment with business goals.
• Environmental assessment focuses on the system's environment, maintenance costs, and application quality.

Business Process Assessment

• Engage stakeholders.
• Identify defined process models and any relevant variations.
• Document process adaptation.
• Assess inter-process relationships.

Factors Used in Environment Assessment

• Factors to consider include supplier stability, failure rate, age, performance, support costs, requirements changes, and interoperability.

Factors Used in Application Assessment

• Considerations for application assessment include code understandability, documentation, data quality, performance, programming language, configuration management, test data, and personnel skills.

System Measurement

• Collecting quantitative data like change requests, user interfaces, and data volumes is necessary to assess system quality.

Explore the critical aspects of software evolution, management, and the spiral model of development. Understand how organizations navigate changes in software to meet user requirements and improve performance. This quiz delves into the phases of software life cycles and their implications for continuous improvement.