TeamF::CGT	Main Page | About | Help | FAQ | Special pages | Log in
	Category: Documentation

Software Project Management Plan

From TeamF::CGT

Revision: 3359

Contents 1 Abstract 2 Introduction 2.1 Project Summary 2.1.1 Client Overview 2.1.2 Project Objective and Scope 2.1.3 Project Purpose 2.2 Project Personnel 2.2.1 Client 2.2.2 Project Supervisor 2.2.3 Team Members 2.2.4 Team Email, Directory, Repository, and Website 2.2.5 Course Co-ordinator 2.3 Project Deliverables 2.3.1 Project Plan 2.4 Assumptions and Constraints 2.4.1 Assumptions 2.4.2 Constraints 2.5 Evolution of the Software Project Management Plan 2.5.1 Audience 3 References 4 Definitions, Acronyms and Abbreviations 4.1 Definitions 4.2 Acronyms and Abbreviations 4.2.1 Document Related 4.2.2 Role Related 4.2.3 Other 5 Project Organisation 5.1 Process Model 5.1.1 Incremental Model Diagram 5.2 Organisational Structure 5.3 Organisational Boundaries and Interfaces 5.3.1 Client Communication 5.3.2 Project Supervisor Communication 5.3.3 Course Co-ordinator Communication 5.4 Project Roles and Responsibilities 5.4.1 Course Coordinator 5.4.2 Project Supervisor 5.4.3 Client 5.4.4 Team Members 5.4.5 Project Manager 5.4.6 Quality Assurance Manager 5.4.7 Client Liaison Officer 5.4.8 Design Manager 5.4.9 Implementation Manager 5.4.10 Risk Manager 5.4.11 Testing Manager 5.4.12 Configuration Manager 5.4.13 Software Administrator 5.4.14 Research Lead 5.4.15 Agenda writer 5.4.16 Minute taker 5.4.17 Document Wroter 5.4.18 Document Maintainer 5.4.19 Document Responsibilities 6 Managerial Process 6.1 Management Objectives and Priorities 6.2 Control Plan 6.2.1 Schedule Control 6.2.2 Deadline Negotiation 6.3 Software Quality Assurance Plan 6.3.1 Quality Control Plan 6.4 Risk management plan 6.4.1 Objectives 6.4.2 Meeting Types 6.4.2.1 Team Meeting 6.4.2.2 Subteam Meeting 6.4.2.3 Project Supervisor Meeting 6.4.2.4 Client Meeting 7 Task Allocation 7.1 Team Task Allocation 7.2 Subteam Task Allocation 7.3 Task Completion 7.4 Task monitoring 7.4.1 Monitoring Responsibilities 7.4.2 Extensions 7.4.3 Slippages

Abstract

---

This document (Software Project Management Plan) describes the project management standards, procedures and various technical processes to be followed by 433-440 Team F throughout this project.These standards ensure management quality and consistency throughout the duration of the project. The Software Quality Assurance Plan defines the Team's quality goals and should be read concurrently with this document to provide the link between the Team's processes and its quality goals.

Introduction

---

This document describes management processes and practices that the Team shall adopt throughout the duration of this project. These processes and management practices will be enforced in order for the Team to meet its four quality goals of Correctness, Completeness, Consistency and Reliability (Refer to Chapter 2.2 of the Software Quality Assurance Plan (SQAP) for more details). Thus, this document should be read concurrently with the SQAP in order to provide the link between the processes and management practices described in this document and the Team’s quality goals described in the SQAP.

This chapter provides background information regarding this document, this project, project milestones, Client deliverables and expected document changes.

Project Summary

Client Overview

The client is a company called Risk Wizard, who provide corporate governance software and services for risk management, performance, voting systems and whistle-blowing. The System that will be developed aims to increase the capabilities of the existing software by providing a highly customisable toolset that can be used to tailor functionalities and services to the client.

Project Objective and Scope

Effective corporate governance is a key cornerstone of success within the corporate and government arena. It is a fast growing area and is primarily being driven by government and banking regulations following the spectacular collapse of large corporations worldwide.

