PROCESS - Project Management Plan.docx



SE 4351.001 Software RequirementsFall 2014Project Management Plan MembersJoe Brownjsb100120Desmond Leedcl102020Giuseppe Mastrolorenzomxg106320Michael Raibickmxr110530Ryan Chenrxc109520Robert Lockwoodrll092020Blessing Osakueboo102020Oscar Reyesoxr110330Travis Chuntwc101020Michael Muggermxm121531Andrew Pohlmannaxp120531James Williamsjxw110730Bennilyn Quekbxq120430Revision HistoryVersionDateComments1.0.009/02/2014Initial version of Preliminary Project Management Plan.1.1.009/04/2014Updated project plan formatting to conform to template and edited content sections for structure.1.1.109/04/2014Formatted sentence structures in §1.1.1, §1.1.2, §2.3 for clarity.1.1.209/04/2014Revised placeholders for printing.1.1.309/08/2014Filled in §2.2.1, §2.4.1, §3, §4.2, §4.31.1.410/1/2014Added ToCUpdated §1.2, §2.4.1,§5.21.210/16/2014Updated §1.2, §2.4.1,§5.21.312/01/2014Updated §1.2, §2.4.1,§5.2Final CheckTable of Contents TOC \o "2-2" \h \z \u 1. Introduction PAGEREF _Toc404690735 \h 51.1 Project Overview PAGEREF _Toc404690736 \h 51.1.1 Project Background PAGEREF _Toc404690737 \h 51.1.2 Project Goals PAGEREF _Toc404690738 \h 51.2 Deliverables PAGEREF _Toc404690739 \h 61.3 Document Evolution PAGEREF _Toc404690740 \h 61.4 References PAGEREF _Toc404690741 \h 71.5 Definitions, Acronyms, Abbreviations PAGEREF _Toc404690742 \h 72. Project Organization PAGEREF _Toc404690743 \h 82.1 Process Model PAGEREF _Toc404690744 \h 82.2 Organizational Structure PAGEREF _Toc404690745 \h 82.2.1 Team Organization PAGEREF _Toc404690746 \h 82.3 Organizational Boundaries and Interfaces PAGEREF _Toc404690747 \h 102.4 Project Responsibilities PAGEREF _Toc404690748 \h 112.4.1 Phase 1 Team Roles and Responsibilities PAGEREF _Toc404690749 \h 113. Managerial Process PAGEREF _Toc404690750 \h 133.1 Management Objectives and Priorities PAGEREF _Toc404690751 \h 133.2 Assumptions, Dependencies and Constraints PAGEREF _Toc404690752 \h 133.2.1 Assumptions PAGEREF _Toc404690753 \h 133.2.2 Dependencies PAGEREF _Toc404690754 \h 133.2.3 Constraints PAGEREF _Toc404690755 \h 143.3 Risk Management PAGEREF _Toc404690756 \h 143.4 Monitoring and Controlling Mechanisms PAGEREF _Toc404690757 \h 164.Technical Process PAGEREF _Toc404690758 \h 184.1 Methods, Tools and Techniques PAGEREF _Toc404690759 \h 184.2 Software Documentation PAGEREF _Toc404690760 \h 194.3 Project Support Functions PAGEREF _Toc404690761 \h 195. Work Elements, Schedule and Budget PAGEREF _Toc404690762 \h 205.1 Work Elements PAGEREF _Toc404690763 \h 205.2 Schedule PAGEREF _Toc404690764 \h 205.3 Budget PAGEREF _Toc404690765 \h 221. Introduction1.1 Project Overview1.1.1 Project BackgroundAs people get older they tend to experience difficulties in either cognitive or sensory function. These difficulties can turn an independent and free-spirited person’s life into a continuous set of daily challenges. Assistive technology processes sensory data to provide meaningful information to the user. Today’s assistive technologies (known as aids) are expensive, trivial and bulky. Persons who have multiple difficulties require multiple devices. There is a growing need for advanced assistive technologies that are easy to use and convenient for the user. The solution is the use of a device many people already own: the smartphone. Smartphone-based aids do more than traditional assistive devices. For example, a hearing aid should recognize speech to create a visual image. A speaking aid should generate speech from visual data. Finally, a memory aid should produce visual queues based on a variety of input.1.1.2 Project GoalsTeam Total Recall’s Project Goal is to create an AAC application, running on an Android mobile device that is capable of enhancing a user’s communication abilities who is suffering from stage 3 dementia.1.2 DeliverablesPhaseNo.PhaseNameDeliverablesInternal ReviewDateDeliveryDateInitialPreliminary PMP09/03/201409/04/20141InterimEvolving PMPEvolving WRSEvolving PPTPrototype Mock-ups09/29/201409/30/2014FinalEvolving PMPEvolving WRSEvolving PPTEvolving UMPreliminary Prototype Mockups10/15/201410/16/20142InterimEvolving PMPEvolving WRSEvolving Process Specification DocumentEvolving Vision DocumentAppendix - Glossary Appendix - References10/17/201411/11/20142FinalFinal PMPFinal WRSFinal Vision DocumentFinal Process Specification Final User ManualFinal PrototypeFinal PresentationFinal Appendix11/12/201412/02/20141.3 Document EvolutionThis is a living document that is updated periodically. The document will be updated in response to feedback from the review process defined in the managerial processes (§3.4.1). This document is to be managed solely in the Google Drive repository established for the team. When changes are made the changes must be documented in the revision history table found at the beginning of this document. Changes must be dated, versioned, described and stamped with the team member who made the changes. The current version is specified on the bottom right of the document on all pages.The versioning system used by the revision history table conforms to the semantic versioning scheme. The version numbers are indicated as a three decimal numerical in the form of “X.Y.Z”. All X, Y and Z are integers in the range zero to nine inclusive. Where X represents the major version, Y represents the minor version and Z represents patches. Major versions are incremented when the minor version number is exhausted by reaching nine and resetting to zero. Minor versions are incremented when content is added or removed. Patch versions are indicated when sentence structure changes are made but no content is added or removed.1.4 ReferencesPlease see the document References in the Appendix.1.5 Definitions, Acronyms, AbbreviationsPlease see the document Glossary in the Appendix.2. Project Organization2.1 Process ModelThe organization will be employing the Spiral Mode. Due to the emphasis on requirements analysis and negotiation, this model serves the organizational requirement of close client collaboration well.2.2 Organizational StructureThe organizational structure of three teams and 4 team members each. The project leader is not directly part of a team, but will form a fourth pseudo group that involves the other team leaders. This pseudo team is in place to encourage high cohesion amongst management elements for more effective work unit scheduling.2.2.1 Team OrganizationPhase 1 - InterimTeamNo.TeamMembers-1. Andrew Pohlmann (Phase Lead)1Michael Raibick (Team Lead)Ryan ChenTravis ChunOscar Reyes2Michael Muggler (Team Lead)Bennilyn Quek Desmond LeeRobert Lockwood3Blessing Osakue (Team Lead)Joe BrownJames WilliamsGiuseppe MastrolorenzoPhase 1 - FinalTeamNo.TeamMembers-1. Michael Raibick (Phase Lead)1Andrew Pohlmann (Team Lead)Michael MugglerJames Williams2Michael Raibick (Team Lead)Joe BrownDesmond LeeOscar Reyes3Bennilyn Quek (Team Lead)Blessing OsakueRyan ChenRobert LockwoodGiuseppe MastrolorenzoTravis ChunPhase 2 - InterimTeamNo.TeamMembers- Bennilyn Quek (Phase Lead)1Andrew Pohlmann (Team Lead)Michael MugglerJames Williams2Desmond Lee (Team Lead)Joe BrownMichael RaibickOscar Reyes3Ryan Chen (Team Lead)Blessing OsakueMichael RaibickRobert LockwoodGiuseppe MastrolorenzoTravis ChunPhase 2 - FinalTeamNo.TeamMembers- James Williams (Phase Lead)1Joe Brown (Team Lead)Michael MugglerBennilyn Quek 2Michael Raibick (Team Lead)Andrew PohlmannDesmond LeeOscar Reyes3Ryan Chen (Team Lead)Blessing OsakueMichael RaibickRobert LockwoodGiuseppe MastrolorenzoTravis Chun2.3 Organizational Boundaries and InterfacesEach team is intended to function as a self-contained entity that can complete its work units independently of other teams. Team leaders will function as interfaces to the project leader in management meetings for progress reviews and new workload assignments. If necessary, team leaders will also coordinate with other team leaders and the project leader for the purposes of synchronizing content production toward an aggregated work unit. The project leader is not directly part of a team, but will work closely with all team leaders for workflow synchronization purposes and clarification of project vision and direction. The project leader will also function as a liaison as necessary between all teams in the event that more precise communication is necessary.2.4 Project Responsibilities2.4.1 Phase 1 Team Roles and ResponsibilitiesPhase 1 - InterimTeamRoleResponsibilities1Requirements Engineering Exploration of Domain, Stakeholder, Functional, Non-Functional Objectives.Update WRS.2Requirements Engineering Exploration of Non-Functional Requirements Update WRS.Generate preliminary Prototype.3Requirements Engineering Exploration of Functional Requirements Update WRS.MGManagementUpdate PMP.Generate preliminary PPT.Phase 1 - Final TeamRoleResponsibilities1Requirements EngineeringCreate system specifications.2System DesignCreate UI of the front-end 3DocumentationGenerate the Initial User Manual MGManagementUpdate PMP, PP2.4.2 Phase 2 Team Roles and ResponsibilitiesPhase 2 - Interim TeamRoleResponsibilities1System Design / DevelopmentDeveloping System ArchitectureImplement the SystemGenerate Product Diagrams.2System Design / Development / Documentation.Develop System UIImplement the System3DocumentationDevelop User Manual Develop AppendixMGManagementDevelop Evolving Vision DocumentDevelop AppendixPhase 2 - FinalTeamRoleResponsibilities1System Development / Documentation.Finalize PrototypeFinalize WRS.2System Development / Documentation.Finalize PrototypeFinalize all Product and Process Diagrams3Documentation.Finalize User ManualFinalize AppendixMG ManagementFinalize PMPFinalize Vision DocumentFinalize Process Specification DocumentFinalize PPT3. Managerial Process3.1 Management Objectives and PrioritiesAccountability: Ensuring that weekly work unit deadlines are met.Accuracy: Ensuring that work units are traceable to end-phase deliverables requirements.Efficiency: Ensuring that no excessive or redundant work is performed.Quality Assurance: Ensuring that all work units completed are free of munication: Ensuring low latency communication between and within teams.3.2 Assumptions, Dependencies and Constraints3.2.1 AssumptionsTeam members will be cognizant of project schedule deadlines.Team members will stay healthy and remain physically capable of carrying out assigned duties.Team members will respond to communications from other team members in a timely fashion.Team members remain motivated through the duration of the project.Team members will always have access to the necessary tools to complete their assigned work units.The group will not lose any team members.3.2.2 DependenciesManagement will effectively communicate the project munication mechanisms to maintain low latency communications in the organizational structureManagement being effective at maintaining linear progression of progress.Team members not procrastinating and delaying assigned work units.3.2.3 ConstraintsPersonal schedule conflicts between team members.Personal lives of team members.3.3 Risk ManagementRiskImpactMitigation Inaccurate Estimations about project costs, scheduling, and time to completeThese bad estimates can end up sinking a project into a sea of budget overruns, delayed deliverables, and wasted effort that can potentially end up in a cancellation of a project. Apply crash techniques to speed up under-performing work units. Work overtime to ensure that work units get completed on time. Modify the schedule as necessary to apply more man hours to work units that are behind.Bad Requirements GatheringBad requirements gathering in a project ensures that the resulting software architecture will not be compliant with what the client truly needs. This situation is sometimes not seen until later in the project and, when discovered, can lead to critical faults that threaten the success of the project.Hire a requirements engineer to elicit the proper set of requirements from the client.Executing Behind ScheduleExecuting behind schedule virtually assures missing deadlines, wasting project resources, and provoking negative client feedback. The worst case of this scenario is that the client cancels the project.We have taken a multifaceted approach in expecting and mitigating the risks of running behind schedule. Ample time has been set aside to collaborate with the customer on creating a detailed list of specifications and expectations with the project. Time has been set aside to review the project at regular intervals with the customer and additional time has been set aside to handle possible changes or issues brought up during these meetings. The project is internally scheduled to complete early so schedule setbacks don’t push us beyond the hard deadline. A change management system is in place to reduce the impact of changes. We believe these mitigations will be sufficient to handle most high-probability or high-impact scheduling situations that may arise.Unforeseen Technical ComplexityUnforeseen technical complexity could introduce delays in implementation of the program, or even worse uncover flaws in the requirements.Our project manager and developers will ask some questions during specification-gathering to ensure common sources of technical complexity are covered early. Integrations with third party systems, for example using Active Directory to handle user management, need to be identified during the specification phase. Change requests relating to third party integrations after the completion of the design phase will be denied unless an agreed-upon amount of time can be added to the five-month deadline.Data LossData loss can easily derail current project progress and make blown deadlines a guaranteed reality. Man-hours spent backtracking and redoing work units could easily lead to serious delays in the schedule and trigger another risk scenario “Executing behind schedule.” Regeneration of the lost data could also produce inaccurate or incorrect work that could cause future problems.Backup database nightly, have a slave database ready at a different location.Scope ChangesScope changes can cause serious changes in the functional and non-functional requirements of the program. Scope changes almost always impact scheduled tasks and work-units because of the refactoring of the scope into all phases of the development process.Expand timeline to accommodate additions or reject additions depending upon contract restrictions, feasibility, meetings with the customer, etc.User Interface Usability IssuesThe client may find the program difficult to use and then issue new requirements to “simplify” program operation. The client may not see the program as fulfilling its requirements and refuse payment of services. We will make use of tools such as to ensure our application is easy to use and follows today’s best practices for user interface design.Personnel LossProject work units could be delayed. Other team members may become strained from having to take on the extra work from the departing employee. The project even may suffer schedule delays if management cannot replace the lost manpower.Hire a qualified replacement, divide work between remaining employees while replacement is located.3.4 Monitoring and Controlling MechanismsLiving Announcement and Meeting Agenda documents will be constantly updated on Google Drive as a means to support project vision and maintain schedule work unit deadlines. Doodle will be used to schedule team member meetings. Glassboard will be used as a group collaboration platform. Github will be used for version control for all code. 4.Technical Process4.1 Methods, Tools and TechniquesThe following methods, tools and techniques will be used:MethodToolTechnique(s)CommunicationEmailDoodle GlassboardEmails are used for direct communication between group members. Doodle will be used to schedule team member meetings. Glassboard will be used as a group collaboration device. StorageGoogle DriveAny document pertaining to a deliverable must be stored on the team accessible Google Drive share folder. Including any preliminary or draft documents. All documents must be shared with the entire team.Version ControlGithubGithub will be the primary tool for storing the codebase, documenting changes and typing the code documentation. The user manual is to be stored in the Google Drive. The Github repository is exclusively for code and code related materials.DocumentationAstah UML EditorRE ToolsStar UMLAny documentation pertaining to the software must be done in Astah, Star, or RE Tools and submitted in the Google Drive. Do not place UML files under version control.Visual EditingMS PaintVisioPrototype Mockups and graphics will be drawn using these tool.System Development IonicJavaScriptHTML5CSS5System development will be done using the Ionic SDK platform, which uses JavaScript, HTML5, and CSS5 to create mobile applications.4.2 Software DocumentationThe software architecture will be documented with UML using Astah, Star, and RE Tools diagrams. A user manual will be created for the application that shows graphical images to demonstrate how to use the system.4.3 Project Support FunctionsLiving Announcement and Meeting Agenda documents will be constantly updated on Google Drive as a means to support project vision and maintain schedule work unit deadlines. Doodle will be used to schedule team member meetings. Glassboard will be used as a group collaboration device. Github will be used for version control for all code. 5. Work Elements, Schedule and Budget5.1 Work ElementsProject Management PlanWRS Process SpecificationProduct Specification (Vision)Prototype User ManualPowerPoint PresentationAppendix5.2 SchedulePhase 1 Interim Deliverable(s)TeamAssignmentsAssign DateInternal Due DateOfficial Due DateEvolving WRS RE Team 1: WRS §2.1RE Team 2: WRS §2.3RE Team 3: WRS §2.209/8/1409/14/1409/30/14Evolving WRSRE Team 1: §3.1 RE Team 2: §2.3RE Team 3: §2.209/15/1409/21/1409/30/14Evolving PPTRE Team 1: Traceability09/22/1409/28/1409/30/14Evolving WRS RE Team 3: §3.2 09/22/1409/28/1409/30/14Evolving WRS RE Team 2: §3.109/22/1409/28/1409/30/14All Deliverables Management09/29/1409/29/1409/30/14Phase I Final (Due 10/16/2014)Deliverable(s)TeamAssignmentsAssign DateInternal Due DateOfficial Due DateEvolving WRSArchitecture Team: Develop System Specifications10/0110/810/16Evolving Prototype UI/UX TeamDevelop prototype wireframes from specifications.10/0910/1310/16Evolving User ManualUM/Testing TeamDevelop user manual.10/1110/1410/16Evolving PMPEvolving PPManagementUpdate PMP, PP10/1510/1510/16Phase 2 Interim (Due 11/11/2014)Deliverable(s)TeamAssignmentsAssign DateInternal Due DateOfficial Due DateEvolving PrototypeUI/UX Team: Develop System UIGenerate Appendix.10/1610/2511/11Evolving PrototypeArchitecture Team: Develop System ArchitectureImplement the System.Generate Diagrams.10/1610/2511/11Evolving User ManualUM/Testing TeamDevelop User Manual10/1610/2511/11Evolving PrototypeUI/UX + Architecture TeamDevelop Prototype 10/2711/1011/11Evolving Vision DocumentUM/Testing: Develop Vision Document10/2711/1011/11All DeliverablesManagement11/1011/1011/11Phase 2 Final (Due 12/05/2014)Deliverable(s)TeamAssignmentsAssign DateInternal Due DateOfficial Due DateEvolving PrototypeArchitecture TeamFinalize prototype.Finalize Diagrams.11/1211/1512/05Evolving User Manual UM/Testing: Finalize User Manual 11/1211/1512/05Evolving Vision Document UI/UXFinalize Vision Document. 11/1211/1512/05AppendixUM/Testing:Finalize Appendix 11/1612/0112/05Process Specification DocumentManagementFinalize Process Specification11/1612/0112/05All DeliverablesManagement12/0212/05 12/055.3 BudgetNo budget is allotted for this project. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download