Software Project Management Plan

SOFTWARE PROJECT MANAGEMENT PLAN

Applied Software Project Management, PA2406

Team 2:

QIU, YEZI

MOHAMED SAEED ELKHALIFA, ISLAM

ILYAS, BILAL

GARCÍA ÁLVAREZ, CARLOS

ALEVRAS, ELEFTHERIOS

November 29, 2011

SOFTWARE PROJECT MANAGEMENT PLAN – TEAM 2

November 29, 2011

SOFTWARE PROJECT MANAGEMENT PLAN – TEAM 2 2

Introduction ....................................................................................................................................... 4

1. Overview ..................................................................................................................................... 5

1.1. Project Summary ........................................................................................................................ 5

1.1.1. Purpose, Scope and Objectives .......................................................................................... 5

1.1.2. Assumptions and Constraints ............................................................................................ 6

1.1.3. Project Deliverables ........................................................................................................... 6

1.1.4. Schedule and Budget Summary ......................................................................................... 7

1.2. Evolution of Plan ........................................................................................................................ 7

2. References .................................................................................................................................. 8

3. Definitions .................................................................................................................................. 9

4. Project organization ............................................................................................................ 10

4.1. External interfaces .................................................................................................................... 10

4.2. Internal structure ..................................................................................................................... 10

4.3. Roles and responsibilities ......................................................................................................... 11

5. Managerial Process Plans .................................................................................................. 12

5.1. Project Start-up Plan ................................................................................................................ 12

5.1.1. Estimation Plan ................................................................................................................ 12

5.1.2. Staffing Plan..................................................................................................................... 16

5.1.3. Resource Acquisition Plan ................................................................................................ 17

5.1.4. Project Staff Training Plan ............................................................................................... 17

5.2. Work Plan ................................................................................................................................. 18

5.2.1. Work Activities ................................................................................................................. 18

5.2.2. Schedule Allocation .......................................................................................................... 22

5.3. Control plans ............................................................................................................................ 22

5.3.1. Requirements Control Plan .............................................................................................. 22

5.3.2. Schedule Control Plan ...................................................................................................... 22

5.3.3. Budget Control Plan ......................................................................................................... 23

5.3.4. Quality control plan ......................................................................................................... 23

5.3.5. Reporting plan ................................................................................................................. 24

5.3.6. Metrics collection plan ..................................................................................................... 24

5.4. Risk management plan ............................................................................................................. 24

5.5. Closeout plan ............................................................................................................................ 25

6. Technical process plans ...................................................................................................... 26

6.1. Process model .......................................................................................................................... 26

6.2. Methods, tools and techniques ................................................................................................ 26

6.3. Infrastructure plans .................................................................................................................. 27

6.4. Product acceptance plan .......................................................................................................... 27

7. Supporting process plans ................................................................................................... 28

7.1. Configuration management plan ............................................................................................. 28

7.2. Verification and validation plan ............................................................................................... 28

7.3. Documentation plan ................................................................................................................. 28


November 29, 2011


7.4. Quality assurance plan ............................................................................................................. 29

7.5. Reviews and audits ................................................................................................................... 29

7.6. Problem resolution plan ........................................................................................................... 29

7.7. Subcontractor management plan ............................................................................................ 30

7.8. Process improvement plan ....................................................................................................... 30

ANNEX I – PROJECT PLAN – GANTT CHART .......................................................................... 31


November 29, 2011


Introduction This document is a Software Project Management Plan, that is format compliant with the

IEEE 1058-1998 standard for SPMP [1].

The reader of this document should be familiar with concepts described in the Project

Management Body of Knowledge [2], in order to have a better understanding of the content

of this document.


November 29, 2011


1. Overview

1.1. Project Summary

1.1.1. Purpose, Scope and Objectives

MMS is a stand-alone application with the purpose of managing the multimedia files of its

users. More specifically, users could access any multimedia files in their computer, through

this application, after these files had been added to the application’s database. The scope of

the product includes:

Support video, audio, images and documents that belong to the following set of

formats, respectively: AVI, MP3, JPG, PDF.

Add/delete files to/from the application.

View list of files.

Open video files and audio files and allow functions, like pausing, stopping, playing

forward and rewinding.

Open PDF/JPG files.

