SOFT30161 Advanced Software Engineering

Portfolio guidance
This document describes the purpose and requirements of the second
coursework element (the Portfolio).
The focus of this part of the module is on Software Engineering practices
as used by development teams and introduces a number of techniques
and technologies. The Portfolio documents your experience and expertise
in these areas and is a record of activity, rather than a product in its own
right; it should reflect your on-going engagement with the tools and
exercises throughout this part of the module.
The Portfolio should cover both the work on Continuous Integration (term
2) and that on Test Driven Development (TDD) in term 3.

Documenting CI activities

This is essentially a diary of activity with an element of

reflection/comment. Aim to establish a timeline for your progress through
the activities (your logs may be useful and should provide the evidence for
these). The activities may well include
Makefiles
Boost UTF
Visual Studio solution/project configuration
The Rational class
Jenkins CI server & automated builds
Collecting / post-processing the output
For each identify
The major activity on which you were engaged and what it was you
were endeavouring to achieve
A description of the progress you made
Any (some) artifacts you produced (new/modified VS projects, hg
check-ins, Jenkins jobs, output from Jenkins jobs) & evidence them
to some extent (logs, commit messages, repo summaries, screen
shots)
Richard Hibberd
Office Hour Mon 5-6 Thu 1:30-2:30

richard.hibberd@ntu.ac.uk
ERD200 ext 88356

v2013 CI & TDD

SOFT30161 Advanced Software Engineering

Any difficulties or issues that were encountered and hopefully

resolved/ addressed; dont avoid or gloss over any areas that
proved problematic, as this is a record of a learning process which is
unlikely to proceed smoothly at all stages (furthermore, the
responsibility for these obstacles may well lie outside your control).
Any avenues that you pursued in more detail and developed some
additional expertise these might be integrated or evidenced by
some documentation you produced (for posterity or future
generations)
The ultimate objective is to demonstrate your unit tests both Red & Green
(initially failing and then passing) on your individual repo or better still on
the main repo; the Portfolio should document the journey towards that
goal!
Documenting TDD activities

Given the lack of time (lateness of Easter & the early submission deadline),
the scope for the TDD component is quite limited; this will be reflected in
the proportions of the marks (75:25 of the Portfolio marks) with a similar
3:1 bias expected in the Portfolio components.
The MRSA project is largely unimplemented as TDD is an approach to
design, rather than to testing.
The documentation you submit might well address
The particular functionality that you are developing
A textual description of the test(s) you design/develop to establish
correct behaviour
Evidence of the test(s) failing pre-implementation (red)
Evidence of the test(s) passing post-implementation (green)
Your impression of using TDD
The evidence could be one of (increasing complexity & value)
Local unit tests run in the VS IDE
Unit tests run on Jenkins server from personal repo on warren
Unit tests run on Jenkins server from TDD repo on warren

Richard Hibberd
Office Hour Mon 5-6 Thu 1:30-2:30

richard.hibberd@ntu.ac.uk
ERD200 ext 88356

v2013 CI & TDD