Software Project Management Plan (SPMP) Project : Music School Administration System Team Respect

October 30, 2003

Revision 1.13

Team Members

CS login

Amy Curran aecurran Jonathan Conn jwac Nikhil Malani nkmalani Vinit Praneel Kumar vpkumar Rohan DSouza rohandd Document Maintainer: Jonathan Conn
Abstract This SPMP sets out the processes, the management plan and stang control that Team Respect will follow as part of the assessment for subject 433-340 at The University of Melbourne.

CONTENTS

Contents
1 Purpose 1.1 Purpose of this SPMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Project Aims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Client Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Introduction 2.1 Project Overview . . . . . . . . . . . 2.1.1 Purpose, Scope and Objective 2.1.2 Assumptions and Constraints 2.1.3 Schedule . . . . . . . . . . . . 2.2 Project Deliverables . . . . . . . . . 2.3 Evolution of the SPMP . . . . . . . 2.3.1 Scheduled Change . . . . . . 2.3.2 Unscheduled Change . . . . . 2.3.3 Possible foreseen amendments 2.4 Reference Materials . . . . . . . . . . 2.5 Denitions and Acronyms . . . . . . 2.5.1 Denitions . . . . . . . . . . 2.5.2 Acronyms . . . . . . . . . . . 3 Roles and Responsibilities 3.1 Project Manager . . . . . . . . 3.2 Client Liaison Ocer . . . . . . 3.3 Risk Manager . . . . . . . . . . 3.4 Secretary . . . . . . . . . . . . 3.5 Requirements Engineer . . . . . 3.6 Design Architect . . . . . . . . 3.7 Quality Assurance Manager . . 3.8 Technical Head . . . . . . . . . 3.9 Backup Manager . . . . . . . . 3.10 CVS in-charge . . . . . . . . . 3.11 Head Programmer . . . . . . . 3.12 Head of Testing . . . . . . . . . 3.13 Internal Review Team . . . . . 3.14 Programming Team . . . . . . 3.15 Testing Team . . . . . . . . . . 3.16 Mail Manager . . . . . . . . . . 3.17 Web Page Maintainer . . . . . 3.18 Assistant Document Maintainer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 1 1 2 2 2 2 3 3 4 4 4 5 5 5 5 5 6 6 7 8 8 8 8 8 9 9 9 9 9 10 10 10 10 10 11 12 12 12 12 12

4 Managerial Process Plans 4.1 Project Start-Up Plan . . . . . . . . . . 4.1.1 Estimation Plan . . . . . . . . . 4.1.1.1 Schedule . . . . . . . . 4.1.1.2 Resource Requirements

CONTENTS

ii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . and Audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 13 13 13 13 13 13 14 14 14 14 14 15 15 16 16 17 17 17 17 18 18 19 19 19 19 20 20 21 21 21 21 21 22 22 22 22 22 22 22 23 23 23 23 24 24

4.2 4.3

4.4

4.1.1.2.1 Technical Resources . . . . . . 4.1.1.2.2 Written Resources . . . . . . . 4.1.2 Resource Acquisition Plan . . . . . . . . . . . . . 4.1.2.1 Technical Resources . . . . . . . . . . . 4.1.2.2 Written resources . . . . . . . . . . . . 4.1.3 Project Sta Training Plan . . . . . . . . . . . . External interfaces . . . . . . . . . . . . . . . . . . . . . Control Plan . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Requirements and Schedule Control Plan . . . . 4.3.2 Quality Control plan . . . . . . . . . . . . . . . . 4.3.2.1 Procedures for Internal Reviews . . . . . . . 4.3.2.2 Procedures for External Reviews . . . . . . 4.3.2.3 Obtaining an External Review . . . . . . . . 4.3.2.4 Conducting an External Review . . . . . . . 4.3.2.5 Procedure for External Audits . . . . . . . . 4.3.2.6 Procedure for Follow-up of External Reviews 4.3.2.7 Quick Reference Sheet . . . . . . . . . . . . 4.3.3 Reporting plan . . . . . . . . . . . . . . . . . . . 4.3.3.1 Email . . . . . . . . . . . . . . . . . . . . . . 4.3.3.2 Procmail and Hypermail . . . . . . . . . . . 4.3.3.3 Header Denition . . . . . . . . . . . . . . . 4.3.3.4 Task Sheet . . . . . . . . . . . . . . . . . . . 4.3.3.5 Tutos . . . . . . . . . . . . . . . . . . . . . . 4.3.3.6 Yahoo Group . . . . . . . . . . . . . . . . . 4.3.3.7 Team Web Page . . . . . . . . . . . . . . . . 4.3.3.8 Hour of Power . . . . . . . . . . . . . . . . . 4.3.4 Meeting Procedure . . . . . . . . . . . . . . . . . 4.3.4.1 Team Meetings . . . . . . . . . . . . . . . . 4.3.4.2 Agenda . . . . . . . . . . . . . . . . . . . . . 4.3.4.3 Minutes . . . . . . . . . . . . . . . . . . . . 4.3.4.4 Chair and Secretary . . . . . . . . . . . . . . 4.3.4.5 Quorum and Voting . . . . . . . . . . . . . . Risk Management plan . . . . . . . . . . . . . . . . . . . 4.4.1 Schedule Control . . . . . . . . . . . . . . . . . . 4.4.1.1 Unrealistic Schedule or Budget . . . . . . . . 4.4.1.2 Real Time Shortfalls . . . . . . . . . . . . . 4.4.1.3 Capability Shortfalls . . . . . . . . . . . . . 4.4.1.4 Wrong Functionality . . . . . . . . . . . . . 4.4.1.5 Wrong User Interface . . . . . . . . . . . . . 4.4.1.6 Personnel Shortfall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Technical Process 5.1 Development Methodology . 5.2 Version Control . . . . . . . 5.3 Conguration Management 5.4 Software tools . . . . . . . . 5.5 Design Tools . . . . . . . .

CONTENTS

iii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 25 25 25 25 25 26 26 26 27 27 27 27 27 27 28 28 28 28 28 28 29 29 29 29 31 31 31 32 32

5.6 5.7

5.8 5.9 5.10 5.11 5.12

5.13

5.14

