2014 Software Project Management Plan TU/E OPEN ACCEL
Abstract This is the Software Project Management Plan (SPMP) for the Open Accel Software Engineering Project. This document is based on the ESA standard for software development. This document provides an overview of the organizational structure and required resources of the project. The SPMP is used to keep track of the planning and to assure that deadlines are met.
Contents Abstract... 1 Document Status Sheet... 4 Document status overview... 4 General... 4 Document History... 4 Chapter 1. Introduction... 5 1.1 Project Overview... 5 1.2 Project Deliverables... 5 1.3 Evolution of the SPMP... 5 1.4 List of definitions... 6 1.5 List of references... 6 Chapter 2 Project Organization... 8 2.1 Process Model... 8 2.2 Organizational structure... 8 2.3 Boundaries and interfaces... 9 2.4 Project responsibilities... 10 2.4.1 Project Manager (PM)... 10 2.4.2 Quality Manager (QM)... 10 2.4.1 Configuration Manager (CM)... 10 2.4.2 Team Leader... 10 2.4.3 Development Team Member... 11 2.4.4 Scrum Master... 11 2.4.5 Product Owner... 11 Chapter 3 Managerial Process... 12 3.1 Objectives and priorities... 12 3.2 Assumptions, dependencies and constraints... 12 3.3 Risk management... 12 3.4 Monitoring and controlling mechanisms... 13 3.4.1 Daily Scrum... 13 3.4.2 Sprint Planning Session... 14 3.4.3 Sprint Demo... 14 3.4.4 Sprint Retrospective... 14
3.4.5 Project metrics... 14 3.5 Staffing plan... 14 Chapter 4 Technical Process... 16 4.1 Methods, tools and techniques... 16 4.2 Software documentation... 16 4.3 Project support functions... 16 Chapter 5 Work packages, schedule, budget... 17 5.1 Work packages... 17 5.2 Dependencies... 17 5.3 Resource requirements... 17 5.4 Budget and resource allocation... 17 5.5 Schedule... 17 5.5.1 Deadlines... 17 5.5.2 Hour planning... 17 5.5.3 Unavailability overview... 17 Appendix A User Requirements Phase... 18 A.1 Output UR Phase... 18 A.2 Work packages UR phase... 18 A.3 Budget and resource allocation UR phase... 18
Document Status Sheet Document status overview General Document title: Identification: Author: Document status: Software Project Management Plan SPMP0.1pdf Erikos Alkalai Draft Document History Version Date Author Reason of change 0.1 05/06/2014 E.Alkalai Document initialization
Chapter 1. Introduction 1.1 Project Overview The project group is one of five project groups for the course called "Software Engineering Project". The group consists of nine students from the Eindhoven University of Technology. The objective of the project is to make a general purpose modeling environment, called OpenACCEL, to be used in the Bachelor Course "Modeling". OpenACCEL will allow students to create models of mainly physical objects. Met opmerkingen [EA1]: Include Project Overview The project deadline is June 27th, 2014. There are several intermediate documents that need to be created. These are described in section 1.2. The budget for the project is 3008 hours. The first phase of the project consists of doing research and writing the User Requirements Document. After three weeks, we move to the second phase of the project in which we use the agile method of working (extreme programming practices and scrumming) to develop the source code of OpenACCEL. During this phase, documentation is written for the product as well. The main deliverables are the User Requirements Document, the Software Requirements Document, the Architectural Design Document, the Detailed Design Document, the Software User Manual, the Software Transfer Document and the source code. Additionally, some project documents will evolve during different phases of the project. 1.2 Project Deliverables During the course of the project, several documents have to be produced and delivered to the client and to senior management. All these documents have to be written according to the ESA software engineering standards [1]. All products that will be delivered to the client and senior management are mentioned in the following list: User Requirements Document (URD) [14] Product Backlog [4] Software Requirements Document (SRD) [9] Architectural Design Document (ADD) [2] Detailed Design Document (DDD) [5] Software User Manual (SUM) [12] Software Transfer Document (STD) [10] Unit Test Plan (UTP) [15] System Test Plan (STP) [11] Integration Test Plan (ITP) [6] Acceptance Test Plan (ATP) [3] Software code The client intends to develop the software further after this project. Therefore the client will receive a copy of all project documents at the end of the project, except for the management documents. All documents have to be delivered both on paper as well as in electronic form. 1.3 Evolution of the SPMP During the project this document will be updated as a plan is refined during the project. These updates will be limited to the refinement of appendices containing more detailed planning for each phase. Because each sprint addresses several phases, the Sprints appendix has to be updated during each sprint with more detailed information (if necessary).
1.4 List of definitions 2IP35 The Software Engineering Course AD Architectural Design ADD Architectural Design Document AT Acceptance Test ATP Acceptance Test Plan Client Kees van Overveld CM Configuration Manager DD Detailed Design DDD Detailed Design Document ESA European Space Agency TU/e Eindhoven University of Technology OM Operations and Maintenance Plan PM QM Quality Manager SCMP Software Configuration Management Plan SEP Software Engineering Project SL Software Librarian SPMP Software Project Management Plan SQAP Software Quality Assurance Plan SR Software Requirements SRD Software Requirements Document STD Software Transfer Document SUM Software User Manual SVVP Software Verification and Validation Plan SVVR TR Transfer phase UR User Requirements URD User Requirements Document VPM Vice Project Manager 1.5 List of references [1] ESA. ESA Software Engineering Standards. Mar 1995. [2] GROUPNAME. Advanced design document. [3] GROUPNAME. Advanced test plan. [4] GROUPNAME. Product backlog. [5] GROUPNAME. Detailed design document.. [6] GROUPNAME. Integration test plan. [7] GROUPNAME. Software configuration management plan. [8] GROUPNAME. Software quality assurance plan. [9] GROUPNAME. Software requirements document. [10] GROUPNAME. Software transfer document. [11] GROUPNAME. System test plan.
[12] GROUPNAME. Software user manual. [13] GROUPNAME. Software validation and verification plan. [14] GROUPNAME. User requirements document. [15] GROUPNAME. Unit test plan.
Chapter 2 Project Organization 2.1 Process Model The project follows the Scrum process model. This model uses a Product Backlog, a prioritized list of high-level requirements written as User Stories. At the start of a sprint, a number of User Stories is selected and put into the Sprint Backlog. These stories are the features that will be implemented during the sprint. For each user story different phases are traversed: requirements, architectural design, implementation and testing. Each sprint has the duration of a week. After the sprints, the product has to be delivered to the customer. Figure 1 The Scrum process Image Lakeworks (http://commons.wikimedia.org/wiki/file:scrum_process.svg) 2.2 Organizational structure The TU/e employs the Senior Management and the technical adviser. Communication be- tween Senior Management and the project group is done via the PM. Otherwise, only the VPM can contact the Senior Management directly and only when he is concerned about the functioning of the PM. Whenever the PM is not able to perform his duties for a certain period of time, this is done by the VPM
Senior Manager Lou Somers Technical Advisor Eric Scheffers Project Manager Erikos Alkalai Team Leader Brinkmann E.K. (Edward) Configuration Manager Denissen P.E.J.G. (Philippe) Quality Manager Duc Luu Software Engineer Gansewinkel L.W.P.H. van (Leo) Vice Configuration Manager Dueren den Hollander C.J.P. van (Carl) Vice Quality Manager Jacco Snoeren Software Engineer Tran T.L. (Loc) Software Engineer Ridder K.A. de (Kevin) Software Engineer Jacobs R. (Roel) Software Engineer Stoof R. (Roy) 2.3 Boundaries and interfaces There are several persons and groups for the project group to interact with. These are: The university: The Software Engineering Project (SEP) is a project of TU/e. The PM and the QAM are responsible for, respectively, the project progress and its quality, and report to the SM. The university is the owner of the software and documents produced in this project The technical adviser: is a staff member of the Computer Science department of TU/e. Team members may consult him on technical issues. The technical adviser is generally invited to the weekly meeting. Due to the small scale and duration of the project, no direct relationship with end users and subcontractors can be defined.
2.4 Project responsibilities In the project, certain management tasks need to be performed. The risk exists, that a member of the team with a management function, is suddenly unavailable. Therefore every manager will be assisted, and if necessary, replaced by a vice-manager. 2.4.1 Project Manager (PM) The primary goal of the project manager is to ensure the completion of the project in the available time, within budget. The PM makes the planning and ensures that it is feasible. Whenever problems occur the planning must be adapted in order to obtain a feasible planning again. The PM must ensure the progress of the project. He will be assisted by the vice PM. In case of absence of the PM, the vice PM takes over the PMs Tasks. The tasks the PM must perform are: Being the chairman during meetings, Motivating team members, Forming teams and assigning tasks, Checking progress, Managing the time budget, Defining work packages and goals, Providing feedback to the Senior Management through progress reports. 2.4.2 Quality Manager (QM) The primary goal of the quality manager is to ensure the quality of the end product and the overall process. In case of absence of the QM, the vice QM takes over the QMs tasks. The tasks the QM must perform are: Writing the SQAP [8] Verifying that procedures and standards which are defined in the SQAP are adhered to Checking that all project documents are consistent, Arranging internal and external reviews, Monitoring and reviewing all testing activities. 2.4.1 Configuration Manager (CM) The task of the Configuration Manager is to create and maintain the project library. More information about the project library can be found in SCMP[7]. The CMs tasks include but are not limited to: Writing the SCMP, Creating a repository for all documents and code, Checking that the repository is used appropriate (that is according to the SCMP) by all team members, Maintaining the repository according to the SCMP 2.4.2 Team Leader During the project, several teams will exist. A team leader is responsible for the activities of his team. The tasks a team leader must perform are: Planning and coordinating team activities, Providing feedback about team progress to the PM, Motivating team members,
Chairing internal reviews of the items made by his team. 2.4.3 Development Team Member The team members are all members of a team including the team leader. The tasks a team member must perform are: Assisting the Team Leader or Project Manager by signaling problems in an early stage, Executing plans made by the Team Leader and by the Project Manager, Keeping track of time spent on various tasks, Following procedures and plans. 2.4.4 Scrum Master The role of the Scrum Master is twofold. He ensures that the Scrum process is followed and used as intended. Furthermore he acts as buffer between the development team and any distracting influences. Tasks that belong to this role are: Ensure that the Scrum process is followed Check that the backlog is updated and that stories are clear Make sure that sprint items are clear Send reminders about demos that are held Create the sprint backlog Lead the daily scrum and make sure that afterwards everybody knows what to do When time is almost up the Scrum master tries to summarize concrete suggestions about what we can do better next sprint 2.4.5 Product Owner The Product Owner represents the customer. He is accountable for a good product backlog. The tasks of the product owner are: Make sure that all requirements asked by the customer are represented by user stories Check that the items in the product backlog are user centered rather than technical Prioritize items in the product backlog according to the wishes of the customer and the suggestions given by the development team
Chapter 3 Managerial Process 3.1 Objectives and priorities The management objective is to deliver the product in time and of high quality. The PM and QAM work together to achieve this by respectively checking that progress is made as planned and monitoring the quality of the product at various stages. 3.2 Assumptions, dependencies and constraints Partly due to the educational nature of the project, it is limited by a rather large number of factors: The budget is 9 team members * 40 days * 8 hours = 2880 The Management Team budget is 2 * 40 days * 1.6 hour = 128 The following hard deadlines, set by senior management: o Project deadline: June 27 th, 2014 o Intermediate presentation: May 19 th, 2014 o Final presentation: June 23 rd, 2014 Holidays o Liberation day: June 5 th, 2014 o Ascension Day, May 29 th 30 th, 2014 o Pentecost, June 9 th, 2014 Scheduled lectures and homework for classes other than this project are every Monday and Thursday mornings. 3.3 Risk management Miscommunication Probability: High Impact: High Misinterpretations of what other team members say and write might stand in the way of a common understanding of what to do and how to do it. This might lead to delays, unwanted results and double work. Prevention: Throughout the project, and especially during weekly meetings, the PM has to make sure every team member understands the task given to him, by having frequent talks with each group member about their task. It is important that the minutes of the meeting are correct and complete, and they should be read by everyone with care. Correction: When a problem occurs, the QAM arranges a meeting with all involved people to come to a common understanding of the situation. After this meeting, its results are briefed to all team members. Too many planned features lead to infeasible design Probability: High Impact: high Prevention: The Technical Advisor should be consulted on whether the delivery of the planned product can be done within the time budget. Every item should have a priority. Correction: By closely monitoring progress the decision to drop certain requirements can be made in time. Illness or absence of team members or the PM Probability: Medium
Impact: High Prevention: Team members should warn their team leader or the PM timely before a planned period of absence. The PM should make planned absence a point on the first meeting to make sure that absence that is known at that time is taken into account in the schedule. Correction: Every role has a person to replace him. Communication between these two people is very important. The vice person should be actively involved in all work in order to be able to replace his counterpart. All important information and design decision should be in documents or in the meeting notes, to make sure that as little information is lost as possible. Loss of critical information, documents or code Probability: Medium Impact: High Prevention: The SCMP [7] should be written and used with care. The base assumption should be that there is a backup of every single piece of information at any single time. Correction: Use the latest backups to recover the most recent version. If the missing parts are necessary, replace these as soon as possible. The customer changes his mind about the requirements, or there is disagreement about the requirements interpretation. Probability: High Impact: Medium Prevention: It should be made very clear to the customer that after a certain date the requirements can t change anymore Correction: If the customer changes his mind during the UR phase his new requirements can be incorporated in the URD. Procedures in SQAP [8] detail if the URD may be changed after approval, and (if so) how to implement changes. The customer is not available when needed Probability: Medium Impact: Medium Prevention: Meetings with the customer should be planned well in advance. The customer has been given room in his schedule for his Software Engineering related work. Holidays and other travel plans of all people involved should be put in this document in section 5.5.3. Correction: When the customer is not available, meetings may have to be rescheduled. 3.4 Monitoring and controlling mechanisms The monitoring of progress is done by the PM using the following means: 3.4.1 Daily Scrum Each day during the sprint a daily scrum is held. Daily scrums take place on 09:15-09:30, and held in front of the task board. The daily scrum is a project status meeting where the task board is updated. Each person describes what he did yesterday and what he will do today. Then he updates the task board by updating his time estimates, adding new post-its, and shift post-it to done. The Scrum Master has to make sure that the daily scrum does not exceed 15 minutes. Furthermore he has to ensure that everybody knows what to do this day.
3.4.2 Sprint Planning Session The sprint planning session is held at the start of each sprint, which is usually every Friday at 13:00, unless it differently requested by the client. The client must be present at the session. First the client has to determine which stories are the most important. Next, the development team plays planning poker and makes time estimates for the most important stories. Then the velocity is determined and the number of story points available for this sprint. The client may shift some stories after the story points are estimated. During the meeting it is determined: sprint goal velocity of the team sprint backlog of the stories that will be included in this sprint defined sprint demo date defined time and place for the daily scrum 3.4.3 Sprint Demo At the end of each sprint a demo is held to present the completed stories to the client. The date, time and location of this demo are set in the sprint planning meeting. The demo takes at most 30 minutes. 3.4.4 Sprint Retrospective After the sprint demo the sprint retrospective is held. During the retrospective the members of the development team reflect on the sprint. Before the meeting starts everybody has to write down items in the categories keep, stop, and change. During the session everybody mentions these items. 3.4.5 Project metrics Every week, the work done by the members, needs to be administrated. Each team member has to fill in their hours on a web-based log. This log needs to be filled in every Sunday Evening. A week starts at Monday and ends at Sunday. Every entry in a log has to belong to one of the following work packages: SPMP, SVVP, UTP, ITP, STP, ATP, SCMP, SQAP, URD, SRD, Prototype, Research, ADD, DDD, Code, IT, ST, AT, STD, Formal reviews, Meetings or Presentations. The PM sends an email to the SM every week, containing the hours spend on the different work packages and the hours spend on following categories: Non project related, General project related, Documentation, specification, design, Source code, Testing, verification, consolidation and rework. Further, for every work package, an estimation of remaining hours is added. 3.5 Staffing plan Name E-mail Role Lou Somers l.j.a.m.somers@tue.nl Senior Management Kees van Overveld k.van.overveld@wxs.nl Product Owner Erik Scheffers e.t.j.scheffers@tue.nl Technical Advisor Erikos Alkalai e.alkalai@tue.nl PM Duc Luu m.luu@tue.nl QM + VPM Snoeren J.P.H. (Jacco) j.p.h.snoeren@student.tue.nl Vice QM Denissen P.E.J.G. (Philippe) p.e.j.g.denissen@student.tue.nl CM Dueren den Hollander C.J.P. van (Carl) c.j.p.v.dueren.den.hollander@student.tue.nl Vice CM Brinkmann E.K. (Edward) e.k.brinkmann@student.tue.nl Team Member
Ridder K.A. de (Kevin) k.a.d.ridder@student.tue.nl Team Member Gansewinkel L.W.P.H. van (Leo) l.w.p.h.v.gansewinkel@student.tue.nl Team Member Tran T.L. (Loc) t.l.tran@student.tue.nl Team Member Jacobs R. (Roel) r.jacobs@student.tue.nl Team Member Stoof R. (Roy) r.stoof@student.tue.nl Team Member
Chapter 4 Technical Process 4.1 Methods, tools and techniques The methods, tools and techniques used during the course of the project are listed in the SCMP. 4.2 Software documentation During the project, documents should conform to a number of aspects: Documents must be of good quality. The standards all documents are required to meet are documented in the SCMP [7] with respect to style and in SQAP [8] with respect to content. Documents must be reviewed. The manner in which document reviews are performed is described in the SVVP [13]. The purpose of document reviews is to get docs of high quality. The requirements which apply to the approval of documents are given in the SVVP [13]. 4.3 Project support functions Besides Project Management, three other management functions are present. Below a short description of each of them is given. All these management plans are standard part of the ESA standard [1]. More detailed descriptions can be found there. Configuration Management. The purpose of software configuration management is to plan, organize, control and co-ordinate the identification, storage and change of software through development and transfer. The Configuration Manager writes the SCMP in which plans are outlined for performing these tasks. Verification and Validation. Software Verification and Validation activities check the software against its specifications. The Quality Manager writes the SVVP as one of his tasks. In it he outlines how he plans to perform his verification and validation activities. Quality Assurance. During the project, all documents should be tested against quality standards; both to conform to the chosen project documentation style and to contain correct information of reasonable quality. The QAM states the regulations and the way in which he plans to check whether these are followed in the Software Quality Assurance Plan [8].
Chapter 5 Work packages, schedule, budget 5.1 Work packages The work packages are defined in the appendix detailing their phase. 5.2 Dependencies There are no dependencies when creating the Product Backlog and the User Requirements Document. The sprints in the sprint phase are dependent on these two documents. The transition phase, when the product is delivered to the customer, is dependent on both the other phases. 5.3 Resource requirements The most important resources during the project are human resources. An overview of resource utilization during the various project phases is given in Section 5.4. 5.4 Budget and resource allocation In most projects the only resource is the number of man-hours of the people involved. This is described in the next chapter, schedule. 5.5 Schedule This section gives a rough planning of resource usage. The only important resource are man-hours. 5.5.1 Deadlines Topic Deadline Management Documents approved June 27, 2014 URD approved May 10, 2014 Intermediate presentation May 19, 2014 Prototype approved May 11, 2014 SRD approved June 15, 2014 Peer review May 19, 2014 ADD approved June 22, 2014 DDD approved June 27, 2014 Coding complete June 20, 2014 Acceptance test successful June 26, 2014 Final presentation June 23, 2014 Project deadline June 27, 2014 5.5.2 Hour planning In every sprint the customer pick up the stories to be developed and prioritized them. Then the team is estimating the hours to be spent. The total hours to be spent for this sprint is called the velocity of the sprint. After the first sprint we can safely estimate if the velocity of the next sprint is feasible or not. 5.5.3 Unavailability overview In the following table we will list which of the group members will be unavailable for some period of time, outside exam weeks and holidays Met opmerkingen [EA2]: Include the dates Met opmerkingen [EA3]: Include unavailabilities Name Role Unavailable Period All Various Mondays 8:45-12:30 and Thursdays 8:45-12:30
Appendix A User Requirements Phase In the UR phase the main focus is on the definition of the user requirements and user stories. Besides the URD, the management documents and Product Backlog are written during the UR phase. A.1 Output UR Phase The UR phase can be called the problem definition phase. User requirements are documented in the URD, giving the customers view of the problem. The main outputs of the UR phase are the: URD SPMP/Sprints phase (SR) SCMP/Sprints phase (SR) SQAP/UR and SQAP/Sprints phase (SR) SVVP/UR and SVVP/Sprints phase (SR) A.2 Work packages UR phase The work packages defined for the UR phase are URD SPMP SCMP SQAP SVVP Project Group Meetings Research Management & initialization The work package Management & initialization embodies the creation of a document repository, mailing list, etc. as well as management activities, the creation of a document template, etc. SPMP embodies the time spent on reviews. The VPM can also spend hours on this work package when he writes parts of the SPMP. The assignment of teams to various work packages is as follows: Document URD SPMP SCMP SQAP SVVP Project Group Meetings Research Management & initialization Members URD team PM CM/VCM QM/VQM Test team Everyone Everyone PM/QM Met opmerkingen [EA4]: Fill in the documents and the names A.3 Budget and resource allocation The following table lists packages and the budget that has been assigned to each.
Work Package Budget Estimate (man-hours) SPMP 70.0 SVVP 45.0 UTP 50.0 ITP 50.0 STP 40.0 ATP 40.0 SCMP 50.0 SQAP 45.0 URD 50.0 SRD 200.0 Prototype 10.0 Research 150.0 ADD 40.0 DDD 40.0 Code 1010.0 SUM 40.0 IT,ST,AT 210.0 STD 40.0 Formal reviews 15.0 Meetings 100.0 Presentations 110.0 Rework 450.0