SOFTWARE DEVELOPMENT METHODOLOGIES

This course is one of the core learning activities of the degree programme and contributes to training professionals able to design, build, release and evolve complex software systems in collaborative settings. It provides knowledge of the main software lifecycle models and schools of thought (plan-driven, lean/agile, DevOps and AI-assisted perspectives), together with quality, architecture and environments, integration and data, delivery automation and team organisation. It develops skills for iterative work on a shared product - thin specification, testing and review, continuous integration, release and observability, recorded architectural decisions - and methodological judgement: selecting, adapting and assessing practices and tools in context, rather than treating them as a mere technology checklist. It thus connects and systematises programming and design competences already gained in the programme, preparing students for technical and coordination roles in realistic software projects.

Expected learning outcomes

1. Knowledge and understanding
Students know and understand the main software lifecycle models and schools of thought, together with their strengths and limits; the role and boundaries of testing, quality assurance and code review; the foundations of system architecture and complexity, working environments, observability and architectural decisions; integration between systems, data evolution and responsibility for data quality; practices for automating software build and release, including infrastructure described as code and deployment strategies; the links between team organisation and system structure; the main ways of measuring delivery effectiveness; and emerging perspectives on AI-assisted development, including related risks.
2. Applying knowledge and understanding
Students can select and adapt process practices to a concrete project context; define and apply clear quality acceptance criteria on an evolving product, that is, state what must be true for a work increment to count as complete; run iterative work cycles with verifiable evidence, such as automated tests, code integration requests and shared completion conditions; contribute to continuous integration pipelines and to release and recovery procedures when problems occur; write concise specifications and architectural decision records that can guide people or automated tools; and use measurements and operational signals to reason about progress and reliability.
3. Making judgements
Students can compare methodological and technical approaches under constraints and incomplete information; separate the complexity inherent in the problem from complexity introduced by avoidable technical choices; assess when to automate, when to standardise and when to keep human control, including in the use of artificial intelligence tools; and recognise trade-offs among speed, quality, risk and team workload.
4. Communication skills
Students can communicate technical and process decisions clearly to peers and to non-specialist audiences, including through demonstrations of working software, architecture notes, completion criteria and retrospective outcomes; and document in an essential form what must remain shared knowledge within the team.
5. Learning skills
Students can update their way of working when new tools and paradigms appear, linking them to durable principles; maintain team knowledge through capture, organisation and reuse; and continue learning autonomously from primary sources and professional case studies.

Prerequisites

Solid programming knowledge is required, together with the ability to build and modify medium-complexity programs in at least one language commonly used in software development.
Prior exposure to basic software design ideas (modularity, interfaces, use of libraries or services) and to version control is helpful, though not strictly mandatory.
No prior knowledge of agile methods, DevOps, or specific continuous integration and delivery tools is required: these topics are introduced and practised during the course.
Any formal prerequisite courses are those set out in the degree programme regulations.

The course combines theoretical foundations with iterative project work on a shared software product. Contents are organised as follows.

1. Method judgement and the software lifecycle
Process models and schools of thought (plan-driven, lean, agile and DevOps approaches); essential and accidental complexity; completion criteria and sources of product truth (code, tests, environments); starting team work on a common product.
2. Quality, verification and code craft
Limits of testing; a portfolio of verification techniques; test-driven development and behaviour specification; code review, including in the presence of artificial intelligence tools; readability, team knowledge hygiene and shared quality criteria.
3. Architecture, environments and operations
Modularity and responsibility boundaries; recording architectural decisions; working-environment strategy; observability and service indicators; intermediate progress demonstrations.
4. Integration and data
Coupling between components and synchronous/asynchronous integration; evolution of existing systems; data modelling and schema evolution; responsibility for data quality and ownership.
5. Build, automation and release
Build systems and trustworthy artifacts; containers and infrastructure described as code; continuous integration and delivery pipelines; deployment strategies, feature flags and recovery procedures.
6. Organisation, estimation, artificial intelligence and measurement
Links between team structure and system architecture; estimation and prioritisation under uncertainty; AI-assisted development paradigms and human supervision; delivery and effectiveness metrics; final synthesis of the working method adopted.

Throughout the course, students apply these topics to successive increments of the same product, with periodic demonstrations, feedback and replanning.

