1. Introduction

1.1 Project Overview

1.2 Project Deliverables

• A Software Project Management Plan defining the technical and managerial processes necessary for the development and delivery of the JAMES system (This document)
• 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.
• A 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 JAMES 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 JAMES System.

1.3 Evolution of the Software Project Management Plan

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.
• [Rational 97a] Using Rational Rose 4.0, Rational Software Corporation, Santa Clara, 1997
  
• [Rational 97b] A Rational Approach to Software Development Using Rational Rose, Rational Software Corporation, Santa Clara, 1997.
• [Rational 97c] Round-Trip Engineering with Rational Rose/Java, Rational Software Corporation, Santa Clara, 1997.
• [CodeWarrior 97] Metrowerks, Inside CodeWarrior Professional, Release 1 for MacOS, Windows NT and Windows 95, Metrowerks, Inc., 1997.
• [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.

1.5 Definitions and Acronyms

API - Applications Programming Interface
CASE - Computer Aided Software Engineering
GUI - Graphical User Interface
JAMES - Java Architecture for Mobile Extended Services
JDK - Java Development Kit
ODD - Object Design Document
OMT - Object-Oriented Modeling Technique
RAD - Requirements Analysis Document
ROSE - Visual modeling tool for Java
SDD - System Design Document
SPMP - Software Project Management Plan
UML - Unified Modeling Notation
VIP - Vehicle Initialization and Personalization

2.1 Process Model

The project is initiated on Aug 26, 1997 and terminated with the end of the semester on Dec 9, 1997. Major milestones are the Client Project Review on Oct 30, 1997 and the Client Acceptance Test on Dec 9, 1997.

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 Perforce running on a PC platform using Free BSE version 2.2. Links to the team documentation are available from the team homepages and the course electronic bulletin boards.The links to the major documents on the Perforce 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 JAMES 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 16 from 9:00- 10:20 in WeH 7500. The Analysis Review consists of a set of presentations given by members of the JAMES project. Project Management will review these slides and post their comments on the 15-413 discuss bboard.

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 Oct 30 from 9:00-10:20 in WeH 7500. 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 JAMES System using stubs. The functional prototype of the James system will be presented during the internal review Nov 25 1997.

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 JAMES 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 JAMES System.Functional Testing: Tests the major functionality (use cases) with the complete JAMES 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. 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.

2.2 Organizational Structure

Below is the organizational chart of the people involved in the development of the JAMES system.

Figure 1: Organization Chart for JAMES Project

The clients of the JAMES System project are:
Dieter Hege, Brigitte Pihulak, Daimler Benz
The project managers are:
Bernd Bruegge, Malcolm Bauer, Brian Cavalier, Allen Dutoit, Alfonso Guerrero-Galan, Sam Perman, Isabel Torres-Yebra
The Infrastructure team consists of:
Joyce Johnstone (Web Master and Lab Management)and Stephan Schoenig (CASE Tool and Java support, Communication Infrastructure)
The project consultants are:
Dieter Hege, Klaus Eitzenberger, Manfred Mueller, Juergen Bortolazzi, Claus Czymmek, Arno Schmackpfeffer, Thorsten Armstroff

DB user group members and list of consultants

2.2.1 Teams and Tasks - Vehicle Subsystem Example

• Access to the functionality of a Mercedes Benz Car simulator provided by the Daimler Benz R&D,;division (F1).
• Provide platform independent interface to the simulator.
• Provide web-based access to the simulator.
• Show that JAMES applications are able to be integrated with the existing electronic systems in the car (mirror/seat position, speedometer).

2.3.2 Meeting Times

There is a weekly project meeting for each group. The initial project meeting times are:

Group	Day	Time	Location
Logbook	Monday	8:00 p.m.	Wean 8220
Maintenance	Wednesday	4:30 p.m	Smith 100
Simulation	Thursday	4:30 p.m.	Smith 101
Travel	Tuesday	6:00 p.m.	Porter 231B
VIP	Thursday	5:30 p.m.	Wean 7220
HCI	Tuesday	4:30 p.m.	Hamburg 1202
Architecture	Tuesday	5:00 p.m.	Smith 100

2.4 Project Responsibilities Tables

Table 2 describes the group leader assignments and Table 3 indicates the other team assignments.

Team Leader Assignments
	Logbook	Maintenance	Travel	VIP	Vehicle
Requirements Analysis	Uhyon Chong	Arjun Cholkar	Bin Zhou		Andrew/Jay
System Design	Pradip Hari, Michael Poole	Joel Slovacek	John Doe		Robin
Object Design	Michael Stienholtz, Aaron Wald	Yenni Kwek	Kalyana Prattipati		Hoda Moustapha
Implementation	Herb Stiel	Vincent Mak	Christofer Chiappa		Will
Testing	Nate Woods	Darren Mauro	Michael Samuel, Ann Sluzhevsky		Paul/Ogi

Team Role Assignments
	Logbook	Maintenance	Travel	VIP	Vehicle
Card Master	Michael Scheinholtz	Arjun Cholkar	Bin Zhou	Philip G Ezolt	Jaewoo You
CASE Modeler	Herbert Stiel	Joel Slovacek	Michael Samuel	Christopher Lumb	Hoda Moustapha
HCI Liaison	Nathaniel Woods	Yenni Kwek	Gordon Cheng	Idan Waisman	Paul Stadler
Architecture Liaison	Pradip Hari	Vincent Mak	Ann Sluzhevsky	Venkatesh Natarajan	Andrew Wang
Configuration Manager	Michael Poole	Darren Mauro	Chris Chiappa	Eric Farng	William Ferry
WebMaster	Uhyon Chung	Aveek Datta	Kalyana Prattipati	Li-Lun Cheng	Tze Bin Loh
Documentation Editor	Aaron Wald	Stanislav Pavlik	John Doe	Patrick Toole	Bob Poydence
Coach	Alfonso Guerrero-Galan	Sam Perman	Isabel Torres-Yebra	Brian Cavalier	Bernd Bruegge

3.2.1 Assumptions - Logbook Subsystem Example

• That the card is used by the driver.
• We will be able to lock data on the card so that it can not be tampered with.
• We can determine what information tax collection agencies need in order to stipulate that a trip is tax deductible.

3.2.2 Dependencies - Maintenance Subsystem Example

• We depend on the stability of the hardware and software involved in the development of the project.
• We depend on other groups in the project to provide us with objects we need.

3.2.3 Constraints - Travel Subsystem Example

• Java language specifications and the Java virtual machine.
• Card will have enough useful space.

3.3 Risk Management - VIP Subsystem Example