Software Engineering Projects


The Bachelor of Software Engineering (BSEng) at the Australian National University (ANU) is a four year degree program that is accredited by the Institute of Engineers Australia (IEAust). As such there are IEAust requirements for students to undertake project work as part of the BSEng degree program. The Department of Computer Science (DCS) at ANU has chosen to include project work at both the 3rd and the 4th year levels of the BSEng program. The 3rd year project is a very controlled affair with several teams (of usually 7-8 students) all issued with the same set of requirements which are provided by DCS academic staff. DCS academics also construct the individual teams and (typically) allocate each team member at least one software engineering role to fulfill.

The 4th year practice-oriented projects are run quite differently and in fact operate more like an internship. Organisations (almost always) outside the DCS and/or the ANU provide (differing) sets of requirements for teams of 2 - 4 students. These teams are self-forming - usually based on mutual interests in a project - and team members are not allocated roles by DCS academics. In fact the approach is to encourage students to think of themselves as having taken on a new project in industry for which they are wholly responsible. They are also strongly encouraged to revise all that they have learned in their previous years of study as software engineering trainees and to apply their learning in a professional manner. To a very large extent, the students are "thrown in the deep end" in terms of undertaking a project.

As of 2002, research-oriented projects are being run. These projects can only be done by indivduals who have performed to at least a distinction average during their first 3 years of software engineering studies. The research orientation means that these projects focus far less on broad practices and far more on fundamental technology or techniques.


Practice-oriented objectives include:

  1. undertaking activities on all key aspects of software engineering development,
  2. reinforcing the fundamental principles of software engineering,
  3. realising of the need to make decisions based on fact and identifiable risks,
  4. exposure to real customers and their needs,
  5. strengthening time and resource management,
  6. gathering further understanding of the importance of project planning and control,
  7. realising the importance of quality control on software projects,
  8. exposure to new skills - including techniques, languages, (multidisciplinary) environments, project communications and intra-team interactions, and
  9. adopting more than rudimentary work discipline,
  10. taking the opportunity to try out different techniques or approaches - experimenting.

Other important objectives:

An important objective is to help students make decisions themselves and to learn about dealing with differing stakeholder requirements on a project. Generally teams have to answer to two customers each having a different perspective and different requirements. One customer is the organisation requiring a product to be delivered, and the other is the COMP4800 Convenor requiring proof of a well-managed project. It is sometimes very easy for students to slip into a mode of software development that closely resembles that of the customer requiring the product rather than to behave as independent software engineering professionals. Whilst some organisations might possess quite mature software development practices (base on the Capability Maturity Model from the Software Engineering Institute) it is more likely that software development practices are quite immature. Thus, when students adopt a company's software development practices, they may be taking a retrograde step in their own professional development. In the context of the COMP45X0 project, such a retrograde step is exhibited in the less than good quality deliverables made to the COMP45X0 Convenor, even though, at the same time, it is also possible that the product that has been developed works fine and of itself is an acceptable deliverable - at least by the organisation needing the product. Unfortunately, what is usually missing from the deliverables to both customers, is any verification and/or validation that the product

Additionally, planning is usually mediocre, tracking effort is often non-existant, shcedule and change control is ad hoc. If poor project management prevails, then the project artefacts that are delivered to the COMP45X0 Convenor are usually barely satisfactory, creating at least one unhappy customer.


From the objectives (above) it is clear that the focus on a COMP45X0 project is broader than just the application of technology surrounding a product. The intention is to have students understand that there needs to be a balance between people-oriented, process-oriented and technically-oriented aspects of a project. Focussing on one of these aspects and ignoring the others will usually lead to a project failure. The following guidelines are provided with the specific intention to remind all students undertaking COMP45X0 to try and reach a reasonable balance between the people, process and technically oriented aspects.

Students need to adopt/choose an approach to their projects that ensures that both customers receive deliverables that are acceptable and of reasonable quality.

Acceptable means that the deliverables adequately fulfill requirements and are complete according to the latest agreed plan.

Acceptable also means that human readable documents are, succinct, clear in their purpose and content, easily understood, and appropriately referenced.

Reasonable quality means that there are fewer than one defects per page of supporting documentation (excluding trivial spelling errors, or formatting), and that there are fewer than one defects per thousand lines of non-comment, non-blank source code.

Initially, a simple contract between an Organisation Customer (OC) and a student team must be drawn up once the team has better established/understood the OC's requirements, and some preliminary scoping has been completed. The contract should include summary/preliminary aspects of the initial plan - especially the scope, main deliverables, effort estimates and milestones. See some of the previous OCs.

All projects must be planned (including scoping, estimating, schedulling, adopted software development life cycle, quality and change control) and as required, replanned.

Deliverables to the COMP45X0 Convenor (CC) must include,

The deliverables above will need to be made in accordance with the adopted software development life cycle (SDLC). Electronic form of the deliverables should be made in Adobe Acrobat PDF format unless otherwise agreed.

Deliverables made to the Organisation Customer should include all but the last of those to be submitted to the COMP45X0 Convenor. However, an agreed set of deliverables will need to be included in the contract/plan between a student team and the OC.

An SDLC will need to be chosen carefully, dependent on the type of project. Well established, relatively stable requirements will suggest a "waterfall" type of SDLC. However, if requirements are largely vague or unknown, then some sort of incremental SDLC should be considered. Agile or eXtreme Programming (XP) approaches are also alternatives when requirements are vague and/or the nature of the project is experimental. Choosing the SDLC is one of the important decisions that student teams need to make and also be prepared to reconsider if the initial choice of SDLC seems to hamper progress or create undue complications. It is plausible for a project to support different lifecycles at different stages of development.

For the purpose of assessment it is important that student teams are able to present a history of their project in the form of maintained versions of all development artefacts. Further, students should be able to demonstrate how they tracked their individual efforts against their planned work requirements.

A post mortem of the project is to be constructed and presented to an audience of (possibly) customers, other student project teams, academics (including COMP4800 Convenor), and (possibly) friends and relatives. The presentation should be designed to be delivered in 30-40 minutes with an additional 15-20 minutes allowed for questions. The presentation should be a summary of a submitted post mortem document that covers aspects of the project like the following:

Take a look at the post mortem sample from the Bapsolve team of 2002.


Projects will be assessed on the basis of a team effort unless extenuating circumstances require an assessment of an individual.


The following is a list of organisations (customers) that have supported the COMP45X0 program and projects provided for student teams: