Posted on May 2, 2013 by orbital
Students should maintain
- A project journal where you record the work periods and work done weekly. It is okay to do more on some weeks and less on others, but to get course credit for CS3108B, the total number of work hours must be at least 130.
- A project wiki where the project documentation is kept.
- Both of these are available on IVLE project.
We will follow a simplified agile methodology (http://en.wikipedia.org/wiki/Agile_software_development) for Orbital. The main part of the methodology we will use is as follows:
- We use iterative development where each iteration (sprint) is done over around 4 weeks (2 iterations over the entire Orbital project).
- For each sprint, a small subset of features is specified using user stories (http://en.wikipedia.org/wiki/User_story) and accepted (http://www.extremeprogramming.org/rules/functionaltests.html) by the peer evaluator at the end of the iteration.
- For Orbital, we will not use any formal specification method. User stories should be done in natural language, but your peer evaluators must be able to understand the stories clearly. We will also not use any automated testing. The peer evaluators do acceptance testing manually until they are satisfied that it meets the requirements based on their understanding of the user stories. You will learn more about specifying requirements and testing (including unit and regression tests) in your software engineering courses.
Each group will act as peer evaluators for three other groups. If you are traveling or have other activities that do not allow you to meet the peer evaluation schedule, you need to discuss alternative dates with your peer evaluation groups. If your evaluation dates are after the scheduled dates, you need to get permission of the instructors for the alternative dates.
Passing requirements are described at https://orbital.comp.nus.edu.sg/?p=45, but will be moderated by the instructors.
Week 1 (13 – 19 May):
Monday & Tuesday: Liftoff Workshop
- Work on mockup and requirements.
- Update journal.
Week 2 (20 May – 26 May):
- Mission control (optional).
- Work on mockup and requirements.
- Update journal.
Week 3 (27 May – 02 Jun):
Submission Week
- Mission control (optional).
- Update journal.
Monday: Submit
- Mockup. This can be a powerpoint mockup with simple interaction, or more sophisticated mockup on other platforms if you wish.
- A 3 minute video describing the aims of the project with the help of the mockup.
- At least 3 user stories describing at least 3 features to be implemented in the sprint over the next 4 weeks.
Tuesday to Friday:
- If necessary, clarify the aim of your project and the features to be implemented with your peer evaluators.
- Act as a peer evaluator. If necessary, clarify the projects you are evaluating with the groups you are evaluating.
Week 4 (03 Jun – 09 Jun):
Monday: Submit the updated version of the user stories after feedback from the peer evaluators. This forms the requirements that you are implementing in the sprint over the next 4 weeks.
- Mission control (optional).
- Implement features.
- Update journal.
Week 5 (10 Jun – 16 Jun):
- Mission control (optional).
- Implement features.
- Update journal.
Week 6 (17 Jun – 23 Jun):
- Mission control (optional).
- Implement features.
- Update journal.
Week 7 (24 Jun – 30 Jun):
- Mission control (optional).
- Implement features.
- Update journal.
Week 8 (01 Jul – 07 Jul):
Submission Week
- Mission control (optional).
- Update journal.
Monday: Submit
- Prototype (url) with the features specified in Week 4 completed.
- A 3 minute video describing the work done with the help of the prototype.
- User stories for the remaining features that you wish to implement.
Tuesday to Friday:
- Act as beta tester to see if the features of the projects you are evaluating can be accepted. Give feedback on any bugs found, or if the requirement is not met. This can be done through the evaluation form, or if necessary through face-to-face meeting or through videoconferencing.
- If necessary, clarify the features to be implemented in the next sprint with your peer evaluators.
- Act as a peer evaluator and give feedback on the features that are implementing in the next sprint by the groups you are evaluating.
Week 9 (08 Jul – 14 Jul):
Monday: Submit the updated version of the user stories after feedback from the peer evaluators. This forms the requirements that you are implementing in the sprint over the next weeks.
- Mission control (optional).
- Implement features.
- Update journal.
Week 10 (15 Jul – 21 Jul):
- Mission control (optional).
- Implement features.
- Update journal.
Week 11 (22 Jul – 28 Jul):
- Mission control (optional).
- Implement features.
- Update journal.
Week 12 (29 Jul – 04 Aug):
Submission Week
- Mission control (optional).
- Update journal.
Monday: Submit
- Prototype (url) with all features specified completed.
- A 5 minute video describing the entire project with the help of the prototype.
Tuesday to Friday:
- Act as beta tester to see if the feature of the projects you are evaluating can be accepted. Give feedback on any bugs found, or if the requirement is not met.
- If necessary, discuss your project with your peer evaluators.
Friday:
- Submit final feedback on the project you are evaluating.
- Submit your reflection on your project after receiving the final feedback from your peer evaluators.
Week 13 (Sem I Week 0: 05 Aug – 11 Aug):
<No activities; Work for Orbital should be complete>
Week 14 (Sem I Week 1: 12 Aug – 18 Aug):
<No activities; Work for Orbital should be complete>
Week 15 (Sem I Week 2: 19 Aug – 25 Aug):
Splashdown (tentatively Wed 21 August, evening)
The schedule for the two-day Liftoff workshop is given below. This schedule is still tentative and subject to change. The workshop is compulsory for those doing the program unless you have prior permission to be excused. We will try to put as much of the material online as possible for your reference.