Playlist creation/deletion.

Playlist management, i.e. add/delete/reorder files from existing playlists.

View list of files in existing playlists.

Play existing playlists.

The objectives of this product are the following:

Provide users a new level of service.

Be easy to use by providing all of its functionality from a graphical user interface

(GUI).

The purpose of this project is to develop the product with the scope, which is specified

above, and the fulfilment of this purpose will be determined by the completion of the

following set of objectives:

Completion of the product, within schedule and under budget.

Compliance of the product with the product’s requirements, even if the later change.

Achievement of as high level of satisfaction as possible from the customer.

Acquisition of experience in both managerial and technical skills, while dealing with a

would-be real world project.

The scope of the project includes:

Determining the requirements of the product.

Developing the product to meet the specified requirements.


November 29, 2011


Execute managerial process that is required for achieving the objectives of the

product.

1.1.2. Assumptions and Constraints

The following assumptions were made for this project:

The customers of this product are Bogdan Marculescu and Michael Unterkalmsteiner.

The members of the development team have sufficient technical skills to develop the

product.

One team member will quit before the completion of the project.

The resources needed for the execution of the project are already available or can be

acquired free of charge.

The product is not intended for any kind of monetary gain. However, in order to

simulate real-world situations, an illusory budget has been specified and is described

in another part of this plan.

The execution of the project will take place under the following constraints:

The customers’ approval is required for the first version of this plan, before the team

can proceed with the execution of the plan.

The entire team is expected by the customers to work in every major work package

of the project.

The deadlines are set by the customers and are firm, i.e. there is no margin for

flexibility.

There shall be no software reuse. The project starts from scratch.

The product shall be developed using the JAVA programming language. Therefore,

the platforms that will run the product are required to have installed a JVM of an

appropriate edition.

The product is intended to run on Microsoft Windows platforms.

This product shall not interact with other products.

1.1.3. Project Deliverables

The deliverables associated with the project are shown in the following table:

Deliverables Delivery date Delivery location

System Requirements Specification 2012/01/11 BTH campus

Executable Files 2012/01/11 BTH campus

User’s manual 2012/01/11 BTH campus

The SPMP will be delivered as a PDF file to the learning platform It’s learning. There are no

specific instructions regarding the packaging and handling of the other deliverables.


November 29, 2011


1.1.4. Schedule and Budget Summary

The project is scheduled to start on November 15, 2011 and end on the January 11, 2012.

For more details regarding the intermediate milestones of the project, please take a look at

the attached Gantt chart.

For this project, it has been estimated a budget of approximately 25,000 US dollars. (For

more information, please see section 5.1.1).

1.2. Evolution of Plan This plan will be updated through the software life cycle. Every team member has the ability

to make change requests, which should be accepted by the entire team, before they can

take effect.

The initial version of this plan is version 1.0. Its development has been completed on

November 16th, 2011.


November 29, 2011


2. References [1]. IEEE Std 1058-1998. IEEE Standard for Software Project Management Plans. The

Institute of Electrical and Electronics Engineers, Inc.

[2]. Adoption of PMI Standard, A Guide to the Project Management Body of Knowledge

(PMBOK® Guide). (2003). IEEE Std. 1490-2003.

[3]. Software artifact,

http://en.wikipedia.org/wiki/Artifact_%28software_development%29

[4]. Software verification and validation,

http://en.wikipedia.org/wiki/Verification_and_Validation_%28software%29

[5]. Crosby’s definition of quality, http://en.wikipedia.org/wiki/Philip_B._Crosby

http://en.wikipedia.org/wiki/Artifact_%28software_development%29

http://en.wikipedia.org/wiki/Verification_and_Validation_%28software%29

http://en.wikipedia.org/wiki/Philip_B._Crosby


November 29, 2011


3. Definitions Artifact: one of many kinds of tangible by-product produced during the development

of software, e.g. use cases, UML models, project plans, source code files [3].

BTH: Blekinge Institute of Technology (Blekinge Tekniska Högskola).

SPMP: Software Project Management Plan.


November 29, 2011


4. Project organization

4.1. External interfaces A team of BTH students, as an assignment of the course Applied Software Project

Management, develops this project. The aim of this course is to develop the skills and

