[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive]
[an error occurred while processing this directive]
Monash University

FIT3140 Advanced programming - Summer semester, 2013

This unit develops the students' ability to design, implement and maintain moderately complex, realistically-sized programs using an Agile software development methodology. It builds upon the basic programming techniques introduced in introductory programming unit and offers the first introduction to the implementation of more complex real-world programs. Examples of such systems include compilers and interpreters, simulations, visualisation tools, drawing packages, database systems, graphical games. Such systems may be implemented in the context of non-traditional computing environments such as smartphone "apps". The unit may offer students the opportunity to get acquainted with a second programming language within the procedural-object oriented paradigm, such as C++, Python or one of their cousins, depending on the scope of the project chosen in a particular semester.

The unit bridges between core programming knowledge and the large-scale software engineering context. It will emphasise the implementation and use of intermediate to advanced data structures (such as search trees, hash structures, graphs and graph algorithms etc.) and the embedding into an actual computing system (i.e. interacting with the O/S, networking components etc).

Contact Hours

2 hrs lectures/week, 3 hr laboratory/week

Workload requirements

During summer students will be expected to spend:

  • 2 hours of lectures per day
  • 2 hours of labs per day
  • A minimum of 2 hours of personal study per one hour contact time. 

Substantial parts of the project work must be completed in pairs.  Students may need to schedule time to meet with their project partners outside scheduled classes.

Unit Relationships



Chief Examiner

Campus Lecturer


Robyn McNamara

Consultation hours: TBA

Academic Overview

Learning Outcomes

Upon successful completion of the unit, students will have an understanding of:
  • agile software development practices including iteration, test-driven development, spiking, and continuous customer involvement;
  • how to design moderately complex programs where that design will typically incorporate a number of modules and a number of levels of refinement;
  • the role of software architecture in program design and a knowledge of a number of commonly-applied software architectures;
  • how to make use of design patterns, re-usable components and software libraries in designing modular software;
  • how to make design decisions that take into account desirable quality attributes such as flexibility, maintainability and re-usability;
  • how to implement programs in a systematic manner using an integrated testing procedure in such a way that modules are highly likely to function as specified;
  • how to isolate faults within a program in a systematic manner;
  • how to use software tools to aid in the program design and implementation process. These tools might include program design tools, integrated program development environments, configuration management systems, re-factoring tools, automatic testing environments and debuggers;
  • how to adequately document a software project.
They will have developed attitudes that enable them to:
  • evolve a software system in response to feedback over time;
  • recognise the importance of process in achieving quality in a repeatable manner;
  • appreciate the distinction between analysis of program requirements and design that seeks to meet specifications;
  • develop software designs that place appropriate importance to the user experience;
  • adopt an approach to making design decisions that involves considering a range of options for design decisions and evaluating potential design decisions with reference to a system of values;
  • evaluate product and process development with the aim of continuously improving their software development methodology;
  • understand the importance of being able to communicate all aspects of the program development process, and identify the most appropriate medium for that communication.
They will have developed the skills to:
  • design moderately complex, real-world programs where that design involves multiple levels of refinement and the specification of a non-trivial number of modules;
  • learn a new programming language or environment efficiently when that programming language or environment is similar to a programming language the student already knows;
  • develop software in a modern software environment that may include software development tools such as those found in an integrated, programming environment, configuration management systems and automated testing systems;
  • design and implement programs that can interface with complex software systems such as graphical-user interfaces, database systems and mathematical libraries;
  • design and implement programs that may need to communicate via a computer network with software systems on other computer devices;
  • design and implement systems on alternative computing platforms including smartphones and embedded systems;
  • identify performance-critical aspects of a software system and learn to apply their analysis skills in larger systems.
They will have demonstrated the communication skills to:
  • create design documents that can be used to present a view of the software to other stakeholders;
  • identify items that are insufficiently clear from written documentation and proactively seek clarification from stakeholders;
  • create documents or on-line help that enable people to understand how to use the program;
  • create documents that allow a programmer to understand the program in sufficient detail to allow the software to be maintained;
  • produce literate programs, i.e. program source statements that are well commented.

Unit Schedule

