| Revision | Description | Date |
| 0.1 | Original Submission | 17 February 1997 |
| 1.0 | Initial Baseline Version | 24 February 1997 |
| 2.0 | Final Submission | 28 April 1997 |
| 1.1 | PROJECT OVERVIEW | 1 |
| 1.2 | PROJECT DELIVERABLES | 1 |
| 1.3 | EVOLUTION OF THE SPMP | 2 |
| 1.4 | REFERENCE MATERIALS | 2 |
| 2.1 | PROCESS MODEL | 2 |
| 2.2 | PROJECT RESPONSIBILITIES | 2 |
| 3.1 | MANAGEMENT OBJECTIVES AND PRIORITIES | 4 |
| 3.2 | MANAGEMENT MEETINGS | 4 |
| 3.3 | RISK MANAGEMENT | 4 |
| 3.4 | MONITORING AND CONTROLLING MECHANISMS | 4 |
| 3.5 | STAFFING PLAN | 5 |
| 4.1 | METHODS, TOOLS, AND TECHNIQUES | 5 |
| 4.2 | SOFTWARE DOCUMENTATION | 5 |
| 5.1 | WORK PACKAGES | 6 |
| 5.2 | DEPENDENCIES | 6 |
| 5.3 | RESOURCE REQUIREMENTS | 6 |
| 5.4 | BUDGET AND RESOURCE ALLOCATION | 6 |
| 5.5 | SCHEDULE | 6 |
| WBS AND SCHEDULE | 7 |
| COST SCHEDULE STATUS REPORT | 14 |
The overall objective of the MJY Team Project is to establish
a web site that can be used as a resource for information concerning
Software Project Management (SPM). The project requirements will
define, in general terms, the setup of the web site, topics for
available information concerning Software Project Management,
and user activities (if any). Official project requirements are
contained in the MJY Team Software Requirements Specification.
The MJY Team will develop this web site by following software management processes and procedures learned during the Software Systems Engineering (SWSE) 625 course. As part of this process, they produce the following management documents and software products as deliverables:
| Deliverable | Date Due |
| Software Requirements Specification (Draft) | 3 February, 1997 |
| Requirements Management Plan (Draft) | 3 February, 1997 |
| Risk Mitigation Plan (Draft) | 10 February, 1997 |
| Project Management Plan (Process) | 17 February, 1997 |
| Project Management Plan (Draft) | 24 February, 1997 |
| Configuration Management Plan (Draft) | 3 March, 1997 |
| Quality Assurance/Test Plan (Draft) | 3 March, 1997 |
| Build 1 Release | 4 March, 1997 |
| Status Report | 24 March, 1997 |
| Build 2 Release | 1 April, 1997 |
| Status Report (to class) | 7 April, 1997 |
| Build 3 Release | 15 April, 1997 |
| Status Report (Final) | 21 April, 1997 |
| Software Requirements Specification (Final) | 28 April, 1997 |
| Requirements Management Plan (Final) | 28 April, 1997 |
| Risk Management Plan (Final) | 28 April, 1997 |
| Project Management Plan (Final) | 28 April, 1997 |
| Configuration Management Plan (Final) | 28 April, 1997 |
| Final Program Build | 28 April, 1997 |
The Team will develop these documents and builds through an iterative
process. The Team member assigned each management role will be
responsible for developing the corresponding draft plan, which
will then be distributed to and commented on by the rest of the
Team, either through Team meetings or electronic mail. The manager
will then incorporate those comments and develop a draft which
will be given to Dr. Bechtold for comment. Based on those comments
and the further Team review, the manager will revise and produce
the final deliverable. The developer will produce the site through
a similar evolution, incorporating content and comments received
from the rest of the Team.
Updates to the SPMP shall be provided in accordance with the paragraph
1.2 delivery schedule. Modifications to the SPMP shall be done
in accordance with the procedures contained in the MJY Team Configuration
Management Plan.
MJY Team Software Requirements Specification, dated 24 April, 1997
MJY Team Requirements Management Plan, dated 21 April, 1997
MJY Team Risk Mitigation Plan, dated 7 April, 1997
MJY Team Software Design Document, 24 April, 1997
MJY Team Configuration Management Plan, 8 March, 1997
MJY Team Quality Assurance/Test Plan, 12 April, 1997
The project shall utilize an evolutionary development approach,
with three interim deliveries prior to the final build. Content
of each build shall be determined by the Program Manager with
direct input from the customer regarding need dates for required
functionality.
The MJY Team will be made up the following Roles, with the listed
responsibilities.
2.2.1 PROGRAM MANAGER (Pat McNeece)
The Program Manager is responsible for working with the customer to identify all requirements; is responsible for submitting the customer's requirements to the Configuration Control Board for analysis and impact; is responsible for communicating requirements impact to the customer; is
responsible for negotiating requirements modification when needed;
and is responsible for delivery of the Test Analysis Report to
the customer. The Program Manager shall be responsible for initial
baseline approval and shall be the approval authority for any
baseline modifications.
2.2.2 PROJECT MANAGER (Paul Young)
The Project Manager shall be responsible for defining and controlling
project work activities and schedules. Other team members shall
work in conjunction with the project manager to define the elements
of their task assignments, establish a schedule baseline, collect
metric data to assess performance against that baseline, and conduct
re-baselining activities as required. The Project Manager shall
submit the initial baseline and any baseline modifications to
the Program Manager for approval.
2.2.3 CONFIGURATION MANAGER (CM) (Jim Mundell)
The CM is responsible for maintaining a matrix of all customer approved requirements; is responsible for oversight of the requirements change control process; is responsible for applying changes to requirements matrix; is responsible for maintaining the modification history of requirements.
2.2.4 QA/TEST MANAGER (Ray Miller)
The QA/Test Manager is responsible for verifying that the delivered product satisfies the approved requirements; is responsible for documenting the results of the requirements verification in a Test Analysis Report.
2.2.5 CONFIGURATION CONTROL BOARD (CCB)
The CCB, which is composed of members of the MJY Team, is responsible
for analyzing and evaluating requirements for feasibility and
impact to the project.
2.2.6 RISK MANAGER (Annette Mirantes)
The Risk Manager is responsible for identifying the risks likely to compromise the project success; is responsible for assessing the loss probability and loss magnitude for each identified risk; will
prioritize the risks as they are identified and bring them to
the attention of the group; is responsible for planning for, resolving
and monitoring each risk item.
2.2.7 DEVELOPER (Kim Jordan)
The developer is responsible for designing a system satisfying
the requirements; is responsible for creating prototypes, as necessary,
for feasibility studies; is responsible for creating and changing
all source files in accordance with the change and control process;
is responsible for documenting the source files for maintenance
purposes. All Team members will be responsible for researching
and forwarding appropriate content to the developer for incorporation
into the web site.
2.2.8 CUSTOMER (MJY Team)
The customer is responsible for defining and approving all requirements, and all modification to requirements.
2.4.9 PRODUCT MANAGER (Darrin May)
The product manager is responsible for periodically reviewing
the content, organization and style of the website in order to
ensure that:
1) the site is easily navigable and its organization coherent to the uninitiated user,
2) the different sections of the site are properly integrated with each other in order to present a complementary view of the Software Risk Management theme, and
3) the quantity and quality of information meets user requirements
and is consistent throughout the site.
3.1 MANAGEMENT OBJECTIVES AND PRIORITIES
The objective of this project is to allow all team members the
opportunity to learn the tasks and develop the deliverables corresponding
to their assigned role. In addition to developing the deliverable
documents, all Team members will be expected to perform their
tasks in accordance to the processes and procedures outlined in
those plans.
The MJY Team will meet at least weekly to review status of the
project, review and comment on draft documentation, report on
individual assignments and progress, and assign and close action
items.
Risk identification, assessment, tracking and mitigation activities
shall be in accordance with the MJY Risk Mitigation Plan.
3.4 MONITORING AND CONTROLLING MECHANISMS
The project shall be managed by means of an established Work Breakdown
Structure (WBS). This WBS shall be the basis for establishing
project schedule and for definition of project tasks and deliverables.
The project manager shall collect actual completion and resource
utilization data from the team members in order to calculate actual
performance against predicted cost and schedule. This data shall
be presented to the program manager in the form of a weekly project
status report.
Task status and resource utilization statistics shall be reported
to the Project Manager utilizing the elements of the WBS. The
project shall be controlled using Microsoft Project to establish
project tasks, dependencies and schedule. WBS activity decomposition
shall be such that tasks can be completed in a maximum one week
time frame. Credit for task progress shall only be awarded upon
task completion. Team members shall provide weekly statistics
on resource expenditures by task as well as information concerning
task completion. This information shall then be compiled to provide
cost and schedule status to the Program Manager. This status shall
include planned cost and schedule by task, actual cost and schedule
by task, overall project cost and schedule variances, estimated
project completion date and project estimate at completion.
The plan for staffing the web site development effort shall be
as required to support the Appendix A WBS and project schedule.
Each member of the team shall be responsible for completing those
sections of the WBS corresponding to their assigned duties as
specified in section 2.2. All team members shall be responsible
for reviewing each work product produced by the team.
4.1 METHODS, TOOLS, AND TECHNIQUES
Based on the requirements provided by the Program Manager, a software
design specification shall be created by the Developer. The design
will be reviewed by the Program Manager for requirements verification.
After approval, any risks identified in the requirements which
require prototyping as a mitigation technique shall be researched
and prototyped in accordance with the Risk Mitigation Plan. If
the use of external software packages is required in the design,
the necessary software shall be acquired. An evolutionary development
approach shall be utilized to create partially functional systems
for test and user interface review throughout the development
period. Modifications to the system requested via feedback and
changes in requirements, as well as software baselines, shall
be made in accordance with the Configuration Management Plan.
The software design and the commented source files shall serve
as software documentation for the project.
Appendix A provides the WBS and Schedule which depicts the activities
and tasks to be completed in the development of the MJY Team Software
Risk Management WWW Site.
Task dependencies are as indicated in the Appendix A WBS and Schedule.
Planned and actual resource requirements, in terms of hours required
by each activity described in section 2.2, are included in the
Appendix B Cost Schedule Status Report (CSSR).
5.4 BUDGET AND RESOURCE ALLOCATION
Planned and actual resource allocations, in terms of hours required
by each activity described in section 2.2, are included in the
Appendix B Cost Schedule Status Report (CSSR).
Initial project WBS shall be provided by 17 February, 1997. Initial
project schedule baseline shall be established using Microsoft
Project by 24 February, 1997. Initial program build shall be released
to system test by 24 February 1997 with subsequent builds released
to system test on 17 and 31 March. Final program build shall be
released to system test by 13 April 1997. A Detailed project schedule
is included as Appendix A.