experience in managing software projects. BTH is the parent organization.

The course teachers shall act as the customers of the product, on behalf of the BTH, which is,

therefore, the acquiring organization.

There shall be no subcontracted organizational entities.

There shall be no other organizational entities that interact with this project.

4.2. Internal structure Five BTH students compose the development team. No member of the team has the

technical skill to perform supporting processes, such as configuration management, quality

assurance, verification or validation.

As specified in the subclause 1.1.2 of this plan, the entire team is expected by the customers

to work in every major work package of the project.

In addition, the team is self-managed, i.e. there is no person with the authority or

managerial skills to lead the team.

However, there are some exceptions to the above statement. A person from the team has

undertaken the role of the coordinator. That team member has the extra responsibilities of

organizing meetings for the team, pose the interface between the team and external factors

and give directions by taking into consideration the will of the other members.

In the same way, for each phase of the development one person is supposed to lead the

phase, in terms of sharing his knowledge with the rest of the team in order to improve the

performance.

Communication between the team members is done through meetings, either campus

meetings or meetings through the Internet. Team members share their work online with the

software programs ‘Google Docs’ and ‘Dropbox’. Web mails services are also used for

communication purposes.


November 29, 2011


4.3. Roles and responsibilities The roles and their respective responsibilities are shown in the following table:

Role Leading person

Associated persons

Responsibilities

Project manager

Bilal Islam Eleftherios Lisa Carlos

Performs project management activities.

Software analyst

Islam Eleftherios Carlos Bilal Lisa

Elicits system requirements, reviews and verifies system requirements.

Software developer

Carlos Islam Eleftherios Bilal Lisa

Develop the product’s source code.

Software architect

Bilal

Eleftherios Islam Carlos Lisa

Design and check software architecture.

Software tester

Eleftherios Islam Bilal Carlos Lisa

Tests the system functionality, performs activities such as unit, system or integration testing.

Team coordinator

Bilal Islam Eleftherios Lisa Carlos

Arranges meetings, provides directions, interacts with external factors on behalf of the team.


November 29, 2011


5. Managerial Process Plans

5.1. Project Start-up Plan

5.1.1. Estimation Plan

In order to estimate the cost, schedule and resource requirements of the project, first of all

we will need to measure the size of the software project. We will use COSMIC Functional

Size Measurement Method, as given below:

COSMIC Functional Size Measurement Method: The COSMIC (Common Software

Measurement International Consortium) method is based on the concept of Function

Point Analysis (FPA), and is one of the most widely used methods to determine the

size of the software project. A function point is a unit of measurement to express the

amount of Functional User Requirements (FUR) in software, i.e., the software

functionality provided to the user. These FURs are analysed to identify the functional

processes. Each functional process consists of a set of data movements. Each Data

Movement (DM) is counted as one COSMIC function point (CFP).

Below we have calculated the size of the project in terms of CFPs, which are the 46 in total:

No. Functional Process Data Movement Description DM Type

CFP Total CFPs

1 Automatic files detection

User clicks on automatic files detection

Reads into default folder

Message of new files or no new files

Files stored in database

Display confirmation message

E R X W X

1 1 1 1 1

5

2 Display files list User selects 1 of 4 file categories

(i.e., video, audio, pictures, text)

Click to open

Read database records

Display files list

E E R X

1 1 1 1

4

3 Open file (play file) User clicks a file to open

Read database record

Open file

E R X

1 1 1

3

4 Delete file User clicks a file to delete

Ask for user confirmation

Delete database record and from default folder

E X W

1 1 1

3


November 29, 2011


5 Display playlists User click on “Playlists”


Display playlists “or ” no playlist message

E R X

1 1 1

3

6 Create new empty playlist

User click on create new playlist

Ask the user to enter a name

User enters the playlist name

Database updating

Display new empty playlist

E X E W X

1 1 1 1 1

5

7 Delete playlist User selects a playlist

Click to delete


Get user confirmation

Delete record from database or cancel

E E X E W

1 1 1 1 1

5

8 Adding items to playlist

User selects a file

Click (or drag) to move the file to any playlist

Database updating

Display confirmation message

E E W X

1 1 1 1

4

9 Delete items from playlist

User clicks a file in any playlist to delete


