A Software Process is a series of predictable steps to follow to create a timely, high-quality result.

-> Provides stability, control, organization

-> Can be adapted to individual process needs (not rigid, can be agile)

[excerpt from Boehm's paper on the Spiral Model, 1988]

The basic model used in the earliest days of software development (and by undergrad students!) contained two steps:

1. Write some code.
2. Fix the problems in the code.

Thus, the order of the steps was to do some coding first and to think about the requirements, design, test, and maintenance later. This model has three primary difficulties:

• After a number of fixes, the code became so poorly structured that subsequent fixes were very expensive. This underscored the need for a design phase prior to coding.

• Frequently, even well-designed software was such a poor match to users’ needs that it was either rejected outright or expensively redeveloped. This made the need for a requirements phase prior to design evident.

• Code was expensive to fix because of poor preparation for testing and modification. This made it clear that explicit recognition of these phases, as well as test and evolution planning and preparation tasks in the early phases, were needed.

Successive stages feedback into each other, but the goal is to make sure that these feedback loops are confined to two successive stages (avoiding extensive rework going back several stages)

Assumptions:

• The requirements are known in advance of implementation.
• The requirements have no unresolved, high-risk implications, such as risks due to cost, schedule, performance, safety, security, user interfaces, organizational impacts, etc.
• The nature of the requirements will not change very much during development or evolution.
• The requirements are compatible with all the key system stakeholders’ expectations, including users, customer, developers, maintainers, and investors.
• The right architecture for implementing the requirements is well understood.
• There is enough calendar time to proceed sequentially.

Principle: Linear sequences of the waterfall process, with each sequence producing an operational deliverable. The incremental model delivers a series of releases, called increments. Suggests that all requirements are finalized early during process.

Incremental and Iterative Idea:

Start by developing a prototype following a mini-waterfall model. Prototype serves to gather requirements. Each increment is reviewed and evaluated. The main risks are identified, and in the next cycle the emphasis on the differnet activities is based on the identified risks.

Iterative and Incremental, Use-case driven, Architecture centric Phases:

• Inception: The core idea is developed into a product vision. We review and confirm our understanding of the core business drivers. We want to understand the business case for why the project should be attempted. Product feasibility and project scope.
• Elaboration: The majority of the Use Cases are specified in detail and the system architecture is designed. "Do-Ability" of the project. We identify significant risks and prepare a schedule, staff and cost profile for the entire project.
• Construction: Produces a system complete enough to transition to the user. The design is refined into code.
• Transition: The goal is to ensure that the requirements have been met to the satisfaction of the stakeholders. Other activities include site preparation, manual completion, and defect identification and correction. The transition phase ends with a postmortem devoted to learning and recording lessons for future cycles.

This diagram shows how the importance of different activities evolves during the project development

Agile is an umbrella term that covers several methodologies, including extreme programming, Scrum, etc.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

• Difficult to predict software requirements
• Difficult to predict analysis, design, construction, and testing
• Design and construction should be interleaved

How can we design a process that can manage unpredictability? ->Process adaptability.

4 phases: Planning (stories), Design (prototype solutions), Coding (pair programming, re-factoring), Test The tests are the specification Communication paramount (small team, knowledgeable programmers?)