Software Project Management Plan

Revision History:

Version 0.9 9/22/1998 Robin Loh. Created.
Version 1.0 12/7/1998 Swati Gupta. Edited.
Version 1.01 12/8/98 Dan McCarriar. Final cleanup.

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, Elaine Hyder, Robin Loh, Jack Moffett, Eric Stein, Keith Arner, Swati Gupta, Russell Heywood, Joyce Johnstone, Luis Alonso, Orly Canlas, David Garmire, Jonathan Hsieh, James Lampe, Yun-Ching Lee, Wing Ling Leung, Kent Ma, Georgios Markakis, Richard Markwart, Dan McCarriar, Reynald Ong, Adam Phelps, Arnaldo Piccinelli, Euijung Ra, Qiang Rao, William Ross, Pooja Saksena, Rudy Setiawan, Timothy Shirley, Michael Smith, Barrett Trask, Ivan Tumanov, Anthony Watkins, Jonathan Wildstrom, Brian Woo, Stephane Zermatten, Andrew Zimdars

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 Liaison
2.4.5 HCI Liaison
2.4.6 Documentation Editor
2.4.7 Configuration Manager
2.4.8 Toolsmith
2.4.9 CASE Tool Manager
2.4.10 Webmaster

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

This project is aimed toward the worldwide dealer network of Mercedes-Benz. It transforms the current information distribution channels within the dealer network. PAID, the Platform for Active Information Dissemination, transfers relevant information to the dealers in a timely, secure and efficient manner. The PAID project described in this document covers the development of a prototypical application that allows the dealers of Mercedes-Benz to access relevant information on their current information system architecture.

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 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).

1.2 Project Deliverables

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

The following items will be produced by the PAID System:

• A Software Project Management Plan defining the technical and managerial processes necessary for the development and delivery of the PAID system (this document).
• An Agreement between client and developers, representing a contract between the client and the developers of what is going to be delivered.
• A Requirements Analysis Document describing the functional and global requirements of the system as well as 4 models - the use case model, the object model, the functional model and the dynamic model. This document is created in interaction with the application domain experts.
• A System Design Document describing the design goals, tradeoffs made between design goals, the high level decomposition of the system, concurrency identification, hardware/software platforms, data management, global resource handling, software control implementation and boundary conditions. This document forms the basis of the object design. This document is read by the analyst as well as the object designer.
• An Object Design Document is which is composed of two documents. The first document is an updated RAD. The code related data will be in the form of JavaDoc output from the code from each team.
• A Test Manual describing the unit and system tests performed on the PAID system before delivery along with expected and actual results. This document is used by the developers and maintainers.
• Source code for all subsystems of 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 Dec. 10, 1998 from 9:00 am to 11:00 am. All work deliverables will be provided online on a project home page. The work products will also be delivered on a CD-ROM, Dec 12, 1998.

The PAID acceptance test will consist of the supported scenarios that will be demonstrated using the network system developed for the purpose of demonstration.

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 bulletin board 15-413 announce and are made available to all the project members.

1.4 Reference Materials

• [Bruegge-Dutoit 97] Bernd Bruegge, Allan Dutoit: Model-Based Software Engineering: A Project-Oriented Approach,
• Course Manuscript.
• [Gamma 96] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns, Addison-Wesley, 1996, ISBN 0-201-63361-2.
• [Orfali-Harkey 97] Robert Orfali, Dan Harkey, Client/Server Programming with Java and CORBA, Wiley & Sons, Inc,1997.
• [Flanagan 96] David Flanagan, Java in a Nutshell, O'Reilly & Associates, Inc., 2nd edition, ISBN 1-56592-183-6.
• [JavaCard 97] JavaCard Consortium, The JavaCard 2.0 API, Draft Document, Revision July 1, 1997.
• [Rumbaugh 96] James Rumabugh,Object Oriented Modelling and Design,Prentice Hall, 1996
• [IEEE 828] IEEE Standard for Software Configuration Management Plans, ANSI/IEEE Std. 828-199.
• [IEEE 1058] IEEE Standard for Software Project Management ANSI/IEEEStd.1058.1-1987
• [IEEE 1074] IEEE Standard for Developing Software Life Cycle Processes, ANSI/IEEE Std. 1074-1991.Software Engineering Course Schedule, 15-413 Fall 1998, /projects/PAID/schedule.html
• PAID System: Problem Statement, 15-413 Fall 1998, Course Handout,/projects/PAID/courseDocs/PS/probStmt.html
  

