Resources

Resources and readings will be added here as the become available.

Readings:

• The Agile Handbook
• The Mythical Man-Month, by Fred Brooks, (1975). The Mythical Man-Month. Addison-Wesley. ISBN 0-201-00650-2.
• What is Code?
• The ACS code of professional conduct
• GIT guide
• GIT tutorial
• Project Briefing Template

Assessment Details

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.

CITS5551 - Technology Seminars (30%, individual)

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.

Tech Seminars	CSSE:2.28
September 15, 10-11am	Underground data transfer
September 22, 9.30-10.20am	EZone Wayfinding
September 22, 10.20-10.50am	UniRide

CITS5551 - System Requirements Document and Prototype (40%, group)

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).

CITS5551 - Reflective Writing (30%, individual)

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.

CITS5552 - System Validation Document (20%, group)

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.

CITS5552 - System Delivery (40%, group)

The system delivery is the handing over of the working product and source code to the client. The specific deliverables are

1. Source code and executable/running instance made available to client.
2. System overview and promotion, presented as a website or brochure.
3. a user manual supporting the day to day use of the system.

The system should be presented to the class and the client in the week 11 seminar. Students will have an oppurtunity to refine the product after that date, but it is expected that the product will be fully functionality.

CITS5552 - Maintenance Manual (20%, group)

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.

CITS5552 - Peer Review (20%, individual)

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:

• Technical contributions to the project: how much code/design did the peer contribute, and was it of high quality?
• Professionalism: did the peer conduct themselves in a professional manner, attend meetings regularly, and treat all members of the group with respect?
• Communication: did the peer contribute at meetings, and make an effort to clearly outline progress and difficulties as the project progressed?

Each student should also submit a timesheet, showing what activities they completed, how much time they estimated they would spend on each activity, and how much time they actually spent on each activity.