Lecture 2: Software Processes

Software process

A set of activities whose goal is the development or evolution of software (specification, development, validation, evolution).

Specification

What the system should do and its development constraints.

Development

Production of the software system to meet the specification.

Validation

Checking that the software does what the customer wants.

Evolution

Changing the software in response to changing demands.

Software process model

A simplified representation of a software process from a perspective, including activities, products, and roles.

Waterfall Model

A sequential software process model with distinct phases and limited feedback; progression through requirements, design, implementation, testing, and deployment.

Requirements analysis

Identifying functionalities to be provided by the system through end-user consultation.

System and software design

Establishing an overall architecture showing how sub-systems interact.

Implementation and unit testing

Coding the software and testing individual units for proper operation.

Integration and system testing

Combining units into a complete system and testing to ensure requirements are met.

Operation and maintenance

Installing the system at the user site, training users, and fixing issues post-delivery.

Characteristics of Waterfall Life Cycle

Discrete, sequential stages; each phase must finish before the next begins; milestones and documentation.

Drawbacks of Waterfall Life Cycle

Inflexible to change; limited customer involvement; difficult to accommodate incomplete requirements.

Prototyping Model

Uses a throwaway prototype to elicit requirements and feasibility, especially when requirements are unclear.

Prototype

A simplified version of the system used to explore requirements or user experience.

Purpose of prototype

To elicit and validate requirements and feasibility, and to refine system design.

Prototyping model benefits

Speeds requirements elicitation, improves user interaction understanding, and increases acceptance.

Prototyping model drawbacks

Prototypes can mislead about progress, may be reused improperly, and can cause quality issues if misused.

Prototype development cycle

Requirements gathering → define functionality → quick design → build throwaway prototype → evaluate and refine.

Throwaway prototype

A prototype intended to be discarded after its purpose is served.

Benefits of prototyping

Clarifies misunderstandings, aids user interaction design, and aids requirement validation.

Spiral Model

A risk-driven process model with iterative loops that combine elements of other models; emphasizes risk assessment and reduction.

Spiral Model sectors

Objective setting; risk assessment and reduction; development and validation; planning.

Spiral Model drawbacks

Requires risk expertise, lacks inherent milestones, and can be hard to manage with many contributors.

Incremental Model

Delivering the system in increments, each adding functionality; allows early delivery and user feedback.

Incremental plan

Prioritize user requirements and deliver highest-priority ones first; later increments freeze requirements.

Incremental advantages

Early value delivery, prototypes for elicitation, lower overall risk, focused testing.

Incremental problems

Small increments must deliver usable functionality; difficult to size increments; documentation and change management can be challenging.

Agile Modelling (AM)

An approach to improve system modelling by combining practices from modeling methods within a project.

Agile Modelling steps

Define requirements, find/use stories, high-level planning, begin iterations, write stories, implement functionality, test, deploy.

Agile methodology

Group of iterative development methods with short timeboxed iterations and minimal long-term planning.

Timebox

A fixed-duration iteration in agile development, typically 1–4 weeks.

Story cards/User stories

Brief requirements from the user perspective, written on cards for planning.

Product backlog

A prioritized list of user requirements maintained by the Product Owner.

Sprint backlog

Tasks derived from the product backlog to be completed in a sprint.

Acceptance testing

Testing to determine whether the system satisfies requirements and is acceptable to the user.

XP (Extreme Programming)

An agile methodology focusing on quality, frequent releases, test-driven development, and customer involvement.

XP release cycle

Select user stories for release, break into tasks, plan release, develop/integrate/test, evaluate, and release.

XP practices (general)

Incremental planning, small releases, simple design, test-first development, and continuous refactoring.

XP practices (2): Pair programming

Two programmers work together at one workstation to improve quality and share knowledge.

XP practices (2): Collective ownership

Any developer can change any part of the code; no isolated ownership.

XP practices (2): Continuous integration

Code is integrated frequently with automated tests run after each integration.

XP practices (2): Sustainable pace

Avoids excessive overtime to maintain productivity and code quality.

XP practices (2): On-site customer

A customer representative is available full-time to the team to provide requirements.

XP testing

Test-first development, scenario-based testing, customer involvement, and automated test harnesses.

Requirements scenarios

User requirements expressed as scenarios or stories, broken into implementation tasks.

Scrum

An agile framework with roles (Product Owner, Scrum Master, Team), artifacts (Product Backlog, Sprint Backlog), and timeboxed Sprints.

V-Model

Verification and Validation model; left side shows development activities, right side shows corresponding test activities.

Verification

Static checking of design and code through reviews and inspections.

Validation

Dynamic testing of the actual product by executing the code.

V-Model test levels

Unit/Component testing, Integration testing, System testing, Acceptance testing.

V-Model advantages

Simple, early test planning, proactive defect tracking, good for small projects with clear requirements.

V-Model disadvantages

Rigid and inflexible; limited early prototypes; changes require test/document updates.

When to use V-Model

Small to medium projects with clearly defined and fixed requirements and available resources.

Reuse/Component-Based Development

Developing by reusing existing components, then modifying and integrating them into the new system.

Component analysis

Search for components to implement requirements; exact matches may not exist.

Requirements modification (reuse)

Modify requirements based on available reusable components.

System design with reuse

Designing the system to incorporate reusable components or