Projects

Project list

A list of projects is available as a PDF document. Here are the slides of project presentation.

Managing your team and project

The chair provides an instance of Redmine [w] to ease the collaboration between you, your team mates, your tutor and the customer.

Click here to access your Redmine instance. Sign in with the button in the upper-right corner of the screen.

Grading

Your grade for the project part of the course will depend on the following:

  • The extend to which you used the standard software engineering tools like version control repository (Git in this course) or project management software (Redmine in this course), especially the issues and time logging subsystems usage. For details, see About Redmine and Git section.
  • The quality of the deliverables (documentation, prototype, etc.), as described in Deliverables schedule section.
  • Your team overall cooperation capability as well as your individual contribution to the team, as assessed by your tutor.
  • The satisfaction of the customer with the final delivered prototype as well as his impression on the communication quality with your team during the entirety of the project.

About Redmine and Git

Redmine

Redmine enables you to (amongst other helpful features):

  • track issues (tasks) of each team member,
  • quickly view your prototype code through version control system repository viewer,
  • log time spent on issues and tasks,
  • keep all the project-relevant information in one place in form of a project wiki with uploaded documents.

If you have never used any project management software and have no idea what is an issue, you might wish to check these out:
A short list of Redmine tutorials.
A 5 minute Redmine guide.
Some dude talking about Redmine for almost 19 minutes.

The most relevant features for you are accessible through tabs named Roadmap, Issues, New issue, Wiki and Repository.

The Roadmap tab (initially hidden!) gives you at-a-glance view on how are you progressing with the project by allowing you to group issues into versions. For this course, the natural candidates for roadmap versions are the three iterations, but you can make multiple versions for each iteration, if you wish. Thanks to the roadmap you can easily see when is your next deadline, how many issues you have already solved and how many still need to be solved.

Note: If you do not see the roadmap, you have to create the first version by going to the Settings tab, then Versions subtab and by click on appropriate button.

The Issues tab allows you to view either all the issues or details of any given issue (after you click on it). An issue is a unit of work. Each issue has an assignee, i.e. a person responsible for solving the issue. Issues can be general purpose tasks, bug reports or anything else. The tracker field of issue denotes its kind. Note that the person who created the issue (e.g. because she found a bug) can differ from the person assigned to the issue (e.g. the developer who made the bug in the first place might be assigned to fix it). When logging time in Redmine, you should always log it to accompanying issue that is assigned to you.

Redmine usage hints:

  • You can customize how all the issues are displayed by saving a custom query. You can change the displayed columns of the table or the filtered out issues. It's not super-duper-obvious how to do this, but you can figure this out, I am sure of it!
  • When displaying an issue, in upper right corner you have a Log time button. Use it! Use it every time you log a new block of time for given issue.
  • If you logged the wrong amount of time, you can click on the value given in the spent time field of a displayed issue to edit the amount of time logged in previous time logs.

The New issue tab is obvious.

The Repository tab allows you to view the repository content through web interface once it is setup, or give explanation how to set it up before that.

The Wiki tab provides access to your project wiki. Such wiki is an excellent place to keep the knowledge related to the project organized. For example, you can keep here relevant urls, important bits of information from the customer, attach relevant documents, describe in high level who is responsible for what, provide design documents for the prototype, upload your requirements and use cases docs, or write anything else, really.

On issues and time logging

What are good examples of issue? How to log time? Tremble not, as the answers await you below.

When working on the project, you have to log the time you spend on it. To log time you create a time log that is assigned to given issue. Don't make the issues too broad like "working on the project" or too precise like "writing exceptional case 3 of use case 2". Here are some examples of good issue subjects (please fill in the issue details using your imagination):

Example issue subject Additional remarks
Writing core use case: user buys a product -
Setting up dev. environment -
Reading the relevant research papers -
Trying out the tool provided by the customer -
Participating in meetings This is an example of an "aggregate issue". Each of team members, instead of creating standalone issue for each meeting, creates one issue to which she logs all the time spent on all the meetings. Thus, if the team has 5 members who participated in 3 meetings of length 0.5h, 1.5h and 2h, the Redmine will have 5 issues, one for each team member. Each of these issues will have three time logs assigned to it, totaling to 4h. In total, 20h of man-hours will be logged in Redmine.
Other organizational matters This is another "aggregate issue", but this time for all the other small things like editing wiki, answering emails, etc.
Implementing class SquirrelDispatcher -
Bug: "squirrels hoard nuts for summer instead of winter" The assigned person is expected to fix the bug, even though the issue might have been created by somebody else.
Setting up the database and explaining to the team how to use it -
Writing documentation for the team how to use the
Squirrel-access API provided by the client
-

