Software Project Management Plan

PAID Project

15-495 Advanced Software Engineering

Spring 1999

Carnegie Mellon University

Pittsburgh, PA 15213


 























Revision History:

Preface:
This is the controlling document for the PAID 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 PAID project, clients, designers, and project management.
PAID Members:
Bernd Bruegge, Elizabeth Bigelow, Thomas Hawley, Eric Stein, Joyce Johnstone, David Garmire, Georgios Markakis, Euijung Ra, Qiang Rao, William Ross, Pooja Saksena, Stephane Zermatten

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 B-Board 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 Liaison
2.4.5 Documentation Editor
2.4.6 Configuration Manager
2.4.7 Toolsmith
2.4.8 CASE Tool Manager
2.4.9 Web-master

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

1. Introduction

The PAID, Platform for Active Information Dissemination, project described in this document covers the development of a prototypical application for Mercedes-Benz. PAID allows the dealers of Mercedes-Benz to access information in a timely, secure and efficient manners. This the third iteration of the project, working in conjunction with the TUM students.

1.1 Project Overview

This document describes the managerial and technical aspect of our project development. It serves as a summary of the deliverables expected from each team, and the plans and schedules for achieving these goals.

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 base-lined. (The base-lined document is placed under configuration management).

Week
Project Phases
Project Milestones
Jul. 17 Requirements Elicitation  Project Presentation by Clients 
Jan. 11 Project Planning  
Jan. 18 Project Planning  
Jan. 25 Project Planning  
Feb. 1 Requirement Analysis Software Project Management Plan Due
Feb. 8 Requirement Analysis  
Feb. 15 Requirement Analysis  
Feb. 22 System Design Document Requirement Analysis Document Due
Mar. 1 Object Design Document Requirement Analysis presentation
Mar. 8 Object Design Document System Design Document Due
Mar. 15 Object Design Document Object Design Document Due & System Design Document Presentation
Mar. 22 Spring Break  Spring Break 
Mar. 29 Test Manual Object Design Document Presentation
Apr. 5 Test Manual Test Manual Due
Apr. 12 Implementation Implementation Review
Apr. 19 Implementation  
Apr. 26 Implementation Project Acceptance by Client (via video conference)

Table 1. Project Schedule


 















1.2 Project Deliverables

The project will produce a running system that allows secure, reliable and intelligent dissemination of information from Daimler-Benz to their dealers worldwide.

The following items will be produced by the PAID System:

The PAID 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 remotely via the Internet on Apr. 26th, 1999. All work deliverables will be provided online on a project home page. The working products will also be delivered on a CD-ROM, Apr. 28th, 1999.

The PAID acceptance test will consist of successful demonstration of the supported scenarios via video conferencing.

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 announcement bulletin board 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 Version Software
GUI Graphical User Interface
PAID Platform for Active Information Dissemination
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
IOU Ingo's Object Update
UML Unified Modeling Notation
 

2. Project Organization

2.1 Process Model

This is the third iteration of the PAID project, in conjunction with the TUM students. The first iteration of the project is initiated on Aug. 26, 1998 and terminated at the end of the semester on Dec 10, 1998. A working version of the system will be delivered to the client during the Client Acceptance Test on Apr. 26th, 1999.

An object-oriented design is used during all phases of the project. Software re-engineering is applied to the original PAID project and the TUM PAID project. All subsystems are required to produce documents. The documents are later combined. The combined documents are under version controls, and they are also made available on the course webpage.

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 PAID 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 describes the complete functionality of the system. The object model describes the objects used in the system. The functional model describes the functionality of the system. And the dynamic model describes the flow of event in the system.

2.1.3 System Design

The purpose of the system design 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 also refines the use cases from the analysis model. And it describes the object interactions in terms of interaction diagrams for each use case.

2.1.4 Analysis Review

Review of software project management plan, requirements analysis and design. The meetings will take place during the week of Mar. 1st. The Analysis Review consists of a set of presentations given by members of the PAID project. Project Management will review these slides and post their comments on the 15-495 discuss b-board.

2.1.5 Client Project Review

This will consist of a review of project plan, requirements analysis and design decisions. Client project review is not currently scheduled. The client liaison will be present at the meeting once the date is determined. 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 PAID System using stubs. The functional prototype of the PAID system will be presented during the internal review a couple weeks before the Client Acceptance Test.

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. Each team will submit the API by posting it on CVS. This ensures that other teams have access to APIs and can configure their code to be consistent with other subsystems.

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 services. All service operations can be called by other subsystems. The implementation of the services can be stubbed out. The prototype will consist of an implementation of all the scenarios being demonstrated.

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. The test cases are part of the Test Manual.

2.1.11 System Integration

During this activity an integration strategy is devised that specifies the order in which the subsystems of the PAID 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 PAID System.

Functional Testing: Tests the major functionality (use cases) with the complete PAID System. The basis for the functional testing activity is the test manual which is revised according to the results of the system testing phase.

Client Acceptance Test: The system is tested to make sure it passes the client acceptance criteria as defined in the project agreement. The test schedule is posted as a part of the overall project schedule.

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. Each of the students taking the course as well as the clients will receive a CD.

2.1.14 Client Presentation

At the Client Presentation, a slide presentation and software demonstration will be given in the Intelligent Workplace 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. The demonstration will have different presenters for each of the scenarios being supported.

2.2 Organizational Structure

Below is the organizational chart of the people involved in the development of the PAID system:
Figure 1. Organization Chart for PAID Project

The clients of the PAID project are:
Helmuth Ritzer, Stephen Wolf

The project managers are:
Bernd Bruegge, Elizabeth Bigelow

