ArgoUML

Project Management Plan

EEL5881 Software Engineering I

 Spring 2002

 

Modification history:

Version

Date

Who

Comment

v0.0

08/15/00

G. H. Walton

Template

v1.0

02/07/02

L. Izquierdo

Added Team info and project overview section.

v1.1

02/12/02

P. Lorins, D. Trawczynski, C. Marcos, L. Izquierdo

Updated info and added links.

v1.2 02/13/02 L. Izquierdo Updated info and added links.

Project Name: ArgoUML

Team Members:


Contents of this Document

Project 0verview

Reference Documents

Applicable Standards

Project Team Organization

Deliverables

Software Life Cycle Process

Tools and Computing Environment

Configuration Management

Quality Assurance

Risk Management

Table of Work Packages, Time Estimates, and Assignments

PERT Chart

Technical Progress Metrics

Plan for tracking, control, and reporting of progress


Project 0verview

ArgoUML is a modeling tool to help you do your design using UML. ArgoUML is an open source project, coded in Java. Diagrams are the main way of presenting object-oriented designs. Argo can also provide tabular presentations of the design and textual presentations in the form of source code, and (future) English language explanations. Your implementation will allow editing in any of these presentations, and all of them are kept consistent. This project is to extend ArgoUML will include the following features:

 


Reference Documents


Applicable Standards


Project Team Organization

Dawid Trawczynski dt39127@pegasus.cc.ucf.edu

Peter Lorins             PeteLorins@aol.com

Leticia Izquierdo Leti_I@hotmail.com

John Marcos cjmmrcs@netscape.net

 

Leticia Izquierdo – responsible for group web site, direct communication with the client and formal documentation

John Marcos – ArgoUML High Level and Low Level Code Design and Implementation, Documentation

Dawid Trawczynski – ArgoUML High Level and Low Level Code Design and Implementation, Documentation

Peter Lorins – ArgoUML High Level and Low Level Code Design and Implementation, Documentation

 

All communication among team members shall be accomplished through personal meetings (minimum one hour per week), email and telephone.  Leticia shall schedule meeting times although all group member shall make a final decision as to where and when meeting shall be held.

Communication with the course instructor shall be thru email unless required otherwise.  Communication with the client shall occur thru email and personal meetings when required.  Leticia shall schedule formal meeting times with the customer upon prior consultation the customer and all team members


Deliverables 

Artifact

Due Dates  

Meeting Minutes

48 hours after meeting

Individual Logs

Updated accordingly

Group Project Management Reports

Weekly

ConOps

02/14/02

Project Plan

02/14/02

SRS

Draft by 02/14/02

High-Level Design

TBA

Detailed Design

TBA

Test Plan

TBA

User's Manual

TBA

Final Test Results

TBA

Source, Executable, Build Instructions

TBA

Project Legacy

TBA


Software Life Cycle Process

This project will use the Water Fall Model as the Software Life Cycle Process. The task is to add additional features to the release software ArgoUML. The requirements are clear and concise. Requirement, Specification and Design phase will be simple with little risk. Major effort will only lie in implementation and later phases.

Waterfall Model


Tools and Computing Environment

All source code shall be compiled by using and SD Java Kit.  The source code shall be compiled for a LINUX operating system.  Visual Java, Java 2 SDK, Jbuilder,  and CodeWarrior may be used as software development environments for this project.  ArgoUML source code will also be needed so that original source code may be modified to include features required by the customer.  All code modification shall be accomplished thru source control software, namely CVS.


Configuration Management

Version control shall be accomplished thru the use of CVS.  All team members shall accept the responsibility of utilizing CVS when modifying source code.  Standard check-in and check-out procedures shall apply when utilizing source code for development purposes.


Quality Assurance

1.Review and verification of each artifact to meet respective requirements.

2.Document each QA review with a checklist.

 


Risk Management

Potential risks for this project are:

1.      Project deadlines not met – unsuccessful design implementation

2.      Project deadlines not met – lack of team member effort and communication

Risk management steps:

1.      Ensure that top level and low level design are feasible by performing required design analysis and reviews

2.      Communicate team related issues with the instructor and team members


Table of Work Packages, Time Estimates, and Assignments

Work Package

Time Estimates
(hours)

Actuals
(hours)

Assignments

Meetings

25

 

 

Individual Log

20

 

 

Team Page

5

 

 

Project Management Plan

8

 

 

ConOps

8

 

 

Project Management Reports

10

   

SRS

20

   

High-Level Design

10

   

Detail Designed

20

   

Test Plan

10

   

User's Manual

10

   

Final Test Results

8

 

 

Source, Executable, Build Instructions

8

 

 

Project Legacy

8

 

 

Code

40

 

 

Totals

210

 

 


PERT Chart


Technical Progress Metrics

Metrics

Measure

Requirements Phase

 

Number of Requirements

 

Number of Requirement Changes

 

Specification Phase

 

Number of Specifications

 

Number of Specification Changes

 

Design Phase

 

Number of Packages Added, Deleted and Changed

 

Number of Classes Added, Deleted and Changed

 

Number of Methods Added, Deleted and Changed

 

Implementation

 

Number of Packages Added, Deleted and Changed

 

Number of Classes Added, Deleted and Changed

 

Number of Methods Added, Deleted and Changed

 

Lines of Code Added, Deleted and Changed

 

Number of Test Cases Added, Deleted and Changed

 

Integration

 

Number of Test Cases Added, Deleted and Changed

 

Number of Defects

 

 


Plan for tracking, control, and reporting of progress

"At a minimum, each team member will post the following information weekly: individual time and activity log, individual status information, individual issues and problems, and individual defect log.

Each week, the project manager will: read and analyze the logs; examine the technical content of the work done to date; examine the technical progress metrics; consider the QA results; reassess the potential project risks; and take corrective action if necessary.

The project manager will issue a Project Management Report on the schedule as indicated in the deliverables section above. At a minimum, the Project Management Report will be generated every two weeks and will include the following information: 1 sentence description of overall status, 1 or 2 sentence of any planned changes to the project plan, graph of planned vs actual time, graph of planned vs actual for each technical progress metric, updated PERT chart."


Template created by G. Walton (GWalton@mail.ucf.edu) on Aug 30, 1999 and last updated Aug 15, 2000

This page last modified by Leticia Izquierdo (Leti_i@hotmail.com) on February 13, 2002.