Software Project Management Plan



STARS3 Project

15-413 Software Engineering

Fall 2000

Carnegie Mellon University

Pittsburgh, PA 15213











Revision History:

Version R0.1 9/22/97 Robin Loh. Created

Version R0.2 9/07/00 Joyce Johnstone. Revised

Preface:

This document addresses the requirements of the STARS3 system. The intended audience for this document are the designers and the clients of the project.

Target Audience:

Client, Developers

STARS3 Members:

(List team members)

Table of Contents

1. Introduction

1.1 Project Overview

1.2 Project Deliverables

1.3 Evolution of the Software Project Management Plan

1.4 Reference Materials

1.5 Definitions and Acronyms

2. Project Organization

2.1 Process Model

2.1.1 Project Planning
2.1.2 Requirements Analysis
2.1.3 System Design
2.1.4 Analysis Review
2.1.5 Client Project Review
2.1.6 Functional Prototype Demonstration
2.1.7 Object Design Phase
2.1.8 System Integration Prototype Demonstration
2.1.9 Implementation
2.1.10 Unit Testing
2.1.11 System Integration
2.1.12 System Testing
2.1.13 Manual Integration
2.1.14 Client Presentation
2.2 Organizational Structure

2.2.1 Teams and Tasks
2.3 Organizational Boundaries and Interfaces

2.3.1 Electronic BBoard Communication
2.3.2 Meeting Times
2.4 Project Responsibilities
2.4.1 Project Management
2.4.2 Coach
2.4.3 Group Leader
2.4.4 Architecture Liason
2.4.5 Documentation Editor
2.4.6 Configuration Manager
2.4.7 Toolsmith
2.4.8 CASE Tool Manager

3. Managerial Process

3.1 Management Objectives and Priorities

3.2 Assumptions, Dependencies and Constraints

3.2.1 Assumptions
3.2.2 Dependencies
3.2.3 Constraints
3.3 Risk Management

3.4 Monitoring and Controlling Mechanisms

4. Technical Process

4.1 Methods, Tools and Techniques

4.2 Software Documentation

4.3 Project Support Functions

4.4 Work Elements, Schedule and Budget

4.4.1 Overall Project Plan
4.4.2 Team plans

Revision History:

Version 0.1 9/22/1998 Robin Loh. Created
Version R0.2 9/07/00 Joyce Johnstone. Revised

Preface:

This is the controlling document for the STARS3 project. It specifies the technical and managerial approaches to develop the software product. As such it is the companion document to Requirements Analysis Document (RAD). Changes in either may imply changes in the other document. All technical and managerial activities required to turnover the deliverables to the client are included. This includes scheduling, identification of tasks, and factors that may impact the project and planning.

Target Audience:

This document is intended for the members of the STARS3 project, clients, designers, and project management.

Project Members:

Bernd Bruegge, Eric Nyberg, Marc Kellner, Alan Black, Joyce Johnstone, Jim Beck, Oliver Creighton, Will Ross, Kannan Ramaswamy, Zia Syed, Yevgeny M. Bokk, Christian Buergy, Eugene Cheleshkin, Tom Min-Tien Chen, Aaron Gideon Goldstein, Kai Huang, Yan Ke, David Ryan Koes, David Kogan, Roman Kurin, Daniel Siu Ping Kwok, Donovan P. Lange, Ted M Lin, Matthew J. McGrath, Kevin C. Miller, Stephen P. Opalenski, Qian Shen, Shalin U. Sheth, Anubhav Singh, Justin L. Sovich, Cort William Stratton, Nathan V. Strom, Chien Tuan Tseng, Yang Wang, Alice Wu

1. Introduction

The cost of maintaining nuclear reactors rises as operating plants age. Additionally, maintenance procedures and related technical information are paper documents that are aging, costly to maintain, and do not deliver information at the point of maintenance in an easy to use format. The goal of the STARS3 project is moving this antiquated system onto a new one, which uses the latest technology. The new system will address many of the down falls of the older paper system and improve the usability of the entire process.

1.1 Project Overview

This document is intended for the members of the project describing the managerial aspects and technical aspects. The document is intended for planning and scheduling purposes, and serves as a summary document of the deliverables expected from each of the teams.

The schedule of project phases and milestones is shown below in Table 1. Each phase results in a document that must be approved by project management and the client liaison before it is baselined. (The baselined document is placed under configuration management).

Table 1: Project Schedule

Date

Project Phases

Project Milestones

Aug 6 - Aug 28

Requirements Elicitation

Aug 29

Project Presentation by Clients

Aug 29 - Sep 12