The information technology vendor market today has many disparate systems providing one of more elements of corporate governance. The motivation behind this project is to build a unique suite of cutting-edge tools that can be accessed from one inter-related central system. This is a product that has a global application and unfulfilled demand. This knowledge management suite is known as the Corporate Governance Toolkit (CGT).

CGT would provide organisations with a single system to record, analyse, manage and report on corporate governance related issues. CGT needs to be very user friendly, colourful and simple whilst being a sophisticated and powerful business intelligence tool.

As the name suggests, CGT will be made up of a range of modules relevant to the ongoing governance of an organisation. Similar to modular MIS products such as SAP, the product offering will expand over time as the product is used and deployed in various organisations.

Project Purpose

The purpose of this project is to participate and contribute in a team-oriented software engineering environment. This project consists of planning and managing the software process, requirements elicitation, and the subsequent phases of software development, including documentation, requirements analysis, specification, design, implementation, testing and release. The project aims to allow the team to become familiar with some of the problems that can arise during execution of the software development lifecycle.

Project Personnel

Client

NAME	PHONE	EMAIL
Richard (Primary Contact)	+61 419 192 735	richardp@riskwizard.com
Mark Crichton	+61 413 991 178	markc@riskwizard.com

Project Supervisor

NAME	PHONE	EMAIL
Steele Griffith	+61 424 632 744	sawg@students.cs.mu.oz.au

Team Members

NAME	CS LOGIN	PHONE
Tim Fang	tfang	+61 412 447 538
Jack Gao	jbgao	+61 401 373 708
Eric Huang	ymh	+61 413 872 883
Sie Ming Huang	smhuang	+61 421 197 558
Luke Jones	ljjones	+61 415 157 718
Gary Liang	zhl	+61 422 169 477
Ivan Seow	iwhs	+61 422 781 435
Sharkar Sribalachandra	srib	+61 401 923 939
Stephan Taitz	sptaitz	+61 403 304 589
Derek Tong	tong	+61 412 274 979
Fan Zhang	fzhan	+61 401 672 526
Amiel Zwier	aczwier	+61 422 593 782

Team Email, Directory, Repository, and Website

Team F Email Alias: s440gf

Team F Group Directory: /home/se440/s440gf/ → ($GROUP)

Team F SVN repository: /home/se440/s440gf/repository/ → ($GROUPSVN)

Team F Website: http://www.cs.mu.oz.au/SE-projects/s440gf/

Course Co-ordinator

NAME	CS LOGIN
Shanika Karunasekera	shanika

Project Deliverables

Project Deliverables that will be produced throughout the course of this project include:

1. Software Project Management Plan (SPMP)
2. Software Quality Assurance Plan (SQAP)
3. Process Improvement Proposal (PIP)
4. Software Requirements Specification (SRS)
5. Software Architectural Design Description (SADD)
6. Software Design Description (SDD)
7. Progress Report (PR)
8. Risk Management Plan (RMP)
9. Test Plan (TP)
10. Poster
11. User Documentation (UD)
12. Corporate Governance Toolkit (CGT)
13. Source Code

The Client will receive the SRS, SADD, SDD, UD, CGT and source codes.

Project Plan

The Team’s overall project plan (Gantt chart) displays the duration of project deliverables and the Team member(s) primarily responsibilities for that particular deliverable.

The project plans will be uploaded on the Team’s website to facilitate communication of the Team’s project plan with the Supervisor and Co-ordinator. The Team’s project plans can be found at:

http://www.cs.mu.oz.au/SE-projects/s440gf/ProjectPlan.html

Assumptions and Constraints

Assumptions

1. The Team will have access to the appropriate software required for the duration of this project.
2. Development tools used will be of a standard that is deemed acceptable for the purposes of this project.
3. All Team members are undertaking this project voluntarily and are willing to work towards the completion of the project.

Constraints

1. Schedule
   1. This project is not a single focus for the year and the Team members are enrolled in another three (or more) subjects each semester.
   2. The schedule and deadlines of other subjects may conflict with the ones of the project.
   3. The timeline of one teaching year (two 12 week semesters and four weeks of mid-semester break) to complete the project is another constraint on the schedule.
