CIS 895 – BRUEProject Plan Version 1.0
Project Plan
For BRUE
Behavioral Reverse Engineering using UML as
Eclipse plugin
Version 1.0
Submitted by Sri Raguraman
CIS 895 MSE Project
Department of Computing and Information Sciences
Kansas State University
Table of Contents
Task Breakdown
Inception Phase
Vision Document
Project Plan
Software Quality Assurance Plan
Simple Prototype
Architecture Design Plan
Revisions of Project Plan and Vision Document
Formal Specification
Test Plan
Architecture Inspections
Project Coding
Project Documentation
Cost Estimate
COCOMO
Architecture Elaboration Plan
Revision of Vision Document
Revision of Project Plan
Architecture Design
Development of Prototype
Test Plan
Formal Technical Inspection
Formal Requirements Specification
Summary of Changes
Version # / Date / Changed By / Summary Log1.0 / Sep 14, 2006 / Sri Raguraman / Initial draft of document
List of Figures
Figure 1: Project plan for BRUE (please zoom for clarity)
List of Tables
Table 1: COCOMO adjustment factors
Task Breakdown
Inception Phase
The inception phase will concentrate on the project’s overview and requirements. This phase will include the following deliverables –
- Vision Document,
- Project Plan,
- Software Quality Assurance Plan, and
- a simple prototype of the software.
Each of the four works will have to be approved by the committee before any further progress on the project.
Vision Document
This document will include the project’s critical requirements. It gives a listing of the current requirements and labels each requirement as “Critical”, “Non-Critical”, or “Future”. Requirements include validation rules and the proposed framework for the project. The introduction to this project includes its goals and purpose. It includes graphical models that are used to describe the framework, and use cases to illustrate the functionality.
Project Plan
This document will include a timeline for the project and a cost estimate for completing this project. Cost estimates will be developed using the COCOMO estimating methodology. All activities involved with this project will be associated with milestones outlined within this document according to the modern software process. This process includes the following phases: Inception Phase, Elaboration Phase, Production Phase, and the Transition Phase.
Software Quality Assurance Plan
This document will include an outline of required documents. To ensure software quality, practiced standards and conventions will be monitored and followed. This document will outline project reviews and the responsibilities of those associated with the project.
Simple Prototype
A simple prototype will be developed to demonstrate at least one aspect of the software. It will demonstrate some of the critical requirements outlined in the Vision Document. This is completed to demonstrate feasibility or to illuminate risky project requirements.
This phase will be complete once the supervisory committee has approved the above four artifacts.
Elaboration Phase
The elaboration phase will concentrate on the project’s architecture. This phase will include the following deliverables –
- Architecture Design Plan,
- Revisions to the Project Plan, and the Vision Document,
- Formal requirements specification,
- Test Plan, and
- Two architecture inspections.
Architecture Design Plan
The Architecture Design plan will include appropriate UML diagrams such as class diagrams, use-case diagrams, and sequence diagrams, but is not limited to those named here.
Revisions of Project Plan and Vision Document
Appropriate changes that were suggested by the committee at the end of phase one will be made to the Project Plan and Vision Document.
Formal Specification
The formal specification will include at least one function of the software to be specified using OCL in USE.
Test Plan
The test plan will include a complete testing procedure for the project. This will include test suites and appropriate procedures for reporting and correcting failed test.
Architecture Inspections
Fellow MSE students will perform two architecture inspections at Kansas State University. Their feedback will be documented and presented.
This phase will be complete once the supervisory committee has approved the above five artifacts.
Production Phase
The production phase will include project implementation and testing. This phase includes project coding and documentation.
Project Coding
Project coding will consist of all committee approved and designated tasks to be coded and developed. Both unit testing and integration testing will be performed throughout coding. Test cases will be developed according to the project requirements outlined in the project’s Vision Document.
Project Documentation
All aspects of this project will be documented. JavaDoc will be generated to exemplify coding structure and explanations. A post-test document will be drafted with all results of the test plan. It will also include the solutions or corrections to the case of test failure. A user manual will be completed and will include a description of project installation, software usage requirements, and software usage.
This phase will be completed once the supervisory committee has approved the project coding and documentation deliverables.
The Gantt chart below gives a schedule for the completion of the above-defined tasks for each phase. (You can increase the screen view size in percentage to view this clearly). The shaded area is the non-working time period.
Title / BRUE Project planProject Start / 8/15/2006
Project Finish / 5/4/2007
Figure 1: Project plan for BRUE (please zoom for clarity)
Cost Estimate
COCOMO
This model is based on Barry Boehm's Constructive Cost Model (COCOMO). This is the top-level model, Basic COCOMO, which is applicable to the large majority of software projects. This is a simple on-line cost model for estimating the number of person-months required to develop software. The model also estimates the development schedule in months and produces an effort and schedule distribution by major phases.
Boehm says:
“Basic COCOMO is good for rough order of magnitude estimates of software costs, but its accuracy is necessarily limited because of its lack of factors to account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and other project attributes known to have a significant influence on costs”.
Due to these facts, the estimate we find out may not be as accurate, but would give us a rough idea about the schedule of the project.
According to Boehm’s classification, this project falls under the ‘organic’ modes of development. The following equations are used to calculate effort and time:
Effort = 3.2*EAF (Size)^1.05
Time (in months) = 2.5(Effort)^0.38
To calculate effort one needs to estimate the Size and EAF values. The Size is measured in KLOC. The EAF value stands for effort adjustment factor and is the product of 15 adjustment factors. Each adjustment factor is classified as very low, low, normal, high, or very high. The value of each adjustment factor lies within a range and the classification will determine the range chosen for the adjustment factor. The table below lists the adjustment factors and their corresponding ranges.
Identifier / EAF / Range / My Classification and ValueRELY / Required Reliability / 0.75 – 1.40 / Normal / 1.1
DATA / Database size / 0.94 – 1.16 / Very Low / 0.95
CPLX / Product Complexity / 0.70 – 1.65 / High / 1.4
TIME / Execution Time Constraint / 1.00 – 1.66 / Normal / 1.35
STOR / Main Storage Constraint / 1.00 – 1.56 / Normal / 1.30
VIRT / Virtual Machine Volatility / 0.87 – 1.30 / Very Low / 0.9
TURN / Computer Turnaround Time / 0.87 – 1.15 / Low / 0.90
ACAP / Analyst capability / 1.47 – 0.71 / Normal / 0.9
AEXP / Application Experience / 1.29 – 0.82 / Normal / 0.9
PCAP / Programmer’s Capability / 1.42 – 0.70 / High / 0.9
VEXP / Virtual Machine Experience / 1.21 – 0.90 / Normal / 1.0
LEXP / Language Experience / 1.14 – 0.95 / High / 1.0
MODP / Use of Modern Practices / 1.24 – 0.82 / High / 0.95
TOOL / Use of software tools / 1.24 – 0.83 / High / 0.90
SCHED / Required development schedule / 1.23 – 1.10 / High / 1.15
Table 1: COCOMO adjustment factors
The EAF value evaluated to 1.63. We estimated the size to be 8000 LOC based on similar experiences with the tool. The effort evaluates to:
Effort = 3.2*2.5*1.63^1.05 = 13.36 staff months
The time can now be calculated as:
Time = 2.5*13.36^0.38 = 6.69 months
We will not consider the Time we have calculated here because this calculation takes teamwork into account where there are many developers. This project will only have one developer.
The Effort figure may be large for such a project since the COCOMO model is designed for large projects with the involvement of several large teams in an industrial setting, so it tends to over-estimate this value. I would estimate that 10-11 staff months for Effort would be a more realistic value for this project.
Architecture Elaboration Plan
The following documents should be complete before the second presentation is made.
Revision of Vision Document
After the first presentation, changes as required by the committee should be made in the
Vision Document. The major professor should approve these documents.
Revision of Project Plan
According to the changes suggested by the committee after the first presentation, the project plan should be modified to include those changes. These changes might be regarding the cost estimate or schedule. Also an extra section about the implementation plan should be added before the second presentation.
Architecture Design
Based on the use case diagram in the vision document and using other UML diagrams, an architecture design should be developed for the second phase. This design should be approved by the committee before proceeding to the actual complete implantation of the tool. It should also undergo formal technical inspection by two other MSE students.
Development of Prototype
This prototype will include the demonstration of the critical requirements identified in the Vision Document.
Test Plan
A complete test plan will be developed indicating the testing techniques used and the way bugs will be reported and solved. Unit testing, integration testing and system testing will be performed. This will be done to test whether all the requirements specified in the vision document are met or not.
Formal Technical Inspection
Raj Nathan and San Solai, two other MSE Students will review the architecture design produced by the developer and submit a report on their findings.
Formal Requirements Specification
The component responsible for rendering sequence diagrams will be specified using OCL. The tool used will be USE (UML-based Specification Environment). This will include operations, such as, hiding / un-hiding lifelines, expanding / collapsing invoked messages, and basic correctness constraints of a sequence diagram, such as, self messages having same source and destination, etc.,
1