Software Project Management Plan

SOFTWARE SOFTW ARE PROJECT MANAGEMENT PLAN PLA N Applied Software Project Project Management, PA2406

Team 2:

SOFTWARE PROJECT MANAGEMENT PLAN – TEAM 2 November 29, 2011

Introduction ............................................................... ....................................................................................................................................... ........................................................................ 4 1. Overview ............................................................. ..................................................................................................................................... ........................................................................ 5 1.1. Project Summary ........................................................... ........................................................................................................................ ............................................................. 5 1.1.1.

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

1.1.2.

Assumptions and Constraints 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................................................ Plan..................................................................................................................... ..................................................................... 16


Introduction ............................................................... ....................................................................................................................................... ........................................................................ 4 1. Overview ............................................................. ..................................................................................................................................... ........................................................................ 5 1.1. Project Summary ........................................................... ........................................................................................................................ ............................................................. 5 1.1.1.

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

1.1.2.

Assumptions and Constraints 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................................................ Plan..................................................................................................................... ..................................................................... 16


7.4. 7.5. 7.6. 7.7. 7.8.

Quality assurance plan .............................................................. ............................................................................................................. ............................................... 29 Reviews and audits ......................................................... ................................................................................................................... .......................................................... 29 Problem resolution plan ............................................................ ........................................................................................................... ............................................... 29 Subcontractor management plan ...................................................................... ............................................................................................ ...................... 30 Process improvement plan...................................................................... ....................................................................................................... ................................. 30

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


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.


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.

SOFTWARE PROJECT MANAGEMENT PLAN – TEAM 2 November 29, 2011 

1.1.2.

Execute managerial process that is required for achieving the objectives of the product. 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.


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.


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


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.


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.


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

Performs project management activities.

Software analyst

Islam

Software developer

Carlos

Software architect

Bilal

Islam Eleftherios Lisa Carlos Eleftherios Carlos Bilal Lisa Islam Eleftherios Bilal Lisa Eleftherios Islam Carlos Lisa

Elicits system requirements, reviews and verifies system requirements.

Develop the product’s source code.

Design and check software architecture.


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:


5

Display playlists

E R X

1 1 1

3

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

User selects a playlist Click to delete Ask for user confirmation Get user confirmation Delete record from database or cancel

E E X E W

1 1 1 1 1

5

User selects a file Click (or drag) to move the file to

E E

1 1

4



User click on “Playlists”



Read database records



Display playlists “or ” no playlist

message 6

Create new empty playlist

    

7

Delete playlist

    

8

Adding items to playlist




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



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:

5.1.2.

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 $

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


5.1.3.

Resource Acquisition Plan

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

Hardware Resources:

Type/Description General purpose computers

Minimum Requirements laptops

or

personal

Printer 

Intel i3 1 GB RAM 80 GB Hard disk Black & white Laser print

Software Resources:

Name Microsoft Windows Operating System 7 Microsoft Office 2010 Microsoft Visio 2010 Microsoft Project 2010

Eclipse 3.7.1 IDE

Description

All the team members are already familiar. Required for documentation. Required for diagrams drawing. Required for project management, activities management, resource management, schedule management. Eclipse IDE is an open source platform-


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


1 Initiation

1.1 Project Team Kickoff Meeting 1.2 Project Overview & Scope Identification 2.1 Develop Software Project Management Plan

2 Planning

2.2 Project Plan Evaluation & Recommendations 2.3 Update Project Management Plan 3.1 Project Kickoff Meeting 3.2 Acquire Hardware/Software Resources

t n e m e g a n a m e

3.3.1 Requirements Analysis & Prioritization 3.3.2 Design

3.3

3.3.3

Increment-1 Workout

Development

3.3.4 Testing

3 Execution

3.3.5 Review Meeting


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.

SOFTWARE PROJECT MANAGEMENT PLAN – TEAM 2 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.


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. 5.3.1.1.

Requirements Control Plan Requirements tracing

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


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.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.










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


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.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 th is 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.


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


Deliverable documents

Document name SRS Executable Files User manual

Prepared by

Reviewed by

Requirement analysts Software developers Requirement analysts

Project team Project team 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 2011/11/28-29

Parties involved

Purpose

Customers, Project team

Review meeting (more available on 2011/11/21)

details


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.

Software Project Management Plan

Recommend Documents