Here are your CA1 individual grades, for Week 1 - 4. OK, I know this is coming very late (this is already Week 10!) and I apologize for it. I completely underestimated the mount of code 50+ students can produce in four weeks, and
the amount of time I need to browse through and somewhat understand your code, as well as individual commits for every student.

Your individual grade is based on what I read from the master branch, up to end of Week 4. For some of you who commited very little to the master branch, I have contacted you and read your other branches. It is possible that, for some of you, you have made significant coding contributions that I missed because it is in another repo or in another branch. Please let me know if this is the case.

Note that this grade is given based on the work done in the first four weeks of the semesters. Some of you might have done more from Week 5 - 10. That work will be assessed accordingly for CA2.

Read more..

Here is the information about what needs to be submitted for your final reports. As mentioned, these will be extensions of your CS3283 final report, splitted into two, a project report and a developer’s guide.

In general, the project report will be written with the instructor and examiners as target reader. It should demonstrate that you have followed and learned good software engineering practices in CS3283/4. The developer’s guide will be written with a fellow developer who will maintain and further developer your project as target reader, and should provide information your project and code.

Project Report

• You need to submit a PDF file, name teamname-proj-report.pdf, into IVLE’s workbin, replacing teamname with the name of your team.
• If repeated content in the project report and dev guide is needed, you can cross reference specific sections in the developer’s guide.
• The report should contain at least the following:
  • Requirements: What are your project requirements? What has changed in the project requirements, and why?
  • Architecture and Design: What is the software architecture of your project? Why do you design it this way? Has the architecture changed over the project, and why? What are the design decisions that you have to make during the project? (Remember the 4+1 view and QOC)
  • Coding and Testing: How much of the original requirements are implemented? If there is anything unfinished, justify why.
  • Code Review: How is code review done within your team?
  • Project Planning: How are the requirements/tasks of the project prioritized? How do you estimate the time needed to complete a task in an iteration. Has the time estimation improved over time?
  • Robustness: How is testing done in your project? What is the code coverage?
  • Usability: How do you evaluate the usability of your project? What are your findings and how do you address it?
  • Performance: How do you evaluate the performance of your project? What are the bottlenecks found? how do you reduce the impact of the bottleneck? How much improvement did you achieve after optimizing the performance?
  • Security: How do you evaluate the security of your project? What security issues do you find? How do you address it?

Developer’s Guide

• You need to submit a PDF file, name teamname-dev-guide.pdf, into IVLE’s workbin, replacing teamname with the name of your team.
• The report documents the project’s motivation/description, software requirements, design, implementation, test cases, coding convention, instructions on how to install/compile/test/run, remaining issues, repository, CI site, etc.
• The target reader is a fellow developer who will maintain and continue the development of your project.
• Any other information that will be helpful to a developer can go into here.

Importance

• ““People will visit a Web site less often if it is slower than a close competitor by more than 250 ms.”” from NY TImes
• “the Apple iPhone 5 still has a dual core processor and 1 GB DDR2 RAM. But the magic is iPhone 5 is performing as good as any latest muscle Android phone” Silicon Station

Rules of Optimization

• Don Knuth says, “Premature optimization is the root of all evil.”
• Ken Beck says, “Make it run, make it right, then, make it fast.”

Latency Numbers

• What every programmer should know (http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html)

Examples of Performance Issues

• Unnecessary disk I/O
• Unnecessary memory copies
• Unnecessary SQL / database access
• Unnecessary network communication
• Unnecessary locking
• Unnecessary format conversion
• Too many indirections
• Unexpected interactions between system components
• Compiler options
• Bad data structures or algorithms
• Memory leaks / garbage collection

Common Tricks for Performance Improvement

• Pre-computation
• Caching
• Prefetching
• Pipelining / Parallelizing
• Make things feel faster

Here is a sample section from CS3281/2 Team Polaris, AY 14/15

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.

Happy new year, and welcome back to a new semester!

A few quick announcements:

• CS3284 will be allocated to you. You need not do anything.

• If you are on leave this semester (due to ATAP/NOC/SEP/etc), please let me know.

• Just like last semester, I would like your team to meet up for a 5-hour sprint every week. The sprint starts in Week 1 (next week!) so please work out a common time to meet and let me know before the semester starts so that I can book the rooms. I understand that you may have to reschedule once the tutorial schedule is finalized. So having a tentative schedule for the first two weeks before the tutorial starts is fine.

• We will have our first lecture next Friday, just to set the expectation for the coming semester.