Project Planning

Sep 13 - Oct 19

Requirements Analysis

Oct 26 - Oct 31

Analysis Review

Oct 24 - Nov 10

System Design

Nov 11 - Nov 17

Object Design

Nov 14

Project Review with Client

Nov 21

Project Agreement

Nov 18 - Nov 22

Implementation & Unit Testing

Nov 30

Object Design Revieww

Nov 28 - Dec 5

System Integration & System Testing

Nov 25

Internal Project Review (functional prototype)

Dec 7

Project Acceptance by Client


1.2 Project Deliverables

The project will develop Class V IETMs based on paper documents from Siemens nuclear reactors. Perform simulated inspection and repair tasks based on Class V IETMs. The user will interact with the IETM using speech and manual commands simultaneously. The speech component will also demonstrate using conversational capabilities of the user interface. The design will allow interruptions and switching between tasks.

The following items will be produced by the STARS3 System:
The STARS3 System documentation will describe the principles of operation. The delivery consists of a presentation of the system, a demonstration of the working system and the successful passing of the acceptance test.The client expects the acceptance test to be successfully demonstrated on Dec. 7, 2000 from 8:30 am to 10:20 am. All work deliverables will be provided online on a project homepage. The work products will also be delivered on a CD-ROM, Dec 12, 2000.

1.3 Evolution of the Software Project Management Plan

The software project management plan is under version control. Proposed changes and new versions of the plan are announced on the course web page and are made available to all the project members.

1.4 Reference Materials

1.5 Definitions and Acronyms

API Applications Programming Interface
CASE Computer Aided Software Engineering
CVS Concurrent Versions System
GUI Graphical User Interface
STARS3 Sticky Technology for Augmented Reality Systems
JDK Java Development Kit
ODD Object Design Document
OMT Object-Oriented Modeling Technique
RAD Requirements Analysis Document
TOGETHER-J Visual modeling tool for Java
SDD System Design Document
SPMP Software Project Management Plan
UML Unified Modeling Notation

2. Project Organization

2.1 Process Model

The project is initiated on Aug 29, 2000 and terminated with the end of the semester on Dec 7, 2000. Major milestones are the Client Project Review on Nov 14, 2000 and the Client Acceptance Test on Dec 7, 2000.

The project uses an object-oriented design methodology based on the UML (Unified Modeling Language) and uses Together® in the development of the software. The development process is organized in several activities. The members of the project are organized in teams. At the end of each activity up to and including testing, each team submits documents describing the achievement of the activity. The individual approved documents produced by the teams are considered work products and are part of the software documentation. The team documents are under version control using CVS running on a Linux platform. Links to the team documentation are available from the course electronic bulletin boards. The links to the major documents on the CVS server are also available from the project home page. The activities and milestones are described in the next following sections.

2.1.1 Project Planning

Project planning includes description of project tasks, activities and functions, dependencies, resource requirements and a detailed schedule. This activity results in the software project management plan for the STARS3 System. Another output of the planning phase is the project agreement, which is issued after the design activity is completed.

2.1.2 Requirements Analysis

The requirements analysis activity takes the problem statement and reviews it in terms of consistency, completeness and feasibility. During this activity, a set of models of the proposed system is determined by interacting with the clients resulting in the requirements model. The main part of the requirements model are four models: the use case model describing the complete functionality of the system, the object model, the functional model and the dynamic model.

2.1.3 System Design

The purpose of the system design activity is to devise a system architecture that maps the analysis model to the chosen target environment. The major part of the system design phase is the design of subsystems, that is, the decomposition of the system with respect to the chosen target platform. The system design activity also refines the use cases from the analysis model and describes in terms of interaction diagrams how the objects interact in each specific use case.

2.1.4 Analysis Review

Review of software project management plan, requirements analysis and design. The meetings will take place on Oct 26 from 9:00- 10:20 in Porter A18B. The Analysis Review consists of a set of presentations given by members of the STARS3 project. Project Management will review these slides and post their comments on the 15-413 web page.

2.1.5 Client Project Review

Review of project plan, requirements analysis and design decisions. The client liaison will be present at the meeting. The meeting will take place on Nov 14 from 9:00-10:20 in Porter A18B. The Client Project Review presentation slides will be made available to the client.

2.1.6 Functional Prototype Demonstration

This activity involves successful execution of a functional prototype of the STARS3 System using stubs. The functional prototype of the STARS3 system will be presented during the internal review Nov 30 2000.

2.1.7 Object Design Phase

The object design phase specifies the fully typed API for each subsystem. New classes are added to the analysis object model if necessitated by the system architecture. Attributes and methods for each object are fully typed.

