Professional Computing CITS3200

Definition of Deliverable B

This Deliverable has four parts:

  1. A project plan. You are recommended to use a project planning tool such as MrProject on Linux or MS Project available with Microsoft Office.
  2. The definition of Use Cases, Object and Dynamic Models will be partly based on the Template for the Requirements Analysis Document, which you used for Deliverable A. You are to submit material in accordance with the instructions below.
  3. Acceptance Tests, based on the Test Manual . template by Bruegge & Dutoit.  Modify this template according to the instructions below.
  4. Client sign off that they accept the Requirements Analysis Document, usage cases, portfolio of acceptance tests and any prototype/mockup you are able to provide at this stage. A copy of the documents should be left with the client this forms the basis of the "contract" between the group and the client.

 Submission: Each group should submit a single (Zip) archive containing one copy of each of the documents detailed below (pdf preferred, MS-Word 2003 is acceptable) via cssubmit.  Ensure your Group ID is clear on the filenames. Please ALSO provide a hard copy to Admin in Room 1.31 for marking purposes.

1. Project Plan

About four pages of mainly tables and charts are all that is required. It should contain the following (Sommerville Chapter 4, Sections 4.2-4.3, and lecture notes):

  1. list of tasks, time estimates, dependencies, responsibilities.
  2. task (activity) bar chart/timeline (sometimes called a Gantt chart)
  3. team member (staff) allocation versus time chart. There is a timeline for each person showing the task(s) they are working on over time.
  4. A table of time estimates, in hours, broken down by person and deliverable. Estimates should include meeting times, in person hours, e.g. 1 hour for 7 people is 7 person hours. From these estimates it will be possible to see the total planned work and that workload is allocated fairly between people and deliverables. Expect patterns of planned work to vary between progammers, documenters and testers.

NOTES: Obtain your list of tasks from your TimeSheet using (a) the General Tasks and (b) the list of Requirements. The list of Requirements will have been taken from section 3.2 of the RAD. You will have a total of 10-30 tasks, approximately. Plan who will do each task. Develop a rough total effort estimate in hours of student time. You will have to think carefully about how you represent time in student hours and dates in timelines. All timelines should be expressed in calendar dates.  You are encouraged to use a project planning tool (Spreadsheets are fine in addition to MrProject and MS Project).

Check that your plan has some slack so that you can reorganise things when your schedule goes wrong.  Do not have everybody assigned to each task - try to create tasks and responsibilities realistically.

Try to make the plan and TimeSheet consistent, particularly when you submit Deliverable B.

Submit the plan in hard copy version to the CSSE Admin Office 1.31, and also via cssubmit.

2. Client sign-off and Prototypes

Invite the client to put her/his signature to a statement such as "I accept these documents as the basis for undertaking this project."

Clearly it is good to provide as much detail as possible about what you intend to do, so mockups/prototypes (where appropriate) are very useful as they enable the client to work with something concrete before (!)  they sign off on the RAD.

3. Use Cases, Object Model and Dynamic Model

Use your Deliverable A as a starting point. Modify the document as follows. (Note that some of what you will be asked to do here might more naturally fall under "design" but we will use the single document to give you an idea of developing ongoing versions. Be aware that this addition of more design-oriented material means the example models in the JAMES document may be rather sparse for your purposes.)

Get your Client to sign off the document again. Submit a hard copy to the CSSE Admin in 1.31 by the deadline and also via cssubmit as detailed above.

Up to Section 1.0

            Modify as appropriate.

Sections 3.2-3.3

Modify and extend if you have discovered significant changes since completing Deliverable A. (Do not spend a lot of time on this; it will not be marked explicitly but is there to help you clarify what you have to build and test.)

Section 3.5

This is to be greatly expanded for Deliverable B.  Ideally you will use UML (using a tool such as ArgoUML or Rational Rose). However you may create the diagrams using any tools (OpenOffice.org, MS Office) you wish. Intellectually this material is not new to you - apply what you have learnt in OOP and DAT if you did not do SED200. Limit submissions to about 20 pages, using your judgement on what to detail so that the document is useful to you for later implementation. Discuss possibilities with your Client perhaps.

Section 3.5.2

Give Top Level Use Cases. See the JAMES example. Use the SE Resources Pages for more information and examples. For some algorithmic projects this will be almost trivial.

Section 3.5.3

Give a set of Objects Models of your proposed system. Exactly what you submit will depend upon what you are building.  Some projects may need an extensive database, so include a model of that. If there is a web based project with much user dialogue, only very high level objects will probably be required. If the project is very algorithmic, low level and detailed models will be appropriate.

Section 3.5.4

Dynamic Models must be presented, but again they will vary with system.  For web applications sequence diagrams may be a natural way to go. If the sequencing is very complex (e.g.mobile phone), a state diagram might be more appropriate. If there is a strong algorithmic bias, depict the dynamic behaviour of your lower level objects. Only one type of notation is generally required, eg state machine models.

4. Acceptance Tests

Acceptance Tests shall be documented based on the Test Manual template by Bruegge & Dutoit. Cross refer your test documents to appropriate parts of RAD documents.

In the past teams have submitted maybe 100 pages of testing, each with little information of value. There will be a PAGE LIMIT of 30 pages. Use common sense to group similar series of tests together in tables.

Devise a series of tests in consultation with your Client. (Groups should do the documentation and detailed work!) Tests must be given a priority.  The highest, or essential, priority will contain the highest ranked functions that the system must achieve . those comprising the top $40 (40%) by value of your Functional Requirements. Aim to create tests for all of these requirements together with about half of next $30 (30%) in value and one or two others. Depending upon the detail and type of system, aim to create about 4 test cases, although in some projects it may be rather more, very simple tests.

These tests will be used in the marking of Deliverable C. Accordingly ensure that you specify and agree with your Client the precise environment under which they will be conducted; define this in the Test Materials section of the document.

Your Client must sign off these tests.

Submit hard copy and electronic versions as detailed above.