Greenfield Development

Building a software product from scratch without any pre-existing code or design.

• Characteristics No existing codebase or system architecture. Often associated with Lehman's S-type (specification-based) programs.
• Academic and Industry Focus Predominantly emphasized in software engineering literature and educational curricula.
• Reality Check Pure greenfield development is relatively rare.

Brownfield Development

Developing a software product by building upon an existing project or environment.

• Characteristics Existing codebase, design, and system. Often relates to Lehman's E-type (evolving) programs.
• Academic and Industry Focus Frequently treated as a secondary topic in academic materials and industry practices.
• Reality Check The majority of software development in the real world falls under brownfield development.

Software Maintenance

Activities involving modifications to an existing software system.

• Economic Impact Consumes approximately 80% of the system's total lifecycle cost, often underemphasized in cost structures.
• Terminology Clarification The term 'maintenance' in software engineering is conceptually different than in other fields.
• Academic and Industry Focus Typically sidelined in literature and training programs.
• Reality Check A large portion of a software developer's tasks can be categorized as maintenance activities.

Categories of Maintenance

• Based On Swanson's model, ISO/IEC 14764
• Corrective Addressing bugs and other problems.
• Adaptive Updating the software to fit new environmental conditions.
• Perfective Enhancing performance or maintainability.
• Preventive Proactively fixing latent issues to prevent future problems.

Waterfall Model

• Source Rahlich'06
• Basic Workflow Complete requirement gathering -> Complete design phase -> Implementation.
• Cross-Discipline Resemblance Mirrors practices in other engineering disciplines.
• Quality Assurance Provides structured stages for validation and verification.
• Limitations Standish Group's 1995 Report found high rates of project cancellations (31.1%) and challenges (52.7%). Only 16.2% of projects were deemed successful.
• Conclusion The Waterfall model is insufficient for tackling most software development challenges.

Requirements Volatility

• Source Rahlich'06
• Dynamic Nature Requirements often evolve during the development cycle.
• Real-World Data Approximately 30% of requirements for Microsoft projects are discovered during development.
• Implication A static design can't guide an inherently volatile development process.

Design for Change

Design and develop software in a way that anticipates and accommodates future changes

• Source Rahlich'06
• Modularity
• Abstraction
• Encapsulation
• Decoupling
• Configuration Over Hardcoding
• Extensibility
• Reusability
• Version Control

Disadvantages of Design for Change

Design and develop software in a way that anticipates and accommodates future changes

• Initial Complexity The upfront design might be more complex and time-consuming.
• Potential Overengineering There's a risk of designing for flexibility that is never used, adding unnecessary complexity.
• Unpredictability Events often occur that are unanticipated.
• Result Can mitigate, but not eliminate, the impact of evolving requirements.

Software Evolution

Software Evolution = Software Development + Software Maintenance

• Methodology Iterative and flexible approach to software development.
• Process Iterate through the complete process for each version, then build upon it.
• Holistic View Doesn't distinguish between development and maintenance; considers both as part of software evolution.
• Paradigms Following This Approach Open-Source, Agile Methodologies, eXtreme Programming.

Incremental Development

The entire system is divided into smaller parts or components, often called "increments." Each increment represents a portion of the complete system's functionality. These increments are developed and integrated into the existing system sequentially, one at a time, until the whole system is fully functional.

• Additive Changes Each new increment adds something new to the system regarding functionality or features.
• Independent Components Increments are often designed to be usable independently, offering some value to the users even before the complete system is developed.
• Predictable This model is straightforward because it involves partitioning the scope into smaller, manageable pieces, reducing complexity.
• Examples Layered architectures are often built incrementally.
• Problems Completion of a part or component before the other parts/components it interacts with

Iterative Development

Refining the system by repeatedly revisiting phases like requirements, design, implementation, and testing. The software's initial version is improved until it eventually evolves into the final product.

• Cyclical Process Each iteration involves the same development phases, and each results in a better, more complete version of the software.
• Feedback Loop After each iteration, feedback is collected, and adjustments are made to the requirements, design, or other aspects of the project.
• Flexible This model is more adaptive to changes and is suitable for projects where requirements are not well understood in advance.
• Examples All projects benefit from an iterative approach

Staged Software Lifecycle Model

• Source Rahlich, Bennett'00
• Initial Development Releasing the first functional version.
• Evolution Adding significant new features and extensions.
• Servicing Implementing minor fixes and functional changes.
• Phaseout Ending active servicing but continuing usage.
• Closedown Withdrawing the system from the market.
• Versioning Each stage can be understood in terms of software versioning.