-
Notifications
You must be signed in to change notification settings - Fork 9
/
index.Rmd
211 lines (141 loc) · 15.1 KB
/
index.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
---
title: "Software engineering"
author: Suzanne Embury and the software engineering team. The text of this guidebook is licensed CC-BY-NC-ND and was last updated on `r format(Sys.time(), '%d %B, %Y')`
site: bookdown::bookdown_site
documentclass: book
bibliography: [software-engineering.bib]
biblio-style: apalike
link-citations: yes
description: "Second year software engineering course at the University of Manchester"
url: 'https\://software-eng.netlify.app/'
github-repo: dullhunk/softeng
twitter-handle: csmcr
# added via R4DS
knit: "bookdown::render_book"
#always-allow-html: yes
always_allow_html: true
# output: word_document
---
# Welcome {.unnumbered #welcome}
Welcome to (ref:coursecode): [software engineering at the University of Manchester](https://studentnet.cs.manchester.ac.uk/ugt/COMP23311/syllabus/).
<!-- this is the main branch-->
## Making better software {#better}
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!
```{r course-overview-fig, echo = FALSE, fig.align = "center", out.width = "100%", fig.cap = "(ref:openingcaption)"}
knitr::include_graphics("images/course-overview.png")
```
(ref:openingcaption) 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 \@ref(opening). 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 \@ref(fig:course-overview-fig). 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 industry (see chapter \@ref(ourmentor)) 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.
## Aims {#bilo}
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.
### 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
<!--codebase, documentbase, languagebase, wordbase-->
## Recommended reading {#recread}
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](https://git-scm.com/book/en/v2) [@progit]
1. The pragmatic programmer : from journeyman to master [@pragmatic]
1. Effective unit testing : a guide for Java developers [@unittesting]
1. Clean code : a handbook of agile software craftsmanship [@cleancode]
1. The clean coder : a code of conduct for professional programmers [@cleancoder]
1. Beginning software engineering [@beginning]
These and any other references cited are listed in chapter \@ref(reading).
### Requirements {#prereq}
The compulsory pre-requisites for this course are the first year programming units:
1. [COMP16321: Programming 1](https://studentnet.cs.manchester.ac.uk/ugt/COMP16321/syllabus/)
1. [COMP16412: Programming 2](https://studentnet.cs.manchester.ac.uk/ugt/COMP16412/syllabus/)
### Overview of course {#courseo}
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
## Using the lab manual {#usingit}
We expect that the web-based version of this manual will be the one you'll use most at [software-eng.netlify.app](https://software-eng.netlify.app/). You can search, browse and link to anything in the manual. It was last updated on `r format(Sys.time(), '%d %B, %Y')`.
<!--However, if you'd prefer, the manual is also available as a single pdf file [softeng.pdf](https://software-eng.netlify.app/softeng.pdf) and an epub as well [softeng.epub](https://software-eng.netlify.app/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.-->
## Contributing to this manual {#contributing}
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](https://github.com/join) and:
* Raise new issues at [github.com/UoMCS/softeng/issues/new](https://github.com/UoMCS/softeng/issues/new)
* Click on the `Edit this page` link, which appears on the bottom right hand side of every page published at [software-eng.netlify.app](https://software-eng.netlify.app) when viewed with a reasonably large screen (not a phone)
* Contribute at [github.com/UoMCS/softeng/contribute](https://github.com/UoMCS/softeng/contribute) and help with existing issues at [github.com/UoMCS/softeng/issues](https://github.com/UoMCS/softeng/issues)
* Fork the repository, make changes and submit a pull request [github.com/UoMCS/softeng/pulls](https://github.com/UoMCS/softeng/pulls). If you need to brush-up on your pulling skills see [makeapullrequest.com](http://makeapullrequest.com/)
* From the command line, clone the repository and submit pull requests from your own setup:
````md
git clone https://github.com/UoMCS/softeng.git
````
Most of the guidebook is generated from [RMarkdown](https://en.wikipedia.org/wiki/Markdown), that's [all the `*.Rmd` files](https://github.com/UoMCS/softeng/search?l=RMarkdown). 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.
## Acknowledgements {#teambury}
This course has been designed, built and written by [Suzanne Embury](http://www.cs.man.ac.uk/~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, Mercedes Argüello Casteleiro, Gerard Capes, Martina Catizone, Sarah Clinch, Peter Crowther, Anas Elhag 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, Sandra Sampaio, Jake Saunders, Federico Tavella, Mokanarangan Thayaparan, David Toluhi, Karl Tye, Jonas Verbickas and Markel Vigo.
Academic staff on the course for 2022/23 include:
* [Thomas Carroll](https://personalpages.manchester.ac.uk/staff/thomas.carroll/)
* [Suzanne Embury](http://www.cs.man.ac.uk/~embury/)
* [Duncan Hull](https://personalpages.manchester.ac.uk/staff/duncan.hull/)
* [Liping Zhao](https://www.research.manchester.ac.uk/portal/liping.zhao.html)
We'd also like to thank all the 2,000+ students who have done the course since its first iteration in 2016 and given us feedback on how to improve.
<!--2016, two cohorts of 250 = 500 plus 250 cohorts in 2017, 2018, 2019 and 2020-->
Thanks also to our [industrial mentors](https://www.cs.manchester.ac.uk/connect/business-engagement/industrial-mentoring/), the Institute of Coding (IoC) [instituteofcoding.org](https://instituteofcoding.org/) and the [Office for Students](https://www.officeforstudents.org.uk/) (OFS) for their ongoing support.
## Licensing {#license}
The *text* of this lab manual is published under the [Creative Commons Attribution-NonCommercial-NoDerivs 3.0 License](https://creativecommons.org/licenses/by-nc-nd/3.0/) (CC-BY-NC-ND) license see figure \@ref(fig:cc-by-nc-nd-fig)
```{r cc-by-nc-nd-fig, echo = FALSE, fig.align = "center", out.width = "100%", fig.cap = "(ref:captionccbyncnd)"}
knitr::include_graphics("images/by-nc-nd.png")
```
(ref:captionccbyncnd) The *text* of this guidebook is published under a [Creative Commons Attribution-NonCommercial-NoDerivs 3.0 License](https://creativecommons.org/licenses/by-nc-nd/3.0/) (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](https://creativecommons.org/licenses/by-nc-nd/3.0/) (CC-BY-NC-ND) for details.
### Your privacy {#privacy}
This site is hosted on [netlify.com](https://www.netlify.com/), see the [netlify privacy policy](https://www.netlify.com/privacy/). This site also uses [Plausible Analytics](https://plausible.io/) to understand our audience better which is compliant with the General Data Protection Regulation (GDPR).
So now that we've dispensed with the formalities, you can start using this laboratory manual.
<!--boilerplate text and constants that gets re-used throughout-->
(ref:ideversion) `2022-12`
(ref:commit-were-using) `5450a33`
(ref:commit-message) `Organize imports`
(ref:repoURI) [https://gitlab.cs.man.ac.uk/COMP23311_2023/sliding_puzzle_<your-username>.git](https://gitlab.cs.man.ac.uk/COMP23311_2023/sliding_puzzle-your-username.git)
(ref:repo2URI) [https://gitlab.cs.man.ac.uk/COMP23311_2023/sliding_puzzle2_<your-username>.git](https://gitlab.cs.man.ac.uk/COMP23311_2023/sliding_puzzle2-your-username.git)
(ref:coursecode) COMP23311
<!-- todo update hanbook urls e.g. UGHandbook21:Academic_Malpractice to UGHandbook22:Academic_Malpractice etc-->
<!--
23311-TeamCwk1-S-Fixing Bugs 120 40
23311-TeamCwk2-S-Adding Features 120 40
23311-IndCwk1-S-Basic Git 10 10
23311-IndCwk2-S-Conflicts in Git 10 10
-->
(ref:infobox) ℹ️ **Note** ℹ️
(ref:cautionbox) ⚠️ **Caution** ⚠️
(ref:commentbox) **`#Comment`**
(ref:anotherref) here
<!-- Configuration for the exercise -->
(ref:totalmark) 10
(ref:percentage) 7
(ref:deadline) 6.00pm, Friday 6th October 2023
(ref:deadline2) 6.00pm, Friday 20th October 2023
(ref:feedbackdateindicwk2) 6.00pm, Friday 13th October 2023
(ref:numsteps) 9
(ref:piazzaforum) [piazza.com/class/lm0s5lzly5q41i](https://piazza.com/class/lm0s5lzly5q41i)
(ref:livehelpqueue) [gitlab.cs.man.ac.uk/comp23311_2023/COMP23311-Live-Help-Queue](https://gitlab.cs.man.ac.uk/comp23311_2023/COMP23311-Live-Help-Queue/)
(ref:mentors) Airbus, Airnode, Alphabet (Google), AND Digital, Apadmi, Apple, ARM, Auto Trader UK, Barclays, the BBC, Bet365, Beyond Trust, Biorelate, BJSS, Blaize, Bloomberg, Booking.com, Brightec, CERN, CDL Software, Cisco, Codat, CodeThink, Code Computer Love, Cognizant, Couchbase, Cubic Motion (now Epic Games), DAI, DataCentred, Digital Bridge Ltd, Disney Streaming, EGN Digital, Farm Digital, Giant Digital, Goldman Sachs, IBM, Interact Software, Ivanti, Koder.ly, Matillion, MediaTek, Meta (Facebook), Microsoft, Moonpig, Morgan Stanley, Nandos, NCC Group, On The Beach, Peak.ai, Push Doctor, Rental Cars, Sainsburys, Sage Group plc, Shout Platform Limited, Roku, Siemens (Mentor Graphics), SKY, Slalom, Spotify, SteamaCo, The Startup Factory, Tanglewood Games, THG, ThoughtWorks, Tranzfar, UK Parliament, UL, Unipart Digital and Zuhlke.