Course Artifacts

Besides the main project results, we expect you to produce a number of artifacts in the course of the Software Engineering Project. These artifacts allow us, to assess your progress and to guide you. At the end, they are used to grade your team’s performance.

Project Management

Good project management is key to the success of a project. To help you quickly establish a process for your team, we require an informal project management document (max. 4 pages, may be in bullet-point form). This document should describe your thoughts on the following questions:

  • Did you understand your customers project vision?
  • How do you organize yourselves? Who does what and when?
  • Which processes do you have and how do you implement them? Especially for the requirements engineering!
  • Which risks do you face and how do you deal with them?
  • When is your project a success? And when is it finished?

We use this document to prepare your individual Project Management Workshops.

Project Specifications

To define what successful completion of your project means, you first need to know what the project is about and you need to agree on this with your customer:

  • What are the goals of the project?
  • What provides value to the customer?
  • Which constraints affect the project?
  • How do you interact with your customer?
  • How can you ask questions and how fast will you get a response?
  • Who will communicate what, to whom, and when?
  • How do you deliver the products?
  • How does your customer give you feedback (e.g., report bugs)?
  • How do you handle change requests?
  • Which risks does the project face and how do you mitigate them?
  • What kind of input (specifications, code, etc.) and devices are required and when are those provided?

All this is part of project specifications and forms the contract between you and your customer. Therefore, we require you to document the answers to these fundamental questions in a specification document. The document should contain:

Project Description (2 to 5 pages)
A description of the status quo before the project and the project vision, as well as a description of the business cases that should be covered by the product you will develop and the application scenarios of your solution. This should include a description of the customers business domain and introduce necessary terminology.
Communication (2 to 5 pages)
An agreement of how you and your customer interact. This documents the external part of your team’s project-management process and your customer’s commitment to provide what you need to succeed with the project. An important aspect here is your process for change requests. Please, reuse the content from your informal project management document.
Requirements (15 to 40 pages)
A description of the requirements on your product. This could be a specification of functional, non-functional, user-interface, and environment requirements, including acceptance criteria and customer prioritization. It could also be a prioritized list of user stories. In any case, this part of the document specifies the product you are going to develop. The goal is for you and your customer to reach a common understanding of what you are going to develop and where to start.
Deployment Environment (2 to 5 pages)
A description of the different environments, e.g., development, testing, and production, used during deployment. This section should include concrete information about the required software for each environment as well as the hardware. Thus, clearly defining the requirements for your deployment during the development as well as for your customer when used in production.
Deliverables (1 to 3 pages)
A description of which artifacts you are going to deliver to the customer, how you deliver them, and when you deliver them. This includes a commitment on how frequently you provide updates. Keep in mind that deliverables may also include documentation, e.g., of the reasoning behind design decisions or choosing a particular technology, manuals, e.g., for administrators, developers, or end users, among other things.
Risk Mitigation (2 to 5 pages)
A description of project-specific risks, the strategies you use to mitigate them, and what you will do when a risk becomes a problem. Please, reuse the content from your informal project management document.
Legal Regulations (2 to 5 pages)
An agreement on the legal aspects of the project, such as an assignment of utilization rights to the client. The projects end date is already fixed, but should be included here as well.

The added page range for each topic should give you an idea of the length for each section. However, for some projects it can be useful to differentiate from the recommendations. In that case, please ask for feedback before removing or adding content for the sake of staying within the recommended page limit.
Your project specifications will be the main topic of Review 1.

Software Design

The design of your software generally determines the most relevant properties, such as its efficiency, scalability, and extendability. Therefore, it is absolutely crucial that you have a deep and correct understanding of the central requirements that determine the overall properties of your software. Only after that it is possible to choose those frameworks and libraries that are well-suited for the task at hand.

In the design workshop, you first have to present the core requirements that are relevant w.r.t. the overall architecture and then discuss the concrete design of it. You should do this by discussing the major control- and data-flow of your application. Furthermore, you should present and justify the usage of the primary libraries and frameworks that you are using. For the presentation, choose those frameworks that have a direct impact on the high-level architecture or which even directly determine the architecture. E.g., a framework such as Spring Boot or JEE typically directly determines the high-level architecture while a library such as org.apache.commons.util has no significant impact on the overall design. Another aspect that is generally very important is the testability of your software and, therefore, every good design has to facilitate testing. As part of the design workshop we will also discuss this aspect.

Quality Assurance

Ultimately, a successful project is a win-win situation. You want your customer to be satisfied and you want the development cost for your team to be low. To achieve this, you need to ensure your projects quality. What this means highly depends on your project. For example, your customer may explicitly define quality goals, such as for your product to respond to input within a certain time. She almost certainly also implicitly expects certain qualities, such as for the product not to crash or loose data. Furthermore, quality goals may come from yourselves. For example, you probably want your code to be easy to understand and change and you don’t want break existing functionality.

To achieve a win-win, you need to know the quality goals of your project and you need to take measures to achieve them. Adequate measures depend one the goal, the importance of the goal, and the effort that the measure inflicts on you. For example, to ensure you don’t break existing functionality in you code, you might decide to write automated unit tests and to set up a build server that checks those tests on every commit. The effort of writing the tests is almost certainly much lower than checking the functionality manually after every change. On the other hand, to ensure good code readability is probably best achieved by code reviews, since automated quality checks are often unreliable.

Finally, consider that quality goals and adequate measures may change over time. While manual testing of a single workflow may be sensible, automated testing may become preferable when the number of workflows increases. To chose adequate measures, consider the current state of your project and your short-to-mid-term knowledge about where it’s going to go. You shouldn’t plan to far ahead, but you should be ready to adapt as goals change.

Your quality assurance will be the main topic of Review 2.

Review Slides

In the project reviews you report on your project progress and the decisions and measures you took. For us to assess your work, we expect you to submit your presentation slides from each review (as PDF) via email to the organizer one the day of the respective review. The slides should show everything we asked you to report in the review.

Final Submission

At the end of the project, you have to hand in a final submission as a digital archive file, e.g., a zip-file. This is mandatory for you to receive your grade. The submission must contain:

  • A document of all updates to your project specification (e.g., change requests).
  • A snapshot of your source code.
  • A poster presenting your project. A selection of the best posters of former years’ are presented in the hallway in S202/A2**. The poster should be DIN A2 with sufficient margins for the frames in the hallway.
  • A static website about your project.
  • The project report(s) (Business Informatics)

Please also submit the poster in print.

Team Website

We present the projects of all teams in our Hall of Fame. To this end, we expect every team to create a static, self-contained website describing the project. This website should contain the following contents:

  • Your team’s information (name, logo, team members, group picture).
  • Your customer’s information (name, logo, link to their website).
  • The title of your project (at most 75 characters).
  • A short, standalone description of you project (at most 400 characters).
  • An extended description of your project (at most 2500 characters).
  • Your “lessons learned”, e.g., your most-important experiences during the project, recommendations to future project teams, Dos & Don’ts, … (for this part there’s no limit or formal requirement).
  • A list of the technologies you used, preferably with a link to the respective website, an icon, and a sentence stating what you used it for.
  • Five images that show (aspects of) you project, e.g., screenshots of your app, photos from meetings, or diagrams depicting important process metrics. Please scale the images to a resolution of about 1024px in the larger dimension.

The website is supposed to show your project’s result, not necessarily the process that got you there. Feel free to reuse texts or images from your documents and to check prior years’ websites for ideas on the layout. Note that we want your websites to still display correctly 5 years from now. So please ensure that the website contains all linked elements, such as images, scripts, and stylesheets. Moreover, please use relative link paths within your website, since it will be included as a subsite to the SEP site.

Project Report (Business Informatics)

If you take the SE project as a “Studienarbeit” (Business Informatics) you have to hand in your project report with the final submission.