Documentation Standards . . . . . . . . . . . . . . . . . Test Procedures . . . . . . . . . . . . . . . . . . . . . . . 5.7.1 Unit Testing . . . . . . . . . . . . . . . . . . . . 5.7.2 Integration Testing . . . . . . . . . . . . . . . . . 5.7.3 Acceptance Testing . . . . . . . . . . . . . . . . . Commenting Standards . . . . . . . . . . . . . . . . . . File Permission Standards . . . . . . . . . . . . . . . . . Coding Standards . . . . . . . . . . . . . . . . . . . . . Backup Processes . . . . . . . . . . . . . . . . . . . . . . Product Acceptance Plans . . . . . . . . . . . . . . . . . 5.12.1 Project Milestones . . . . . . . . . . . . . . . . . 5.12.2 Approval Process . . . . . . . . . . . . . . . . . . 5.12.3 Acceptance Criteria . . . . . . . . . . . . . . . . 5.12.4 Critical Success factors . . . . . . . . . . . . . . . Software Documentation . . . . . . . . . . . . . . . . . . 5.13.1 Software Project Management Plan [SPMP] . . 5.13.2 Software Requirements Specications [SRS] . . . 5.13.3 Software Architectural Design Document [SADD] 5.13.4 Software Design Description [SDD] . . . . . . . . 5.13.5 Design Decisions Document . . . . . . . . . . . . 5.13.6 Software Build Plan [BP] . . . . . . . . . . . . . 5.13.7 Software Test Plan [TP] . . . . . . . . . . . . . . Project Support Functions . . . . . . . . . . . . . . . . . 5.14.1 User Documentation [UD] . . . . . . . . . . . . . 5.14.2 Documentation Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Work Plan 6.1 Work Activities . . . 6.2 Schedule Allocation . 6.3 Resource Allocation 6.4 Stang Plan . . . . 7 Appendix 7.1 Task Sheet

34 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

LIST OF TABLES

iv

List of Tables
1 2 3 4 5 6 7 Team Members . . . . . . . . Allocation of Team Roles . . external contacts . . . . . . . Reviewers and Documents . . document reference materials Document managers . . . . . work schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 7 13 15 30 30 32

PURPOSE

1
1.1

Purpose
Purpose of this SPMP

The purpose of this Software Project Management Plan (SPMP) is to detail the standards, practices, tools, and techniques the team will use during the development life cycle of this software product. The team is the intended audience for this document.

1.2

Project Aims

This project is aimed at creating an administration database for The Masters Music School based in Brisbane. The music school currently uses Microsoft Excel to store student information and would like to transfer this information to an interactive database.

1.3

Client Information

The Clients name is Christine Masters, the proprietor of Masters Music School in Brisbane, Queensland. The client will be represented by Kathleen Keogh of The University of Melbournes Computer Science Department. The teams point of contact will be Mrs Keogh who will organise direct contact with Mrs Masters when needed. Mrs Keogh will be contacted via e-mail at kathleen@cs.mu.oz.au

INTRODUCTION Name Jonathan Conn Rohan DSouza Amy Curran Nikhil Malani Praneel Kumar Student Number 91469 110594 108532 121824 133026 login jwac rohand aecurran nkmalni vpkumar Mobile Number 0412 122282 0409 251460 0402 823687 0405 202442 0421 595546

Table 1: Team Members

Introduction

Each team member can be contacted by phone or by e-mail. Table 1 shows team contact details. E-mail addresses are team members CS login followed by @students.cs.mu.oz.au. The supervisor for this project is Sharyn Oh. Contact Details: 1. Login: ssjo 2. Mobile Number: 0413 608546 3. Email: ssjo@students.cs.mu.oz.au

2.1

Project Overview

This section contains an overview of the elements involved in the project. 2.1.1 Purpose, Scope and Objective

The purpose of this project is to produce a functional database of the details of all the students and sta of Masters Music School with the objective of automating many of the schools processes which are currently performed manually. The project is to be completed over the course of the year as part of 433-340 Software Engineering Project at the University of Melbourne. The scope of the project covers the core requirements detailed in the SRS. However, if time allows, optional requirements will also be implemented. Details of both the core and optional requirements can be found in the SRS. The main requirement of the Client is that the product be time-eective, in that the Client wishes to have minimal interactions with the interface in order to produce desired results. The Clients current system runs on a Windows 95 operating system. However, the Client is looking at purchasing a new laptop and would like the members of the team to assist her in choosing a system which will be compatible with the product being designed. 2.1.2 Assumptions and Constraints

The following assumptions and constraints will have an aect on the progress of the project.

INTRODUCTION

1. It is to be assumed that the Client will be the only user of the system being developed, and it will only be necessary for the system to be used on a single PC or laptop. 2. However there is the non-functional requirement of designing the system to allow for the possibility of making it available on the world wide web at a later date. (See the SRS for more information) 3. Student information is currently stored in Microsoft Excel and it would be ideal if this information could be electronically transferred to the new system. However there is no requirement for an ongoing integration with Microsoft Excel and the new database system. 4. The client has stipulated that security is not a major issue of concern however a simple login functionality is required.. 5. The client, Christine Masters resides in Brisbane causing a geographical constraint for the client/team interaction. To overcome this, the Client has arranged a representative (Kathleen Keogh) who is readily available for consultation and is in close contact with the actual client. 6. There is a time constraint on the project in that it must be completed by the end of 2003. 7. The project development is constrained to the resources available at the University of Melbourne, as well as those owned by team members. 2.1.3 Schedule

The project must be delivered before the end of 2003. Deadlines for individual documents will be outlined by the university as part of the subject 433-340. For a more detailed schedule, see section Schedule Allocations, 6.2.

2.2

Project Deliverables

The deliverables of the project are as follows: 1. Software Project Management Plan. (SPMP) Outlines the project and people involved and details the processes and guidelines to be followed throughout the duration of the project. 2. Software Requirements Specications. (SRS) Details what is required of the system by the Client. Will contain both functional and non-functional requirements, ranked as core or optional. 3. Software Architecture Design Document. (SADD) A top level design of the system. The architecture is a decomposition of the system to three levels. 4. Software Design Document. (SDD) Contains an in-depth design of the software, including use-case, collaboration, sequence and class diagrams.

INTRODUCTION

5. Test Plan. (TP) Details the types of tests to be carried out on the system to ensure the system meets requirements and maintains integrity. 6. Source and Object Code. The main deliverable of the project which allows the client to run the required system. 7. User Manual. Details how the system runs and instructs the user in how to install and use the product. Note: The SADD and the SDD have been evolved into one document.

2.3

Evolution of the SPMP

The SPMP will be placed under version control in the team repository using CVS. Whenever a change needs to be made, the following protocol will be followed: 1. A team member will advise the PM that a change needs to be made (this may be done informally). 2. Once the change has been approved by either the PM (for minor changes) or the group (for major changes), the PM will allocate time in Tutos for the team member to make the change. 3. The PM will check any changes made at the end of the week (time will be allocated through Tutos to ensure traceability). 2.3.1 Scheduled Change

A scheduled change is dened as a change made as the result of a review (internal or external). 1. The document will be checked out of the repository. 2. The person responsible for the scheduled change will make the amendments 3. The person making the changes will e-mail the PM once completed, detailing what changes were made. 4. The PM will proof read the changes within 5 days. 2.3.2 Unscheduled Change

1. If a team member wishes to make an unscheduled change, they will propose the change to the PM for authorisation. 2. They follow the same protocol as for a scheduled change.

INTRODUCTION

2.3.3

Possible foreseen amendments

