Welcome

Welcome to COMP23311: software engineering at the University of Manchester.

0.1 Making better software

The development of software systems is a challenging process. Customers expect reliable and easy to use software to be developed within a set budget and to a tight deadline. As we come to depend upon software in so many aspects of our lives, its increasing size and complexity, together with more demanding users, means the consequences of failure are increasingly severe. The stakes for today’s software engineers are high!

Course unit roadmap. This twelve week course will take you from small scale code changes (shown in grey), through to working with features (shown in orange) and on to larger-scale change (shown in yellow). We finish with an open source challenge in chapter 11. The skills you will develop on this course are fundamental to modern software engineering.

Figure 0.1: Course unit roadmap. This twelve week course will take you from small scale code changes (shown in grey), through to working with features (shown in orange) and on to larger-scale change (shown in yellow). We finish with an open source challenge in chapter 11. The skills you will develop on this course are fundamental to modern software engineering.

Experience over the last few decades has taught us that software development failures are rarely caused by small scale coding problems. Instead, failures result from the difficulties of writing software that customers actually need, of keeping up with constantly changing requirements, of coping with the scale of large developments, of getting many different people with very different skill sets to work together, and of working with large bodies of existing code that no one on your team may fully understand. Being a good coder is an important part of being a good software engineer, but there are many other skills - including soft skills - that are needed too.

In this course unit, you will get the chance to expand and broaden the programming skills you gained in your first year course units by applying them in a more realistic context than is possible in a small scale lab, see figure 0.1. Instead of coding from scratch, you will be working in a team to make changes to a large open source software system, consisting of thousands of classes and tens of thousands of files - and all without breaking the existing functionality.

You will fix bugs in the codebase and add new features, as well as performing larger scale refactorings to maintain or improve on non-functionality properties of the system. You will perform all this using an industry strength tool set. We will complement the hands-on experience-based learning with an understanding of the core concepts underlying current notions of software engineering best practice. Volunteer mentors from local industry will help you to put your learning into context, and to understand the key importance of being not just a good coder, but a good software engineer.

This course unit detail provides the framework for delivery in 20/21 and may be subject to change due to any additional Covid-19 impact. Please see Blackboard / course unit related emails for any further updates.

0.2 Aims

This unit aims to help students appreciate the reality of team-based software development in an industrial environment, with customer needs, budget constraints and delivery schedules to be met. Through hands-on experience with an industry-strength development toolkit applied to a large open source software system, students will gain an appreciation of the challenges of green and brownfield software development, along with an understanding of the core software engineering concepts that underpin current best practice. Students will have the core skill set needed by a practicing software engineer, and will be ready to become productive and valuable members of any modern software team.

0.2.1 Learning outcomes

On successful completion of this unit, a student will be able to:

  • make use of industry standard tools for version management, issue tracking, automated build, unit testing, code quality management, code review and continuous integration.
  • write unit tests to reveal a bug or describe a new feature to be added to a system, using a test-first coding approach.
  • explain the value of code reviews, and to write constructive and helpful reviews of code written by others.
  • make use of basic Git workflows to coordinate parallel development on a code base and to maintain the quality of code scheduled for release.
  • explain the role of software patterns (design and architectural) in creating large code bases that will be maintainable over the long term.
  • explain why code that is easy to test is easy to maintain, and make use of test code smells in identifying and correcting design flaws (design for testability)
  • apply basic software refactorings to maintain or improve code quality
  • explain the challenges inherent in cost estimation for software development, and create defensible estimates with the help of work breakdown structures

0.3 Recommended reading

The following books are recommended course texts, they are all available from the University of Manchester library if you clickthrough to the references:

  1. Pro Git (Chacon and Straub 2014)
  2. The pragmatic programmer : from journeyman to master (Hunt and Thomas 2004)
  3. Effective unit testing : a guide for Java developers (Koskela 2013)
  4. Clean code : a handbook of agile software craftsmanship (Martin and Feathers 2009)
  5. The clean coder : a code of conduct for professional programmers (Martin 2011)
  6. Beginning software engineering (Stephens 2015)