2. Budget: Budget is not a factor to be considered in the project.
3. Resources
   1. This project’s resources will be limited to the resources supplied by the Department of Computer Science and Software Engineering (CSSE) and the Client.
   2. This project’s resources will be limited to the 12 members of the team, no additions resources can be added to the project.
4. System interfaces to other products: The System will not interface with other products.

Evolution of the Software Project Management Plan

This document is dynamic and will be maintained by the PM as new processes, documents, responsibilities, technologies and time revisions are encountered. The Team will review this document when deemed necessary by the PM to ensure that processes are understood and accepted by the Team.

Audience

This document is written for the Team and the PS, which defines the overall management procedures and processes the Team shall follow in order to achieve this project’s objectives. This is a managerial document and will not be delivered to the Client.

References

---

1. IEEE Std 1058-1998, "Standards for Software Project Management Plans"
2. Karunasekera, Shanika., "Software Quality Assurance Plan (SQAP) 2004", Version 2.1
3. Presman, Roger., "Software Engineering: A Practioner’s Approach", 5th Edition, 2001
4. Chai, Albert et al., "Software Project Management Plan (SPMP) 2004", Version 3.4
5. Chan, Nathan et al., "Software Project Management Plan (SPMP) 2004", Version 2.11
6. Team F, "Risk Management Plan 2006"
7. Team F, "Software Quality Assurance Plan 2006"
8. Team F, "Software Requirements Specifications 2006"
9. Team F, "Software Review and Audit Plan 2006"
10. Team F, "Test Plan 2006"
11. Team F, "Traceability Document 2006"

Definitions, Acronyms and Abbreviations

---

Definitions

Client

The company Risk Wizard

Core Requirements

Requirements that have been defined by the Client as being crucial to the working operations of the System. The Team must implement these requirements before the System is accepted by the Client

Desirable Requirements

Requirements that have been defined by the Client to be of intermediate importance. These requirements will be designed for but only implemented if time permits

Document Maintainer

Team member responsible for preparing a document for review, making review changes, updating the document version number and submitting the document

Document Writer

Team member responsible for writing a part of a document Lead A lead is a the head of a subteam. This person will be responsible for overseeing and managing work done by the members of their subteam

Essential Requirements

Requirements that have been defined by the Client to be of high importance as these these features will greatly enhance the System. These requirements will be designed for but only implemented if time permits

Optional Requirements

Requirements that have been defined by the Client to be of low importance. These requirements will only be designed for and im plemented only after all Core, Essential and Desirable requirements have been implemented and time permits

System 

Corporate Governance Toolkit

Team 

Students in Team F

Traceability Document

Document that links the Client’s requirements to the Software Requirements Specification, Software Design Description, source codes and test cases

User 

Person(s) who will be in direct contact with the System

Acronyms and Abbreviations

Document Related

CI 

Configuration Item

PIP 

Process Improvement Procedure

PR 

Progress Report

RMP 

Risk Management Plan

RIS 

Risk Information Sheet

SDD 

Software Design Description

SDDD 

Software Detailed Design Description

SPMP 

Software Project Management Plan

SQAP 

Software Quality Assurance Plan

SRS 

Software Requirements Specification

TP 

Test Plan

UD 

User Documentation

Role Related

CLO 

Client Liaison Officer

CM 

Configurations Manager

DM 

Design Manager

IM 

Implementation Manager

PM 

Project Manager

PS 

Project Supervisor

QAM 

Quality Assurance Manager

RM 

Risk Manager

RE 

Requirements Engineer

RL 

Research Lead

SA 

Software Administrator

TM 

Test Manager

Other

CC 

Carbon Copy

CD 

Controlled Decentralised

CSSE 

Computer Science and Software Engineering

CGT 

Corporate Governance Toolkit

GUI 

Graphic User Interface

IEEE 

The Institute of Electrical and Electronics Engineers

RW 