The infrastructure team consists of:
Joyce Johnstone (Web Master and Lab Management) and Eric Stein (Lotus Notes and Demo Machines)

The project consultants are:
Guenter Tuebner

2.2.1 Teams and Tasks

This section describes the teams working on the PAID subsystems and their tasks:

2.3 Organizational Boundaries and Interfaces

2.3.1 Electronic BBoard Communication

The Lotus Notes Databases shown in Table 1 will be used for electronic communication in the PAID 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 
Help  Request for assistance in course material, software applications 
Architecture Team Discuss  Discussion about the Architecture 
Event Service/Learning Team Discuss  Discussion about Learning 
Billing Discuss  Discussion of Billing 

Table 2. Electronic BBoards for PAID Project


 


















Every team member must:

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

There is a weekly project meeting for each group. The initial meeting times are:
Group Day Time Location
Learning Monday 5:30-7:00pm Smith 100
Billing Monday 5:30-7:00pm Smith 100
Architecture Monday 5:30-6:30pm  Smith 100

2.4 Project Responsibilities

Management of the PAID System is done with the following roles: project management, coach, group leader, Architecture liaison, documentation editor and liaison, configuration manager, toolsmith, CASE tool manager, web-master.

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:

2.4.9 Webmaster

The responsibilities of the web-master in each team are: Table 2 describes the group leader assignments and Table 3 indicates the other team assignments.
Task Billing Learning
Requirements Analysis  Euijung Ra  Qiang Rao
System Design  Georgios Markakis  William Ross
Object Design  Georgios Markakis  Stephane Zermatten
Implementation  Pooja Saksena  David Garmire
Testing  Pooja Saksena   Qiang Rao

Table 3. Team Leader Assignments


 



 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Role Billing Learning
CASE Tool Manager Everyone Everyone
Toolsmith  Pooja Saksena William Ross
Architecture Liaison Everyone Everyone
Configuration Manager Stephane Zermatten Stephane Zermatten
Webmaster Georgios Markakis Qiang Rao
Documentation Editor Euijung Ra David Garmire
Coach Thomas Hawley Eric Stein

Table 4. Team Role Assignments


 
















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 PAID system completely.

3.2 Assumptions, Dependencies and Constraints

The functionality of the PAID 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.

[Grading]

The PAID 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.1.1 Billing
3.2.1.2 Learning

3.2.2 Dependencies

3.2.2.1 Billing
3.2.2.2 Learning

3.2.3 Constraints

3.2.3.1 Billing
3.2.3.2 Learning

3.3 Risk Management

3.3.1 Billing

Risk:  Lack of specific requirements from the client
Contingency:  Billing will make all efforts to implement the requirements put forth by the client. However, in the case that requirements are not produced, Billing will research and develop its own assumptions, and build its system on those.

Risk:  Lack of applicable 3rd party billing software
Contingency:  Especially in the case that the client does not provide us with specific requirements, we will rely significantly on 3rd party software research.  If there is no such software applicable to PAID Billing, design of the Billing subsystem will be made based primarily on our own understanding of the problem.

3.3.2 Learning

Risk: Code could be computationally intensive
Contingency: Fundamentally, the learning system should be written with fast algorithms and fast 3rd party code. The data mining process will be performed off-line, since it will be the most costly of all the learning operations. Finally, to avoid increased iterations, there will be a default, less intelligent behavior, that the system will recommend when appropriate.

Risk: No ability to use 3rd party code
Contingency: A decision tree algorithm will yield a sub optimal solution for all the scenarios and will take a relatively shorter time to implement. The learning system, therefore, will not over apply the various learning techniques available. When looking for 3rd party code, however, we will not search for too much domain specific code; but rather we will try to modify the code we find.

Risk: No 3rd party packages in Java available
Contingency: In this case we will write Java "wrappers" to implement code written in other languages. We can also obtain source code for packages that enable cross-compiling.

Risk: Need more than 1 learning algorithm for optimal performance
Contingency: We could either use multiple learning methods (most likely using multiple 3rd party packages). Otherwise, we must accept a suboptimal but nonetheless effective single solution.

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 a combination of use cases (from the OOSE methodology) [Jacobsen 92] combined with the OMT methodology [Rumbaugh 1991].The following tools are available to support the management and development of the PAID project:
 
 
Netscape Communicator Internet browser
Adobe PageMill 2.0, Claris Home Page 2.0, FrontPage HTML editors
Together-J CASE tool for UML by Object International
Adobe Acrobat 3.0 Portable Document Format software reader
PowerPoint 4.0 Slide presentation program
VOYAGER Supports event hierarchy
Macromedia Director 6.0 Prototype presentation

 

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

PAID had the following support functions that were provided from outside the main PAID team:

4.4 Work Elements, Schedule and Budget

The schedule for the PAID project is as shown in the table above. The class material was structured in such a way that each class covers material that was needed in the next stage of the PAID project.

4.4.1 Overall Project Plan

The overall project plan follows the sawtooth model, a modified waterfall model. 3 prototypes have to be delivered:
  1. An efficient, modularized Learning subsystem
Analysis is started before project planning is finished. System Design is followed by Object Design. 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 Apr. 26th.

4.4.2 Team plans

The common team plan is shown in the following GANTT chart:

TIME ----------------->

Planning
      Analysis ( RAD)
                                System Design( SDD)
                                                            Object Design ( ODD)
                                                                                            Implementation
                                                                                                          Unit Testing
                                                                                                                    Integration Testing
                                                                                                                                                Client Acceptance
 
 
 
 
 
 


This page is hosted by the Chair for Applied Software Engineering of the Technische Universität München.
Imprint (Impressum)