2.1.8. System Integration Prototype Demonstration

This activity involves the demonstration of a fully functional system prototype based on the subsystem decomposition. Each subsystem is represented by its service. All service operations can be called by other subsystems using remote method invocation. The implementation of the services can be stubbed out.

2.1.9 Implementation

The focus of this activity is on coding the individual objects described in the object design document.

2.1.10 Unit Testing

During unit testing, test suites are designed and executed for objects or collections of objects in each subsystem. Unit testing enables the individual subsystems to be tested independent from the status of the other subsystems. The result of this activity is part of the test manual that describes how to operate the test suite and how to interpret the test results.

2.1.11 System Integration

During this activity an integration strategy is devised, that specifies the order in which the subsystems of the STARS3 system are integrated and tested with respect to the use cases defined in the analysis model. The system integration strategy and the subsystem tests are described in the Test Manual.

2.1.12 System Testing

Structural Testing: This activity tests the major data paths in the complete STARS3 System.
Functional Testing: Tests the major functionality (use cases) with the complete STARS3 System.
The basis for the functional testing activity is the test manual which is revised according to the results of the system testing phase.
Alpha-test (Client Acceptance Test): The system is tested to make sure it passes the client acceptance criteria as defined in the project agreement.

2.1.13 Manual Integration

During this activity, the project deliverables are revised. As a result, a complete set of documents consisting of the software project management plan, requirements analysis document, software design document, test manual and source code is made available on the project home page. The system documentation will also be printed on a CD. The clients will receive a copy of the CD.

2.1.14 Client Presentation

At the Client Presentation, a slide presentation and software demonstration will be given in Porter Hall A18B at Carnegie Mellon University. The software developed during the project will be demonstrated for the client acceptance test. The clients will attend the client acceptance test in person or via video conference.

2.2 Organizational Structure

Below is the organizational chart of the people involved in the development of the STARS3 system:

STARS3 Org Chart

Figure 1: Organization Chart for STARS3 Project


2.2.1 Teams and Tasks

Accepts query from user interface in either free form text format or as refined query, depending on UI identification of command.

Accepts either query or error code from natural language server.

Accepts an XML document and new state from the database. New state is stored by application server. XML document is returned to UI, as requested by user.

2.3 Organizational Boundaries and Interfaces

2.3.1 Electronic BBoard Communication

The Lotus Notes Databases shown in Table 2 will be used for electronic communication in the STARS3 project. Note that these databases are intended to replace Andrew bulletin boards academic.cs.15-413 that have been set up for this course (The Andrew bboards are neither used nor read by project management).

Table 2: Electronic Bboards for STARS3 Project

Announcements

Lecture and project announcements

Discuss

Group discussion

Issues

Structured discussion providing for Issues, Proposals, Arguments, and Resolutions

Client Discuss

Primary forum for interchange with the clients

Handin

For electronic submission of homework

Review

For electronic sequencing of document reviews

Help

Request for assistance in course material, software applications

Architecture Team Discuss

Discussion about the Architecure

Application Server Team Discuss

Discussion about the Application Server

IETM Database Team Discuss

Discussion about the IETM Database

Multimodal User Interface Team Discuss

Discussion about the Multimodal UI

Natural Language Team Discuss

Discussion about Natural Language

Every team member has to:
Communication with the client is primarily via the Client BBoard. As the need arises direct e-mail and/or telephone contact is set up with specific consultants within the client organization.

2.3.2 Meeting Times

Application Server : Wednesday 4:45pm, Smith 231

2.4 Project Responsibilities

Management of the STARS3 System is done with the following roles: project management, coach, group leader, Architecture liaison, documentation editor, configuration manager, toolsmith, CASE tool manager, webmaster.

2.4.1 Project Management

The project management function has the following responsibilities:

2.4.2 Coach

The coach has the following responsibilities:

2.4.3 Group Leader

The group leader leads an individual team. The main responsibility of the group leader is to manage the action items of the group. In addition he or she has the following responsibilities:

2.4.4 Architecture Liaison

The liaison interacts with the liaisons of the other teams and with the project management. Each team has a liaison to the Architecture Team. The responsibilities of the liaison are:

2.4.5 Documentation Editor

The editor in each team is responsible for producing the documentation of the current project phase and:

2.4.6 Configuration Manager

The responsibilities of the configuration manager in each team are:

2.4.7 Toolsmith

The responsibilities of the toolsmith in each team are:

2.4.8 CASE Tool Manager