• F. P. Brooks Jr., “No Silver Bullet — Essence and Accident in Software Engineering”, Computer, IEEE, 1987 (1986 essay version; available via university libraries / ACM Digital Library).
• Manifesto for Agile Software Development, 2001, https://agilemanifesto.org/ (and related principles).
• J. Humble, D. Farley, Continuous Delivery, Addison-Wesley, 2010; related resources at https://continuousdelivery.com/
• N. Forsgren, J. Humble, G. Kim, Accelerate: The Science of Lean Software and DevOps, IT Revolution, 2018; metrics overview also at https://dora.dev/
• M. Skelton, M. Pais, Team Topologies, IT Revolution, 2019; https://teamtopologies.com/
• M. Nygard, “Documenting Architecture Decisions”, 2011, https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions (see also https://adr.github.io/ )
• M. Fowler, “Strangler Fig Application”, https://martinfowler.com/bliki/StranglerFigApplication.html
• M. E. Conway, “How Do Committees Invent?”, Datamation, 1968 (overview: https://en.wikipedia.org/wiki/Conway%27s_law )
• Up-to-date materials and cases on the impact of artificial intelligence on software development and on AI-assisted lifecycles (white papers and reports indicated by the instructor at the start of the academic year; copies or links on the e-learning platform).
• K. Beck, Test-Driven Development: By Example, Addison-Wesley, 2002.
• K. Beck, Extreme Programming Explained, Addison-Wesley (latest available edition).
• G. Kim, J. Humble, P. Debois, J. Willis, The DevOps Handbook, IT Revolution (latest available edition).
• E. Evans, Domain-Driven Design, Addison-Wesley, 2003; alternatively V. Vernon, Domain-Driven Design Distilled, Addison-Wesley, 2016.
• R. C. Martin, Clean Code, Prentice Hall, 2008.
• M. Fowler, Refactoring, Addison-Wesley (latest available edition); https://refactoring.com/
• Google, Site Reliability Engineering (SLO and error-budget chapters), free online: https://sre.google/books/
• Z. Dehghani, Data Mesh principles, https://martinfowler.com/articles/data-mesh-principles.html
• Further articles, engineering posts and industrial cases (e.g. Netflix, Zalando, Google SRE) will be pointed out as topics are covered.

Assessment methods

Assessment matches a course based on iterative project work and methodological judgement. It has two compulsory components, plus an optional participation component.

1. Project portfolio (indicative weight: 60% of the final grade)
During the course students work in teams on successive increments of a shared software product. Assessment focuses less on feature count than on the quality of the working method and on the evidence produced, including in particular:

• team work history (board, priorities, replanning after demonstrations);
• code contributions submitted for integration, with tests and reviews;
• completion criteria defined and met;
• architectural decision records and concise specifications;
• integration/release automation and, where applicable, deployment and recovery stories;
• periodic demonstrations of working software and retrospective summaries;
• any use of artificial intelligence tools, disclosed and explainable.

The portfolio mainly assesses applying knowledge and understanding, methodological judgement, technical communication and iterative work with evidence.

2. Individual examination (indicative weight: 40% of the final grade)
A written and/or oral examination, lasting about 30–60 minutes, on concepts, comparisons between approaches and cases. It may ask students to interpret situations similar to those met in the project (quality, architecture, integration, release, organisation, measurement, responsible use of AI).
It assesses knowledge and understanding, judgement and clarity of expression. It is not a memorisation of the portfolio: students must reason independently on the course material.

Final grade rules
The final mark out of 30 is the weighted average of the components above. To pass, students must achieve an overall pass mark; when the portfolio is team-based, the instructor may also require a pass on both main components in order to verify individual preparation.
In group work, individual marks may differ according to evidence (commits, reviews, parts discussed in the individual examination).
Use of artificial intelligence tools is allowed in project work only if disclosed; in assessment students must be able to explain choices, limits and the content of any automatically generated parts.
Detailed criteria, demonstration deadlines and sample papers, when available, are published on the e-learning platform.

written

The instructor is responsible for ensuring the authenticity and originality of all examinations and coursework. In cases of suspected academic misconduct, an additional on-site assessment may be required during the exams, which may differ from the standard format.

Grade descriptors

The final mark is out of 30 and is the weighted average of the project portfolio (60%) and the individual examination (40%). The levels below guide the assessment of each component and of the overall result.

Fail (below 18/30)
Fragmentary or incorrect knowledge of core topics. The portfolio lacks essential evidence (increments, tests, integrations, completion criteria, demonstrations), or the work cannot be explained by the individual student. In the individual examination the student cannot reason about simple cases or compare approaches correctly.

Pass / sufficient (18–20/30)
Basic knowledge of the main contents and correct but limited application. The portfolio shows a minimal complete path, with some quality and process evidence, even if uneven or shallow. The individual examination answers simple questions and cases with essential arguments.

Fair (21–23/30)
Sound grasp of concepts and ability to apply them to typical course situations. The portfolio is coherent: successive increments, checks and integrations are present; decisions and completion criteria are documented understandably. The individual examination compares approaches with relevant examples and few major errors.

Good (24–26/30)
Secure knowledge and good application and judgement. The portfolio shows good iterative work (effective tests and reviews, motivated choices, automation or release/recovery procedures where required, clear demos). The individual examination handles non-trivial cases, justifies trade-offs and links theory to project practice.

Very good (27–28/30)
Broad mastery and mature use of method. The portfolio is solid, readable and well argued; evidence shows improvement over time and conscious control of quality, architecture, integration and delivery. The individual examination is precise, critical and able to deal with incomplete information.

Excellent (29–30/30)
Full mastery and high-level independent judgement. The portfolio is an example of rigorous and effective method, with essential but high-quality documentation and clearly recognisable individual contributions. The individual examination is excellent in completeness, rigour and synthesis; any AI-generated parts are disclosed and fully explained. Honours (lode) may be awarded when excellence is shown in both components.

Cross-cutting criteria (both components)

• Conceptual correctness and completeness relative to the task.
• Quality of evidence and explainability of one’s own contribution.
• Judgement on trade-offs (speed, quality, risk, workload).
• Clarity of communication (written, oral or via working software).
• Disclosed and responsible use of artificial intelligence tools, where applicable

Theoretical lectures and practical laboratory classes;
Audio and Video online resources;
Chat and forum;