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
Tools and Computing Environment
Table of Work Packages, Time Estimates, and Assignments
Plan for tracking, control, and reporting of progress
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:
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
|
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 |
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.
1.Review and verification of each artifact to meet respective requirements.
2.Document each QA review with a checklist.
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 |
Actuals |
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 |
|
|

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