Get user confirmation

Delete database record

E X E W

1 1 1 1

4

10 Play playlist User selects a playlist

Click to play


Play

E E R X

1 1 1 1

4

11 Reordering files User clicks to reorder files

(by name, size)


Displays new order

E R X

1 1 1

3

TOTAL 43


November 29, 2011


After calculating the COSMIC Functional Points (CFPs), we will use the COCOMO method to

compute the software development effort and cost, as given below:

COCOMO (Constructive Cost Model) Method: It is an algorithmic software cost

estimation model designed for estimating effort, cost, and schedule for software

projects. COCOMO computes software development effort as a function of program

size, either in terms of Function Points or Source Lines of Code. Currently COCOMO II

is available which is better suited for estimating modern software development

projects.

Below we have estimated the software by using an online COCOMO II tool:

http://csse.usc.edu/tools/COCOMOII.php

http://csse.usc.edu/tools/COCOMOII.php


November 29, 2011


Schedule Estimation: On the basis of results acquired from the online COCOMO tool,

we can estimate the project schedule in terms of number of working days, as shown

below:


November 29, 2011


Resource Estimation: As it is already assumed that there will be 5 members in the

project team.

Cost Estimation: As in online COCOMO tool, we have assumed that salary of each

team member will be $2500 per month, so we can calculate the total amount of

salary for whole team, as shown below:

1 day salary of each member 2500 / 30 = 83.33 $

42 days salary of each member 83.33 x 42 = 3,500 $

Total salary of 5 members 3500 x 5 = 17,500 $

5.1.2. Staffing Plan

The purpose of the staffing plan is to make certain the project has sufficient staff with the

right skills and experience to ensure a successful project completion. The following human

resources will be needed to complete this project. Number of staff will remain same during

the whole project, that is 5, but their tasks will be shuffle according to their skills.

Role Project Responsibility

Skills Required Project Phase

Number of Staff

Required

Estimated Start Date

Duration Required

Source

Project Manager (Bilal)

Team leading, project monitoring and controlling, report status

Project management skills, leadership skill, interpersonal skills, presentation skills

All 1 15/11/11 42 days Applied Software Project Management Course Fellows

Software Analyst (Islam)

System and software requirements elicitation, analysis, specification, validation

Analytical skills, software documentation skills, negotiation skills, business processes understanding

Planning, Execution

2 15/11/11 42 days Applied Software Project Management Course Fellows

Software Architect (Eleftherios)

System and software architecture design, database design, interface design

Software engineering technical skills, software design skills

Planning, Execution, Monitoring & Controlling

2 15/11/11 42 days Applied Software Project Management Course Fellows

Software Developer (Carlos)

Development of standalone multimedia management application, and its deployment

Programming languages skills, software testing skills, release management skills

Execution 3 15/11/11 42 days Applied Software Project Management Course Fellows

Software Tester (Bilal)

Evaluate and test the software

Software testing skills, quality assurance skills

Execution 2 15/11/11 42 days Applied Software Project Management Course Fellows


November 29, 2011


5.1.3. Resource Acquisition Plan

The following non-human resources will be required for the project work:

Hardware Resources:

Type/Description Minimum Requirements

General purpose laptops or personal computers

Intel i3 1 GB RAM 80 GB Hard disk

Printer Black & white Laser print

Software Resources:

Name Description

Microsoft Windows Operating System 7 All the team members are already familiar.

Microsoft Office 2010 Required for documentation.

Microsoft Visio 2010 Required for diagrams drawing.

Microsoft Project 2010 Required for project management, activities management, resource management, schedule management.

Eclipse 3.7.1 IDE Eclipse IDE is an open source platform-independent software framework for application development

Java 1.6.0 Required for running Java based application.

MySQL 5.5.17 Required to build application database.

Other resources

o Internet connections

o Communication tools (e.g. skype, emails)

5.1.4. Project Staff Training Plan

5.1.4.1. Development Seminar

As it has been stated, not every member of the team is skilled in the tools and programming

languages that have been chosen to develop the system. Due to this, a development seminar

will be held, in order to provide enough proficiency to each member of the team to

contribute to the development phase.

The contents of the seminar will be:

1. Setting up the local environment

a. Java 1.6.0