These and any other references cited are listed in chapter 25.

0.3.1 Requirements

The compulsory pre-requisites for this course are the first year programming units:

  1. COMP16321: Programming 1
  2. COMP16412: Programming 2

0.3.2 Overview of course

The following is an outline of the topics covered in COMP23111.

  • Team software development
  • Software project planning and issue tracking
  • Greenfield vs brownfield software development
  • Git best practices and common Git workflows
  • Automated build tools and release management
  • Automated unit, integration and acceptance testing
  • Test code quality and test coverage tools
  • Continuous integration and testing tools
  • Best practices and tool support for code review, including source code quality tools
  • Design patterns and common architectural patterns
  • Design for testability
  • Refactoring for code quality
  • Safely migrating software functionality
  • Basic risk management techniques
  • Working with open source software systems

0.4 Using the lab manual

We expect that the web-based version of this manual will be the one you’ll use most at software-eng.netlify.app. You can search, browse and link to anything in the manual. It was last updated on 18 October, 2021.

However, if you’d prefer, the manual is also available as a single pdf file softeng.pdf and an epub as well softeng.epub. Having said that, the content is optimised for viewing in a web browser, so while the pdf and epub are OK, the web version is the best.

0.5 Contributing to this manual

If you’d like to contribute this laboratory manual, we welcome constructive feedback. Once you’re familiar with git and markdown you can github.com/join and:

git clone https://github.com/dullhunk/softeng.git

Most of the guidebook is generated from RMarkdown, that’s all the *.Rmd files. So markdown files are the only ones you should need to edit because everything else is generated from them including the *.html, *.tex, *.pdf and *.epub files.

0.6 Acknowledgements

This course has been designed, built and written by Suzanne Embury at the University of Manchester with support from a team of academics, industry club members, support staff, graduate teaching assistants (GTAs) and summer students including (in alphabetical order):

Muideen Ajagbe, Mohammed Alhamadi, Aitor Apaolaza, Gerard Capes, Martina Catizone, Sarah Clinch, Peter Crowther, Sukru Eraslan, Gareth Henshall, Duncan Hull, Caroline Jay, Nikolaos Konstantinou, Kamilla Kopec-Harding, Kaspar Matas, Chris Page, Dario Panada, Steve Pettifer, Liam Pringle, Julio Cesar Cortes Rios, Sara Padilla Romero, Viktor Schlegel, Stefan Strat, Jake Saunders, Federico Tavella, Mokanarangan Thayaparan, David Toluhi, Karl Tye and Markel Vigo.

Academic staff on the course for 2021/22 include:

We’d also like to thank all the 1,500+ students who have done the course since its first iteration in 2016 and given us feedback on how to improve.

Thanks also to our industrial mentors, the Institute of Coding (IoC) instituteofcoding.org and the Office for Students (OFS) for their ongoing support.

0.7 Licensing

The text of this lab manual is published under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 License (CC-BY-NC-ND) license see figure 0.2

The text of this guidebook is published under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 License (CC-BY-NC-ND) license which means you can copy and redistribute the material provided that you provide full attribution, do not use the material for commercial purposes and you do not make any derivative works.

Figure 0.2: The text of this guidebook is published under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 License (CC-BY-NC-ND) license which means you can copy and redistribute the material provided that you provide full attribution, do not use the material for commercial purposes and you do not make any derivative works.

This license means you can copy and redistribute the written material provided that:

  • You provide full attribution by linking directly to the original source
  • You do not use the material for commercial purposes
  • You do not make any derivative works

See the full license (CC-BY-NC-ND) for details.

0.7.1 Your privacy

This site is hosted on netlify.com, see the netlify privacy policy. This site also uses Google Analytics to understand our audience better which is compliant with the General Data Protection Regulation (GDPR). If you want to, you can opt out using the Google Analytics Opt-out Browser Add-on.

Some of these services use cookies. These can be disabled in your browser, see allaboutcookies.org/manage-cookies

So now that we’ve dispensed with the formalities, you can start using this laboratory manual.

Document version: 18 October, 2021