1.5 Definitions and Acronyms

2. Project Organization

2.1 Process Model

The project is initiated on Aug. 26, 1998 and terminated with the end of the semester on Dec 10, 1998. Major milestones are the Client Project Review on Nov. 5, 1998 and the Client Acceptance Test on Dec 10, 1998.

The project uses an object-oriented design methodology based on the Objectory lifecycle process and uses UML for 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 PC platform. Links to the team documentation are available from the team home pages and 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 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 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. 22 and Oct. 27 from 9:00 - 10:20 in WeH 5409. 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-413 discuss bboard.

2.1.5 Client Project Review

This will consist of a 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. 5 from 9:00-10:20 in WeH 5409. 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 Nov. 25 1998.

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 the 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 service. All service operations can be called by other subsystems using remote method invocation. 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 a 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.

Alpha-test (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

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:

• Database
  • Store and replicate data on the dealer server database
  • Store and replicate data on the COMET server - The PAID server that supplies data to the dealer database
  • Respond to data queries from nonaffiliated dealer via an external network
  • Allow for installation of a base set of data from CD or other high-capacity medium
  • Provide local storage for aftersales database and PAID persistent storage
  • Allow for updates of data on CD or other high-capacity medium
  • Provide waterfall updates of information from the main Daimler-Benz server in Germany (push-based replication updates)
  • Allow synchronization of data on client and server computers on demand
  • Provide data upload capability for new data that needs to go to the main DB server
  • Provide user database services for the Authentication subsystem

• Network
  • Pull functionality that allows dealer to request transfer of data from remote database
  • Push functionality to send information to a dealer
  • Multicast facility to send update information to multiple dealers
  • Monitoring server load and network response for most efficient data transfer
  • Expose an API with which other subsystems can interact with the network

• Authentication
  • Secure access to client and parts information across all viable media
  • Provide login and logout services to various classes of users
  • Provide distinct level of security for affiliated and nonaffiliated dealers
  • Provide processes that use the smart card for authentication purposes
  • Verify queries to prevent unauthorized access to data

• Learning and Event Service
  • Expedite decision making process in the PAID system
  • Analyze dealer behavior and recommend actions that make the dealer-PAID interaction more efficient
  • Analyze data from database activities using data mining
  • Reschedule updates and recommend to store frequently accessed data on local database to avoid network congestion
  • Recommend behavior to enhance the cost/speed performance of the system
  • Provide an event service that receives and publishes event information to all users and subsystems who subscribe to a particular event channel

• User Interface
  • Provide login and logout interface to the user
  • Display sales and parts data in the proper screen format
  • Provide a tool panel, status panel and an information panel to the user
  • Provide a User Interface for the mobile devices that will be used to access the PAID system

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. 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).

Every team member must:

• Bookmark the Announcements, Discuss, Client, Handin, and Help bboards
• Bookmark the team specific bboard
• Check these bboards at least twice a day

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:

2.4 Project Responsibilities

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

2.4.1 Project Management

The project management function has the following responsibilities:

• Schedule and prepare meetings with clients
• Assign presentations (in-class project meetings, client review, client acceptance test) to project members
• Listening to gripes from the team members
• Resolve conflicts if they cannot be resolved otherwise

2.4.2 Coach

The coach has the following responsibilities:

• Review weekly team progress
• Attend weekly team meetings
• Insist that guidelines are followed

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:

• Responsible for intragroup communication
• Run the weekly project meeting
• Define, post and keep track of action items (who, what, when), i.e the agenda
• Measure progress and enforce milestones
• Deliver work packages for the tasks to project management
• Deliver project plan and accomplishment for project phase to project management
• Coordinate and schedule use of resources needed by team (lab, tools,...)
• The group leadership position has to be rotated on a regular basis among the team members

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:

• Responsible for intergroup communication
• Make available public definitions of each subsystem service ("API") to the other teams (ensure consistency, etc.)
• Coordinate tasks that overlap subsystems with the teams
• Responsible for team negotiations, that is, resolve technical issues spanning more than one subsystem
• Defines the software architecture for PAID
• Defines the class library for PAID

2.4.5. HCI Liaison

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

• Responsible for inter-group communication
• Make available public descriptions of each subsystem interface to the other teams (ensure consistency, etc.)
• Coordinate interfaces for overlapping subsystems with the teams
• Resolve technical interface issues spanning more than one subsystem
• Defines the hardware and software elements of interface for PAID
• Develops the style ("look & feel") for PAID

2.4.6 Documentation Editor

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

• Collect, proofread and distribute team documentation to the Architecture team
• Interaction with the Architecture team
• Writes minutes and provides them to team webmaster

2.4.7 Configuration Manager

The responsibilities of the configuration manager in each team are:

• Coordinate change requests
• Provide version control for group's working directory
• Coordinates configuration management issues with other groups
• Installation of group specific software and hardware

2.4.8 Toolsmith

The responsibilities of the toolsmith in each team are:

• Familiarize with all the software/applications used in this project
• Serve as a guide for his/her team regarding the tools

2.4.9 CASE Tool Manager

The responsibilities of the CASE tool manager in each team are:

• Familiarize with CASE Tool
• Serve as a guide for his/her team regarding CASE Tool usage

2.4.10 Webmaster

The responsibilities of the webmaster in each team are:

• Maintain the team home page
• Coordinate team page with course webmaster
• Link meeting agendas, minutes, action items and issues to the team home page
• Maintain links to team documentation under version control

Table 2 describes the group leader assignments and Table 3 indicates the other team 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.

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 PAID system passes the client acceptance test as defined in the requirements analysis document.

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 Database

• The database is updated using IOU
• The IOU can be propagated from the STAR network server to the PAID servers
• The update can be propagated from PAID server to the dealer server
• Authentication provides database with a serializable  user and group object, whose complete structure is stored on the database
• Database will have access to dealer database or CDs that show the form of the required data
• We depend on the stability of the hardware and software involved in the development of the project.
• We depend on the network subsystem to provide us with a connection between the client PCs and the Daimler-Benz server.
• We depend on having a database server that is: compatible with JDBC capable of supporting large amounts of  simultaneous connections capable of supporting large volumes of data (~20 GB)
• We depend on regular backups of the data being performed at the server level.
• We depend on having access to samples of STAR network data during our development process.

3.2.1.2 Learning and Event Service

• The database maintains logging records that are analyzed to make learning recommendations
• Learning has access to database at all times
• Database logs show records only of completed transactions
• Event service is notified of events by the relevant subsystems
• Voyager is a stable system that has all the services required for the event hierarchy in PAID
• The learning algorithms that are used are stable and will not require changes as data characteristics change
• The learning subsystem is able to obtain the usage data of all the concurrent users, in a timely manner
• The database resources are enough to store information on all 6000 dealers
•  Learning is on server side
•  Different types of data to analyze; one general system
•  Using 3rd party software whenever possible
•  Rely on database triggers for actions

3.2.1.3 Authentication