b. Eclipse 3.7.1

c. MySQL 5.5.17


November 29, 2011


2. Setting up the common environment

a. Connection to online repository (SVN or Git decision pending to be done).

3. Java 1.6

a. Basics of Language

b. Basics of Swing

c. Connection to MySQL

The learning of a programming language requires extra effort by the group members, so

initiation course material will be provided for personal work. The material will be ‘Eclipse

and Java for Total Beginners’ course.

The estimated duration of the classroom lessons will be 6 hours (held in 2 days – December

12 & 13 in the Development Phase @ Increment 1), but it is important to remark that for

achieving the acceptable level of learning, extra effort with the initiation material is needed.

5.2. Work Plan

5.2.1. Work Activities

Project work activities are defined in terms of WBS (Work Breakdown Structure), as shown

on the next page:


November 29, 2011


Mu

ltim

edia

Man

agem

ent

Syst

em

1

Initiation

1.1

Project Team Kickoff Meeting

1.2

Project Overview & Scope Identification

2

Planning

2.1

Develop Software Project Management Plan

2.2

Project Plan Evaluation & Recommendations

2.3

Update Project Management Plan

3

Execution

3.1

Project Kickoff Meeting

3.2

Acquire Hardware/Software Resources

3.3

Increment-1 Workout

3.3.1

Requirements Analysis & Prioritization

3.3.2

Design

3.3.3

Development

3.3.4

Testing

3.3.5

Review Meeting

3.4

Increment-2 Workout

3.4.1

Requirements Analysis & Review

3.4.2

Design

3.4.3

Development

3.4.4

Testing & Integration

3.4.5

Review Meeting

3.5

System Deployment/Installion

4

Monitoring & Controlling

4.1

Project Management

4.2

Project Status Meetings

4.3

Risk Management

4.4

Update Project Management Plan

5

Closeout

5.1

Document Lessons Learned

5.2

Update & Archive Files/Documents

5.3

Gain Formal Acceptance


November 29, 2011


WBS Dictionary

Multimedia Management System

WBS Code Element Name Definition

1 Initiation The work to initiate the project.

1.1 Project Team Kickoff Meeting

The first meeting of the project team and the project sponsor (i.e., course responsible).

1.2 Project Overview & Scope Identification

The project team discussion regarding the overview of the project, identification of the preliminary scope of the project, and to evaluate and suggest different alternatives.

2 Planning The work for the planning process of the project.

2.1 Develop Software Project Management Plan

The development of the software project management plan with the equal participation of each member of the project team.

2.2 Project Plan Evaluation & Recommendations

The project plan evaluation and recommendations by project sponsor.

2.3 Update Project Management Plan

The updating of project plan by project team, with regard to the evaluation and recommendations suggested by project sponsor.

3 Execution The work involves executing the project.

3.1 Project Kickoff Meeting A formal kickoff meeting of the project team to discuss the project execution work.

3.2 Acquire Hardware/Software Resources

The acquisition of all the hardware and software resources needed to develop, test, and install the system.

3.3 Increment-1 Workout As system is going to be implemented in increments, and so here Increment-1 workout involves all the tasks needed to complete the first increment.

3.3.1 Requirements Analysis & Prioritization

The analysis of system requirements, and prioritization of requirements according to the importance and current understanding.

3.3.2 Design System design includes architecture design, database design, interface design.


November 29, 2011


3.3.3 Development Development is the coding phase of the system.

3.3.4 Testing This phase involves system testing with different testing techniques, e.g., code testing, functional testing, performance testing etc.

3.3.5 Review Meeting A review meeting after the Increment-1 workout, in order to discuss and evaluate the progress of the system.

3.4 Increment-2 Workout All the tasks needed to complete the second increment.

3.4.1 Requirements Analysis & Review

The requirements analysis and review for the remaining part of the system, in accordance with the earlier defined requirements.

3.4.2 Design System design may need to be modifying according to new set of system functionality and requirements.

3.4.3 Development The coding phase of the second increment.

3.4.5 Testing & Integration The testing of Increment-2 components and then integration of all the components from both increments, and testing of system as a whole.

3.5 System Deployment/Installation

System deployment and installation consists of all the activities needed to make software system for use, e.g., release management activities.

