If it looks like a duck, walks like a duck and quacks like a duck, it probably is a duck.
Too few people on a project can't solve the problems - too many create more problems than they solve.
A problem shared is a buck passed.
A user will tell you anything you ask about, but nothing more.
A user is somebody who tells you what they want the day you give them what they asked for.
Of several possible interpretations of a communication, the least convenient is the correct one.
What you don't know hurts you.
The conditions attached to a promise are forgotten, only the promise is remembered.
There's never enough time to do it right first time but there's always enough time to go back and do it again.
I know that you believe that you understand what you think I said but I am not sure you realise that what you heard is not what I meant.
Resources and readings will be added here as the become available.Readings:
The main assessment in this unit will be the software project. You are expected to meet regularly with your team mates, have weekly meetings with the unit coordinator, as well as meetings with your software engineering mentor, and client. Everybody should keep a record of every meeting. Who was present, what was discussed, what tasks were assigned with what deadlines, and when the next meeting will be held. Students will be expected to show these notes to the unit coordinator upon request. They will also be required for the reflective writing exercise in semester 2, as well as the peer review. Students will lose marks if they are not able to substantiate their assessments and opinions with documented evidence.
As well as regular meetings, students will have to present a technology seminar in semester 1 (between weeks 7 and 12). All students are expected to attend the seminars. In second semester, students will also be expected to attend guest lectures from industry.
The available projects for 2016 are described here.
In the first semester of the project, each member of the group must investigate some technology that is relevant to the project. They should then present their findings to the rest of the group in a short seminar (10-15 minutes). The seminar may involve some slides, or a software demonstration, but it isn't essential. The idea of the seminar is that it should help the group select a technology (or methodology, or approach) by identifying an issue to be adressed, different solutions available, the assessment criteria, and the pros and cons of each solution. There should be questions and discussion at the conclusion of the seminar.
|September 15, 10-11am||Underground data transfer|
|September 22, 9.30-10.20am||EZone Wayfinding|
|September 22, 10.20-10.50am||UniRide|
At the end of the first semester of the project, the entire group should submit a system requirements document. This document should outline the goals of the project, use cases (or user stories) describing the expected operation system, design constraints, and system mockups. The project client will sign off on these requirements. The team should also submit prototype code demonstrating key functionality to be delivered. There is no prescribed size or form for the document: it could be a 20 page report; or it could be a website, with prototype animations. This example provides a rough idea of the expected content (but not necessarily the expected format).
The reflective writing component will require members of the group to write an essay reflecting on the process of completing the project. The essay should be approximately 1500 words. The essay topic will vary from semester to semester and be released and discussed in the week 7 seminar.
In semester 2 2017, the essay topic is as follows:
Software and applications can have significant implications for the end users safety, often in ways that the application developers did not envisage. While there are methods to identify safety critical functions, and test and verify safety in expected use cases, it is much harder to mitigate risk in unexpected or unintended use cases. To what extent should a software developer be responsible for how their product is used? What are the legal implications for the developer when their software is misused in malicious ways? What steps can a developer take to ensure the safety of end-users or to protect themselves from litigation (or should these be the same thing). Read the ACS Code of ethics and discuss the topic in the context of the code and your own project.
Submit your essay on this topic via cssubmit by 5pm Friday, November 3, via cssubmit.
The system validation document should describe the steps taken to ensure the quality and reliability of the product. There should be a focus on testing, but other strategies can be described (for example, code inspections). It should present the overall purpose and scope of the quality assurance process, and each test should be described in the context of this purpose. Tests, frameworks and execution environments should be explicitly documented. The validation document should also support ongoing system maintenance, via regression testing and defect management strategies. A lightwieght template that could be used is available in the following document.
The system delivery is the handing over of the working product and source code to the client. The specific deliverables are
The maintenance manual should describe the procedure for installing and building the system. It should support the continued development of the system, and describe the main architecture and rational for design choices made.
Each student must complete a professional appraisal of every other student in the group. The apopraisal should cover conduct in both CITS5551 and CITS5552. For each peer you should prepare a short (1 page) assessment addressing the following criteria: