SPE: Software Product Engineering
Connecting Industrial Partners with Student Talent.
Potential partners please contact:
Dr. Daniel Schien, Lecturer
Tel: +44 (0)117 3315105
Department of Computer Science
University of Bristol
Merchant Venturers Building
Bristol BS8 1UB
The Software Product Engineering unit is a core element in the learning software engineering at the University of Bristol. Within this unit, teams of students develop their software engineering skills, acting as a software consultancy for real-world clients.
For the clients this is fantastic opportunity to work with our Computer Science students. In their projects our students work on project ideas from public and the private sector organisations.
Below we summarise what’s involved for clients. For any remaining questions, please get in touch via email.
In the second year of our undergraduate program in Computer Science, our students work as a group on a problem for a real-world client. Within this project the students develop a solution to a problem or an opportunity that the client has identified.
There are lots of reasons to get involved in SPE:
- Use a student project to create engagement in your organisation on a new topic or technology. These kinds of project are great for trying out new ideas and exploring novel technologies.
- Promote your organisation and establish a relationship with some of our students (for example, for summer internship positions).
- Develop mentoring skills or experience as a product owner within your organisation.
- Get direct value for your organisation from the project outcomes. But please bear in mind that many features and aspects of the implementation may remain prototypical.
There is no direct financial cost to the client organisation. The main investment from the client side is to meet with the students every couple of weeks to feed back on their progress (distributed meetings/teleconferencing is now the norm).
Each group contains approximately four students and works on their project during 22 weeks of study from the beginning of October until May of the following year. On average each student works for about six hours per week on the project. The students work in small iterations along the entire software development life cycle from requirements gathering, over design and implementation to test and deployment of a solution.
Once a group has been allocated to the project in the first week of October, the team meets their client. They begin by trying to understand the motivation for the project and exploring the solution space. This requirements-gathering stage is a key part of the project itself.
It is important to note that these are software engineering projects and thus must always involve the construction of a software system. Whilst software is the ultimate output of the project, the work involved may well require the students to investigate various technologies and alternative designs for the solution. These designs themselves form another type of project output.
Projects should be incremental in scope - at their core will be a minimum set of functionality that all student groups will be able to implement. Depending on progress, the team will increase the scope and scale of the system over time, providing more ambitious revisions of increasing value to the client. The students will take your exciting vision and work on it iteratively in incrementally scoped packages in an agile fashion.
Projects should not include a significant degree of investigative system modelling or any research. For example, any data science, machine learning or computer vision aspects need to be straightforward to implement with existing software packages.
By default backend systems will be implemented with Spring Boot in Java and mobile applications will be based on Android. It is possible to deviate from this on a case-by-case basis.
Responsibilities and involvement
The effort provided by the students is contributed without charge to clients. We do however expect that the client will commit to meeting their student teams on a frequent basis. The students will be applying an agile development method that involves meeting with their client in regular intervals to present their progress, gain feedback and discuss the next steps. The purpose of these meetings is to steer the projects towards a mutually agreeable outcome.
The length of the intervals between meetings will depend on the progress of the groups, but it is expected that this will usually be every two to three weeks.
The duration of the meetings will again depend on the progress of the project, but are likely to be approximately an hour in length.
Besides these meetings with the students, the teaching staff we will be in contact with the client from time to time to get feedback on their developing relationship with the students.
The proposal brief
To propose a project, submit a brief using the button at the bottom of this page. The brief should be directed at the students - at the start of the semester, the students will chose their projects based on these descriptions. If you wish, you may include your contact details in the brief so that students can contact you in the first week of the semester before making their project choice.
It is recommended that you include the following elements in your brief:
- Client description - please describe yourself.
- Motivation - what is the opportunity/problem that you have identified?
- Solution - what do you think the solution might look like? Just set a frame that allows for a variety of solutions. Part of the project is to find the best among several alternative solutions.
- Constraints - are there any constraints that the students should be aware of?
- IP - by default solutions will be made open-source and the students will retain the IP. If this is not the case for you project, please indicate so in the brief.
Please try to stay within two pages of A4 (appox 800 words)
Feel free to get in touch using the contact details at the top of this page if there are any issues you wish to discuss further.
This year submission takes place via Microsoft Forms.