Project Plan Community Forum Version 1.0 Submitted by Nayan Ancha

Transcription

1 Project Plan Community Forum Version 1.0 Submitted by Nayan Ancha CIS 895 MSE Project Department of Computing and Information Sciences Kansas State University 1

2 Table of Contents 1. TASK BREAKDOWN INCEPTION ELABORATION PHASE CONSTRUCTION PHASE COST ESTIMATE COCOMO ARCHITECTURE ELABORATION PLAN REVISION OF VISION DOCUMENT REVISION OF THE PROJECT PLAN FORMAL REQUIREMENTS SPECIFICATION ARCHITECTURE DESIGN DEVELOP PROTOTYPE FORMAL TECHNICAL INSPECTORS TEST PLAN

3 1. Task Breakdown 1.1. Inception The inception phase management deals with the tasks that are needed to be completed during the inception phase iterations of the Community Forum. The main purpose of inception phase is to investigate the scope, vision and business case for the project but not to define all the requirements. This phase is mainly responsible for establishing the project scope and boundary conditions. The cost and schedule of the project will also be determined. During business case development, the following activities like developing the alternate approaches, choosing one or deciding to build a comparison for the business case, identifying the likely benefits and potential risks. This also provides details about the budget or the cost required to complete the project and also the schedule, which is the time taken for each phase of the life cycle. As part of the first phase of the presentation, the following documents i.e. Vision document, Project plan and Software Quality Assurance Plan is presented to the committee for its review and to go ahead with the next phase Elaboration Phase The elaboration phase is responsible for ensuring the system architecture and after critical analysis of the use case of the inception phase, the production plan is completed and stability of requirements is achieved and also risks are minimized. The construction phase project control is addressed here. And also all the tasks and sub tasks of the construction phase are to be base lined. In the elaboration plan, executable architecture prototype is built, intermediate milestones are achieved and are evaluated regularly. As part of the second phase of the presentation, the following documents i.e. vision document, project plan, Software Quality Assurance Plan, Formal Requirement Specification, Architecture Design, Test Plan is presented to the committee for its review and to go ahead with the next phase. 3

4 1.3. Construction phase The construction team should plan the product baseline.i.e. Community Forum such that it is deployed by the user to the committee. And also they should ensure the stability of the product before deployment. This typically deals with the documentation of how the Community Forum is to be deployed. They must enable the stake holder s i.e. supervisory committee in order to deploy the project by the user. And it is also responsible for analyzing various releases such as initial release, beta release and few acceptance criteria for product release. (Since this is the course related project we will not be coming up alpha, beta releases). An initial version of user manuals, operation procedures etc., are to be released. As part of the third phase of the presentation, all the documentation of the project is submitted to the committee and the final version of the project is deployed and shown in the third presentation. 2. Cost Estimate The cost estimate is done with the help of COCOMO model which is described below: 2.1. COCOMO COnstructive COst MOdel II (COCOMO II) is a model that allows one to estimate the cost, effort, and schedule when planning a new software development activity. COCOMO II is the latest major extension to the original COCOMO (COCOMO 81) model published in It consists of three sub models, each one offering increased fidelity the further along one is in the project planning and design process. Listed in increasing fidelity, these sub models are called the Applications Composition, Early Design, and Post-architecture models. There are three modes of software development as described below: 4

5 Organic: detached, in-house software with less complex environments and flexible processes, batch jobs. Semidetached: In between organic and embedded, e.g. transaction processing. Embedded: e.g. OS kernel, real-time defense related software, highly rigorous processes. Since the project Community Forum is developed as part of the course study. It falls under organic mode of software development which is developed as detached, in-house software with less complex environments. The effort is calculated using the following formulae for this organic mode of software development. Effort = 3.2 * EAF * (Size) 1.05 Time = 2.5 * (Effort) 0.38 Where: Effort = number of staff months (PM) EAF = effort adjustment factor Size = number of lines of code for completed product. It is measured in KLOC (thousands of lines of codes) Time = total number of months EAF represents the combined effect of the following multiples parameters which has the following rating with typical values assigned to it. Required reliability - 1 Database size - 1 5

6 Complexity Execution time constraints - 1 Storage constraints - 1 Computer turnaround time 0.87 Analyst capability 1 Applications experience 1.13 Programmer capability - 1 Virtual machine experience - 1 Language experience 1.14 Use of modern practices 0.91 Use of modern tools - 1 Required development schedule 1 After having all these parameters, the EAF value is evaluated as a product of all these 14 parameters i.e Therefore upon calculations, I got the following effort and time. Effort = 5.69 Time = Architecture Elaboration Plan Before giving to the second presentation, the following reviews should be done: 6

7 3.1. Revision of Vision Document The vision document which was done in the first phase may have concentrated only upon the critical requirements. Therefore in the second phase, not only the critical requirements but the entire requirement must be taken into consideration. If some of the use cases that were not mentioned in the first phase of the vision document that needs to be updated in the revised edition of the vision document in the second phase. The vision document which was submitted to the committee during the first phase needs to change according to the feedback given back. The vision document with according changes is submitted to the committee for its approval before the second presentation is to be given. To differentiate each vision document from other, we will have an identifier affixed with the name of the vision document Revision of the Project Plan In the first version of the project plan, the estimated cost and schedule are estimated. According to the feedback given at the end of the first presentation, if they are any changes that needs to be updated, the revised project plan would be presented with the new estimation of the cost and the schedule of the project Formal Requirements Specification Part of the project will be formally specified using an OCL Architecture Design The complete architectural design will be documented using UML diagrams such as class and object diagrams, sequence/collaboration diagrams, state chart/activity diagrams, hierarchy diagrams, etc. Each component in the architecture will be documented at the interface level. 7

8 3.5. Develop Prototype During the second phase of the presentation, an executable architecture prototype is developed which needs to address all the critical requirements that were mentioned in the vision document Formal Technical Inspectors The executable prototype and the architecture will be subjected to a formal technical inspection by at least two independent MSE students (inspectors) which in my case would be Vineetha Kadiyala and Vamsi Mummaneni. A formal checklist to be used by the inspectors will be prepared by the student. Each independent inspector will provide a report on the result of their inspection, which will contain, at a minimum, a cover letter and the annotated checklist. These reports will become part of the project documentation which would be approved by the major professor Test Plan A test plan should be developed that tests the product as a whole and address the required tests needed to evaluate all the critical use cases. The plan will include evaluation criteria for all critical use cases and a set of test data deemed adequate for acceptance testing. Specifically, the test plan will identify a set of test cases, the types of tests that will be used for these test cases, the data that will be used for each case, and the requirement traces for each test case. 8