This semester, the class will be pretty much the same as last semester. But as focus shifts to implementation, testing, and evaluation, we will make a few changes to our schedule:
-
We will have much fewer lectures (3-5 over the semester). The key one is the lecture on performance evaluation, which is scheduled mid February, before the break. I will continue to schedule any additional lecture on an ad hoc basis depending on how your project progress.
-
There is no midterm report submission.
-
There will be fewer meetings between me and you. I will talk to you at the beginning of your sprint and see a demo of your achievement at the end. If you have technical issues or are still working out your requirements/architecture, I will meet you every week. Note: I usually arrive 10-15mins after your sprint starts, please take the first 10-15 mins to setup and plan the meeting.
-
We have Jay back as our TA, and Rey Neo as a new TA. Rey will help me to pull/compile/install/run/test some of your code at the end of the sprint.
-
I will recommend your class for participation in STePS.
-
We will continue to have CA1 after Week 4, CA2 after Week 10, and CA3 after the reading week, but the breakdown is now 30%, 30%, 40%.
-
You will submit a final report that is built upon your final report last semester, but now split into two reports: a developer’s guide and a project report. Some of your reports are getting really thick!
As before: * We will have a final presentation to exmainers at the end of the semester during the reading week.
- Individual score will continue to be 70% of your final grade. The remaining 30% comes from your team score.
Your Sprint
-
At the end of the sprint, you should tag your code as a release with a version number. We will check out tag releases only. This means you can still experiment with things in other branches and continue to work after the releases.
-
All released code should be as clean, robust, well commented, as you can get (see notes here
-
We will also check your test cases (on CI servers for most teams). Your code should pass the tests!
-
You should provide proper README or installation instructions on your github so that the teaching team can easily compile/install/run/test your code.
Looking Back
There are some lessons I see from last semester that I would like to share with the class.
-
Design decision is important. We went through the exercise of making decisions on what platform/framework/library/algorithm to use during the design phase. When you consider the criteria (the C in QOC), considering your own ability (or your laptop’s ability) is important. A few teams learnt this the hard way.
-
Scoping your requirements is important. A few teams tried to take on too much during the requirement elicitation phase. Recall that one of the properties for a good requirement is attainable. While it is not necessary that, at the end of CS3284, you need to completely implement all the requirements, but adding more requirements than what you can achieve may add clutters and may cause distraction, if you do not plan well.
-
Project manager is important.
I have seen teams that do very well during the some period, due to motivating PM that plans well, and teams that stall due to PM that not ready to take up the role. So current and future PM, please take your role seriously and take this opportunity to learn about and put it to practice, some of the dos and donts of being a software project manager. I am not the best person to teach you how to be a leader or project manager, but there are many sources where you can learn.