Risk Wizard

SVN 

Subversion Version Control System

XML 

Extensible Markup Language

Project Organisation

---

This Chapter describes the software process model used in this project, the organisational structure adopted, roles and responsibilities for each Team member, and the organisational boundaries and structure of the Team.

Process Model

To manage project complexity and risks, the Team will adopt the Build implementation of the Incremental Model of software development. This will aid the Team to achieve its four quality goals of Correctness, Completeness, Consistency and Reliability. The client has requested a fifth quality goal of sexiness. The Build implementation involves eliciting all requirements from the Client and partitioning these into different priority levels, which will form the requirements of the different builds (Build 1 and Build 2). The builds will be tested individually and successive builds will contain the implemented requirements of the previous build. Each build is considered to be a working product.

The project will be divided into two builds. Requirements will be gathered for both builds in the requirements elicitation stage. The UD will be delivered to the Client after the delivery of the last implemented build. The Incremental Model Diagram displays the planning, implementation and testing of the first build, implementation and testing of subsequent builds, operations mode and the retirement stages of the Incremental Development Model.

Incremental Model Diagram

Organisational Structure

The Team will adopt the Control Decentralised (CD) Team structure, where the PM is responsible for the overall management of this project, delegation of tasks and monitoring of the Team’s progress (Refer to Project Manager for more details regarding the PM’s responsibilities). This will give the PM the ability to effectively manage the Team and attempt to ensure that project deliverables are ready for submission.

The CD Team structure was selected because Team members possess specialist skills that are suitable for leading subteams (i.e. Managers/Leads). Managers/Leads will be responsible for different parts of this project and will be required to manage members in their subteam. The formation of subteams allows for more effective horizontal communication between members of a subteam due their relatively small size.

Managers/Leads will be primarily responsible for providing feedback on the subteam’s progress, issues and concerns to the PM via email, or during Team or PS meetings. Individual subteam members will also be able to report directly to the PM if required or when requested by the PM. This form of reporting allows for more effective vertical communication, as it reduces the communication overhead between the PM and individual subteam members.

Personal issues or concerns regarding Managers/Leads or other Team members should be reported directly to the PM in order to reduce the probability of hostility or resentment between Team members. The PM will attempt to resolve such issues or concerns in order to ensure that progression of this project is not severely affected (Refer to Project Supervisor for processes regarding escalating issues or concerns to the PS).

Organisational Boundaries and Interfaces

The inter-organisational boundaries and interfaces of the Team describes which Team members are primarily responsible for communicating with external interfaces (Refer to Project Supervisor Communication and Course Co-ordinator Communication for more details).

EXTERNAL PERSONNEL	TEAM LIASON(S)
Project Supervisor	All Team members
Client	Client Liason Officer
Course Co-ordinator	Project Manager

Client Communication

Apart from scheduled client meetings where the communications are represented by the meetings minutes, the interface between the team and the client is performed through the Client Liaison Officer (CLO). Messages from the team will be forwarded to the CLO who will then pass this message on to the client and vice versa for messages from the client to the team. Communication between the client and the CLO will be performed by email. In the event where the CLO is unavailable, other Team members may contact the Client when necessary.

Phone communication between the client and CLO will only occur in situations which require immediate contact and confirmation. Eg. Running late to a meeting or cancelling a meeting within 24 hours of scheduled time.

Project Supervisor Communication

Team members can discuss issues or concerns regarding this project with the PS via email or during PS meetings. The PM will escalate issues or concerns that cannot be resolved internally to the PS for resolution. In addition, Team members should report issues or concerns regarding the PM directly to the PS for resolution.

Course Co-ordinator Communication

The PM is primarily responsible for contacting the Course Co-ordinator to discuss issues or concerns regarding this project and the PS. Other Team members may also contact the Course Co-ordinator.

Project Roles and Responsibilities

Refer to Sub-Team_Allocation for the breakdown of the project roles and responsibilities for each team member.

A description of the project roles and responsibilities are as follows.

Course Coordinator