When and how to log time exactly? What if you got distracted by facebook for 15 minutes? As a rule, if you spent time doing something related to the issue that you wouldn't do if you would have no issue assigned, then you should log the time. This includes setting up the dev environment, googling up the knowledge you need (e.g. on stack overflow), coding, meetings, emailing, writing documentation, etc. but doesn't include commuting, facebooking (or procrastinating in any other way), eating, talking about unrelated stuff or taking extended (15+ minutes, 5+ if you are hardcore time logger, 2+ if you are like me) breaks. For other activities not listed, use common sense :)

Git

Git [w] is a version control system [w]. For motivation why we use Git for this course, please see the motivation section. For documentation on Git refer to the instructions and urls given in the Overview tab and Repository (if still no repo is setup) tab of your Redmine project.

Deliverables schedule

For a quick overview of what we requires from you, please refer to the relevant slides (TBA).

The schedule below implicitly assumes you will run into numerous technical difficulties and will often have missing/imprecise/outdated/incorrect information preventing you from preparing the appropriate prototype and documentation. It is expected from you that you will proactively extract the necessary information about technology and clarifications from the customer, thus enabling you to meet on time the expectation described below.

The expected progress column is for your internal consideration. In general, we won't held you accountable for it, but we will look at your Redmine usage and your progress reports to make sure you are using the tools effectively and you are on track with the project. If you will have constant delays, most probably the customer and tutor will be unhappy and so your grade will be negatively impacted. Not meeting the expected progress also increases the risk you won't be able to provide on time the iteration deliverables, which are graded.

The preferred way of sharing deliverables of last week of iteration is to put them on your Redmine wiki and inform your tutor, including link to the relevant wiki page.

Milestone Due date Expected progress Deliverables
Iteration 1, week 1 13 Nov 2015 You have met with your team, tutor and customer. You have taken notes needed to prepare the first requirements draft and you started to research the technology stack: google it, download, install, etc. Students are expected to provide Redmine issues, time logs and progress report each Friday to their tutor
Iteration 1, week 2 20 Nov 2015 You have prepared the first complete requirements draft. You deployed all the technologies (IDE, database, plugin/extension frameworks, web services, API libraries, tools with GUI, etc.) on your developer machines. You can create and run a "hello world" app using the easier parts of the tech stack. You have a sketchy draft of the core use case. Students are expected to provide Redmine issues, time logs and progress report each Friday to their tutor
Iteration 1, week 3 27 Nov 2015 You have successfully exercised the entire technology stack. You wrote a nontrivial app, based on the use case "happy path", that goes through the entire technology stack, proving that everything works and is ready for serious development. You have refined the requirements document and completed the first use case.
  • Students are expected to provide Redmine issues, time logs and progress report each Friday to their tutor
  • Four A4 pages of contract-style must/may/will not -have requirements
Iteration 1, week 4 4 Dec 2015 A buffer & polishing week. You have solved any remaining technical difficulties with the technology. You have refined use-cases and ready to hand them in for grading as a result of iteration 1.
  • Students are expected to provide Redmine issues, time logs and progress report each Friday to their tutor
  • 1 Pressman-style core use case, based on the requirements, with detailed "happy path"scenario and comprehensive listing of all exceptional cases.
  • A working vertical prototype partially implementing some of the main scenario of the use case. The missing parts, if required by the implemented part, can be stubbed, mocked up, manually provided or hard-coded. The prototype is to be presented to the customer and the tutor, showing your team is capable of using the technology stack for further development.
Iteration 2, week 1 11 Dec 2015 You started to implement the must-have requirements in your prototype, probably by progressively replacing mockups with actual implementation. You are getting continuous feedback from the client and use it to update your existing requirements and use cases documents. Students are expected to provide Redmine issues, time logs and progress report each Friday to their tutor
Iteration 2, week 2 18 Dec 2015 You have first drafts for the GUI paper prototypes for all use cases, as well as first drafts of class and sequence UML diagrams for all use cases. You continue to furiously implement the must-have requirements in your prototype. You have already implemented at least 50% of them. Again, you have updated your requirements and use cases accordingly, based on customer's feedback. Students are expected to provide Redmine issues, time logs and progress report each Friday to their tutor
Iteration 2, week 3 29 Dec 2015 You are mostly done with the paper prototypes and UML diagrams. Similarly, you have implemented over 75% of the must-haves. You keep the documentation synchronized. Students are expected to provide Redmine issues, time logs and progress report each Friday to their tutor
Iteration 2, week 4 15 Jan 2016 You finished, updated according to client's feedback and polished the entire documentation. You implemented most of the must-haves.
  • Students are expected to provide Redmine issues, time logs and progress report each Friday to their tutor.
  • Updated requirements and use case from 1st iteration.
  • GUI paper prototypes for all the use cases, also encompassing the exceptional scenarios.
  • UML class and sequence diagrams for all the use cases.
  • A working prototype implementing most of the must-have requirements.