1. Additional reference materials. 2. Additional denitions and acronyms. 3. Amendments to the schedule. 4. Amendments to processes.

2.4

Reference Materials

1. Van Vliet, H. 2000: Software Engineering Principles and Practices. John Wiley and Sons, West Sussex 2. IEEE Std 1058-1998 Software Project Management Plan 3. University of Melbourne 433-252 Lecture Notes 2002 4. Tutos User Manual 5. Hypermail User Documentation (from www.landeld.com/software/hypermail/hypermail.html ) 6. Procmail user documentation (from www.ii.com/internet/robots/procmail/qs/ )

2.5

Denitions and Acronyms

The following are denitions and acronyms used throughout this document: 2.5.1 Denitions

1. Core requirements - Requirements which are necessary for the system to meet the Clients requirements. 2. Optional requirements - Extra functionality which will be implemented if possible 3. Task Sheet - One A4 sheet (created from the le tasksheet.txt) in which a team member writes the weeks tasks and lls in time taken during the week. See 4.3.3.4 for more information. 4. Tutos - A project management tool used mainly for task allocation and tracking. 2.5.2 Acronyms

1. PC - Personal Computer 2. SPMP - Software Project Management Plan 3. SRS - Software Requirements Specication 4. SADD - Software Architecture Design Document 5. SDD - Software Design Document

ROLES AND RESPONSIBILITIES

6. GUI - Graphical User Interface 7. UML - Unied Modelling Language 8. CVS - Concurrent Version System 9. TP - Test Plan 10. SQAP - Software Quality Assurance Plan 11. UD - User Documentation 12. PM - Project Manager 13. CLO - Client Liaison Ocer 14. SAG - System Administrators Group 15. TBA - To Be advised 16. TBI - To Be Informed at a later date by the University of Melbourne 17. IEEE - Institute of Electrical and Electronic Engineers 18. University - University of Melbourne 19. CSSE - Department of Computer Science and Software Engineering at the University 20. 433-340 - The Subject held by the CSSE named Software Engineering Project whose code is 433-340 21. School - Masters Music School

Roles and Responsibilities

This section describes the roles and responsibilities of the various members of the team. One person may take on more than one role. Table 3 illustrates the various roles lled by each team member: As Team Respect consists of only 5 members, each member will play some part in the reviewing, programming and testing teams. However the head of each team will not change throughout the year to ensure at least one team member is always aware of exactly what stage each team is at.

3.1

Project Manager

1. To distribute tasks amongst group members and record tasks allocated at the Monday meeting on Tutos. 2. To arrange reviews with the 4th year Reviewers and Team Members. 3. To provide regular feedback to supervisor.

ROLES AND RESPONSIBILITIES Role Project Manager Client Liaison Ocer Risk Manager Secretary Requirements Engineer Design Architect Quality Assurance Manager Technical Head Backup Manager CVS Manager Head Programmer Head of Testing Mail Manager Web Page Maintainer Assistant Document Maintainer Team Member Jonathan Conn Amy Curran Praneel Kumar Rohan DSouza Amy Curran Praneel Kumar Nikhil Malani Nikhil Malani Praneel Kumar Praneel Kumar Nikhil Malani Rohan DSouza Amy Curran Nikhil Malani Amy Curran

