Every software project follows some kind of process, whether explicit or implicit. A software process describes how teams are organised to develop a system, which tasks are appointed to people, and the workflow of development activities. The classical reference is the Waterfall model, which structures development into sequential macro-stages:
The Waterfall is a predictive method: it requires foreseeing the future. Requirements instability is its primary weakness — if requirements change, the whole sequence must restart from the beginning.
Real projects rarely follow a pure waterfall. Three common adaptations address its rigidity:
| Variant | Idea | Key characteristic |
|---|---|---|
| Waterfall with feedback | Each phase can revise the previous one | Going back is treated as the norm, not an exception |
| Overlapping phases | Phases have smooth transitions | Different teams keep interacting throughout |
| Incremental waterfall | Isolated increments delivered at different stages | Partial releases provide some features early |
| Model | Features delivered | Accuracy |
|---|---|---|
| Predictive (Waterfall) | All at once | Full accuracy from the start |
| Iterative | All features | Partial accuracy initially, improved in later versions |
| Incremental | Some features early | Full accuracy for delivered features |
| Agile | Some features early | Partial accuracy initially, improved iteratively |
Agile combines iterative and incremental approaches: it delivers working software frequently, each iteration adding features and improving accuracy based on feedback.
The Agile Manifesto (2001, agilemanifesto.org) was signed by many practitioners of the Agile Alliance. It started from criticising the waterfall model and its inability to handle change. The key idea: do not refuse change, rather embrace it.
These principles deeply influenced modern software development:
You should be able to explain the Agile principles and contrast them with the Waterfall approach. The examiner may ask: "Why is 'working software' the primary measure of progress, rather than documentation or design completeness?"
| Methodology | Focus | Key practices |
|---|---|---|
| Lean | Highest efficiency | Eliminate waste, amplify learning, decide as late as possible, deliver fast, empower the team, build quality in, see the whole |
| XP (Extreme Programming) | Core engineering practices | Release planning, iteration planning, acceptance tests, stand-up meetings, pair programming, TDD, code quality |
| Scrum | Project management wrapper | Roles (PO, SM, Team), artifacts (backlogs), time-boxed sprints, ceremonies |
Most industries claim they use "agile methods", but many just inherit some principles without fully embracing them all. Scrum is widely adopted, but needs trust, experience, and tailoring.
Scrum is an iterative and incremental agile framework for managing product development. It enables teams to self-organise by encouraging close collaboration. The name comes from the rugby term "scrum" (Italian: mischia), coined by Jeff Sutherland and Ken Schwaber in 1993, inspired by a 1986 paper by Takeuchi and Nonaka.
| Role | Goal | Key responsibilities |
|---|---|---|
| Product Owner (PO) | Maximising return on investment | Interacts with customers, identifies features, creates and maintains the priority list (Product Backlog). The PO understands product development and continuously interacts with the team, reviewing sprint results. |
| Development Team | Build the product the PO indicates | Cross-functional, self-organising, 5–9 people, 100% dedicated. They estimate time, decide which items to implement, and provide ideas to the PO. |
| Scrum Master (SM) | Help the group learn and apply Scrum | A coach, not a manager or leader. Helps smooth coordination between PO and Team. Not the PO (which would create micro-management). Can be an external counsellor. |
| Artifact | Description |
|---|---|
| Product Backlog | A prioritised list of customer-centric features. Exists and evolves over the project lifetime. Each item has: priority position, description, estimation size (relative points). Items include new features, major improvements, research work, bug fixes, and bootstrap activities. |
| Sprint Backlog | A refinement of the Product Backlog portion for the current Sprint. Each item is broken into Sprint tasks with estimates and person-task assignments. Often rendered as a physical or digital board with columns: To-Do, WIP, Done. |
| Increment | The sum of all completed Product Backlog items at the end of a Sprint. Must meet the Definition of Done. |
An item is "done" when it meets agreed criteria: thorough and non-failing tests, no breakage of existing code, proper documentation, acceptance testing, and quality criteria. This impacts the notion of "potentially shippable increment".
A Sprint is a time-boxed iteration (1–4 weeks; shorter means more agile). The entire development happens within sprints, each producing a potentially shippable increment.
Part 1 (WHAT): Review high-priority items, discuss goals and context with the PO. Result: Sprint Goal — a summary statement of the Sprint objective.
Part 2 (HOW): Forecast the amount of items completable, considering team velocity. The team commits to a forecast, not the PO. Duration: ~1 hour per part per week of Sprint.
15 minutes daily at the appointed time (team standing). Each member reports: (i) what was done, (ii) what will be done, (iii) what obstacles exist. No in-depth technical discussion — that happens in follow-up meetings. The team updates the Sprint Backlog daily and plots the Sprint burndown chart to track progress.
Inspection and adaptation of the product increment. Whole team + stakeholders. Key for the PO to understand product evolution. Involves live demo of working software, not slides. Duration: ~1 hour per week of Sprint.
Inspection and adaptation of the process, not the product. Discuss what is working and what is not, and what changes to try. Focus on both positive and negative aspects. Next Sprint Planning comes immediately after. Duration: ~45 minutes per week of Sprint.
Ongoing activity (max 10% of Sprint time) where the team splits big items, analyses, re-estimates, and re-prioritises for future Sprints. Doing this properly makes Sprint Planning quick and effective.
Be prepared to explain: What is the Sprint Goal? Who decides what goes into a Sprint? What happens if work cannot be completed within the Sprint? How does the burndown chart help track progress?
These principles form the foundation of good software engineering practice. You should be able to explain each one and give examples of its application.
| Acronym | Principle | Meaning | Examples |
|---|---|---|---|
| RF | Rigour and Formality | Describe behaviour as precisely as mathematics would | Finite state machines, DSL-like APIs, rule-like specifications in tests |
| SOC | Separation of Concerns | Master complexity by grouping issues, consider each in isolation | Split teams, divide tests (unit/integration/acceptance), separate functional from non-functional requirements |
| MOD | Modularity | Divide software in modules with high cohesion and low coupling | Package structure, nested classes, deployment artifacts (JARs, DLLs) |
| ABS | Abstraction | Identify key aspects and ignore unnecessary details | Interfaces, API layers, DSLs, choosing the right paradigm |
| AOC | Anticipation of Change | Create the ground for flexible reactivity to likely changes | Abstract classes, constants instead of magic numbers, encapsulate implementation choices |
| GEN | Generality | Solve a more general problem than the one at hand | Parameterise implementation choices, support more input cases than currently needed |
| INC | Incrementality | Reason in terms of smaller and smaller increments | Version numbering, Scrum sprints, TDD red-green-refactor cycles |
These principles are well-known and universally agreed upon — yet developers often believe they have "no time" to follow them. The real skill is knowing when to apply each one judiciously.
Requirement specification is the phase that grounds all subsequent design and implementation. The goal is to turn abstract stakeholder needs into well-engineered, precise descriptions of what the system will do.
| Type | Question answered | Examples |
|---|---|---|
| Business Requirements | Why is this software strategic? | Project goals, ROI expectations, success criteria |
| Functional Requirements | What functionalities does the system provide? | User requirements (how users interact) and System requirements (internal behaviour, rules, constraints) |
| Non-functional Requirements | What qualities must the system have? | Performance, scalability, reliability, security, usability |
| Implementation Requirements | What constraints exist on production? | Technologies, training, internal quality standards |
A requirement must be verifiable. Bad examples: "the user can insert a product" (what data?), "the system should be fast" (how fast?), "the code should be modular" (that is a principle, not a requirement).
Software developers must become experts in the domain at hand. A domain model is a formal description of key aspects of the domain that the software is about. It should be complete and cover all useful information about terminology, structure, and behaviour. UML diagrams (class, object, sequence, activity) with prose descriptions are the typical formalism.
You should understand the Pacman example: the requirement "there are 4 types of enemies" must be specified precisely — Blinky targets the player's current location, Pinky targets four spaces ahead, Inky uses Blinky's position as reference, and Clyde flees when too close. The specification makes the system objectively verifiable.
Design turns the requirement specification into a detailed implementation schema. It is an iterative, creative process based on experience, patterns, and principles.
Defines the strategic aspects: frameworks, tools, paradigms, high-level principles, main sub-systems and their boundaries, contracts, and roles.
Defines the tactical aspects: class-level decisions, interfaces, data structures, algorithms. Can rely on design patterns (GoF) and programming idioms.
| Pattern | Description | When to use |
|---|---|---|
| Layers | Organise code into horizontal layers (presentation, business logic, data access) | Standard enterprise applications |
| MVC | Model-View-Controller: separate data, presentation, and user input handling | GUI applications, web frameworks |
| ECB | Entity-Control-Boundary: domain entities, use case controllers, and interface boundaries | Use-case driven design |
| Space-based | Shared tuple spaces for distributed coordination | Distributed/concurrent systems |
| Publish-subscribe | Event-driven communication between components | Event-driven architectures, decoupled systems |
Architecture and architectural patterns are distinct: an architecture is a division into named components with defined roles and interactions; an architectural pattern is a reusable template. The same relationship holds between "design" and "design patterns".
| Stage | Key recipes |
|---|---|
| Architectural design | Technology-deferring, abstract but complete, requirement-enabling, iterative, self-contained |
| Detailed design | Technology-dependent, complete, formal (UML), still abstract, iterative, self-contained |
| Requirement specification | Visionary, verifiable, result-complete, agreement-complete, iterative, self-contained, prescriptive |
Unified Modelling Language (UML) diagrams are the standard visual formalism for documenting software design. They serve as powerful design tools, not just bureaucratic documentation.
| Diagram | Focus | Used for |
|---|---|---|
| Class diagram | Entities, properties, and relations (OO terminology) | Static structure, types and their relationships |
| Object diagram | Snapshot of a portion of the heap | Clarifying example collaborations between objects |
| Component diagram | Code portions providing functionality | What components provide/require, how they connect |
| Package diagram | Overall code structure in (sub-)packages | High-level organisation, package features |
| Sequence diagram | Object method calls over time | Low-level dynamic collaboration |
| Activity diagram | Workflow of activities | Choice points, multiple activities, process flow |
| State diagram | System state as finite automaton | State-dependent behaviour, lifecycles |
| Use case diagram | Scenarios for external actors | System boundary, actor interactions |
Documentation is an essential part of quality software. Key facts to remember:
The suggested process for the course project adapts Scrum: one student acts as client/domain expert, another as Product Owner. Sprints should be short (~1 week, ~15 hours of work). The team maintains a Sprint Backlog, holds frequent meetings, and produces brief reports at each Sprint's end, kept under version control.
Predictive (Waterfall) delivers all features at once with full accuracy planned upfront. Iterative delivers all features but with partial accuracy, improving over time. Incremental delivers some features early with full accuracy. Agile combines iterative and incremental: delivers some features early with partial accuracy, then adds features and improves accuracy. Scrum is an agile framework.
Product Owner: maximises ROI, maintains the Product Backlog, interacts with customers. Development Team (5-9 people): self-organising, cross-functional, builds the product, estimates and decides Sprint items. Scrum Master: coach who helps the group learn and apply Scrum, smooths coordination, not a manager or leader.
It is an agreed-upon set of criteria that must be met for an item to be considered "done". Facets include: thorough and passing tests, no breakage of existing code, documentation, quality criteria, acceptance testing. It impacts the notion of "potentially shippable increment" and ensures consistent quality across the team.
It means describing or enacting behaviour as precisely as mathematics would. It is key where errors would incur high technical debt. Examples: using finite state machines, Petri nets, DSL-like APIs for configuration, rule-like specifications in tests.
A requirement that cannot be objectively validated is not a true requirement — it is just a principle. Bad: "the system should be fast". Fixed: "the system should respond to user queries within 200ms under a load of 1000 concurrent users".
Architectural design defines strategic aspects: which architectural pattern (MVC, Layers), which technologies, high-level module boundaries. Detailed design defines tactical aspects: which classes, interfaces, and design patterns (GoF). Example: choosing MVC is architectural; deciding to use the Observer pattern within the Model is detailed design.