Iteration 3, week 1 22 Jan 2016 No explicit progress defined. You are working on incorporating the feedback provided to your team by your tutor. Also, you are working on the current week and iteration deliverables. Students are expected to provide Redmine issues, time logs and progress report each Friday to their tutor
Iteration 3, week 2 29 Jan 2016 No explicit progress defined. You are working on incorporating the feedback provided to your team by your tutor. Also, you are working on the current week and iteration deliverables. Students are expected to provide Redmine issues, time logs and progress report each Friday to their tutor
Iteration 3, week 3 5 Feb 2016 No explicit progress defined. You are working on incorporating the feedback provided to your team by your tutor. Also, you are working on the current week and iteration deliverables. Students are expected to provide Redmine issues, time logs and progress report each Friday to their tutor
Iteration 3, week 4 12 Feb 2016 You are ready to hand in the project to the customer and to the tutor for grading. You have uploaded all the code to your team's Redmine repository (if you didn't signed an NDA) and uploaded to (or linked from) Redmine all the documentation.
  • Students are expected to provide Redmine issues, time logs and progress report each Friday to their tutor
  • Updated, polished and working software prototype presented to the customer and the tutor. The implementation has to be present on your team's Redmine Git repository (unless you signed an NDA agreement with your client), so the course staff has access to it while grading the project.
  • Updated requirements, use cases, GUI paper prototypes and UML class and sequence diagrams. The update has to incorporate the professor's remarks and the final documentation has to accurately reflect the implementation handled in for grading and presented to the customer. All the documentation has to be linked from your team's Redmine wiki so the course staff has access to it while grading the project.
  • Implementation of all the must-haves that have remained unimplemented in 2nd iteration.
  • Implementation of any remaining may-haves, as time permits.

Motivation

Tools

You might be asking yourself why we stress so much you should use Redmine and Git. Turns out, tools of this kind, i.e. project management software and version control systems, are the absolutely minimal foundation any modern software engineer has to know. They aid in mitigating very important challenges of knowledge sharing, work coordination and code archiving, that you run into as soon as you code with somebody else or work on project larger than a couple of thousands line of code.

As for justification of our concrete technological choices. Redmine is a quite heavily used free project management software and by learning it you will have a very easy time with similar popular tools of this type like Trac [w] or JIRA [w] or the built-in project management functionalities of software project hosting sites like GitHub [w], BitBucket [w], CodePlex [w] or SourceForge [w].

Speaking of which, we decided to use Git for this course as GitHub is by far the most important repository of open-source projects today and it is based on Git. Git is a distributed version control system (DVCS) created by Linus Torvalds (if you don't know who he is - shame on you! And this comes from a person who has a Windows on a MacBook with Android sticker on it). One can consider DVCS to be a second generation VCS, as compared with plain VCS, e.g. SVN [w]. DVCS are inherently more complex than VCS (compare this with that. full post), but they are designed for efficient collaboration in much more challenging setup. Git is especially notorious for being very non-intuitive for newcomers, thus I highly recommend to you to bite the bullet and carefully read through the first three sections of the excellent git book. You will save countless hours of hair pulling thanks to this, trust me on that.

Software engineering

The core activity of being a programmer is writing software. In the olden days of programming in assembly code, coding required huge amounts of time to make anything useful out of it. Thus, programmers were called programmers and they could just sit and code all day long. With time however, as the programming languages, framework, libraries and entire toolchains started to provide more powerful abstractions, programmers were able to very rapidly create useful software.

And this were very bad news for them. Why?

When you are done programming, now you have to do something interesting with the program, which means interacting with humans. The less time you need to code, the more time you need to talk with people: understand what they need, collaborate with them and all the other usual hassle this course is trying to give you hands-on experience with. Requirements documents, use cases, diagrams, mockups, wireframes etc. are development artifacts aimed at easing the process of communicating with humans about the software. That's why you are now called software developers (or engineers) instead of "just" programmers: in the past you just coded and somebody else did the talking; now you have to do both.

Having said that, if you have never used tools like Redmine or Git or, even worse, you can't program, then please do yourself a favor and do your best to get a handle of these tools during this course and actually implement a meaningful part of the prototype. I hope it is clear from the paragraphs above that you will have a very hard time as a software engineer without strong (or at least - any at all) coding skills. If you can't program, this course is a terrifying occasion to learn the technology and team up with the more capable team mates to practice pair programming, the hallmark activity of extreme programming methodology.