Software Project Management Plan

(1)

Software Project Management Plan

Julie Makelberge

[email protected] November 3, 2010

Version Date Author Comment 1.0 02/11/2010 Julie Initial version 1.1 03/11/2010 Kevin Revision

(2)

1 Overview

1.1 Project Summary

1.1.1 Purpose, scope and objectives

Introducing the real world to be complement with the virtual universe of games calls for a whole new level of gaming experience. In this project, a game will be developed that uses QR tags, spread in the real world, that the player can use to gather information about the current location, being the particular place where the tag is found. This principle of finding QR tags and gathering information will be used to introduce goals in the game. To create a game session, the player will be given two sets of templates: one for interactive, scenic routes and one for competitive games where players race through way points, marked by the QR tags. If wished for, players can introduce their own rules for custom competitive games.

The requirements are based on the official statement. Functional Requirements

Finding and selecting a game

• requesting the existing possible games

• filtering games based on their name or properties (e.g. Atomium, Empire State Building)

• Detailed description of a selected game, stating duration time, location, etc

• social ranking of games

Playing Games

• Starting and ending game with QR tag

• Possibility of reviewing a played game

• Possibility to publish your progress

Creating Games

• Templates for scenic routes

• Templates for competitive gaming

(4)

Non-Functional Requirements

• The system must work on Linux and a web container like Tomcat

• The design must be modular so extensions and replacements of components will be easy

• The web interface must be simple, attractive and standard (CSS, XHTML)

• A service interface (using REST or SOAP) is an interesting extension

• Probable languages are C++, Java, Python, possibly extended with libraries. Only free software can be used as well as for the end product as for the resources. The choice of a certain library or recourse needs to be justified by reliability, being open and simplicity. A free library can only be used for certain (sub)components after authorisation of the client and a comparative study of what is available. The study is a part of the project documents and needs to be a part of the configuration management. It also needs to be available on the website. Frameworks are not allowed for non-technical reasons

• The system needs to be able to be installed easily on a standard machine

• The system will be demonstrated on the wilma server

Requirements concerning the process

• All documents (and code) need to be in English

• Documents need to be available in pdf format

• All code needs to be documented by the usual resources like javadoc, doxygen, etc

• A repository needs to be used for ’configuration management’. The repository needs to be available on the website. Eventually a subversion can be used. In that case the repository also needs to be available on the website

• A test automation tool for the framework needs to be used

• At least these documents need to be maintained: 1. Software Project Management Plan (SPMP) 2. Software Quality Assurance Plan (SQAP)

3. Software Configuration Management Plan (SCMP) 4. Software Test Plan (STD)

5. Software Requirements Specification (SRS) 6. Minutes of all meetings

(5)

• The use of a project management tool is mandatory as well. This tool needs to be able to show for each team member what his/her function is, how much time was planned for a task and how much time was actually spend for a task. The client needs to be able to access this particular tool.

• All documents need to be publicly available on the website of the group at all times.

1.1.2 Assumptions, dependencies and constraints

No assumptions are made concerning the project. The project is completely dependent on the motivation and work of the team members. Therefore good communication is necessary. There is a constraint on the available work hours since every team member has other courses to attend to and other projects to spend time on. Another constraint is that there is no financial budget, so all used software should be free and/or open-source. The last constraint is that the program needs to run on Linux as well as on the Wilma server.

1.1.3 Project Deliverables

The required documents are:

• SPMP • SCMP • SRS • SDD • SQAP • STD • Minutes of meetings

2 References

- Requirements document

- Software engineering course - WE-DINF-6537 Rachnild Van Der Straeten - Eric J. Braude - Software Engineering, An Object-Oriented Perspective

(6)

3 Definitions

SPMP Software Project Management Plan SCMP Software Configuration Management Plan SRS Software Requirement Specification

SDD Software Design Document

SQAP Software Quality Assurance Plan STD Software Test Plan

CM Configuration Management VUB Vrije Universiteit Brussel

4 Project Organisation

4.1 Process model

The chosen process is the spiral model with four iterations. With this model the most risky problems are identified and handled with in the beginning of the project. This gives the project a very high chance of success. Also it becomes clear early on in the process whether some parts of the project are unrealisable. Unlike the waterfall process, after each iteration, prototypes are made and can be evaluated by the client in order to reduce risks.

4.2 Project Organisation 4.2.1 External Interfaces

The professor (Ragnild Van Der Straeten) will act like the stakeholder in this project and can be reached through mail. Frequent SCRUM meetings will be held after each iteration.

4.2.2 Internal Structure

The project consists of a group of peers with following roles: Project Manager, Con-figuration Manager, Quality Assurance Manager, Web-master, Requirements Manager, Design Manager, Implementation Manager and Secretary.

(7)

4.2.3 Roles and Responsibilities Project Manager

• responsible for the SPMP

• responsible for the contact with the professor

• approves timesheets

• responsible for the agenda

• approves the documents

• keeps the SPMP up-to-date

• approves decisions

Configuration Manager

• responsible for the SCMP

