The lesson in one paragraph. The waterfall runs the stages of development one after the other and assumes the future can be predicted. Unstable requirements, design choices that only appear while coding, and late testing break that assumption. Agile development instead welcomes change: working software is delivered in short iterations, and each one brings feedback. Scrum turns this into roles (Product Owner, Team, Scrum Master), artifacts (the backlogs and the increment) and time-boxed events around the Sprint. Whatever the process, the stages still exist: a complete, verifiable requirements specification, then architectural and detailed design, all documented as they evolve. This material matters mainly for how you organise, build and document your exam project, not for concept questions.
A software process says how teams are organised, who does which task, and how development activities flow. The reference is the waterfall, which nobody uses in pure form: each stage starts when the previous one ends, possibly with a different team, and each produces an artifact.
The waterfall is predictive: it requires foreseeing the future. It breaks on unstable requirements (a change freezes everything until all stages are redone), on detailed design that only emerges while coding and testing, and on late testing (code piles up on buggy abstractions).
| Waterfall variant | Idea |
|---|---|
| With feedback | Going back is the norm: during each stage, the result of the previous one can be revised. |
| With overlapping stages | Stages hand over smoothly, and the different teams keep interacting throughout. |
| Incremental | Work is split into isolated increments (releases), built one by one at different times. |
| Process type | First delivery | Later deliveries |
|---|---|---|
| Predictive | all features, full accuracy | none |
| Iterative | all features, partial accuracy | increase accuracy |
| Incremental | some features, full accuracy | add features |
| Agile | some features, partial accuracy | add features and accuracy |
Real processes add feedback, overlapping stages or increments. Agility combines iterative and incremental development: deliver some features early with partial accuracy, then add features and accuracy, to get feedback from early versions of the system.
Early prototypes are horizontal (a thin layer across the whole system, such as the full UI with no logic) or vertical (one feature through all layers). They improve requirements, create a shared vision and a better design, but can also narrow the vision and create impatience, pressure, expectations and a bias towards code.
The Agile Manifesto (agilemanifesto.org, 2001), signed by the practitioners of the Agile Alliance, grew out of a critique of the waterfall. Its key idea: do not refuse change, embrace it. It is a set of guidelines, not a process.
The manifesto opens with four values: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. The items on the right still matter, but the ones on the left matter more.
The twelve principles; the six that most affect coding are in bold:
Principle 7 is the sharpest contrast with the waterfall: only running software can be tried and produce feedback, while a finished-looking document can still predict the future wrongly. Principles 9 and 10 tie agility to code quality: without good design and simple code, frequent change becomes impossible.
Development is broken into short pieces and periods. In each period:
Continuous-integration tools support it, and interactions between people count for more than processes and tools. Steps 4–6 are the TDD of lesson 1.
Agile methodologies include Lean (efficiency, eliminating waste), XP (core engineering practices such as TDD and pair programming) and Scrum (a project-management wrapper). Most companies adopt some agile principles but fear to embrace them all; Scrum needs trust, experience and tailoring.
| Methodology | What it is | Content |
|---|---|---|
| Lean | lean manufacturing and lean IT principles applied to software, aiming at the highest efficiency | eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build quality in, see the whole |
| XP (Extreme Programming) | a set of core engineering practices essential to every agile project | release planning, iteration planning, acceptance tests, stand-up meetings, pair negotiation, TDD, pair programming, code quality |
| Scrum | a project-management wrapper for agile projects | roles (e.g. Product Owner), artifacts (e.g. Product Backlog), meetings (e.g. Sprint Retrospective) |
Scrum is an iterative, incremental framework for managing product development, in which a self-organising team works as a unit towards a common goal. It answers how to split months of work into milestones and a large development among team members, how to regulate relations between team, product manager and stakeholders, and how to choose priorities and track progress.
From Takeuchi and Nonaka’s paper “The New Product Development Game” (1986); Jeff Sutherland and Ken Schwaber applied it separately and coined the term in 1993 (a scrum is the rugby formation, mischia in Italian). The course follows “The Scrum Primer 2.0”. Scrum encourages co-location, daily face-to-face contact, or close online collaboration.
The Product Backlog is the prioritised, emergent list of customer-centric items for the whole project, more fine-grained at the top. Each item has a position, a description and a relative size estimate in points, so that the team’s velocity (points per Sprint) emerges. Most items should deliver customer value.
The Sprint Backlog breaks the items chosen for one Sprint into estimated tasks assigned to people, usually shown on a to-do / in-progress / done board. Changes to the target go into the next Sprint; a dramatic change stops the current one.
The increment is the set of items completed in a Sprint, the “potentially shippable increment”. An item counts only when it meets the Definition of Done agreed at the start (for example: thorough passing tests, nothing broken, documented, meeting quality criteria, acceptance-tested); otherwise it moves to a later Sprint.
A Sprint is a time-boxed iteration of 1–4 weeks (shorter is more agile). Sprints follow one another, each producing a potentially shippable increment.
| Event | Participants | Time-box | Result |
|---|---|---|---|
| Sprint Planning (part 1, part 2) | whole Scrum Team; PO optional in part 2 | 1 h per part per week of Sprint | Sprint Goal; Sprint Backlog |
| Daily Scrum | Team required, PO optional, SM usually present | 15 min, every day | synchronisation, obstacles surfaced |
| Product Backlog Refinement | Team and PO; SM only in early Sprints | ≤ 10% of the Sprint (sometimes more) | items ready for the next 1–2 Sprints |
| Sprint Review | whole Scrum Team, possibly stakeholders and users | 1 h per week of Sprint | product inspected and adapted |
| Sprint Retrospective | Team, SM; PO optional | 45 min per week of Sprint | process improvements to try |
Part 1 (what): the Scrum Team discusses the top items with the PO and agrees a Sprint Goal, a summary of the objective that leaves the exact items flexible. Part 2 (how): the team forecasts how many items it can finish, from its velocity and assuming 4–6 productive hours per person per day, and breaks them into tasks. The team decides, not the PO: it commits to a forecast.
Every day, standing, 15 minutes: each member says what they did, what they will do, and what is in the way. Technical discussion happens in follow-up meetings. The Sprint Backlog is updated daily and the burndown chart plots the remaining points.
Backlog Refinement splits, re-estimates and re-prioritises items for the next Sprints, so that planning is quick. The Sprint Review inspects the product: a conversation between PO and team around live software, not a slide demo. The Retrospective inspects the process: what works, what doesn’t, what to try; the next planning follows immediately.
In planning part 1 the team focuses on what the PO wants and why; in part 2 it starts from the top of the Product Backlog and may pick items further down, and communicates its forecast to the PO (optional in part 2). Sprint Backlog tasks are assigned not only by volunteering or skill, typically one task per person at a time, partly dynamically. The Daily Scrum requires the team; the PO is optional and the SM usually present. Refinement involves the SM only in early Sprints. The review, often mislabelled a “demo”, is how the PO sees where the product is going and the team learns about the PO and the market; stakeholders and users may attend. For retrospectives there is a whole catalogue of techniques (“agile retrospectives”), looking at strengths as well as weaknesses.
The Sprint Backlog board can be physical (sticky notes on a wall) or in a tool such as Trello, possibly integrated with the repository. The PO decides when and what to release. Delivery must be quick, which takes the right technology; without it a dedicated “Release Sprint” is needed. Continuous integration and delivery tools add new code to the code base quickly, run automatic regression tests before releasing, and release automatically. Team effectiveness usually grows from Sprint to Sprint.
Without a methodology you just start programming, which cannot handle complexity or changing requirements and works only for a handful of programmers. A methodology identifies the stages and their products, adopts suitable principles and techniques, and sets up a process to allocate and control tasks: its goal is to make development predictable. Its ingredients are principles, architecture, specification, verification, process, management and tools; its steps are those of section 1; its process can be predictive, iterative or agile.
Companies look for “software engineers” with some mix of programming, system design, project tools, team management, stakeholder skills, “AI” and the newest technologies. What is really needed: experience in building systems and in joining and guiding teams; the ability to work with people as well as machines; a balance between idealism and pragmatism (good and on time); a focus on the process, not only the result.
Definitions: “an organized approach to the design, development, use and maintenance of software”; “methods, tools and techniques used for developing software, especially when it consists of thousands of lines of code and involves many person-months”; the field of systems “so large or so complex that they are built by a team or teams of engineers”; “the theories, methods and tools which are needed to develop software”.
Ingredients: principles; architecture (design and architectural patterns, modularisation for distributed systems); specification (Petri nets, process algebras, UML, DSLs); verification (testing, code analysis, symbolic execution, simulation, model checking, debugging); process; management (planning and coordinating people); tools (compilers, IDEs, version control, repositories, build tools, deployment). Processes: waterfall, spiral, XP, Scrum.
The principles are the seven of lesson 1 (abbreviated here RF, SOC, M, A, AOC, G, I); incrementality is a quality of processes, which Sprints put into practice.
Software is code, data and documentation. Project documentation records the path from requirements (what) to implementation (how): it is the team’s reference, tracks goals, choices and their motivations, mediates conflicts, and tells you why a problem happened and where to act. It is part of the software, so the software principles apply to it, and it evolves with the code rather than being written afterwards.
A stakeholder is anyone involved who is not a developer; a requirement records a stakeholder’s need; a requirement specification says precisely what will be done to meet it. The software requirements specification (SRS) covers everything that grounds design and implementation.
The course follows the completeness school: the SRS characterises the system’s behaviour and qualities fully, filling the gaps the stakeholders left, because a system’s behaviour must be understood before design decides how the software is organised. In an agile process the specification is ongoing and may be completed during or after development. The key rule: from the same specification, two independent teams should build equivalent systems. That is also what makes good tests possible and third-party code checkable.
For example, “there are 4 types of enemies, as in the standard Pacman” becomes a specification only once each enemy’s target is stated (Blinky chases the player’s position, Pinky a point four spaces ahead, and so on); only then can the result be judged objectively.
Business (why the software is strategic, and how success is judged), functional (what it does: user requirements on interaction, system requirements on internal rules), non-functional (qualities such as performance and reliability) and implementation requirements (constraints on production, such as technologies, which must not anticipate design decisions). They are recorded as user stories, use cases, prototypes, UML diagrams, formulas, pseudo-code and tables.
| Kind | Question | Content |
|---|---|---|
| Business | Why is this software strategic? | High level: project goals, customers’ hopes, developers’ goals. They must say how you judge whether the project succeeded. |
| Functional, user | How do end users use the result? | How users interact with the software, and the input/output constraints. |
| Functional, system | How does the system work internally? | Its rules of behaviour, norms and constraints. |
| Non-functional | What qualities must the running system have? | Performance, scalability, reliability, user-friendliness… |
| Implementation | What constraints apply to production, and why? | Technologies, training, material, internal quality. They anticipate details of architecture, design or process, but must not anticipate design decisions. |
A requirement must be validatable; otherwise it is a principle. “The system should be fast” is not a requirement; “a search returns within 200 ms with 1000 concurrent users” is. Requirements are numbered so that design and code can refer to them, and each records how it was validated: user requirements by acceptance tests, system requirements by automated tests, non-functional ones by stress or acceptance tests.
Bad requirements:
The process:
Recipes for an SRS:
The team must also become expert in the domain. The domain model describes its terminology, structure and behaviour completely, usually with UML diagrams and prose, and need not match the design.
Developers must become experts in the domain at hand (covid infection, chess rules, agriculture, ships and aliens) and reach a shared understanding of it. Use class diagrams with good names and few methods, object, sequence and activity diagrams, whatever is needed, each with a prose description explaining its concepts precisely. Development itself is the realm of the coding techniques covered throughout the course; deployment and maintenance are framed today as continuous integration and delivery.
Design turns the specification into a schema developers can implement: a graph of entities (types, components) and relations (uses, inherits, calls), refined iteratively from architecture down to interfaces, data structures and algorithms. It is creative work guided by patterns and principles. There is no design without a description: organisation that is not documented looks as if it “just happened”.
Architectural design takes the strategic decisions: frameworks, paradigms, the main subsystems with their boundaries, contracts and roles, possibly using architectural patterns (layers, MVC, entity–control–boundary, space-based, client–server, peer-to-peer, 2/3-tier, publish–subscribe). It is technology-deferring. Detailed design takes the tactical decisions of how code is organised, using design patterns (lesson 1) and idioms; it is technology-dependent and complete: a choice not written down is not a choice.
An architecture divides the system into named components with roles and interactions; an architectural pattern is a template to instantiate in (parts of) it. The same holds for a design and a design pattern. Layers: horizontal layers each using the one below; MVC: model, view and controller separate data, presentation and input; ECB: entity (domain objects), control (use-case logic), boundary (interfaces to actors and systems).
| Recipe | Architectural design | Detailed design |
|---|---|---|
| Technology | deferring: described independently of technologies | dependent: technology constrains the developer, so it is decided here |
| Completeness | abstract but complete: abstract boundaries, but roles and interactions clearly stated | complete: a choice that is not written here is not a choice, it “happened”, and its implications are probably not understood |
| Purpose | requirement-enabling: any choice needed to guarantee the requirements is taken here | formal but still abstract: captured in UML diagrams, but not just a picture of the implementation |
| Evolution | iterative: it is software and evolves with the code, though usually not much | iterative: it evolves with the code, usually often |
| Scope | self-contained: requirements + architecture stand on their own | self-contained: requirements + architecture + detailed design stand on their own |
Eventually a design becomes formal. UML diagrams are design tools, not bureaucracy: structural (class, component, object, package) and behavioural (state machine, activity, sequence, use case). Concurrency and distribution also use nets (automata, Petri nets, workflows) and process algebras. Testing and continuous integration/delivery complete the stages (lesson 1).
| Diagram | Shows |
|---|---|
| Class | entities, their properties and relations, in OO terms that also apply to code |
| Object | a snapshot of part of the heap, to clarify an example collaboration |
| Component | parts of the code providing a functionality: what they provide and require, and how they connect |
| Package | how the code is structured in (sub)packages, and what each package does |
| Sequence | how objects call each other’s methods: low-level dynamic collaboration |
| Activity | a workflow of activities, with choice points and parallel activities |
| State | part of the system state as a finite-state automaton |
| Use case | scenarios in which external actors use the system |
Documentation is software: apply DRY and KISS to it, grow it alongside the code, and use it to make explicit the choices the code does not show. For the exam it ends up in the project report, which must help the teacher evaluate the project, already answer questions about it, and discuss and motivate the key decisions.
The course proposes a Scrum-inspired process for a team project:
The repository then tells the story: backlogs, sprint reports and commit history show the process, the tests show the Definition of Done at work, and the report explains the requirements and design choices.
Each stage is completed before the next starts, so everything must be foreseen at the beginning. Changing requirements force all stages to be redone, many design choices only emerge while coding and testing, and testing at the end means building on top of buggy abstractions.
Predictive delivers all features with full accuracy at once. Iterative delivers all features with partial accuracy and then improves it. Incremental delivers some features with full accuracy and then adds more. Agile delivers some features with partial accuracy, then adds features and accuracy, for the sake of early feedback.
Only running software can be tried by stakeholders and produce real feedback. Documents and designs can look complete while being wrong about the future, which is the waterfall’s weakness.
The PO orders the Product Backlog and explains goals in part 1 of Sprint Planning. The team decides how much it can do, forecasting from the top of the backlog using its velocity, and commits to that forecast.
The SM is a coach who helps everyone apply Scrum. A PO who also coached the team would turn into a micro-manager, undermining the team’s self-organisation and its right to decide the forecast.
The criteria, agreed at the start, for an item to count as finished: e.g. thorough passing tests, nothing broken, documentation, quality criteria, acceptance tests. An unfinished item goes back to the Product Backlog for a later Sprint; the Sprint is not extended.
The review inspects the product increment, with the PO and possibly stakeholders, using live software. The retrospective inspects the process and the environment: what works, what doesn’t, what to try next.
Two independent teams starting from the same specification should build equivalent systems. “Fast” is not verifiable; a requirement must state a measurable threshold under stated conditions, and say how it will be validated (for instance by a stress test).
Choosing MVC is architectural: it fixes the main subsystems and their roles, independently of technology. Using Observer inside the model is detailed design: a class-level choice made with a design pattern.
Decks: 08-Agility (processes, waterfall and variants, the Agile Manifesto, Lean/XP/Scrum, Scrum roles, artifacts and events, the proposed project process) · 08b-Methodology (software engineering and its ingredients, artifacts and documentation, requirements specification, design, UML, recipes, documentation for the exam) · 01-quality, section “Software methodologies and the agile manifesto” (critique of the waterfall, the principles that most affect coding, agility as the course philosophy). The software-engineering principles are in lesson 1. The burndown numbers in section 4 are an illustration, not from the slides.