Table 2: Allocation of Team Roles 4. To keep a record of the tasks allocated to each team member in tutos. 5. To be available for team members to see when there is a problem within the group. 6. To ensure that the project keeps to the schedule. 7. To create, distribute and collect every Monday, each Team Members Task sheets for task and time allocation (this process begins on 28/7/2003) 8. To ensure a day, time and place is arranged for every meeting. (Either by delegating this task to other team members or completing himself.

3.2

Client Liaison Ocer

1. To arrange meetings with the client. 2. To prepare an agenda for each client meeting. 3. To minute client meetings. 4. To regularly update the client on the progress of the project, either via email or during a client meeting. 5. To notify the team members of the clients needs. 6. To resolve all doubts and queries with the client. 7. To ensure that the SRS matches the clients requirements and is approved by the client. This has been done successfully if the client signs o on the SRS.

ROLES AND RESPONSIBILITIES

8. To elicit requirements from the client which are within the teams capabilities. 9. To take meeting minutes in the event of the secretary being absent.

3.3

Risk Manager

1. To suggest possible solutions for problems arising within the team. 2. To identify, assess, manage and document the risks that may occur during the course of the project. 3. Suggest a way to prevent the same type of risk from re occurring. 4. To alert team members when a risk is identied.

3.4

Secretary

1. To maintain records of all meetings. 2. To archive the minutes. 3. To post the minutes in the team repository.

3.5

Requirements Engineer

1. To ensure that the specications are well documented. 2. To ensure the requirements are met.

3.6

Design Architect

1. To produce a design for the software based on the SRS. 2. To ensure that the CLO and the Requirements Engineer are satised with the design architecture. 3. To supervise the documentation of the SADD and the SDD. 4. To ensure the design is thorough and easily implemented by the Programming team.

3.7

Quality Assurance Manager

1. To ensure that the team members follow all the standards and procedures mentioned in the SPMP. 2. To set up deadlines for internal reviews. 3. To supervise internal reviews. 4. To approve document for submission. 5. To ensure that all changes made to a document or code once its collation adhere to guidelines.

ROLES AND RESPONSIBILITIES

6. All documents produced will adhere to the formats and syntax laid out by the teams LaTeX guidelines. 7. All Code will adhere to guidelines layed out by the groups code guidelines.

3.8

Technical Head

1. To prepare templates and shell scripts to automate report writing. 2. To allocate tasks to Technical team members. 3. To contact the SAG if any technical assistance is required.

3.9

Backup Manager

1. To take regular back ups of the project les and document that these backups have occurred. 2. To perform le recovery procedures if and when needed.

3.10

CVS in-charge

1. To set up the team CVS repository. 2. To create directories in the repository. 3. To ensure that all les and folders have the correct permissions. 4. To maintain version control of all documents and code.

3.11

Head Programmer

1. To lead the programming phase of the development life-cycle of the software. 2. To designate tasks to the programming team. 3. To make programming decisions. 4. To perform code inspections on a regular basis. 5. To ensure code is clearly documented.

3.12

Head of Testing

1. To prepare the test-case suit. 2. To supervise unit, integration, system and acceptance tests. 3. To ensure all testing procedures are followed.

ROLES AND RESPONSIBILITIES

10

3.13

Internal Review Team

1. To perform internal reviews and audits as and when requested by the Quality Assurance Manager. 2. To provide internal review report with suggested changes to be made before submission.

3.14

Programming Team

1. To code the core and the non-core functionality of the software. 2. To request the Head Programmer for code inspections. 3. To link and compile the code. 4. To ensure that high quality, ecient code is produced.

3.15

Testing Team

1. To perform unit, integration, system and acceptance tests. 2. To supervise the documentation of the Software Test Plan. 3. To ensure all testing procedures are followed.

3.16

Mail Manager

1. To ensure email is utilised eciently by team members for communication purposes. 2. To ensure all team members utilise email tags correctly. (See 4.3.3.1) 3. To contact a team member if an email requiring a reply is not replied to within 24 hours. 4. To use Procmail to lter emails into folders using the email tags. 5. To upload all emails to the team web-page once a week using hypermail.

3.17

Web Page Maintainer

1. To ensure the web page is up to date. 2. To upload minutes and agendas to the web page. (See 4.3.3.8) 3. To upload documents, as versions are updated, to the web page.

ROLES AND RESPONSIBILITIES

11

3.18

Assistant Document Maintainer

1. To have a knowledge of all formal documents. 2. To ensure all documents meet the teams internal document standards/formats through reviews. 3. To assist document managers in making changes to their documents. The main role of the Assistant Document Maintainer is to be a back-up for document managers when they are unable to perform updates and make changes to their documents. If any team member requires a person or group of people to assist them in fullling a task, then the PM will assist the team member in organising a team.

MANAGERIAL PROCESS PLANS

12

4
4.1

Managerial Process Plans

Project Start-Up Plan
Estimation Plan

4.1.1

4.1.1.1 Schedule The current schedule dates are based upon the due dates for 2002 project deliverables in the subject 433-340. The deliverable dates will be adjusted to this years dates when they become available from the University. The team will nish all documents at least a week before the due dates given by the university for 2003. Non-deliverables are also included in the schedule and their expected completion dates. The schedule may alter as the expected completion dates draws closer to take into account any risk delays or accelerations in the schedule. 4.1.1.2 Resource Requirements The estimation of resource requirements is based upon the groups experiences in previous years, as well as the teams knowledge of both management and technical practices. Some resources which are known to be required are: 4.1.1.2.1 Technical Resources

1. Tutos Task management software which will mostly be utilised by the PM to allocate tasks. However all group members will be able to indicate how much time they spend on specic tasks to ensure no one member takes on too much work. 2. CVS Version control software. This will be used to keep track of changes to both documents and code. 3. Procmail This will be used to lter all 340 mail to ensure it is logged and not mixed up with other mail. 4. Hypermail Will be used to create html links to emails. 5. Homepage A resource for all team members, and also anyone interested in the project. Will contain mail and links to documents related to the project. 6. Development Programs The following resources will be used in the actual development of the system: (a) Smartdraw - For drawing design diagrams (b) Microsoft Frontpage - To aide the HTML coding (c) HTML, MySQL and php unit testing tools (d) A MySQL database server

MANAGERIAL PROCESS PLANS Team Member PM CLO CLO Technical Head contact Project Supervisor Melbourne Client Contact Client Computer Resourses provider Table 3: external contacts contacts name Sharyn Oh Kathleen Keogh Christine Masters SAG

13

4.1.1.2.2

Written Resources

1. Textbook Software Engineering Principles and Practices by Hans Van Vliet. 2. IEEE Standards 3. Various web sites Including: (a) php.resourceindex.com (b) www.mysql.com (c) www.phpbuilder.com (d) www.ieee.com 4.1.2 Resource Acquisition Plan

4.1.2.1 Technical Resources The main source for technical resources will be the SAG. When a team member becomes aware of the need for a certain resource, which is not currently installed on the CSSE computer system, they will post a message on the 340 newsgroup looking for other teams who also have a need for the resource. Once it is established how many teams require the resource, the initiator will email the SAG requesting the resource. 4.1.2.2 Written resources Borrowed from the library, when available. It is realised that there will not be an unlimited availability of resources. When a resource cannot be attained, a suitable replacement will be found. 4.1.3 Project Sta Training Plan

When there is no expertise in an area where it is required, a team member will be allocated to learn about the resource/software/hardware. They will then pass their knowledge onto those who need it through consultation during team meetings and sub-team meetings.

4.2

External interfaces

For a description of external interfaces please see Table 3.

MANAGERIAL PROCESS PLANS

14

4.3

Control Plan

This section of the SPMP looks at the reporting mechanisms and control procedures that the team will use to measure, report and control the product requirements, schedule, budget and resources of the project. 4.3.1 Requirements and Schedule Control Plan

The schedule control plan involves splitting various requirements and schedules into core and non-core requirements. A schedule will be determined to complete all core requirements on time with the relevant slippage allowances 4.3.2 Quality Control plan

Quality control will be the main task of the Quality Assurance Manager. They will ensure that all changes to documents and code will adhere to the guidelines layed out by the group. 4.3.2.1 Procedures for Internal Reviews

An overview of the procedures are: 1. The team, document manager or the PM request an internal review. 2. A team member will nominate themselves to conduct the review. 3. The team member will review the document within a time frame layed out at the time by the PM and the reviewer. 4. The reviewer will print a hard-copy of the current version of the document being reviewed. 5. The reviewer will review the hard-copy and make suggested amendments on the hard-copy. The front of the hard-copy will be marked with the date and the reviewers login. 6. The reviewer will give the hard-copy to the document manager, who will then make the suggested amendments on the soft-copy. If they do not agree with any of the suggested amendments, the team will be consulted at the next meeting. 7. After completing the amendments the document manager will store the hardcopy in the Internal Review folder kept in the team locker. 4.3.2.2 Procedures for External Reviews

1. There are ten(10) external reviews available to the team. The team will choose any of the review slots for an external review. The rst ve review slots have been pre-decided by the 440 reviewers. Review slots six to ten shall be lled in by the team. Review slots six to ten allow the team to choose which document is to be reviewed and also which 440 reviewer be allocated to review that document.

MANAGERIAL PROCESS PLANS Reviewer Nick STYLIANOU Henry TSAI Kunal BEDSE Eric Shiu-Wah LAU Li-Hsia YAP Document Software Project Management Plan Software Requirements Specication Software Architectural Design Description Software (Detailed) Design Description Software Test Plan

15

Table 4: Reviewers and Documents 2. It is the responsibility of the team to ensure that the document to be reviewed meets the following criteria before an external review takes place. (a) There are minimal spelling mistakes. (b) There are minimal grammatical mistakes. (c) All sections of the document are up to date. 4.3.2.3 Obtaining an External Review

1. Project Manager will send the respective 440 reviewer an e-mail no less than three(3) days prior to the date being requested for the review. Included in the e-mail will also be the name of the document to be reviewed. 2. The 440 reviewer must reply via e-mail to the Project Manager within two(2) days of the request being sent. This reply will either conrm the date requested for the review or propose an alternate date. (a) In the case that an alternative date was requested by the 440 reviewer, the Project Manager must reply within one(1) day, either conrming the new date, or making an alternative request. (b) This process will continue until a mutually agreeable date has been chosen. 3. A copy of the document (in Postscript format) will be left in the directory, /home/se340/s340gr/440 at CSSE which will be accessible to the 440 reviewer, no later than 24 hours prior to the review taking place. 4.3.2.4 Conducting an External Review

The review will be conducted under these conditions, a failure to meet these conditions will cause the review to be cancelled and re-initiated. In the event of a review being cancelled, the 440 reviewers will send an e-mail to the Project Manager notifying them of the reason for cancellation, and the entire procedure will be restarted (including organising a new review as per the above procedures) 1. Once a copy of the document (in Postscript format) is left in the directory, /home/se340/s340gr/440 at CSSE, a three(3) day period will follow for the review to take place.

MANAGERIAL PROCESS PLANS

16

2. At the end of the review period, the 440 reviewer will e-mail the Project Manager, a copy (soft-copy) of the review report. 3. The review will be deemed as nished once the review report has been emailed to the Project Manager. 4.3.2.5 Procedure for External Audits

When the team is to be audited by our 440 auditors, the following procedure will be used. 1. The 440 auditor(s) will email a notice of audit to the Project Manager no less than six(6) days before the commencement of the audit. The e-mail shall contain details of who is conducting the audit. 2. Within two(2) days of the notice, the Project Manager will place the latest version of the SPMP (in Postscript format) in the directory, /home/se340/s340gr/440/ 3. The auditor(s) will then email the audit plan to the Project Manager, no less than 24 hours prior to the commencement of the audit. 4. The team will leave any hard copy design notebook entries in the Team Respect locker in ICT Room 1.08 in a clearly marked binder or box no less than 24 hours before the commencement of the audit. 5. At the audit commencement time, the auditor(s) will make a copy of the teams repository which will then be used to conduct the audit. 6. A four(4) day period will follow the audit commencement date, over which the audit will be conducted. 7. At the end of this four(4) day period, the auditor(s) will e-mail a copy (soft-copy) of the audit report to the Project Manager. This will signal the end of the audit. 4.3.2.6 Procedure for Follow-up of External Reviews and Audits

This outlines the procedure for the organisation of a post-review meeting if one is deemed appropriate. A post-review meeting will be scheduled to discuss the content of the review report and allow both parties to discuss any issues and/or concerns raised in the review. 1. The Project Manager will send a request for a post-review meeting to the 440 reviewer no later than three(3) days after receiving the review report. Included in this e-mail will be a list of possible meeting times that are no later than ve(5) days after the submission of the review report. 2. Within 24 hours of receiving a request for a meeting, the 440 reviewer must reply either conrming or oering three(3) alternative meeting times. (a) In the case that an alternative time was requested by the 440 reviewer, the Project Manager must reply within 24 hours, either conrming a new time, or making an alternative request.

MANAGERIAL PROCESS PLANS

17

(b) This process will continue until a mutually agreeable time has been chosen. 3. The exact same procedure will be used for following-up external audits. 4.3.2.7 Quick Reference Sheet

In order to ensure processes dened in this document are followed, a quick reference sheet will be created and a copy given to each team member. The quick reference sheet will contain items such as team contact details, le permission protocols and email tags to allow team members to follow processes without having to continually check the SPMP. In the event of a team member misplacing their copy of the Quick Reference Sheet, a soft copy will be kept in the team repository in the Management/General folder and a hard copy will be kept in the Team Respect locker. 4.3.3 Reporting plan

This section of the SPMP will outline the teams reporting mechanisms. This involves documentation management and communication management. 4.3.3.1 Email

Email will be heavily used by the team as its main form of communication away from direct personal interaction. Each team member will be required to check their computer science e-mail accounts twice (2) a day. Once in the morning and again in the afternoon. A e-mail sent before 5pm will be required to be read on the same day, while emails after 5pm will be assumed not to be read until the following day. The group will use hypermail to store all emails. Until the use of hypermail is implemented, emails will be stored and backed up by the Secretary. 4.3.3.2 Procmail and Hypermail

The following process will be followed to store all emails on the team web-page: 1. The Mail manager will lter mail sent to their Computer Science account with Procmail, and all mail relevant to the project will be stored in a separate mailbox, as per its email tag. Email tags are to be used at the beginning of the Subject eld of the email, enclosed in square brackets []. See 4.3.3.3. The email tags to be used by the team are: (a) SADD (b) SRS (c) Code (d) SPMP (e) SDD (f) Design (g) Risk

MANAGERIAL PROCESS PLANS

18

(h) Meetings (i) Client (j) Supervisor (k) Processes 2. Once a week, the Mail Manager will use Hypermail to create html versions of the mails and place in the team repository. 3. The Web manager will ensure the links to the mail on the team web page are up-to-date. 4.3.3.3 Header Denition

To assist with the archiving of the emails, all emails will follow the following denitions. To: s340gr@students.cs.mu.oz.au CC: Any relevant supervisor, 440 student or client. Attachment: Any related items with relation to the email Subject: [Email Tag] A brief description of the subject of the email This format is only for internal team discussions and is only required to be followed by members of Team Respect. 4.3.3.4 Task Sheet

During the team meeting each Monday, each team member will be responsible for lling out their task sheet for the following week. The procedure followed will be: 1. The PM will bring to the meeting ve blank copies of the Task Sheet, and distribute them to each team member. Refer to the Appendix in section 7.1 for a blank copy of the task sheet. 2. Throughout the meeting, as tasks are allocated, each team member is responsible for writing their tasks into their task sheet, along with a due date, and the amount of time the task is expected to take. 3. Throughout the week, each team member is responsible for lling in how much time they spend on each task each day. 4. At the end of a meeting, the PM will collect the task sheets with the following weeks tasks and enter the tasks and expected times into Tutos in the Hour of Power. (See 4.3.3.8. The PM will then return the sheets to the team members so they can ll them out during the week. 5. Meanwhile, during the Hour of Power, each team member will enter into Tutos the amount of time they spent on their allocated tasks the previous week. 6. Completed task sheets will be archived in the Task Sheet folder in the team locker. 7. If a team member fails to complete their task sheet, they will be required to contribute to the Kitty.

MANAGERIAL PROCESS PLANS

19

4.3.3.5

Tutos

Tutos will be used by the PM to allocate tasks to specic team members. Tasks will be decided in team meetings. Additional tasks needed by a document manager will be sent to the PM who will add it to the tutos database. The PM will update tutos once (1) every two (2) day. All team members will be required to log into their tutos account at least once (1) every two (2) days. 4.3.3.6 Yahoo Group

Due to travel plans of some members of the group, a Yahoo discussion group will be set up to allow team members to contact other members of the group via the internet when they can not access their computer science accounts. This discussion group will also allow team members to transfer les between each other while overseas. 4.3.3.7 Team Web Page

The teams web-page will be found at www.cs.mu.oz.au/SE-projects/s340gr The web-page will contain: 1. Current versions of documents 2. Team member contact details 3. Links to Tutos, SAG and the 433-340 web page 4.3.3.8 Hour of Power

In order to ensure that team members complete the duties associated with their roles, after each Monday meeting the team will spend an hour together in the computer laboratories performing the following roles: 1. Jonathan (a) Enter following weeks tasks into Tutos for all team members (b) Email Sharyn (supervisor) with update of team progress (c) Email relevant 440 students to request any reviews needed (d) Print a Gantt diagram for the following week and store in the team locker 2. Praneel (a) Ensure CVS is working correctly (b) Check CVS logs and ensure team members are completing them correctly 3. Nikhil (a) Update web page - upload new versions of documents, previous meetings minutes and next meetings agenda

MANAGERIAL PROCESS PLANS

20

(b) Backup whole team repository 4. Rohan (a) Type up minutes from previous meeting (b) Type up agenda for next meeting, if it has been set 5. Amy (a) Email client/client representative to organise a meeting if one is required (b) Type up minutes from previous weeks client meeting, if one occurred. (c) Use Hypermail to create html versions of previous weeks emails. 6. Everyone (a) Enter times taken to complete previous weeks tasks into Tutos (b) Document Managers - Check documents If a team member does not complete their duties in the Hour of Power due to either a lack of time or being absent, the duties must be completed within 24 hours or a contribution must be made to the kitty. If a team member has a valid excuse, they must email the PM who will set a new date for their duties to be completed. Similarly, if a team member nishes before the hour is up, they will inform other team members who can then ask them for assistance. 4.3.4 4.3.4.1 Meeting Procedure Team Meetings

A weekly team meeting will be held each Monday at 10:00am in the SEECS building Room B126 on the basement level. From 28/7/2003, team meeting will be held at the same time, but in meeting room UG13 in the ICT building. This meeting is scheduled to go for two hours. If all two hours is not required, then the remainder of the time will be allocated for a work session. From 28/7/2003, the meeting will go for only one hour followed by a work session where all team members will be allocated time to do their weekly tasks (See 4.3.3.8). This meeting is compulsory to attend unless an apology is given in advance. A second meeting is reserved for Thursdays at 5:15pm after the 433-340 lecture. This meeting will convene as required. If the meeting is not required, a work session will occur in its place. Emergency meetings can be held during the year at the discretion of the PM and will follow the procedural guidelines of a normal meeting. On the Monday meetings, from 28/7/2003 onwards, each team member will be given their log sheet for the week in which they ll out the tasks assigned to them. The PM will take these log sheets and enter them into tutos directly after the meeting in the work session. At the conclusion of the week (at the following Monday meeting) the log

MANAGERIAL PROCESS PLANS

21

sheet will be handed to the PM who will enter time taken on tasks into tutos with 2 days of the meeting. 4.3.4.2 Agenda

The Agenda for a meeting will be decided by ether the group in the previous meeting or by the PM who will send it via e-mail to the other group members the day before the meeting. 4.3.4.3 Minutes

All meetings will be minuted by the secretary of the team.. The minutes will be taken by hand and then transcripted onto computer. Any important information from the meeting will be emailed to the relevant people. Further, all minutes will be stored in the Minutes folder in the team repository. They will be stored in the following order: MMDD.tex online. The minutes will follow the following order 1 Open 2 Attendance and Apologies 3 Agenda 4 Business Proposed and Completed 5 Discussion Items 6 Other Business 7 Schedule check 8 Close of meeting 4.3.4.4 Chair and Secretary

The Chair is the Project Manager - Jonathan Conn The Secretary is Rohan DSouza During the second semester of the academic year, each team member will have one turn at chairing a team meeting in order to gain experience. When the chair is not Jonathan, the replacement chair will be noted in the meeting minutes. 4.3.4.5 Quorum and Voting

The Quorum for team meetings is four team members. Therefore is less than four people attend the meeting, the meeting will be unocial and be declared to have not occurred. The time will then be allocated to a work session. All decisions will aim to be carried without any dissent. When disagreements occur and a consensus agreements can not be reached, the business (if not urgent) will be put aside and discussed at the next meeting after any relevant research can be completed by all team members. If the matter is required to be resolved immediately, the team will hear all arguments and vote upon the actions to be taken with a decision being given to the majority, with the chair having the casting vote.

4.4

Risk Management plan

This section identies all of the methods and measures that the team has used to determine, assess and take action on various risk factors involved in the project.

MANAGERIAL PROCESS PLANS

22

4.4.1 4.4.1.1

Schedule Control Unrealistic Schedule or Budget

The estimates that are made on completion dates for dierent documents and dierent parts of the project may be completely unrealistic to dierent parts of the requirements. Preemptive action on this risk by factoring slippage dates into the schedule. 4.4.1.2 Real Time Shortfalls

This is when the real-time performance of parts of the coded system are inadequate for the client. The team will attempt to ensure though design, testing requirement engineering that real-time shortfalls are prevented. 4.4.1.3 Capability Shortfalls

This is when an unstable environment or new or untried technology poses a risk to the development schedule. The team does not believe that this will be an issue in the development of the project. 4.4.1.4 Wrong Functionality

To prevent this problem, the team will sign o on each client functionality. The use of prototypes will assist the team in minimising this risk. 4.4.1.5 Wrong User Interface

The team will use prototyping along with demonstrations to the client to ensure this risk is minimised. 4.4.1.6 Personnel Shortfall

1. Inexperience from programmers and group members, loss of crucial team members may cause conict in the team. The team expects that inexperience will exist in some areas. To overcome this, the team member most knowledgeable in the area will, if required, obtain the extra knowledge required, and give a demonstration and tutorial to the non-procient team members. 2. It is a requirement at the University for all team members to remain in the team for the duration of the subject and the project in order to pass the subject 433340. If an event occurs that should cause a member of the team to be unable to undertake any further involvement in the project the remaining members of the team will continue work on the project. Since the large amount of personal travel that team members will be undertaking during the project development lifetime, the team will spread the workload of a document/area so that a single team member does not hold all the information about the document/area. This will ensure that in the event of a team members ceasing their involvement with the project, there will be little or no loss of information

TECHNICAL PROCESS

23

Technical Process

This section describes the technical methods, software tools and the methodologies to be used to develop the required software.

5.1

Development Methodology

This project has a clear specication and therefore the development model to be followed is the waterfall model. However, prototyping will be used to some extent to perfect the GUI. The waterfall model is largely a document driven model and is composed of the following ve distinct phases. These phases occur sequentially and a new phase cannot begin until the previous one has been completed. 1. Requirements phase: The exact requirements of the system, in terms of functionality, goals and constraints are established. These specications are then added in detail into an SRS document. 2. Design Phase: The details in the SRS are used to produce an in depth plan in the form of an SADD and a SDD of the system to be produced. 3. Implementation Phase: The designs made explicit in the SADD and the SDD are implemented by the programmers using the computer language of choice. 4. Testing Phase: Various testing methods are used to verify that the software works correctly and that the requirements have been met. 5. Maintenance: The continued updating of the software that may involve the correction of previously unaddressed problems and the adding or improvement of functionality.

5.2

Version Control

Version control aims to solve the problems of: 1. recreating older versions of les when needed, 2. identifying which version a le is, 3. restricting the set of people allowed to create new versions.

5.3

Conguration Management

Conguration management is the process of back tracking and requesting a change of a previous phase. Conguration management will be used by the team in producing all documents and coding. Conguration management will also improve the traceability of changes in the teams work. CVS will be used by the team as a tool for implementing conguration management.

TECHNICAL PROCESS

24

5.4

Software tools

This section documents all of the software tools that will be used by the team during the project. 1. CVS (Concurrent Version System): Tool for applying version control and conguration management. 2. Vi/gVim: Editor to be used for coding. 3. Microsoft Windows 98/ME/XP, Unix, Linux: Platforms to be used during the development phase. 4. Pine: Unix based e-mail client to be used for the purposes of internal communication. 5. HTML: Used for the development and maintenance of the group web page. 6. LaTeX: All documents produced during the development process will be formatted using LaTeX. 7. TUTOS: A task tracking device to monitor the activities of the team members. 8. Procmail: Email ltering program. 9. Hypermail: Creates html links to Unix format mail. 10. Install shield: Package to be used to simplify the installation process of the software. 11. MySQL Database Server 12. php 13. Apache - Used with the server

5.5

Design Tools

The tools to be used during the design phase of the project. 1. Sequence diagrams 2. Collaboration diagrams 3. Use Case Diagrams 4. Entity relationship diagrams (ERD) 5. UML Diagrams

TECHNICAL PROCESS

25

5.6

Documentation Standards

All supporting documentation produced including the SPMP, SRS, SADD, SDD and the TP shall follow as closely as is suitable, their complementary IEEE standards. The team will use the IEEE standard as a tool to assist in the structuring of the document. The team will make any necessary changes/omissions to the structure so that the documents structure is more practical to the project. All of the supporting documentation shall be formatted using LaTeX. The minutes of all team meeting shall be reproduced in text format and be placed on the team homepage and in the Archive folder in the team repository.

5.7

Test Procedures

All coding produced will be tested systematically in various ways to ensure the integrity of the system. All test les that are generated must be stored in the Testing folder, with clear documentation of the scope, date and the results of the test. The Testing folder is to be located at the path /home/se340/s340gr/cvs/. (Refer to Test Plan for further details.) 5.7.1 Unit Testing

Unit testing enables the individual modules to be tested independently from the status of the other modules. Unit testing will occur when a module is completed to ensure its functionality. A summary of the modules test result (PASS/FAIL) along with a description of any errors, will be kept in a suitable le in the Testing folder. 5.7.2 Integration Testing

As modules are integrated, they are tested to ensure their compatibility. Integration testing will occur when all modules concerned are completed. A summary of the integration test results along with a description of related modules and identied errors will be kept in a suitable le in the Testing folder. 5.7.3 Acceptance Testing

The nal system is checked to verify that it complies with the clients requirements. This verication will be made through careful consideration of the requirements laid out in the SRS and those implemented in the system.

5.8

Commenting Standards

Each module produced during the implementation phase is to contain: 1. File name 2. Date 3. Contributor 4. File description

TECHNICAL PROCESS

26

5. Related Modules Commenting of the actual code shall clearly depict how the algorithm being used works and any limitations of the code. Comments that span just one line are to begin with //. Any comments that extend over more than one line are to begin with /* and end with */. The log for all the les committed to the CVS repository must contain: 1. Status: A short description of where the item is at. Eg Ready for Review no. 1 2. Description: A short description of the changes made to the item and the reasons behind the change. it Eg Spelling and grammar checked and corrected. Or A description of the item if it is the rst check in. Eg A research report on Procmail done in order to allow the team to set up Procmail for emails. Note: CVS automatically logs the user and the date of all changes.

5.9

File Permission Standards

The following commands will be used when setting the permissions on les in the team repository: 1. For general group les: chmod 770 lename 2. For 440 les: chmod 775 lename 3. For website les: pdf: chmod 775 lename, other: chmod 771 & 664 lename

5.10

Coding Standards

All code needs to be clearly commented to a level at which any member of the team can read the code and easily recognise how it works. For purposes of neatness and readability, all lines of code and comments are to be no longer than 80 characters.

5.11

Backup Processes

1. During the planning and design phases of the project, a backup of the groups working directory is to be made on CD once a week, every Tuesday at approximately 12.00pm. Each backup will overwrite the previous weeks backup as CVS can be used to retrieve/recover previous versions of documents. 2. Once work on the implementation of the system begins, a daily backup of the group directory shall be made onto the Backup managers personal PC as well as the regular weekly CD backup. 3. These will be the only ocial backups, however programmers are encouraged to backup their work a few times everyday, depending on their progress.

TECHNICAL PROCESS

27

5.12
5.12.1

Product Acceptance Plans

Project Milestones

The software is to be delivered to the client by 3rd of November 2003. During May, a demonstration of a software prototype shall be made to show our progress. 5.12.2 Approval Process

The software approval process will involve a review of software by all of the team members and the team supervisor (This include the software forlling all requirements outlined in all documents, including the Test Plan). With a focus on whether the core functionality has been implemented correctly and whether the software operates reliably, the team and the supervisor will decide through discussion and voting processes if the project has been a success and thus if the software shall gain approval for delivery. 5.12.3 Acceptance Criteria

The criteria for the software that must be met for it to be accepted by the client is as follows: 1. All core functional requirements are implemented. 2. All non-functional requirements are satised. 3. User Documentation has been provided. 5.12.4 Critical Success factors

The following success factors are listed in order of importance. 1. The software must be reliable. Implemented functions must work properly and pass all suitable test cases. 2. All core functions required by the client needs to be completed. 3. The project must be on schedule as the deadline is nal. Since the project is being undertaken by students as a University requirement, it must be completed by the years end for assessment. 4. Extra functionality that the user would like but are not essential to the systems operation will be implemented only if time permits and core functions are already completed.

5.13

Software Documentation

This section species directly, or by reference, the documentation plan for the project. The use of these documents ensures that there are no major omissions of important areas of development. Note: It was decided, during the design phase, that the SADD and the SDD would be combined as the team consider that this would result in a more comprehensive and complete document.

TECHNICAL PROCESS

28

5.13.1

Software Project Management Plan [SPMP]

The SPMP entails an assessment of project properties that may aect the development process. It provides an overview of the project and the product, a list of deliverables and a plan for their development. Audience: Team members, supervisor, external reviewers and auditors. 5.13.2 Software Requirements Specications [SRS]

The SRS clearly and precisely describes each of the essential requirements (functions, performances, design constraints, and attributes) of the software and the external interfaces. The SRS provides the basis for design. It also provides the basis for testing. Audience: Team members, client, external reviewers, supervisor. Please refer to the Software Requirements Specications [SRS] document for more details. 5.13.3 Software Architectural Design Document [SADD]

The SADD depicts the architectural design of the proposed system to illustrate the subsystems and hierarchies for control and processing. Audience: Team members, external reviewers, supervisor, client. Please refer to the Software Architectural Design Document [SADD] for more details. 5.13.4 Software Design Description [SDD]

The SDD describes the components and sub-components of the software design implementation and unit testing. It is similar to the SADD but more implementation and unit testing. It is similar to the SADD but more in-depth. Audience: Team members, external reviewers, supervisor, client. Please refer to the Software Design Description [SDD] for more details. 5.13.5 Design Decisions Document

The Design Decisions Document describes the reasoning behind the teams decisions regarding choice of architectural styles and design methodologies. Audience: Team members, external reviewers, supervisor 5.13.6 Software Build Plan [BP]

The BP describes the coding procedures and order in which modules and components are coded. The reasoning behind the coding priorities, and which team member will be doing what coding is also detailed. Audience: Team members, external reviewers, supervisor.

TECHNICAL PROCESS

29

5.13.7

Software Test Plan [TP]

The TP describes all the testing procedures that will be followed and the standards that will be adhered to for the testing phase. The test plan also describes the test cases and test results that are obtained during testing activities. Audience: Team members, external reviewers, supervisor. Please refer to the Software Test Plan [TP] for more details.

5.14

Project Support Functions

This section provides either directly or by reference, plans for the supporting functions for the software project. 5.14.1 User Documentation [UD]

User documentation species and describes the required data and control inputs, input sequences, options, program limitations and other activities or items necessary for the successful execution of the software. A User Manual will be provided, including: 1. Instructions for Installation/Un-installation. 2. Description of the various software features and capabilities. 3. Working examples to help understand the program better. 4. Program limitations A Service Maintenance Manual will also be provided containing maintenance information to troubleshoot and information necessary to incorporate future upgrades to the product. Please refer to the User Manual and the Service Maintenance Manual. Audience: Users, client, software developing team members. 5.14.2 Documentation Plan

All documentation related to the project will follow the IEEE standards as closely as possible. However, when an IEEE standard does not t the format of the project, the team will decide upon suitable guidelines. Table 5 lists the IEEE standards applicable to the various documents. Any text editor can be used to write the documents, however the nal document will be formatted using LaTeX. The maintenance and submission of each document will be the responsibility of a specied team member. All team members will, however, be involved in the writing of any document. This will ensure that the risk management plan outlined in section 3.4.7 is followed. The following table summaries these responsibilities:

TECHNICAL PROCESS

30

Document Software Project Management Plan [SPMP] Software Requirements Specications [SRS] Software Architectural Design Document [SADD] Software Design Description [SDD] Software Test Plan [TP] User Documentation [UD]

IEEE Standard 1058.1 and 1540 830 4016 1987 & 1016.1 1993 4016 1987 & 1016.1 1993 829 &1008 1063 - 1987

Table 5: document reference materials

Person Jonathan Conn Amy Curran Vinit Praneel Kumar Amy Curran Nikhil Malani Rohan DSouza

Document SPMP SRS SADD SDD TP UD

Table 6: Document managers

WORK PLAN

31

6
6.1

Work Plan
Work Activities
Software Project Management Plan. The document, once developed, will be altered throughout the life of the Softwares development. Software Requirements Specication. The document must be completed and agreed upon by all parties by the end of July 2003 (Project team and client). Once signed by the client the SRS will under go no alterations. High level architecture. Towards the end of the SRS development, the High level architecture design will begin. The developers of the SRS will inform the architectural designers of any late major changes in the SRS that could aect the design. Low level architecture. When the High level architecture is near completion and SRS nalised, the low level architecture design can begin. No coding may occur until the document is completed but the document may be changed during the coding and testing phase of the project. Software Architecture Design Document. Once both the high level and low level architecture design is completed, it will be compiled into the SADD. The nal version of the SADD must be agreed upon by all team members. Test Plan. The test plan formation will begin just after the start of the SADD. Once completed it will continue to be altered throughout the remaining lifetime of the project development. Coding of core functionality. Coding of the core functionality can begin once the SADD is completed and agreed upon. Coding will follow the plans set out in the SADD. Testing of core functionality. Testing of the core functionality will be done continually throughout the coding period. All tests will be contained within the guidelines set out by the TP. Coding of extra functionality. Once the code functionality is completely coded and tested, the team will discuss which extra functionality time allows to be coded and thoroughly tested. Only these extra sections will be attempted. Testing of extra functionality. The testing of extra functionality will be done as outlined in the TP. A function will not be included in the nal package if testing is not completed. Compilation of project for nal submission. A period of time will be allocated towards the end of the projects development to compile all documents and code together into the deliverable package.

6.2

Schedule Allocation

Table 7 gives an outline of the teams schedule.

WORK PLAN Task Software Project Management Plan Software Requirements Spec High level Architecture Low level architecture Software Architectural Design Document Test Plan Core code Testing of core code Extra functionalities designed Extra functionalities implemented Extra functionalities tested preliminary demonstration Final Documentation Industry Night Demonstration Start 15th March 2003 8th April 2003 8th May 2003 20th July 2003 8th May 2003 1st Jul 2003 18th Aug 2003 8th Sep 2003 18th Aug 2003 22nd Sep 2003 5th Oct 2003 N/A N/A Finish 8th April 2003 13th May 2003 27th July 2003 25th Aug 2003 27th July 2003 4th Aug 2003 6th Oct 2003 24 Oct 2003 5th Oct 2003 10th Oct 2003 24th Oct 2003 29th Oct 2003 30th Oct 2003 3rd Nov 2003

32

Table 7: work schedule

6.3

Resource Allocation

1. Team members will have access to the Universitys computers. 2. Team members will be allocated personal and group space in which to develop the project. 3. All group members will have access to all parts of the group repository. 4. All code and documents will be accessed in the group repository via CVS. 5. Group members will have access to the group web page. 6. Group members will have access to the tutos program for task allocation.

6.4

Stang Plan

All sta will be required to work on all documentation, coding and designs. The work load will be evenly spread and allocated at initial time of task undertaking. Each member of the team will be required to work approximately 10 hours a week. The weekend will count as only 1 working day. Public holidays will count as 1 working day (except on weekends) Team members will be required to take some time away during University Holidays. Each team member will be given set tasks to complete during

WORK PLAN

33

University Holidays Each team member, from the 28/7/2003 onwards, will be required to ll out a task log sheet each week to be submitted to the PM each Monday.

APPENDIX

34

7
7.1

Appendix
Task Sheet

Name: Week starting: Start due time Tasks: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Weekly tasks Time spent on: Task 1 2 Mon: Tue: Wed: Thu: Fri: Sat: Sun: Additional Tasks during the week + time taken:

10

11

extra

Notes made during the week to be presented to the group: