Projects
ISEE - Course Project 2020
The course project will provide you with hands-on software engineering experience, involving a team of four students.
You will design and develop your product (an Android App) in ~12 weeks, and in this time, cover all phases of software development in an agile fashion.
The project is broken into five milestones, for which certain deliverables are expected (see below).
Deliverables for each milestone:
- a Blog, summarizing your work in a less formal way.
- a presentation, to convey your progress to other students
Continuous tasks (mostly weekly):
In addition to submitting artifacts required for each milestone, each week you will submit reports and attend meetings, just as real software development projects do.
- commit a weekly team status report every Wednesday Thursday, 5 pm (starts in week 3)
- attend a weekly project meeting (exceptions will be announced) every week within your assigned Tutorial (slot to be announced)
Project Topics
A brief description for each of the projects can be found here
How to form a Team
Just as in real life, you can't have all that you want. This is particularly true when composing a project team: If you join a company they will put you in a team where they need your expertise and/or man power. The extent you can influence this decision: ~0%.
We follow this pattern in a similar way:
- First, you have to register for the Tutorials in the LSF (there called "Seminar/Exercise"). Indicate each slot that fits to your schedule (there are four tutorials avaible).
- Until April 27, I will eventually assign students to ONE tutorial. This is fixed for the whole course.
- In week 2, come to your assigned tutorial. There, we will build teams of 4 students in an adhoc fashion.
- Finally, each team send an Email to the Lecturer( Dr. Steup ) with the following information:
- a team name
- preferred topic (see introductory slides)
- for each team member: full name, email adress, student ID, github account
Software Engineers Blog
For each milestone, each team has that create a Blog, which summarizes their activities. These Blogs adhere to the milestones, defined in the Schedule, and must be submitted until the same deadline as the milestone presentations (see below).
You will be provided with a set of questions that must be possible to answer when reading the Blog (but you are not supposed to put them in the Blog).
The Blog will be created as a Github page and a template (that you can change at your own preferences) will be provided in your team's initial Github project.
Finally, we will publish a rubric with criteria that are important for the evaluation of the Blog.
Milestone Presentation
Besides the software engineers blog, teams will give presentations for each milestone to reflect their current project status and get feedback from other teams.
The content is basically the same as for the Blog, just differently prepared and presented.
The time for each presentation is approx. 10 minutes (tentative).
Presentations for the exercises need to be submitted BEFORE the following deadlines using moodle.
- Team Presentation, deadline: 26.04.2020, 23:59
- Basic Prototype, deadline: 31.05.2020, 23:59
- Advanced Prototype, deadline: 21.06.2020, 23:59
- Beta Prototype, deadline: 05.07.2020, 23:59
- Final Presentation: TODO
The instructor will not accept any presentation sent after the above deadlines. For dates of presentation, see the Schedule.
Participation in project presentations is mandatory for ALL participants (not showing up frequently will lead to a penalty)!
Weekly Project Meetings
You will meet with a TA for 15 minutes during your assigned Tutorial.
The course staff serves as both customer and mentor. When you have a meeting with your TA, you are allowed to ask the TA to serve any of these roles, or even to switch roles during the meeting. As customer, the TA can help you to determine what a reasonable set of requirements are, and whether your documents and prototypes are compelling. As mentor, the TA can help you to resolve conflicts or give suggestions about designs, teamwork, and tools. Don't forget or underuse either of these roles.
It is a bad idea to try to hide information from your customer. If things are going poorly or you are having trouble, be upfront. You may get good suggestions, and the customer won't feel blindsided if you are unable to resolve the problems on your own. It is a doubly bad idea to try to hide problems from your TA. Instead, use the TA as a resource to help solve your problems.
Team Status Report
Weekly status reports help to keep your boss, the executives, the customers, and yourselves informed about your progress. It ensures that you understand your problems, notice if you are unproductive, and get help.
Just like in a real software development project, each week your team will provide a team status update to management each week. This should roughly fit on a single page.
Each team status update should have four sections. Each section is typically about the size of one or at most two paragraphs, but it can be organized as bullet points or in some other clear way.
- The first section is easy. It should be an exact copy of the third section from last week that is, your goals from a week ago. (It can be empty for the first .)
- The second section should report the progress you've made this week: what you've done, what worked, what you learned, where you had trouble, and where you are stuck.
Here, you should also indicate the roles and responsibilities/tasks of each team member in the recent week. - The third section should outline your plans and goals for the following week (including who is responsible for wat). Bullet points are fine. If tasks from one week aren't yet complete, they should roll over into your tasks for the next week. It's good to include some less-detailed longer-range schedule items in this list as well, so that you don't think just about the next week.
- Team reports should have a fourth section: an agenda for the meeting with your TA.
Note: Since parts of this report concern the individual team members, it is expected that the team status report is composed in a collaborative fashion, that is, each member should contribute to each report (at least for Section 2 and 3).