SOFTWARE PROJECT MANAGEMENT PLAN

Applied Software Project Management, PA2406

Team 2: QIU, YEZI MOHAMED SAEED ELKHALIFA, ISLAM ILYAS, BILAL GARCA LVAREZ, CARLOS ALEVRAS, ELEFTHERIOS

November 29, 2011

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 ............................................................................................ 6 1.1.3. Project Deliverables ........................................................................................................... 6 1.1.4. Schedule and Budget Summary ......................................................................................... 7 1.2. Evolution of Plan ........................................................................................................................ 7

2. 3. 4.
4.1. 4.2. 4.3.

References .................................................................................................................................. 8 Definitions .................................................................................................................................. 9 Project organization ............................................................................................................ 10

External interfaces.................................................................................................................... 10 Internal structure ..................................................................................................................... 10 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.
6.1. 6.2. 6.3. 6.4.

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

Process model .......................................................................................................................... 26 Methods, tools and techniques................................................................................................ 26 Infrastructure plans .................................................................................................................. 27 Product acceptance plan .......................................................................................................... 27

7.
7.1. 7.2. 7.3.

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

Configuration management plan ............................................................................................. 28 Verification and validation plan ............................................................................................... 28 Documentation plan................................................................................................................. 28

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 2

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 November 29, 2011

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

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 3

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

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 4

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

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 5

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 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 System Requirements Specification Executable Files Users manual Delivery date 2012/01/11 2012/01/11 2012/01/11 Delivery location BTH campus BTH campus BTH campus

The SPMP will be delivered as a PDF file to the learning platform Its learning. There are no specific instructions regarding the packaging and handling of the other deliverables.

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 6

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

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 7

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 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]. Crosbys definition of quality, http://en.wikipedia.org/wiki/Philip_B._Crosby

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 8

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 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 Hgskola). SPMP: Software Project Management Plan.

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 9

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

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 10

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 November 29, 2011

4.3. Roles and responsibilities

The roles and their respective responsibilities are shown in the following table: Role Project manager Leading person Bilal Associated persons Islam Eleftherios Lisa Carlos Eleftherios Carlos Bilal Lisa Islam Eleftherios Bilal Lisa Eleftherios Islam Carlos Lisa Islam Bilal Carlos Lisa Islam Eleftherios Lisa Carlos Responsibilities Performs project management activities.

Software analyst

Islam

Elicits system requirements, reviews and verifies system requirements.

Software developer

Carlos

Develop the products source code.

Software architect

Bilal

Design and check software architecture.

Software tester

Eleftherios

Tests the system functionality, performs activities such as unit, system or integration testing. Arranges meetings, provides directions, interacts with external factors on behalf of the team.

Team coordinator

Bilal

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 11

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 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 1 Automatic files detection Data Movement Description 2 Display files list 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 User selects 1 of 4 file categories (i.e., video, audio, pictures, text) Click to open Read database records Display files list User clicks a file to open Read database record Open file User clicks a file to delete Ask for user confirmation Delete database record and from default folder DM Type E R X W X CFP Total CFPs 1 5 1 1 1 1

E E R X E R X E X W

1 1 1 1 1 1 1 1 1 1

Open file (play file)

Delete file

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 12

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 November 29, 2011

Display playlists

User click on Playlists Read database records Display playlists or no playlist message User click on create new playlist Ask the user to enter a name User enters the playlist name Database updating Display new empty playlist User selects a playlist Click to delete Ask for user confirmation Get user confirmation Delete record from database or cancel User selects a file Click (or drag) to move the file to any playlist Database updating Display confirmation message User clicks a file in any playlist to delete Ask for user confirmation Get user confirmation Delete database record User selects a playlist Click to play Read database records Play User clicks to reorder files (by name, size) Read database records Displays new order

E R X

1 1 1

Create new empty playlist

E X E W X E E X E W

1 1 1 1 1 1 1 1 1 1

Delete playlist

Adding items to playlist

E E W X

1 1 1 1

Delete items from playlist

E X E W

1 1 1 1

10

Play playlist

E E R X E R X

1 1 1 1 1 1 1

11

Reordering files

TOTAL 43

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 13

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

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 14

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

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 15

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 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 42 days salary of each member Total salary of 5 members 2500 / 30 = 83.33 x 42 = 3500 x 5 = 83.33 $ 3,500 $ 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 Team leading, project monitoring and controlling, report status Skills Required Project Phase All Number of Staff Required 1 Estimated Start Date 15/11/11 Duration Required 42 days Source

Project Manager (Bilal)

Software Analyst (Islam)

System and software requirements elicitation, analysis, specification, validation System and software architecture design, database design, interface design Development of standalone multimedia management application, and its deployment Evaluate and test the software

Software Architect (Eleftherios)

Project management skills, leadership skill, interpersonal skills, presentation skills Analytical skills, software documentation skills, negotiation skills, business processes understanding Software engineering technical skills, software design skills Programming languages skills, software testing skills, release management skills Software testing skills, quality assurance skills

Applied Software Project Management Course Fellows

Planning, Execution

15/11/11

42 days

Applied Software Project Management Course Fellows Applied Software Project Management Course Fellows Applied Software Project Management Course Fellows Applied Software Project Management Course Fellows

Planning, Execution, Monitoring & Controlling Execution

15/11/11

42 days

Software Developer (Carlos)