The responsibilities of the CASE tool manager in each team are:
Table 3: Group Leader Assignments
Project Phase Group Leader
Analysis Mathew McGrath
Design Anand Marathe
Implementation & Testing Daniel Kwok


Table 4: Other Team Assignments
API Engineer Justin Sovich
Integration & Testing Eugene Cheleshkin
Documentation Editor Aaron Goldstein
Configuration Manager
Toolsmith
CASE Tool Manager

3. Managerial Process

3.1 Management Objectives and Priorities

The philosophy of this project is to provide a vehicle for students to get hands-on experience with the technical and managerial aspects of a complex software problem. The emphasis is on team work and encouraging individual teams to work together towards the goal of implementing the STARS3 system completely.

3.2 Assumptions, Dependencies and Constraints

The functionality of the STARS3 System is achieved when the client acceptance test can be executed.

Each software development activity results in one or more documents to be submitted to the project management before the deadline. Each document is reviewed at least once by the project management before it is accepted and becomes a baseline document.

The following documents will be graded: SPMP, RAD, SDD, ODD, TM and are worth each 10 points. The agenda, minutes, action items and issues for each weekly team meeting have to be posted. The complete set of these is also worth 10 points. We will give a project A to everybody who participates in the project if all the project deliverables are delivered and the STARS3 system passes the client acceptance test as defined in the requirements analysis document.

The STARS3 System is a project that puts emphasis on collaboration, not competition between the students. We will not accept a system that is done by one team alone.

3.2.1 Assumptions

3.2.2 Dependencies

3.2.3 Constraints

3.3 Risk Management

Risks associated with the application server module and implementation.

Risk: Communication failure with other teams.
Contingency: The Application Server team needs to remain in contact with all three other teams at all times. This goal must be actively pursued, using inter-team liaisons and other forms of communication.

Risk: Performance Issues. Presumably, the application server will not be running in an environment with strong resource limitations, but performance is still an issue.
Contingency: Try to keep the system "slim and lean". Test the final system against several Java Virtual Machines, to see which provides the best runtime performance. For reference, see Sun's HotSpot Server VM, and IBM's virtual machine.

Risk: Development expectations in one or more teams are not met.
Contingency: Try to make the weakest possible assumptions regarding the functionality available from other teams. Ideally, there could be some sort of modularity, allowing teams to smoothly implement subsets of desired functionality, and allowing the final system to cope as effectively as possible.

3.4 Monitoring and Controlling Mechanisms

For each project meeting each team produces an agenda and the minutes of the meeting. The minutes have to contain explicitly the action items assigned during the meeting. The agenda and minutes are posted on team specific bulletin boards by the minute taker of the meeting.

The baseline documents are reviewed by the project management. It is expected that each document undergoes one or more iterations.

4. Technical Process

4.1 Methods, Tools and Techniques

Our development methodology is based on UML.The following tools are available to support the management and development of the STARS3 project:

Netscape Communicator Internet browser
Together-J CASE tool for UML by Object International
Adobe Acrobat 3.0 Portable Document Format Software Reader
Powerpoint 4.0 Slide Presentation program


4.2 Software Documentation

The following activities result in a project deliverable:
Project Planning: Software Project Management Plan (SPMP)
Requirements Analysis: Requirements Analysis Document (RAD)
Analysis Review: Analysis Review Slides
System Design: System Design Document (SDD)
Client Review: Client Review Slides
Object Design: Object Design Document (ODD)
Reviews: Review Presentation Slides
Implementation and Unit Testing: Code
System Integration and System Testing: Test Manual
Delivery: Client Acceptance Test Slides

4.3 Project Support Functions

None.

4.4 Work Elements, Schedule and Budget

All work on the STARS3 project is being conducted as part of the course 15-413, Software Engineering. Since the course is 12-unit/hours, and there is approximately 5-8 hours of class time, homework, assigned readings and studying, we are left with approximately 4-7 hours a week for working on the project. Since this is part of a course, there is no monetary budget.

4.4.1 Overall Project Plan

The overall project plan follows the sawtooth model, a modified waterfall model. 3 prototypes have to be delivered: A graphical user interface, a functional prototype and a system integration prototype. Analysis is started before Project Planning is finished. System Design is followed by Object Design. Important Milestones are the Analysis Review Oct 26, the System Design on Nov 14, and the Object Design Review on Nov 30. Implementation and Unit Testing are scheduled to overlap significantly. System Integration is scheduled to immediately follow Unit Testing. System Testing starts immediately after system integration and leads to the Client Acceptance Test on Dec 7.

4.4.2 Team plans

To develop, design, implement, and support the Application server piece of the STARS3 project.