imperial logo

Software Engineering Group Project (60021)

Spring 2026

Overview

Purpose: This course is about the development and management of software projects. We hope that you will learn and put into practice state-of-the-art techniques used in industrial software development to ensure that your team produces software co-operatively, reliably and on schedule. The material on this page is a collection of resources to help you to adopt these practices.

People:

Course Information: Most of the information on how the course is run, administrative information, dates and so on can be found on the course wiki site here. This page contains further information relating to the software engineering aspects of completing an SEGP project. We gave an initial lecture on this topic on 6th January 2026 and the slides and recording can be found here on the wiki.

Software Engineering Resources

We are not prescriptive about the specific software engineering techniques, practices and approaches that you use. However we expect a modern, professional approach and we suggest a number of well proven starting points for defining your team's approach. We provide some links to useful resources on some of the key topics below. These are in addition to the material we covered in the introductory lecture. Where possible we have linked to O'Reilly Learning or other online sources so you can access these resources directly. An O'Reilly playlist with the O'Reilly references can be found here.

Agile Software Delivery

We strongly suggest that you use an agile approach to software delivery, by which we mean an incremental and iterative approach, which is actively open to change throughout the delivery lifecycle. An incremental approach means delivering the software regularly, in useful, valuable pieces ("increments"), each of which delivers a useful improvement in the capability of the system. An iterative approach means structuring the delivery into repeated sequences of well defined steps ("iterations"), each one delivering a useful increment to the software. An incremental approach allows you to learn about the product you are building as your customer sees each increment you deliver. An iterative approach allows you to improve your delivery process and practice each iteration as you reflect on what went well and what needs to be improved in the retrospective.

Some useful resources on the fundamentals of agile delivery are:

  • The book Learning Agile by Andrew Stellman and Jennifer Greene explains agile fundamentals, introduces Scrum, XP and Kanban, and the reasoning behind each.
  • The book The Art of Agile (2e) by James Shore and Shane Warden also explains how to adopt agile delivery. A lot of the book is concerned with a level of adoption and scale you don't need to worry about in a small 8-week project, but the material on Focusing may help you with thinking about how to focus your effort for best results.
  • Dr Chatley's materials on agile fundamentals (pdf)
  • Dr Chatley's materials on agile practices (pdf)
  • Dr Chatley's materials on agile planning and estimation (pdf)

Scrum is one of many agile processes but, as we explained in the initial lecture, we think it's a good place to start as it is simple, well understood and based on iterations. Some introductory resources are below. The original book Agile Software Development with Scrum by Ken Schwaber and Mike Beedle has been out of print for some time (although we do have a few copies in the library!) but the books below are more modern options.

  • Comprehensive online guides to Scrum are available at ScrumGuides.org, written and maintained by many of the original creators of the method including Jeff Sutherland and Ken Schwaber. This may be all you need.
  • If you'd like a book, then Essential Scrum by Ken Rubin is a good place to start. It starts with the basics and defines all of the Scrum concepts and processes pretty clearly.

Some resources for other well known agile methods are:

Product Management

In many software projects building the software is not the hard part, working out what software to build is actually much more difficult, particularly in the face of the constant constraints of cost, time and customer demands. Product Management is the discipline of solving this problem and a "Product" group often works alongside an "Engineering" group to work out what to build, and when (and just as importantly what not to build). For this project you need to do your own product management and manage the customer yourself.

Some introductory resources on product management are below:

  • Dr Chatley's introductory material on product management. (pdf)
  • A clear explanation of what a product manager really is from Martin Eriksson, a well known figure in the field. (Medium article)
  • The book, Agile Product Management with Scrum by Roman Pitchler, a well known independent consultant, is a very good "how to" guide to understand the fundamentals quickly in a Scrum delivery context.
  • We mentioned Impact Mapping as a useful technique for customer conversations in the initial lecture, a website devoted to the technique is at www.impactmapping.org.
  • Finally, the website for the conference series Mind the Product (coincidentally founded by Martin Eriksson) has a lot of good content if you have specific questions, at www.mindtheproduct.com

