Distributed Team Collaboration Processes II OMSE 555 - Winter 2012
Software Project Management Plan (SPMP)
Distributed Team Collaboration Processes II
Ivan Dontsov, Andy Phenix, Maureen Rottschaefer
Version 1.5
3/18/2012
This document describes the processes and tools to be used in planning, developing, monitoring and controlling the activities and assignments of the Distributed Team Collaboration Processes II team.
Revision History
Version / Description of Versions / Changes / Responsible Party / Date1.0 / Initial version of SPMP for comment by team / Maureen / 1/31/12
1.1 / First revised draft post OMSE 555 recalibration meeting / Andy / 2/8/12
1.2 / Second revised draft / Andy / 2/12/12
1.3 / Incorporated feedback from Maureen / Andy / 2/16/12
1.4 / Additional feedback from team incorporated prior to submission to Stuart for review / Andy / 2/19/12
1.5 / Incorporated feedback from Stuart and project team / Andy / 3/18/12
Approval Block
Version / Comments / Responsible Party / Date1.0
Table of Comments
Page 2 of 19
Distributed Team Collaboration Processes II OMSE 555 - Winter 2012
Introduction 3
1.1 Overview and Objectives 3
1.2 Deliverables and Internal Project Documents 4
1.3 Priorities, Assumptions, Constraints, Risks 4
1.3.1 Priorities 4
1.3.2 Assumptions, Constraints and Dependencies 4
1.3.3 Risks 4
1.4 Evolution of the SPMP 5
1.5 Reference Materials 5
1.6 Definitions and Acronyms 5
2 Development Process 6
2.1 Process Model 6
2.1.1 Phased Delivery 6
2.1.2 Key Deliverables (by Phase) 7
2.1.3 Key Milestones (by Phase) 8
2.2 Project Organization 9
2.3 Activities, Tasks, Resources 10
2.3.1 Work Breakdown and Tasks 10
2.3.2 Dependencies 11
2.3.3 Resources 11
2.4 Schedule 12
3 Managerial Process 12
3.1 Risk Management 12
3.2 Requirements Management (Scope Control) 13
3.3 Monitoring and Control 13
3.4 Configuration Management 14
3.5 Quality Assurance 14
4 Technical Processes 15
4.1 Processes and Methods 15
4.2 Development Tools / Development Environment 15
4.3 Technical Product and Process Metrics (TBC) 15
5 Additional Supporting Plans 16
Appendices 17
5.1 Project Schedule – Phases 2 and 3 17
Page 2 of 19
Distributed Team Collaboration Processes II OMSE 555 - Winter 2012
Introduction
1.1 Overview and Objectives
The Oregon Master of Software Engineering (OMSE) 2010 Practicum Project focused on developing a software engineering process specification specifically tailored to distributed teams – the Distributed Software Engineering Process Specification (DSEPS). As part of that project the team also developed a process specification tool which, while used in subsequent OMSE courses, has some opportunities for improvement which are outlined in the 2012 OMSE 555 course syllabus:
“Based on our 551 experiences, the current tool implementation provides a simple interface but is not particularly user friendly. The tool also lacks any support for collaborative review, analysis, explicit support for process families, or other things we might wish to do with processes and process models.
A useful project would extend the existing process tool. The most obvious extension would be to provide a more user-friendly interface and easier administrative support. Further extensions that would add capabilities to the tool might include:
· Collaborative Review: support for distributed, collaborative review of process models. This would define review processes and provide supporting tools or infrastructure.
· Modeling and analysis: support for formally modeling processes, simulating process execution, or analyzing key process properties.
· Improved support for defining families of processes and creating family members.”
The primary objective of this OMSE 2012 Practicum Project is to extend and refine the process specification tool and address some of its limitations. In particular, the project will address the ‘most obvious extension’ to provide a more user-friendly interface and easier administrative support.
As a secondary objective, should bandwidth permit, the project will also extend the tool to provide support for defining families of processes and creating family members, and / or collaborative review of process models. It is not intended to address the proposed modeling and analysis extension during this project.
In order to demonstrate the effectiveness and features of the redesigned process specification tool, the DSEPS will be modeled using the new tool.
The project will be executed over two semesters as the curriculum for OMSE 555 / 556, and the project team will consist of the following students - Ivan Dontsov, Andy Phenix, and Maureen Rottschaefer. The project team will act as the primary customer for the project (based on availability); the other OMSE 555 / 556 project teams, and Stuart Faulk, the OMSE 555 / 556 instructor, will act as the secondary customers for the project.
1.2 Deliverables and Internal Project Documents
The following deliverables will be provided for the project (to all stakeholders):
· Plans
o Software Project Management Plan (SPMP)
o Software Test Plan (STP)
· Technical Documents and Software
o Software Requirements Specification (SRS)
o Software Architecture Document (SAD)
o Software User Documentation
o Source Code (including installation and configuration instructions).
1.3 Priorities, Assumptions, Constraints, Risks
1.3.1 Priorities
Given the fairly high-level requirements that have been identified for the project to-date, it is likely that some tradeoffs will need to be made to meet the fixed-resource and schedule constraints. It is assumed that the course instructor will act in the interests of the OMSE program, and provide the project team with guidance on the project scope and relative priority of each identified requirement.
As such, one of the key deliverables in the first phase of the project will be a baseline set of requirements (via the SRS) that clearly identify the scope of the core functionality required to meet the primary project objective. The SRS will be extended in the second and subsequent phases of the project to cover requirements to meet the secondary project objectives.
Another key deliverable will be to define a base architecture that can be extended in the second and subsequent phases to accommodate whatever subset of extensions the project team has capacity to develop. Indeed, if well executed, the base architecture should accommodate additional extensions provided by subsequent OMSE practicum project teams.
1.3.2 Assumptions, Constraints and Dependencies
It is assumed that the process specification tool developed by the project team will be hosted by PSU’s existing IT infrastructure provided by the Computer Action Team (CAT). Each project team member will be responsible for provisioning their own development environment in accordance with the toolset identified in section 4.2.
1.3.3 Risks
The following key risks have been identified for the project:-
· Limited resources – there are insufficient team members to cover all project activities (leading to secondary issues – for example, independent validation & verification of project artifacts).
· Unavailability of secondary stakeholders – it is likely that many competing demands will be made of the course instructor (across multiple practicum teams, multiple OMSE courses, etc.). Additionally, given the dual role played by the instructor (course lecturer vs project customer) there is potential for confusion in intra-team communications.
· Confusion around practicum project process – recent changes to the OMSE program (including the departure of key staff members and loss of course materials) has created confusion between the participants and delayed project activities.
· New development process / project team – the project team intends to leverage the distributed software engineering process that resulted from the prior 2010 practicum project. However, the documented process specification does not cover all project activities, the most notable absence being quality assurance. Additionally, the project team has no past shared working experience to draw upon (for example, when estimating team capacity).
Section 3.1 details how the project team will address these risks and any additional risks that arise during the course of the project.
1.4 Evolution of the SPMP
This initial draft of the Software Project Management Plan (SPMP) will be placed under change control upon publication (see section 3.3 for details). During each subsequent phase of the project, the project team will meet periodically to review any proposed changes to the plan, assess the impact of making those changes and recommend accordingly (approve, reject, defer). If necessary, an updated version of the SPMP will be published at the conclusion of each phase of the project.
1.5 Reference Materials
This Software Project Management Plan (SPMP) references the following existing project documentation:
· OMSE 555 course syllabus
· 2012 Practicum Project Proposal
· Distributed Software Engineering Process Specification (DSEPS)
· DSEPS Process to SDLC Mapping (PSM)
· 2010 Practicum Project Team Materials
1.6 Definitions and Acronyms
DTCPII is an acronym that stands for Distributed Team Collaboration Processes II.
2 Development Process
2.1 Process Model
The project will use a hybrid development process, with a bias towards Waterfall in the first project term (OMSE 555), switching to a more iterative process model in the second project term (OMSE 556). This will allow the project team to:
· Focus on understanding the core desired functionality for the process specification tool
· Conservatively manage project scope based on team member availability
· Establish a working relationship within the project team, and clarify roles and responsibilities
2.1.1 Phased Delivery
The project will be delivered in a phased manner with three major phases:
· Phase 1 – base-lining
· Phase 2 – core functionality
· Phase 3 – desired functionality
For the first phase of the project, it is anticipated that two main streams of work will be scheduled – one focusing on requirements elicitation and specification, and the second focused on establishing a candidate architecture for the system. Phase 2 will focus on the implementation activities required to deliver the core functionality identified for the process specification tool. Phase 3 will focus on delivering the functionality required to meet the secondary objectives for the project – the scope of which will be adjusted based upon the project schedule and capacity at that time. For the second and third phases of the project, it is hoped that the project team can switch to using a more iterative development methodology, delivering incremental functionality on bi-weekly iterations.
The following chart provides an overview of how the project is broken down into each phase across the proposed schedule:
2.1.2 Key Deliverables (by Phase)
Based on the process model outlined above, it is expected that the key deliverables for each phase will be as follows:
· Phase 1 – Initial base-lining phase
o Project plan (SPMP)
§ Team member roles and responsibilities
§ Project size & schedule estimates
§ Agreement on how project scope will be managed
§ Risk management plan – key project risks documented and mitigation plan provided
o Base-lined requirements
§ Requirements (in the form of use cases & scenarios) for core (essential) functionality (SRS)
§ ‘Paper’ prototypes – wireframe diagrams for proposed tool user interface
o Candidate architecture
§ Establish the technical landscape, identify major sub-systems and the key system interfaces between them (SAD)
§ Identify hosting platform and development environment
o Communication plan
§ Establish standards for team communication
§ Provision document repository for managing key deliverables
· Phase 2 – Core functionality build out
o Design artifacts
o Working software
o Testing artifacts (test plans, test output)
o User documentation
· Phase 3 – Desired functionality, enhancements, revisions, etc.
o Additional Requirements (in the form of use cases & scenarios for secondary (non-essential) functionality (SRS)
o Design artifacts
o Working software
o Testing artifacts (test plans, test output)
o Amendments to user documentation (if required)
2.1.3 Key Milestones (by Phase)
Phase / Deliverable / Milestone Date / Comments1 – Base-lining / Draft SPMP / 2/23/12 / Mid-term pushed out 1 week (from original class schedule)
Draft SRS / 2/23/12
PPT (progress report) / 2/23/12
Draft Candidate Architecture (SAD) / 3/8/12
PPT (end of term status) / 3/15/12
SPMP (final) / 3/22/12
SRS (final) / 3/22/12
Candidate Architecture (SAD) / 3/22/12
UI Prototype / 3/22/12 / Paper-based mockups
2 – Core Functionality / Technical Prototype / 4/5/12 / To validate platform and application framework
Iteration 1 / 4/19/12 / 1st Deployment of Core Functionality + User Documentation
SRS (draft) / 4/19/12 / Updated for Secondary Project Objectives
Iteration 2 / 5/3/12 / 2nd Deployment of Core Functionality + Bug Fixes + User Documentation Updates
PPT (progress report) / 5/3/12
3 – Desired Functionality / SRS (final) / 5/3/12 / Updated for Secondary Project Objectives
Iteration 1 / 5/17/12 / 1st Deployment of Desired Functionality + User Documentation Updates
Iteration 2 / 5/31/12 / 2nd Deployment of Desired Functionality + Bug Fixes + User Documentation Updates
PPT (end of term status + demo) / 6/7/12
2.2 Project Organization
For the initial phase of the project, each team member will assume a primary role that maps back to the key phase 1 deliverables – the project plan (SPMP), requirements specification (SRS) and candidate architecture (SAD). Each team member will also assume a secondary role, providing support for quality assurance on each of the phase 1 deliverables. Additionally, it is tentatively planned that the project team will interact with other OMSE project teams, trading SQA tasks between individual practicum projects. It is assumed that the course instructor will act as the primary customer for both phases of the project. The proposed organizational structure for Phase 1 is:
For the second and subsequent phases of the project, it is expected that each of the project team members will switch their primary role to that of software developer or tester, with a secondary role assigned to one of project management, requirements, or architecture. Again, it is tentatively planned that the project team will interact with other OMSE project teams, trading SQA tasks between individual practicum projects. The proposed organizational structure for Phase 2 is:
2.3 Activities, Tasks, Resources
2.3.1 Work Breakdown and Tasks
An initial Work Breakdown Structure (WBS) for the project is provided below. This reflects the current high-level understanding of the tasks required to complete the Project, and will be used in subsequent sections for dependency planning, resource allocation & schedule estimation. It is expected that this WBS will be periodically refined throughout the project life cycle.