Project Plan 1.0

For

Natural Language to Machine Readable Format

Damian Aaron Tamayo

CIS 895 – MSE Project

Department of Computing and Information Sciences

Kansas State University

Committee Members

Dr. Daniel Andresen

Dr. David A. Gustafson

Dr. William Hsu

1.  Project Phases

Project is divided into three phases: 1.) Inception, 2.) Elaboration and 3.) Production

1.2  Inception Phase

The purpose of the Inception phase is to evaluate whether or not a project has the potential to be accomplished given a specific scope. In order to do this, the Inception phase analyzes the project through several documents, such as the vision document, the project plan, and software quality assurance plan. However, it is also customary to provide a demo of a small prototype or simulation of what can be expected from the proposed system on a much smaller scale. Such a demonstration will cover only the barest of requirements and look to address any potential risks that may be proposed as being detrimental to the completion of the project.

This phase is considered complete when a supervisory committee has reviewed all of said material and given their approval.

1.2.1  Vision Document

The vision document is meant to be an outline for the project. This document addresses the motivation behind the project, the goals or expected outcome of the product, the assumptions for the project and the requirements in order to evaluate the project as being complete and/or successful.

1.2.2  Project Plan

The project plan is meant to give the evaluation committee a look at the plan along which a project will be developed over time. More specifically it will outline the milestones, tasks, and deadlines that are expected to be reached for the project to be finished in a timely manner. Furthermore, the project plan should outline an effort estimation showing that the project can be done in said time and given said resources.

1.2.3  Software Quality Assurance Plan

The Software Quality Assurance Plan (SQA Plan) is a document that is meant to display the methodologies, guidelines and procedures that the developing team will adhere to in order to maintain software quality as defined by the document and the committee’s standards.

1.3  Elaboration Phase

The elaboration phase is similar to the point of no return. At this point there is still time to re-evaluate and adjust the scope of the project and/or the requirements. During this phase the risks are identified, the problem domain is established and the architecture of the project is constructed. As a result the project begins to take place during this phase. The elaboration phase is considered one of the most important phases by many due to the fact that many projects succeed or fail due to the amount of attention given to this phase.

Furthermore, system requirements are captured by OCL diagrams and a test plan is developed along with a methodology of documenting, tracking and debugging. All documents developed in the inception phase will be updated and two technical inspectors will inspect the architectural design and provide feedback.

Finally, another demo will be given to the supervisory committee that will demonstrate the current system requirements. At the end of this phase, the supervisory committee will evaluate and submit changes and/or approval of the project.

1.3.1 Technical Inspectors

The technical inspectors will be two fellow MSE students. Their job is to analyze the architecture of the project and report their findings to the supervisory committee.

1.4  Production Phase

This is the final phase and is where the developer presents the project for final review. In addition, the developer will submit documentation, user manual, executable version of the project and any other deliverables that are necessary. A final demonstration is given to show the completion of the project.

2.  Project Schedule

The Gantt chart below will provide the timetable under which this project will be developed.

3.  Cost Estimation

The COCOMO II model will be used to measure the effort, cost and schedule of the project because it is one of the most commonly used cost estimation models in use today.

COCOMO II follows the following estimation equation:

Effort = 2.45 * EAF * (KSLOC)^1.09

Time = 2.5 * (Effort)^0.38

The following definitions will describe the variables used in the equations:

Effort = the total number of person months (PM)

Time = Duration of time in terms of months for a given project

KSLOC = Estimated number of source lines of code for the project

-  This is expressed in terms of thousands of lines

EAF = Effort Adjustment Factor

3.1 Person Months (PM)

Person months are the amount of time required to finish the project for a given organizations definition of time or for a given organizations time table.

3.2  EAF

EAF has 15 different categories in which to apply adjustment values. The following is a table of the adjustment categories along with a short description of their meaning and a range of possible values.

Signifier / Description / Range (low – high)
Product
RELY / Required Software Reliability / 0.75 – 1.40
DATA / Database size / 0.94 – 1.16
CPLX / Product Complexity / 0.70 – 1.65
Computer
TIME / Execution time constraint / 1.00-1.66
STOR / Main storage constraint / 1.00 – 1.56
VIRT / Virtual machine volatility / 0.87 – 1.30
TURN / Computer turnaround time / 0.87 – 1.15
Personnel
ACAP / Analyst capability / 1.46 – 0.71
AEXP / Applications experience / 1.29 – 0.82
PCAP / Programmer capability / 1.42 – 0.70
VEXP / Virtual machine experience / 1.21 – 0.90
LEXP / Language experience / 1.14 – 0.95
Project
MODP / Modern Programming Practices / 1.24 – 0.82
TOOL / Software tools / 1.24 – 0.83
SCED / Development Schedule / 1.23 – 1.10

The following is a table representing the chosen values for the project and why.

Signifier / Value / Type / Justification
RELY / 1.00 / Nominal / Software should be reliable for what it does but at this point is not a part of critical software.
DATA / 0.94 / Low / There is minimal need at this time for a database
CPLX / 1.65 / Extra High / This project requires a complex set of specialized code
TIME / 1.00 / Nominal / Response time is non critical at this point
STOR / 1.06 / High / Tagging is memory heavy and needs to be run on separate servers
VIRT / 0.87 / Low / There is no virtualization of the product at this time.
TURN / 0.87 / Low / Single developer results in low turnaround
ACAP / 0.86 / High / Programmer has had 4+ experience
AEXP / 0.91 / High / Programmer has developed several standalone applications for various companies
PCAP / 1.42 / Low / This is a new area for the programmer
VEXP / 1.00 / Nominal / Programmer has worked with virtual machines before for several companies
LEXP / 0.95 / High / Programmer is very experienced in the language of the project
MODP / 0.82 / Very High / Modern programming practices like OO-Design are used in the project
TOOL / 0.83 / Very High / Modern tools like mature IDE’s are used in developing the project
SCED / 1.00 / Nominal / Project has flexibility

The current EAF = 0.89

The current KSLOC = 3.5

Therefore the following equation results are:

26.8 = 2.45 * 0.89 * 10^1.09

8.7 = 2.5 * 26.8 ^0.38

From the calculations it can be seen that the Effort is estimated to be 26.8 Person months to complete the project. In addition, from the Time calculation we can see that the project should take 8.7 months to complete. Both of these estimations are within the time frame allowed by the Gantt chart.

4.  Architecture Elaboration Plan

The elaboration phase will end at the time of the second presentation. As result, all of the required documents must be completed at this time too.

4.1 Vision Document

The Vision document that was completed in the inception phase will be revised as needed to reflect the current stage of the project and any changes to the requirements.

4.2 Project Plan

The project plan that was completed in the inception and elaboration phase will be revised as needed to reflect any changes in the cost estimate. In addition, the document will also reflect the changes in the Gantt chart to reflect the current milestones that have been reached and any modifications to the previous work schedule.

4.3 Formal Requirements Specification

This document will specify a module of the project using OCL and it will be submitted to the Major Professor for approval.

4.4 Architecture Design

This document will contain diagrams that will depict the architecture of the project at the interface level. This document will be submitted to the Major Professor for approval.

4.5 Test Plan

A test plan will be developed in order to show a way of verifying that the project works according to the required specifications. This document shall be submitted to the Major Professor for approval.

4.6 Formal Technical Inspections

The formal technical inspections shall be performed by two peers in the major. At this time, these peers have yet to be determined. However, when determined they shall follow a set of predefined guidelines in order to evaluate the project. When finished, they will report their findings to the supervisory committee.