1. Design and administer this course
2. Monitor and control the progress of this course
3. Arrange guest lectures and presentations
4. Develop the assessment criteria
5. Co-ordinate the assessment of project Teams
6. Develop and deliver lecture material
7. Ensure that students receive timely feedback on preliminary assessment results

Project Supervisor

1. Attend PS meetings
2. Monitor the overall progress of the Team and provide feedback via email or during PS meetings
3. Provide support and guidance to the Team regarding Team, Client, and technical issues
4. Assist the Team to develop project management strategies to control slippage
5. Review documents
6. Monitor the quality of project deliverables through audits and reviews
7. Resolve conflicts escalated by the PM or issues and concerns regarding the PM
8. Report issues and concerns to the Course Co-ordinator regarding the progress of this project if required

Client

1. Provide a suitable contact to supply the Team with requirements
2. Prioritise requirements as Core, Essential, Desirable and Optional
3. Negotiate the implementation of Essential, Desirable or Optional functions with the Team during Client meetings
4. Negotiate the addition, modification and removal of requirements with the Team during Client meetings
5. Understand the limitations of the Team’s resources and the scope of this project as defined in the SRS
6. Negotiate an appropriate meeting time and place with the CLO and attend all Client meetings
7. Provide the PS and the Team with feedback on issues or concerns regarding this project and the performance of the System
8. Provide hardware required by the System

Team Members

1. Provide assistance to other Team members when required
2. Attend work sessions, Team, relevant subteam and PS meeting unless an apology has been sent to the meeting Chairperson
3. Complete assigned tasks in dotProject and update task logs
4. Maintain contact with the subteam leaders and other Team members via email, Team or PS meetings to discuss the project’s progress and express issues and concerns for resolution
5. Identify risks that may arise throughout the course of the project and communicate these risks with the RM and the Team via email, Team or PS meeting
6. Adhere to processes in this document

Project Manager

Responsiblites shared by both PM's are:

1. Monitor activities undertaken by the Team via email, dotProject or during Team or PS meetings
2. Provide feedback to the Team and PS on the Team’s progress
3. Maintain contact with the PS by providing updates regarding the Team’s progress, issues and concerns as well as eliciting advice from the PS via email or during PS meetings
4. Write Team and PS meeting agendas and minutes
5. Chair PM, Team and PS meetings
6. Chair emergency Team and PS meetings
7. Maintain a professional working relationship with the Team, PS, Client and the Course Co-ordinator
8. Act as the first point of contact for internal issues and concerns. If these issues and concerns are unable to be resolved, they will be escalated to the PS
9. Delegate and monitor work orders using dotProject
10. Manage the project on a macro level, which involves frequent contact with the Team via email or during Team or PS meetings

Responsiblites for Tim

1. Maintain the Team’s project plan and inform the Team and PS via email or during Team or PS meetings when slippage occurs such that corrective actions can be taken
2. Monitor and provide technicial guidence for team members involved in the risk, QA and requirements subteams

Responsiblites for Stephan

1. Monitor and provide technicial guidence for team members involved in the design, implementation and testing subteams

Quality Assurance Manager

1. Checking that the quality and managerial processes in the SQAP and SPMP are being followed and devote one to two hours per week for this task
2. Email weekly summaries of processes not being followed. Should there be an internal review scheduled for a given week, then the QAM is not required to perform this weekly summary and point 1.
3. If email communication of the processes not being followed does not end in resolution by the next occurring weekly summary, then the QAM must raise the issues in the next team meeting
4. Ensuring that internal audits are completed by each team member
5. Write QA subteam meeting agendas

Client Liaison Officer