• Install and maintain used tools

• Make back-ups of all project documents

• Manage revision control system

• Keeps the SPMP up to date

Quality Assurance manager

• Responsible for the SQAP

• Responsible for the consistency of the documents

• Responsible for the quality of the deliverables

• Decides the coding conventions

• Keeps the SQAP up to date

Web-master

• develops and maintains the project website

(8)

Requirements Manager

• responsible for the SRS

• verifies if the requirements are correctly implemented

• looks for extra functional requirements

• presents final requirements to the customer

Design Manager

• responsible for the SDD

• verifies if the SDD is correctly followed

• design and maintenance of the database

• verifies if the implementation is consistent with the SDD

Implementation Manager

• responsible for the integration of the different parts of the code

• assigns implementation tasks

• track errors

• responsible for the testing of the code

• responsible for the STD

Secretary

• responsible for the minutes of meetings

(9)

5 Managerial process plans

5.1 Start-up plan 5.1.1 Staffing plan

Each staff member will be needed for the entire duration of the project and will be all responsible for a part of the implementation. Hiring has been done by the professor. This table shows who will be responsible for which role. The secretary role will passed on every meeting.

Name Role

Julie Makelberge Project Manager Jasper Maes Configuration manager Kevin De Valck Quality Assurance Manager

David Bos Web-master, Requirements Manager David Blinder Design Manager

Jesse Zaman Implementation Leader 5.1.2 Project staff training plan

If a member of the team lacks experience or knowledge on a certain subject and can not work on it by himself, peer-to-peer training will be given. The member with the most knowledge concerning the subject will be assigned to train this individual. Such training will be given as follows: presentations, tutorials, workshops, consultations,

(10)

5.3 Control Plan

5.3.1 Requirements control plan

Requirements shall be described in the projects SRS and will be regularly checked on by the requirements manager.

5.3.2 Schedule control plan

All members of the team will be responsible for checking whether the schedule is main-tained and should report to the project manager if this is not the case. This way the schedule can be modified and arrangements can be made. The milestones do not only consist of the implementation but also of unit testing and correct commenting of the code.

5.3.3 Reporting plan

Initial documents will be sent to the quality assurance manger for checking and then to the project manager for a final revision. All documents will be put on the website as soon as the project manager has approved of it. External documents supplied by the course can be found on the course website. Other external documents will be published on the site. Each meeting shall be reported and the minutes will be published at least 24h before the next meeting on the website.

5.4 Risk management plan

Localising risks is essential for the completion of the project. That’s why it must start at the beginning of the project and be continued during the course of the project. If a team member identifies a risk, it must be notified to the project manager immediately, so the effect and the chance of the risk can be evaluated and can be put in the SPMP.

• Poor communication

Communication is essential in a team project. That is why certain measures have been taken. Bi-weekly meetings have been set up to share ideas, make remarks and discuss risks. A forum has been put up on the website to be able to discuss issues between meetings. All contact information has been exchanged at the first meeting and there is a mailing list for the project.

• Lack of knowledge on the programming languages

If a team member lacks knowledge on a programming language, peer-to-peer train-ing will be used.

• Misunderstandings about requirements

(11)

That is why prototypes will be showed to the client after each iteration so adjust-ments can be made if necessary.

• Missed deadlines

Missed deadlines will also make the project fail. That is why good arrangements need to be made and the progress of every member needs to be followed up.

• Sickness or a team member giving up

For this reason we have appointed a back-up for each function.

• Loss of data

To avoid this, the configuration manager will back-up weekly.

6 Technical process plans

6.1 Process model

The project is organised according to the spiral model consisting of 4 iterations. Each iteration consists of 4 parts. First the system requirements are defined as detailed as possible, then a design is made so all the possibilities are analysed. Once the design is completed, the implementation phase starts. Here a prototype is made for the customer. Finally the implementation gets thoroughly tested. We have chosen for the spiral model because it fits our needs best. The agile process was another possibility because of his flexibility but it requires a very regular work schedule and it is impossible to fit into all of our schedules.

6.2 Methods, tools and techniques

Each member can choose how to make his documents. The Quality Assurance manager will receive the documents and put them in the correct lay-out and will provide the necessary formats. PHP will be used as the main programming language. Should it prove to be inadequate, a change to Ruby will be made.

(12)

7 Supporting process plans

7.1 Configuration management plan

The configuration management plan is the responsibility of the configuration manager and will be available on the website at all times.

7.2 Verification and validation plan

The verification and validation plan (STD) is the responsibility of the implementation leader. It will be available on the website. Verification shall occur by unit testing and full scale testing.

7.3 Documentation plan

All documents will be available in LaTeX format and pdf format. The consistency in lay-out is the responsibility of the quality assurance manager.

7.4 Quality assurance plan

The quality assurance plan is the responsibility of the quality assurance manager. It will be available on the website.

Software Project Management Plan

Software Project Management Plan

Contents

1

Overview

2

References

3

Definitions

4

Project Organisation

5

Managerial process plans

6

Technical process plans

7

Supporting process plans