Week Activities Assessment
0   No formal assessment or activities are undertaken in week 0
1 Unit overview, the problem domain, introduction to Agile, requirements gathering Assignment 1 due Friday 29 November 2013
2 Design and modeling, project lifecycles, performance analysis Assignment 2 due Friday 6 December 2013
3 Software engineering tools, user interfaces, releasing your software, unit summary Assignment 3 due Friday 13 December 2013
4   Assignment 4 due Friday 31 January 2014
  SWOT VAC No formal assessment is undertaken in SWOT VAC
  Examination period LINK to Assessment Policy: http://policy.monash.edu.au/policy-bank/

*Unit Schedule details will be maintained and communicated to you via your learning system.

Assessment Summary

Examination (3 hours): 50%; In-semester assessment: 50%

Assessment Task Value Due Date
Assignment 1: Planning and requirements (pairs) 10% Friday 29 November 2013
Assignment 2: Iteration 1 (pairs) 15% Friday 6 December 2013
Assignment 3: Iteration 2 (pairs) 15% Friday 13 December 2013
Assignment 4: Final report (individual) 10% Friday 31 January 2014
Examination 1 50% To be advised

Teaching Approach

  • Lecture and tutorials or problem classes
    This teaching and learning approach provides facilitated learning, practical exploration and peer learning.
  • Laboratory-based classes
    This learning and teaching approach provides the opportunity for practical experimentation with approaches taught in lectures.

Assessment Requirements

Assessment Policy