1. Act as the first point of contact for the Client
2. Write Client and requirements subteam meeting agendas
3. Organise a suitable location for all Client meetings held on campus
4. Chair regular and emergency Client meetings
5. Elicit project requirements from the Client via email or during Client meetings
6. Maintain contact with the Client via email, telephone or during Client meetings to provide updates on the Team’s progress
7. Communicate issues and concerns regarding the Client or the System to the Client via email or during Client meetings
8. Present research reports during Client meetings for feedback
9. Communicate email correspondence from the Client to the Team by forwarding all emails received from the Client to the Team’s email
10. Record important outcomes from all telephone conversations with the Client in an email to be sent to the Client and the Team
11. Maintain a professional relationship with the Client
12. Ensure all equipment provided by the Client is stored in a safe place
13. Deliver documents such as Client meeting agendas and minutes, research reports, SRS, SDD, UD and source codes to the Client electronically via email or in hard copy if requested by the Client
14. Communicate issues and concerns regarding the SRS with the PM via email or during Team or PS meetings

Design Manager

1. Analyse and communicate complex design tasks to the Team via email or during Team or PS meetings
2. Communicate technical risks to the RM and the Team via email or during Team or PS meetings
3. Identify hardware and software available for Team members to use
4. Maintain the design log to reflect important design and technical decisions made during the course of this project
5. Communicate issues and concerns regarding the SADD and SDD with the PM via email or during Team or PS meetings
6. Write the Design subteam meeting agendas

Implementation Manager

1. Delegate coding tasks
2. Monitor the development of this project’s code when Team members inform the IM via email that significant changes to the code has occurred to ensure that the System is correctly coded
3. Provide coding assistance for Team members when required
4. Write the Team’s coding guidelines and standards
5. Write the Implementation subteam meeting agendas

Risk Manager

1. Identify major risks that may arise during the course of this project
2. Monitor identified risks and conduct risk mitigation strategies in the attempt to reduce the likelihood of risks occurring
3. Conduct risk treatment strategies when risks occur in the attempt to reduce the impact on this project
4. Communicate issues and concerns regarding the RMP with the PM via email or during Team or PS meetings
5. Manage, mitigate and monitor risks using techniques and strategies stated in the RMP and various Risk Information Sheets (RIS)
6. Write the Risk Management subteam meeting agendas

Refer to the Risk Management Plan for more details regarding the responsibilities of the RM.

Testing Manager

1. Co-ordinate all testing phases
2. Train Team members to use testing tools via email or during work sessions, Team or PS meetings
3. Communicate issues and concerns regarding the TP with the PM via email or during Team or PS meetings
4. Write the Testing subteam meeting agendas

Refer to the Test Plan for more details regarding the responsibilities of the TM.

Configuration Manager

1. Ensure that directories in the SVN repository are correctly structured
2. Ensure that directories and files in the SVN repository have correct permissions
3. Train Team members to use SVN when requested via email or during work sessions, Team or PS meetings
4. Write Shell scripts and train Team members to use them when requested via email or during work sessions, Team or PS meetings
5. Perform baseline procedures when requested by the PM
6. Monitor the Team’s adherence to formal change procedures on baselined documents
7. Perform daily and weekly backups of the Team’s directory

Software Administrator

1. Perform System administration duties such as installing software that are required by Teams
2. Define formal processes for managing requests which will be placed on the Software Administrative Group (SAG) website

Research Lead

1. Co-ordinate research efforts related to the project
2. Conduct research and recommend the most appropriate technologies, tools and methodologies that should be used for this project
3. Communicate information gathered from research to the Team via email or during Team or PS meetings
4. Communicate information discovered during research to the Team, Client and PS via email or during Team, Client or PS meetings
5. Support Team members using the information discovered from research during the course of this project
6. Write the Research subteam meeting agendas

Agenda writer

1. Creating the agenda for an upcoming meeting
2. Emailing the agenda to the team email alias (and client if applicable) at least 24 hours before the meeting begins
3. Check the agenda in to the SVN repository at least 12 hours before the meeting
4. Format of the agenda must follow template found in SVN directory $GROUPSVN/templates/.

Minute taker

1. Recording the events and discussions that occur during a meeting
2. Producing minutes 48 hours after end of meeting or have at least 48 hours to produce minutes in the case of successive meetings
3. Add any decisions made during the meeting to the Decision Log
4. Check the minutes into SVN repository within 48 hours after the conclusion of the meeting
5. Minutes are to be emailed to the team email alias with the appropriate subteam email tag according to section 3.1 of the SQAP.
6. Collect any fines due and update the Fines Table on Wiki
7. Format of minutes must follow template found in SVN directory $GROUPSVN/templates/.