Technical Practices

Source control: is a fundamental practice, which we are sure you are already quite proficient in, but when working as a team it is easy for complexity to get out of control and mistakes to be made (inevitably at the very worst time). You will almost certainly use the Git source control system (although others such as Mercurial are pefectly acceptable if you know and prefer them). If you are using Git then it has some quite good learning resources available on the main website.

Within DoC, Git is generally the preferred source control system and specifically, GitLab has been adopted as a departmental standard, there is an internally hosted service of the Community Edition, and you are encouraged to use that as a starting point. That said, some teams prefer to use one of the free services from a commercial provider such as GitHub, which is also acceptable. Just be sure you know what you are signing up for in terms of cost and what security is provided.

  • If you're a visual learner, then Learning Git by Anna Skoulikari may well suit you.
  • If you'd like a more advanced, independent, book on Git, a recently revised one is Version Control with Git (3e) by Prem Kumar Pnuthorai and Jon Loeliger.
  • Dealing with branching in source code control often gets people into a mess quickly if a simple and standard approach isn't agreed. Martin Fowler has a nice article capturing some of the important patterns for this potentially complex topic.

Testing: As we discussed in the introductory lecture, automated (and manual) testing are absolutely key to controlled, reliable, professional delivery. This isn't an academic point. Tests save you from yourself when you make a mistake, allow a team to collaborate on shared code, and give you the confidence to ship your software, knowing that it is working correctly. Some useful background on testing includes:

  • The book Agile Testing by Lisa Crispin and Janet Gregory is a classic in the field, explaining how think about testing in an agile context, make testing effective, what sorts of testing you need, and when and when not to automate testing.
  • Test Driven Development is a really fundamental and proven technique for integrating unit testing into the development cycle. Martin Fowler has a good introductory article on the technique, the original book is Kent Beck's Test Driven Development by Example and a more recent book which explains the technique clearly is Learning Test-Driven Development by Saleem Siddiqui. James Shore's book that we referenced above also has a chapter explaining the basics.
  • Behaviour Driven Development (BDD) is a testing approach that tries to make testing comprehensible to the customer and so is usually used to replace traditional approaches to functional, end-to-end or acceptance testing. The definitive introductory article is Introducing BDD by Dan North the inventor of the approach. The Cucumber tool is one of the best known BDD frameworks and they have both practical tool documentation as well as introductory material on BDD. There are also books on using Cucumber from its originators including The Cucumber Book (2e) and The Cucumber for Java Book
  • Finally a book which takes a wholistic view to automated testing, and explains how to make automated testing an effective part of the core delivery process is Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce (Nat is a DoC MEng and PhD alumni). Highly recommended to at least read the introductory parts.

Continuous Integration is the backbone of disciplined, reliable team-based software delivery. In brief it involves implementing a "pipeline" of automated tools that perform all of the activities needed from code being checked in, to the code being ready to deploy to production. This typically involves build, unit testing, integration testing, functional testing (such as BDD), automated quality checks (such as those provided by SonarQube), automated security checking, packaging for deployment and so on. It is a large field, so it is difficult to point at one or two definitive sources, but the following are good starting points:

  • Martin Fowler has a good (recently updated) introductory article on the core concepts on his web site here.
  • The original and still arguably definitive book on continuous integration and delivery is Continuous Delivery by Jez Humble and Dave Farley.
  • A widely used book focusing on CI is Continuous Integration: Improving Software Quality and Reducing Risk by Paul Duvall, Steve Matyas and Andrew Glover.
  • Both GitLab and GitHub have CI guides although both are inevitably highly tailored to the specifics of their products.

As we said in the lecture, avoid a lot of complexity in your CI pipeline, but make sure it contains simple and reliable actions and checks for everything that is important to verify before releasing your software.