Faculty Policy - Unit Assessment Hurdles (http://intranet.monash.edu.au/infotech/resources/staff/edgov/policies/assessment-examinations/assessment-hurdles.html)

Academic Integrity - Please see the Demystifying Citing and Referencing tutorial at http://lib.monash.edu/tutorials/citing/

Assessment Tasks


Students are expected to attend lectures and lab classes.

While lab exercises will not be marked, many of the labs will be used for project work in pairs, including assessment.  As such, students will need to attend these.

Students will identify a project partner to work with by the end of the first laboratory, who is enrolled in the same lab class.  Students will work with their partner for subsequent in-semester assessment unless there are exceptional circumstances.

  • Assessment task 1
    Assignment 1: Planning and requirements (pairs)
    Project pairs will produce the following deliverables:
    • A "vision statement", i.e. a brief, high-level description of the key requirements of the project which will form the basis for subsequent assignment tasks.
    • A risk analysis document that outlines potential problems that the project team may face, and details the actions that team members will take to avoid or ameliorate them.
    • Proof-of-concept code that demonstrates the ability to work with the tools, languages, and libraries that will be used to implement the project.
    Criteria for assessment:
    • Effective capture of key functional requirements.
    • Identification and description of key attributes of system context.
    • Effective capture of likely risks.
    • Designing feasible risk mitigation strategies.
    • Readability and presentation quality of documents.
    • Functionality and readability of proof-of-concept code.

    This assignment will be completed in pairs.  Pairs are expected to share the workload and will usually receive the same mark.  Individual contributions will be documented, and if workloads are not appropriately shared over the semester marks will be adjusted accordingly.

    Due date:
    Friday 29 November 2013
  • Assessment task 2
    Assignment 2: Iteration 1 (pairs)
    Project pairs will complete their first iteration of the active development phase of the project.

    They will deliver working and tested software implementing several "user stories".

    The deliverables will also include release notes and user documentation as required.
    Criteria for assessment:
    • Completeness of implementation.
    • Quality of implementation.
    • Appropriateness of testing.
    • Correct use of provided tools.
    • Appropriate supply of documentation.

    The assignment will be assessed as a pair.  Students will document their individual contributions to the assignment.  Generally, students will receive the same mark, unless there are significant discrepancies over the semester in contributions to the pair project work.

    Due date:
    Friday 6 December 2013
  • Assessment task 3
    Assignment 3: Iteration 2 (pairs)
    Students will complete a second iteration of development for the system, implementing additional functionality.  They will use "pair programming" for at least part of this development, and reflect on whether it is useful for them.

    Another release will be delivered at the end of the iteration, which will include appropriate testing and documentation for the implemented functionality.

    Students will demonstrate this functionality in labs.
    Criteria for assessment:
    • Completeness of implementation.
    • Quality of implementation.
    • Appropriateness of testing.
    • Correct use of provided tools.
    • Appropriate supply of documentation.
    • Conduct of pair programming.
    • Quality of written reflection on pair programming.

    The assignment will be assessed as a pair.  Students will document their individual contributions to the assignment.  Generally, students will receive the same mark, unless there are significant discrepancies over the semester in contributions to the pair project work.

    Due date:
    Friday 13 December 2013
  • Assessment task 4
    Assignment 4: Final report (individual)
    Students will reflect on their project work, including:
    • Reflecting on the overall quality of the deliverables to date.
    • Identifying the strengths and weaknesses of the development processes used in the context of the current project.
    • Determine a realistic timeframe for completion of the full vision as described earlier in semester.
    • Describe the process they would follow to achieve completion.
    Criteria for assessment:
    • Quality and depth of reflection.
    • Plausibility of analysis of future prospects.
    • Quality of proposed process.
    • Clarity of written report.
    Due date:
    Friday 31 January 2014


  • Examination 1
    3 hours
    Type (open/closed book):
    Closed book
    Electronic devices allowed in the exam:

Learning resources

Reading list

  • The Scrum Primer.  Free download: http://www.scrumprimer.com/
  •  Scrum and XP from the Trenches by Henrik Kniberg.  Free download: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Monash Library Unit Reading List

Feedback to you

Examination/other end-of-semester assessment feedback may take the form of feedback classes, provision of sample answers or other group feedback. Please check with your lecturer on the feedback provided and take advantage of this prior to requesting individual consultations with staff. If your unit has an examination, you may request to view your examination script booklet, see http://intranet.monash.edu.au/infotech/resources/students/procedures/request-to-view-exam-scripts.html

Types of feedback you can expect to receive in this unit are:

  • Informal feedback on progress in labs/tutes
  • Graded assignments with comments

Extensions and penalties

Returning assignments

Resubmission of assignments

No resubmission of assignments will be permitted.

Referencing requirements

Code based on algorithms or information from third-party sources (such as books or websites) must acknowledge these sources in comments, in sufficient detail for markers to find and check these sources.  Some assignments will explicitly prohibit the use of this - if so, you must not use them.

Where third party material is used in written assignments, they should be cited.  Students may use any of the referencing methods described in the Monash University Library's tutorial on referencing to do so:


Assignment submission

It is a University requirement (http://www.policy.monash.edu/policy-bank/academic/education/conduct/student-academic-integrity-managing-plagiarism-collusion-procedures.html) for students to submit an assignment coversheet for each assessment item. Faculty Assignment coversheets can be found at http://www.infotech.monash.edu.au/resources/student/forms/. Please check with your Lecturer on the submission method for your assignment coversheet (e.g. attach a file to the online assignment submission, hand-in a hard copy, or use an online quiz). Please note that it is your responsibility to retain copies of your assessments.

Online submission

If Electronic Submission has been approved for your unit, please submit your work via the learning system for this unit, which you can access via links in the my.monash portal.

Recommended Resources

Students will need a Java development environment (exact version of JDK to be specified in class).  Eclipse will be provided in laboratory work, but students may choose to use any development environment that they prefer.

Students may choose to use their own laptops if they wish; however, they will be responsible for all technical support and ensuring that their code runs on the specified platform.

Recommended text(s)

Kent Beck, Cynthia Andres, Erich Gamma. (). Extreme Programming explained. (2nd Edition) Addison-Wesley Professional (ISBN: 978-0321278654).

Examination material or equipment

Students should refer to the unit website for details about the exam.

Other Information


Monash has educational policies, procedures and guidelines, which are designed to ensure that staff and students are aware of the University’s academic standards, and to provide advice on how they might uphold them. You can find Monash’s Education Policies at: www.policy.monash.edu.au/policy-bank/academic/education/index.html

Key educational policies include:

Graduate Attributes Policy

Student services

Monash University Library

Disability Liaison Unit

Students who have a disability or medical condition are welcome to contact the Disability Liaison Unit to discuss academic support services. Disability Liaison Officers (DLOs) visit all Victorian campuses on a regular basis.

Your feedback to Us

Previous Student Evaluations of this Unit

Based on student feedback:

The project has been changed to provide more of a computer science emphasis.

The environment has been switched back to using a virtual machine to avoid the many hassles that were happening with the Windows native environment.

If you wish to view how previous students rated this unit, please go to

[an error occurred while processing this directive]