Document Wroter

Team member responsible for writing a component of a document.

Document Maintainer

Team member responsible for preparing a document for review, making review changes, updating the document version number and submitting the document. The role of a Document Maintainer can be delegated to other Team members at the discretion of the subteam leader or PM.

Document Responsibilities

Documents that will be delivered during this project can be written by any Team member. All documents will be maintained by one Team member.

DOCUMENT	MAINTAINER	WRITER(S)
SPMP	sptaitz and tfang	sptaitz and fang
SQAP	iwhs	azwier and iwhs
CMR	fzhan	fzhan, ymh and sptaitz
SRS	tong	tong, srib, and smhuang
SADD	jbgao	jbgao, ymh, azwier, sptaitz, fzhan, smhuang
SDD	jbgao	jbgao, ymh, azwier, sptaitz, fzhan, smhuang
PR	sptaitz and tfang	sptaitz and tfang
RMP	srib	srib, tfang, iwhs and ljjones
TP	zhl	zhl, tong, smhuang, sptaitz, tfang, iwhs
Poster	ljjones	ljjones and fzhan
UD	TBA	TBA

Managerial Process

---

This Chapter describes the Team’s management objectives and priorities, assumptions and constraints, quality assurance plan, risk management plan, review, audit and meeting procedures.

Management Objectives and Priorities

The aim of management is to ensure the project runs smoothly, and to ultimately supply the Client with a quality product that meets their requirements. To successfully achieve this aim, management intends to employ rigid managerial processes set out in further detail in the SQAP and this document. The quality of the resulting software is important, and so a high priority will be given to implementing the quality procedures, as these ultimately result in a high quality product that meets the desired functionality.

The management objectives of this project include:

1. Delivering a high quality software System on time that meets the Client's requirements (Refer to Section 9 of the SRS)
2. Producing software that satisfies or exceeds the Team’s four quality goals (Refer to Chapter 2.2 of the SQAP for more details). These quality goals include:
   1. Correctness
   2. Completeness
   3. Consistency
   4. Reliability
3. Ensuring efficient use of time and resources by adhering to processes in this document
4. Ensuring that Team members contribute meaningfully to this project so that this project experience is satisfying and memorable

Control Plan

Schedule Control

This section describes the scenario when a team member feels he is unable to finish the work that he has been assigned.

If the team member feels he cannot complete his assigned task by the deadline then the team member must email the subteam and raise the issue in the next subteam meeting. The subteam leader must reassign the task at the earliest instance.

If the time remaining is less than two days, then the team member must email the subteam and risk manager. The subteam leader will reassign the task to another team member. sending a group email detailing who is now doing the task.

NB: Changes must be made in dotProject by the original assigner to reflect any reassigning of tasks in both scenarios.

Deadline Negotiation

In the event that a previously agreed on deadline for reviews and audits will not be met, then an extension is required. This will require the following procedures provided the new deadline does not interfere with the final submission date.

Internal

To push back an internal review/audit deadline, a group email must be sent or the issue can be raised in the next team meeting. This notification must be sent at least 24 hours before the original deadline by the document maintainer.

Client

Any deadline made with the Client that the team wants to be changed will be negotiated through the CLO via email or a meeting at the Client’s request. In the event that period to deadline is less than 24 hours, then the CLO must then make phone contact with the Client to undertake negotiation. Outcomes of telephone communications must be emailed to the team email alias as a means to log such communications.

Software Quality Assurance Plan

The SQAP defines the Team’s quality goals and outlines the high level processes and practices that the Team shall adopt in order to produce a quality product (Refer to the SQAP for more details).

Quality Control Plan

Quality will be measured in terms of the following:

1. Correctness
   • Work products such as documents and code must be compared with the SRS to ensure they agree with each other.
2. Completeness
   • The output of work products must match the listed requirements. Definitions of the responses of the software must be specified. Labelling and referencing in documents of tables, figures, and diagrams must be specified always and correctly to be complete.