15/11/11

42 days

Software Tester (Bilal)

Execution

15/11/11

42 days

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 16

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 November 29, 2011 5.1.3. Resource Acquisition Plan The following non-human resources will be required for the project work: Hardware Resources: Minimum Requirements personal Intel i3 1 GB RAM 80 GB Hard disk Black & white Laser print

Type/Description General purpose computers Printer

laptops

or

Software Resources: 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 platformindependent software framework for application development Required for running Java based application. Required to build application database.

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

Eclipse 3.7.1 IDE

Java 1.6.0 MySQL 5.5.17

Other resources o Internet connections o Communication tools (e.g. skype, emails) Project Staff Training Plan

5.1.4.

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

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 17

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

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 18

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 November 29, 2011

1.1 Project Team Kickoff Meeting 1 Initiation 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 3.3 Increment-1 Workout 3.3.1 Requirements Analysis & Prioritization 3.3.2 Design

3.3.3 Development

3.3.4

Multimedia Management System

Testing

3 Execution

3.3.5 Review Meeting 3.4.1 Requirements Analysis & Review 3.4.2 Design

3.4 Increment-2 Workout

3.4.3 Development

3.5 System Deployment/Installion

3.4.4 Testing & Integration

4.1 Project Management

3.4.5 Review Meeting

4.2 Project Status Meetings 4 Monitoring & Controlling 4.3 Risk Management 4.4 Update Project Management Plan 5.1 Document Lessons Learned 5.2 Update & Archive Files/Documents 5.3 Gain Formal Acceptance

5 Closeout

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 19

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 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 Project Overview & Scope Identification The first meeting of the project team and the project sponsor (i.e., course responsible). 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. The work for the planning process of the project. The development of the software project management plan with the equal participation of each member of the project team. The project plan evaluation and recommendations by project sponsor. The updating of project plan by project team, with regard to the evaluation and recommendations suggested by project sponsor. The work involves executing the project. A formal kickoff meeting of the project team to discuss the project execution work. The acquisition of all the hardware and software resources needed to develop, test, and install the system. 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. The analysis of system requirements, and prioritization of requirements according to the importance and current understanding. System design includes architecture design, database design, interface design. SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 20

1.2

2 2.1

Planning Develop Software Project Management Plan Project Plan Evaluation & Recommendations Update Project Management Plan

2.2

2.3

3 3.1

Execution Project Kickoff Meeting

3.2

Acquire Hardware/Software Resources Increment-1 Workout

3.3

3.3.1

Requirements Analysis & Prioritization

3.3.2

Design

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 November 29, 2011 3.3.3 3.3.4 Development Testing Development is the coding phase of the system. This phase involves system testing with different testing techniques, e.g., code testing, functional testing, performance testing etc. A review meeting after the Increment-1 workout, in order to discuss and evaluate the progress of the system. All the tasks needed to complete the second increment. The requirements analysis and review for the remaining part of the system, in accordance with the earlier defined requirements. System design may need to be modifying according to new set of system functionality and requirements. The coding phase of the second increment. The testing of Increment-2 components and then integration of all the components from both increments, and testing of system as a whole. System deployment and installation consists of all the activities needed to make software system for use, e.g., release management activities. The activities involved to monitor and control the process of the project, e.g., identifying variances from the plan, take corrective actions. Overall project management activities to ensure the smooth and managed flow of the project. Weekly team status meetings. This phase involves risk management activities as defined the Risk Management Plan, e.g., identification of potential risks, and risks response plans. The updating if project management plan as the project progresses. SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 21

3.3.5

Review Meeting

3.4

Increment-2 Workout

3.4.1

Requirements Analysis & Review

3.4.2

Design

3.4.3 3.4.5

Development Testing & Integration

3.5

System Deployment/Installation

Monitoring & Controlling

4.1

Project Management

4.2 4.3

Project Status Meetings Risk Management

4.4

Update Project Management Plan

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 November 29, 2011

5 5.1

Closeout Document Lessons Learned Update & Archive Files/Documents Gain Formal Acceptance

The work activities to close-out the project. The project team meeting to discuss and document the lessons learned during the project. This phase involves updating and archiving all the files, records, and documents relating to the project. Formal acceptance of project by project sponsor.

5.2

5.3

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

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 22

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 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. 5.3.3.1. Budget Control Plan 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.

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 23

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

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 24

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

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 25

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

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

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 27

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 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 teams 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 Boundary Value Analysis Static Analysis Process validation verification Tool N/A 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: Prepared by Software designers Software testers Project coordinator Project team Software developers Reviewed by Project team Project team Project team Project team Project team Document UML models Test plan Moments of meeting Project management plan Source code

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 28

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 November 29, 2011 Deliverable documents Prepared by Requirement analysts Software developers Requirement analysts Reviewed by Project team Project team Project team

Document name SRS Executable Files User manual

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 2011/12/16 Parties involved Customers, Project team Project team Purpose Review meeting (more details available on 2011/11/21) Presentation of results from increment 1. Discussion for increment 2. Presentation of results from increment 2. Project presentation (more details available on 2011/12/13) Project review

2011/12/29 2012/01/11 2012/01/17

Project team Customers, Project team Customer, Project team

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

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

SOFTWARE PROJECT MANAGEMENT PLAN TEAM 2 30

ANNEX I PROJECT PLAN GANTT CHART