4 Monitoring & Controlling

The activities involved to monitor and control the process of the project, e.g., identifying variances from the plan, take corrective actions.

4.1 Project Management Overall project management activities to ensure the smooth and managed flow of the project.

4.2 Project Status Meetings Weekly team status meetings.

4.3 Risk Management This phase involves risk management activities as defined the Risk Management Plan, e.g., identification of potential risks, and risks response plans.

4.4 Update Project Management Plan

The updating if project management plan as the project progresses.


November 29, 2011


5 Closeout The work activities to close-out the project.

5.1 Document Lessons Learned

The project team meeting to discuss and document the lessons learned during the project.

5.2 Update & Archive Files/Documents

This phase involves updating and archiving all the files, records, and documents relating to the project.

5.3 Gain Formal Acceptance Formal acceptance of project by project sponsor.

5.2.2. Schedule Allocation

See Annex I – Project Plan – Gantt chart.

5.3. Control plans

5.3.1. Requirements Control Plan

5.3.1.1. Requirements tracing

In this project the requirements are clear and simple, we have first identified the

requirements since the customer demanded that after a preliminary discussion with the

customer, after that we will review and document the requirements and provide it to the

customer to verify it before proceeding to the next step in developing the project.

5.3.1.2. Requirements prioritization

As for prioritizing the requirements, we have already identified 2 iterations to develop the

software, based on that we will choose the prioritization strategy, the requirement will be

grouped in 2 groups with relevance to the functionality identified in each iteration, after that

a ranking of requirements will be performed on each group, we have chosen this strategy

because it is simple and effective as the requirements are not large.

5.3.1.3. Reporting

For reporting the requirements we will use SRS to document and report the requirements.

5.3.2. Schedule Control Plan

Once the project schedule is created and the project schedule is being tracked and updated,

the most challenging job of managing a project is controlling the project. The schedule

control plan will take measures to eliminate schedule delay and to ensure tasks are on time.

It includes several components:

5.3.2.1. Control Changes

To prevent the project from falling behind from defined schedule, a process for continuous

control and monitoring of needs has been implemented. Controlling project variances will


November 29, 2011


keep the project schedule accurate, detailed, and on task. Continuously refer to the

statement of work or scope will help eliminate scope creep.

5.3.2.2. Observe Performance:

Human behavior plays a very large role in controlling the project schedule as it relate to

timely task completion. The project manager, along with the team members, will have a

keen awareness of what is happening (or not happening) with the project and will be alert to

possible risks.

5.3.2.3. Follow Up

The schedule will be updated routinely. If a team member will not be available during a

normally scheduled update session, arrangements will be made to get the update earlier so

that information can be shared with the rest of the project team.

5.3.2.4. Reporting Strategy

A reporting strategy has been developed beyond the updating of the project schedule. These

status reports will include topics such as issue identification, issue resolution, decisions, or

upcoming events. These reports will be generated on weekly basis, and will be distributed to

all of the team members routinely.

5.3.3. Budget Control Plan

5.3.3.1. Cost baseline

A cost baseline is created and estimates the budget of the whole project, which mainly includes

human resources (see Subclause 5.1). Besides this, we can estimate a cost of 2,500 $ in acquiring the

hardware and software resources. Summarizing the baseline cost is estimated in 20,000 $.

5.3.3.2. Activity completion status

We have estimated our task in the estimation plan. We further break down the tasks and represent

them in the WBS. In the WBS we have work packages which define our sub tasks. We estimate the

completion of our status by comparing it with the WBS and check how much we finished our task.

5.3.4. Quality control plan

Quality control is performed on the following levels:

5.3.4.1. Life cycle model

During the second iteration, any faults that were found during the testing phase of the first

iteration will be taken into consideration and the necessary changes will take place in the

requirements, design and the source code.

5.3.4.2. Verification and validation

During the testing phase, verification and validation will be performed, in order to minimize

the risk that failures will occur to the end product. More details about verification and

validation can be found on the subclause 7.2 of this SPMP.


November 29, 2011


5.3.4.3. Project activities

During any of the project activities, either management or product oriented, each member

has the responsibility of monitoring the quality of the work. Any discrepancies shall be

reported and mitigation strategies shall be discussed during scheduled or unscheduled team