• The smart card is easy to use and is secure
• The smart card, issued to a new user, is mailed by Daimler-Benz headquarters in Stuttgart and this process is thus free from security holes
• The smart card is the only source of authentication, i.e. whoever has the smart card has access to PAID
• The non affiliated dealers do not have access to a dealer server and thus are subject to different security considerations on the external network
• The API for other subsystems work and authentication is able to interface with them
• A main is provided on the dealer machine because authentication is one of the subsystems that is required at start up time
• Enough space exists on the card for all the information required
• The functionality and the information on the card does not get corrupted
• The extranet is a secure network.
• There will be a user class that has administration rights
• Customer list is only maintained on the dealer's local machine, not on the main PAID database
• Users of the system have a JAVA Smart Card and Reader (w or w/o password protection)

3.2.1.4 Network

• Voyager is robust and is able to handle all client sessions concurrently
• Event notification will provide a list of events that have to be multicast
• A target list of all the intended recipients of the event will also be provided by the evnt service
• Voyager works reliably on LINUX
• Database will handle all caching of information.
• All information, requests, events, and other messages will all be handled the same by the network (i.e. We  will treat everything as a bit string and it will be the responsibility of the receiving party to "listen" for the message
• Rebuilt messages will stay in the message queue at the receiving end until all subsystems have notified us that they have finished with it
• Events that the network subsystem will publish include, but are not exclusive to, MessageHasArrived, NetworkIsDown, and UnspecifiedFailure
• Database or Authentication will handle encryption of all sensitive data before sending or give an API to allow us to do so after compression of the message. If the latter is followed, the clear text message must be marked with a flag as sensitive material if encryption is necessary
• Routing for Network involves only specifying the destination server for the packets and developing a scheme to choose another to improve performance. This does not involve routing the individual packets at the intermediate routers
• The dealer to server ratio will be about 150:1 with the dealer making about 5-7 requests for information per network session

3.2.1.5 User Interface

• End users are computer illiterate. In other words, we should design a user interface that is easily understood by everyone
• External subsystems may have their own user interfaces.
• Computers used by end users might differ (in OS, screen size, etc) from user to user
• There are various groups of end users each of which has access to only certain types of data

3.2.2 Dependencies

3.2.2.1 Database

3.2.2.2 Learning and Event Service

• Rely on database team for persistent storage (log, behavior files)
• Rely on database for actions

3.2.2.3 Authentication

• Depends on the stability of the Java card readers and the SmartCards
• Depends on other groups in the project to provide them with needed objects
• Depends on the user not to give out security information.

3.2.2.4 Network

• Depends on Event Service/Learning, Authentication, and the Database subsystems to communicate their assumptions or needs relevant to us freely and in a time efficient manner
• Depends on the Architecture team to point out/clarify any discrepancies existent in the assumptions made in our RAD with assumptions made in the RADs of other subsystems
• Depends on the correctness and stability of existing software that we will be using (i.e. - Voyager, Marimba, Together/J, etc.)
• Depends on the client to make timely responses and clarifications to items that we post to the client bboard

3.2.2.5 User Interface

• Depends on the capabilities of the development packages chosen to develop the user interface with
• Depends on other subsystems to provide us with APIs that we need
• Depends on other subsystems to provide us with objects that we need

3.2.3 Constraints

3.2.3.1 Database

• The database must be accessible through Java using JDBC
• The database must be able to run under Red Hat Linux v. 5.1 or NT

3.2.3.2 Learning and Event Service

• Learning problem essentially data mining
• Everything needs to be Java or wrapped in Java
• Domain specific knowledge may be limited

3.2.3.3 Authentication

• Java language specifications and the Java virtual machine
• The use of Java SmartCard as the authentication method

3.2.3.4 Network

• System will be developed in Java (ver 1.1)
• Object and CASE models will be developed in Together/J
• Source control will be handled using CVS
• Voyager will be used to handle RMIs.

3.2.3.5 User Interface

• The Java language and the Java Virtual Machine version 1.1

3.3 Risk Management

3.3.1 Database

Risk: Database compatibility with JDBC. Because the system will be written in Java, database access must be via JDBC, thus, we must determine if the database used can support Java.
Contingency: If the database cannot support JDBC directly, we will see if it can be accessed using a protocol which is available to JDBC. For example, if the database is ODBC compatible, it may be possible to use a JDBC-ODBC bridge to access the database. If this is not possible, then a different database will have to be used.

Risk: JDBC support of SQL. We must determine the exact SQL supported by JDBC, and determine if this is sufficient to implement the Database subsystem.
Contingency: If JDBC does not support a desired feature, we must implement the feature ourselves using either the SQL that JDBC does support or outside of JDBC entirely

Risk: Size of car info. If a car's info is too large, it will not fit onto the Smart Card or PDA that we use.
Contingency: We can attempt to compress the data, if this is not practical or successful, then a different PDA or Smart Card will have to be used.

Risk: Detection of Updates/Changes to remote data. Detection of changes to data may be quite expensive, and is an important part of the problem statement.
Contingency: If Detection of Changes cannot be done cheaply we will have to either settle for a slow system or redesign the system so that only a small portion of the data is replicated locally.

Risk: Grouping of data. The problem statement requires that some subset of "frequently used" data be stored locally. We must determine if there is any simple means of categorizing the data, so that we can simply specify a "rule" about what data to store locally (e.g. store data locally for all cars sold in the dealer's state).
Contingency: If there is no way to categorize the data, then we must specify the local data on a per car basis, making this specification quite cumbersome and expensive.

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.

Risk: Assumptions change because of other teams assumptions
Contingency: This problem can be resolved in the systems design phase.

Risk: Subsystem assumptions invalidated
Contingency: We will start from the beginning and revise our plans.

3.3.3 Authentication

Risk: Local data can not be securely stored.
Contingency: Attempt to make it hard for the local data to be found or understood.

Risk: Can't get SmartCard to work, either because of hardware or software failure.
Contingency: Write a Java card simulator that simulates the behavior of a real Java card system. An alternate plan is to implement a password mechanism that can be used to authenticate the user.

Risk: Failure to deliver the correct interface by other groups.
Contingency: Attempt to use the given interface.

3.3.4 Network

Risk: For some reason the network becomes unreliable or goes down during the transmission of data.
Contingency: We will cancel the request and notify both ends of the transmission that the network has gone down and the request has been canceled.

Risk: Our system may not be scalable.
Contingency: We are operating under the assumption that the dealer to server ratio will be about 150:1. If this changes dramatically, our system needs to be adaptable to handle other ratios.

Risk: The client fails to clarify issues completely or in time for us to be able to make the appropriate changes.
Contingency: We can re-post to the client bboard. If that does not elicit further response, we should talk to the coaches and make a best guess as to what functionality is needed and expected.

3.3.5 User Interface

Risk:  Because of previous experience with the systems at the dealership, people may not want to take time to learn the new interface.
Contingency: We must strive to make our interface as comprehensive as possible while still maintaining a high level of user friendliness and intuitive design. We must work with Daimler-Benz to assure end users of the worthiness of our system and its ease of use.

Risk: The user-friendliness of our design may be compromised by our dependency on other subsystem designs (double login, etc.).
Contingency: The ease and comfort of use by potential end users should carry heavy weight against other concerns (i.e. security). The subsystems must work together so that the right balance is found.

Risk: As the vision for PAID get clearer, the requirements for user interface could change drastically. Some of the assumptions we have been basing our work on may turn out to be wrong. New and completely different interfaces might be needed (maybe one for a palm PC, maybe one for ordering parts, maybe a new language, etc.)
Contingency: Be flexible in design and leave room for later adjustments in case of changes in conditions and requirements.

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:

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:

• Information Services department provided Video Conferencing using PictureTel
• Bobby Rahal Motorcars, Inc. of Wexford, PA provided examples of existing dealer information systems

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. A graphical user interface
2. A functional prototype
3. 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 on Oct. 16, the Project Status on Oct. 23, the Project Review on Oct. 30 and the Object Design Review on Nov. 13 and Nov. 15. 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. 10.

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