3. Consistency
   • Consistency is satisfied when no subset of information or requirements conflict or contradict each other.
4. Verifiable
   • Information or requirements are verifiable if there exists a process with which a person or machine can check the software product meets the requirements. Concrete terms and measurable quantities must be used as much as feasible.
5. Modifiable
   • Where structure and style are such that any changes can be made easily, completely, and consistently while retaining the structure and style.
6. Traceable
   • A work product is traceable if the origin of each of its requirements is clear and it facilitates the referencing of each requirement in future development or enhancement documentation.

Quality control mechanisms include:

1. Quality assurance of work processes
   • This will be the responsibility of the QAM to carry out the assigned responsibilities defined for the role in Quality Assurance Manager
2. Verification and validation
   • This QC mechanism will be exercised according to the Quality Control Plan
3. Reviews Reviewing procedure is defined in SQAP Section 6.2
4. Audits Auditing procedure is defined in SQAP Section 6.3

Risk management plan

Objectives

Risk management procedures will be employed and periodically revised to try to ensure that there are no unexpected events affecting the quality of the end product. Identified risks will be monitored and contingency plans will be implemented if these risks occur. It will be a priority for management, in particular the RM, to keep the RMP, RIS and other related forms up to date reflecting the risk relevant to the team.

Refer to the Risk Management Plan for more details.

Meeting Types

The following tables detail the requirements for each type of meeting.

Team Meeting

CHAIRPERSON	MINIMUM ATTENDEE	FREQUENCY
PM	Four Team members including the PM. In the event that no PM is unable to attend, the Team will choose an alternative chairperson at the start of the meeting	Monthly (more frequent if required)

Subteam Meeting

CHAIRPERSON	MINIMUM ATTENDEE	FREQUENCY
Subteam Leader	Three subteam members including the leader. In the event that the subteam leader is unable to attend, the subteam will choose an alternative chairperson at the start of the meeting	Weekly (if possible)

Project Supervisor Meeting

CHAIRPERSON	MINIMUM ATTENDEE	FREQUENCY
PM	The PS and a PM. In the event that no PM is able to attend, another Team member must attend and chair the meeting	On Request

Client Meeting

CHAIRPERSON	MINIMUM ATTENDEE	FREQUENCY
CLO	The Client, CLO and one other Team member. In the event that the CLO is unable to attend, another Team member must attend and chair the meeting	On negotiation with the Client

Task Allocation

---

Team Task Allocation

General team tasks must be assigned as follows:

1. The PM can assign general task to any team member

Subteam Task Allocation

Subteam tasks must be assigned as follows:

1. The subteam leader can assign any subteam-related task to any subteam member
2. The document maintainer can create and assign any task relating to the document that they are maintaining to any sub team member.

Task Completion

The following procedures must be followed:

1. The assigning person must update any task within 24 hours of completing the task.
2. To complete a task perform the following:
   1. Create a new log for the task in dotProject
   2. Update the progress of the task to 100%
   3. Enter the hours worked
   4. Enter a detail description of the work down in the description box

Task monitoring

Monitoring Responsibilities

1. Subteam leader must monitor all task relating the to their subteam.
2. Document maintainers must monitor all task relating to the document that they are maintaining
3. Risk Manager must monitor all tasks to prevent slippage
4. PM should keep abreast of all tasks through communication with all subteam leaders and adjust resource assignments to maximise the possiblility of meeting all task deadlines.

Extensions

Any Team member that is not going to complete their task on time must:

1. Email the person in charge of the task at least 24 hours before it is due. This email must include an request for a new complete date.
2. The manager must inform the PM and the Risk Manager of the slippage.

Slippages

All Team member must monitor their tasks and tasks assigned by them to prevent slippage. If a team can see that a task is going to slip they should follow the procedures outline in the Risk Management Plan.

This page has been accessed 972 times. This page was last modified 03:24, 8 September 2006. Content is available under Attribution-NonCommercial-ShareAlike 2.5.