meetings.

5.3.5. Reporting plan

Reports shall be presented during scheduled meetings. In case of unforeseen contingencies,

e-mails, VoIP or file sharing shall be used.

Each member of the team has the right to file and present a report about any issue relevant

to the project. The rest of the team shall decide on the importance of the issue and solutions

shall be discussed before a final decision can be reached.

The form of reports may be in document file format, e.g. MS Word and PDF files.

Reports to external factors, e.g. the customers, shall be filed in a format and at a time

specified by those factors.

5.3.6. Metrics collection plan

The size and complexity of this project renders the need for metrics collection obsolete.

5.4. Risk management plan This subclause of the plan contains a list of identified risks. The method of dealing with risks

is team meetings to determine possible mitigation strategies. Before any such strategy can

be implemented, it shall first be evaluated and accepted by the team members.

o List or risks

The main risk the customers pose for the project is the disapproval of the project’s

scope. Depending of the degree of the customer dissatisfaction, major changes may

be required and the schedule of the project could be affected.

The relationship between the customers and the project team is very likely to be

stable. The customers’ requests are clear from the beginning of the project and they

are least likely to change.

The size of the product is relatively small and its complexity is relatively low.

Therefore, the SPMP is not likely to be affected by problems occurring due to the

product’s size or complexity.

The development environment is new to some members of the team. However, the

team members are experienced with development environments and, thus, are

familiar with their basic functionality. Learning to use the target development

environment, which is the IDE Eclipse, is unlikely to incur extra cost in time, for the

purpose of learning how to use it.


November 29, 2011


The product shall be developed for the Windows operating system. It is unlikely that

the underlying technologies will change so dramatically, during the execution of the

project, that the product will be rendered useless or have to change considerably to

meet new technological requirements.

The customers have formed the team. Therefore, the team formation poses no risk

to the execution of the project. The customers assured the team that the team

formation is final. It is most unlikely that this decision will change.

The diversity of the team is an important risk. Each team member has very different

background knowledge and experience. As a result, understanding of common issues

may differ from member to member. This can result in some members devoting a lot

of effort, but without quality results. It is therefore acknowledged that, more time

may be wasted for communication reasons than the respective time that would be

required in a homogeneous team.

Risks related to schedule are apparent, for a variety of reasons. The team has no

prior experience in managing projects. In addition, the skill levels of the team

members are different. That means that time is likely to be spent on learning from

each other, so that all members can contribute to all phases of the project.

Risks related to budget are very low. As mentioned in the subclause 1.1.2 of this plan,

all software shall be acquired for free. For this reason, the expenses from the team

are not likely to rise. The computer systems the team is using have already been

purchased and, so, they are not likely to change, unless the computer of a member

breaks down.

To sum up, the main risks that can affect the project are the scope acceptance by the

customers and the communication between the team.

5.5. Closeout plan The project is executed on the context of a master program course. Therefore, it has a

strong educational character. As a result, the documentation of lessons learned during the

project execution is most important.

In addition, all artifacts created for the project shall be archived by each team member for

future reference and use.

Finally, the closing of the project includes a project review on 2012/01/17, for the purpose of

gaining formal acceptance of the product.


November 29, 2011


6. Technical process plans

6.1. Process model This project will use a hybrid incremental/iterative model. More specifically, there shall be

two iterations. The second iterations will both expand and improve the functionality of the

software produced during the first iteration.

Iterations are used for the purpose of dealing with any faults or problems that occur during

the development process.

During each iteration, the waterfall model shall be followed. The waterfall has been selected,

because the requirements are not likely to change and because applications, such as the

product of this project, already exist. Therefore, the requirements of such an application are

well understood by the project team.

The following figure shows the major phases of the model:

6.2. Methods, tools and techniques The development paradigm that shall be used for the development of this product is Object

Oriented Programming.

The programming language that shall be used is Java.

Eclipse shall be used as the IDE of the development process. Eclipse plug-ins should be used

for increased performance of the development team, or for testing (JUnit).

The tool UMLet shall be used for software analysis and design.

The Microsoft Office suite will be used for document and report development.

The Microsoft Project shall be used for plan development.


November 29, 2011


6.3. Infrastructure plans The project shall be developed on MS Windows Vista or 7 operating systems.

The Internet shall be used as the main media of communication.

There are no standards or policies that the project team has agreed on.

The workspace shall mostly be the facilities provided by BTH and the team members’ private

space.

6.4. Product acceptance plan The customers have agreed to provide feedback on the scope of the project within a few

days after this plan’s submission, i.e. a few days after 2011/11/16.

A review meeting shall also take place between the customers and the project team, during

the period 2011/11/28 – 29. After that meeting, the customers’ approval on the products is

expected.

The customers’ level of satisfaction shall be determined on the project presentation, on

2012/01/11 and on the project review meeting on 2012/01/17.

The customers have not provided acceptance criteria. Therefore, the team shall consider as

acceptance criteria the conformance to the products requirements, once the approval of the

scope has been obtained.


November 29, 2011


7. Supporting process plans

7.1. Configuration management plan There is no member in the team that has the technical skills to apply configuration

management. Therefore, all changes will be handled based on the following procedure:

1. A member of the team identifies, documents and propagates the reasons for change

in one or more artifacts to the rest of the team.

2. The team accepts/rejects the change.

3. If the team has accepted the change, it shall be performed by making the necessary

resource reallocations.

This procedure may also be subject to change, for the better accommodation of the team’s

needs.

The only tools that may be used for the configuration management are documenting tools,

such as Microsoft Word. No automated tools will be used for configuration management.

7.2. Verification and validation plan Software verification and validation is the process of checking that a software system meets

specifications and that it fulfils its intended purpose [4]. It shall be performed as part of the

testing process.

The different methods that shall be used are:

Method Process Tool

Boundary Value Analysis validation N/A

Static Analysis verification JUnit

The lifecycle of the product development will include two iterations. During the second

iteration, the results of verification and validation will be considered, in order to improve the

quality of the end product.

7.3. Documentation plan

Non-deliverable documents:

Document Prepared by Reviewed by

UML models Software designers Project team

Test plan Software testers Project team

Moments of meeting Project coordinator Project team

Project management plan Project team Project team

Source code Software developers Project team


November 29, 2011


Deliverable documents

Document name Prepared by Reviewed by

SRS Requirement analysts Project team

Executable Files Software developers Project team

User manual Requirement analysts Project team

7.4. Quality assurance plan The definition of quality that shall be used for the needs of this project is the definition that

Philip B. Crosby provided:

Quality is conformance to requirements. [5]

Therefore, quality assurance is equivalent to validation in this project. Validation will be

performed as parting of the testing process, as mentioned in the subclause 7.2 of this plan.

7.5. Reviews and audits

Date of review/audit Parties involved Purpose

2011/11/28-29 Customers, Project team Review meeting (more details available on 2011/11/21)

2011/12/16 Project team Presentation of results from increment 1. Discussion for increment 2.

2011/12/29 Project team Presentation of results from increment 2.

2012/01/11 Customers, Project team Project presentation (more details available on 2011/12/13)

2012/01/17 Customer, Project team Project review

7.6. Problem resolution plan

The method for problem resolution is described by the following steps:

1. Every team member has the responsibility to identify problems, document the problems and report them to the rest of the team during scheduled or unscheduled review meetings.

2. During these meetings, the importance of the problems will be taken into consideration and corrective actions may be decided by the project team.

3. Log files will be used to archive problems, along with their significance and corrective actions taken.

The tools that shall be used for reporting the problem are e-mail and the software Skype. The documentation of the problem shall be performed using a program of Microsoft Office suite.


November 29, 2011


The software Dropbox and Google Docs shall be used for sharing accepted solutions to the occurring problems.

7.7. Subcontractor management plan

The project size and complexity render the need for a subcontractor plan obsolete. Therefore, there shall be no subcontractor plan.

7.8. Process improvement plan The level of maturity for the development process of this project is very low and the team

has been assembled only for the duration of this project. Therefore, a process improvement

plan is unnecessary for this project.

Suggestions for improvement may be compiled as part of the lessons learned, while

executing this project. However, there is no plan for compiling a report on the software

process, regarding potential ways of improving it.

ANNEX I – PROJECT PLAN – GANTT CHART

Software Project Management Plan

Documents

Transcript of Software Project Management Plan