Life Cycle Plan (LCP)
SnApp – Voice Communication System
Team 05
Divij Durve - Integrated Independent Verification and Validation Harsh Mhatre - System/Software Architect Khyati Thakur - Prototyper Monica Varhale - Feasibility Analyst Nikita Gupta - Project Manager Shlok Naik - Operational Concept Manager Shruti Gotmare - Life Cycle Planner Sushmaja Bondili - Requirements Engineer
09/28/2014
ii Version History
Date Author Versi Changes made Rationale on
Original for CSCI477; Tailored 08/20/12 SK 1.0 To fit CS477 course content from ICSM OCD Template
iii Table of Contents
Life Cycle Plan (LCP)...... i Version History...... ii Table of Contents...... iii Table of Tables...... iv Table of Figures...... v 1. Introduction...... 1 2. Milestones and Products...... 2 3. Responsibilities...... 3
3.1 Responsibilities by Phase...... 3
3.2 Skills...... 3
4. Approach...... 5
4.1 Monitoring and Control...... 5
4.2 Methods, Tools and Facilities...... 5
5. Resources...... 6 6. Iteration Plan...... 11 6.1 Plan...... 11 6.1.1 Capabilities to be implemented...... 11 6.1.2 Capabilities to be tested...... 11 6.1.3 Capabilities not to be tested...... 12 6.1.4 CCD Preparation Plans...... 12 6.2 Iteration Assessment...... 12 6.2.1 Capabilities Implemented, Tested, and Results...... 12 6.2.2 Core Capabilities Drive-Through Results...... 12 6.3 Adherence to Plan...... 13
iv Table of Tables
Table 1: Stakeholder's responsibilities...... 3 Table 2: COCOMOII Scale Driver...... 6 Table 3: COCOMOII Cost Driver...... 6 Table 4: Module lists and SLOC of each module - example...... 7 Table 5: COCOMOII Scale Drivers - example...... 7 Table 6: COCOMOII Cost Drivers of Module 1 - Plant Service Recording module - example...... 8 Table 7: Construction iteration capabilities to be implemented...... 11 Table 8: Construction iteration capabilities to be tested...... 11 Table 9: Capabilities implemented, tested, and results...... 12
v Table of Figures
Figure 1: COCOMO Estimation Result...... 10
vi Introduction
<< Discuss the purpose of the LCP>> << Discuss the status of the LCP especially key differences from previous version, for example “ The status of the LCP is currently at the Operation Commitment Package version number 10.0. This is the version that will be delivered to the client. The major changes from Rebaselined Foundations phase are: Two team members, Ritesh Kothari and Jerome Wan, did not continue in Development Phase. One core capability, Report and Certificate Generation, is deferred.” >>
1 Milestones and Products
<< Identify the life cycle phases and its dates, deliverables, milestone and strategy of each phase. For example:
“Exploration phase Duration: 08/24/09- 9/21/09 Concept: They identify project operational concept, system and software requirement, system and software architecture, and life-cycle plan. These phases prioritize the capabilities, conduct investment and feasibility analysis, and implement the software prototype. Deliverables: Valuation Commitment Package Milestone: Valuation Commitment Review Strategy: One Incremental Commitment Cycle”
Note: Schedule of the class and its milestone can be found in the first lecture of the class.>>
2 Responsibilities
A.1.1 Responsibilities by Phase
<< Identify responsibilities of each team member including client, user, and maintainer in each phase. Please note that a document name such as OCD, WinWin Agreements or Prototype is not a responsibility. Examples of responsibilities are identify project risk, develop prototype, acquire NDI, and etc.
The following table is a template for each stakeholder’s responsibilities. Repeat the table for each stakeholder. >>
Table 1: Stakeholder's responsibilities
Name: <
A.1.2 Skills
Team Role Skills members
Divij Durve Integrated Independent Current skills: Android SDK, Java, MySQL, Oracle Verification & Validation db, PostgreSQL,HTML, CSS, jQuery, Spring, Architecture design & Discussion Required skills: ability to objectively judge requirements without taking sides.
Harsh System/Software Architect Current Skills: UML Designing, Web Technologies, Mhatre and Developer DBMS & SQL, Java, Ruby
3 Required Skills: PostgreSQL
Khyati Prototyper and Developer Current Skills: Web technologies, Axure RP Thakur Required Skills: Ruby on Rails, PostgreSQL
Monica Feasibility Analyst and Current Skills: COCOMO, Analysis skills, JAVA, Varhale Developer Web technologies, MySql, Python.
Required Skills: Ruby on Rails, PostgreSQL, Gitlab.
Nikita Project Manager and Current Skills: Software & project management, C+ Gupta Tester +, Web technologies, Python, SQL (PostgreSQL/MySQL)
Required Skills: Ruby on Rails
Shlok Naik Operational Concept Current Skills: Manager and Tester Web Technologies, JAVA, UML Design
Required Skills: Ruby On Rails, PostgreSQL,Gitlab
Shruti Life Cycle Planner and QA Current Skills: Gotmare C#, VBScript, Quality management, Git, Project planning skills
Required Skills: Ruby on Rails, PostgreSQL
Sushmaja Requirements Engineer Current Skills: C, JAVA, jQuery, HTML, CSS, Bondili and Developer JavScript, MySQL, Linux, Communication Skills
Required Skills: Ruby on Rails, PostgreSQL
4 Approach
A.1.3 Monitoring and Control
<< Identify the approach you are using in monitoring and controlling your project. Examples are Progress Report, Project plan, and etc. >>
.1.3.1 Closed Loop Feedback Control
<< Explain how your team gets and provides feedback internally within the team. >>
.1.3.2 Reviews
<
A.1.4 Methods, Tools and Facilities
<< Describe methods, tools, facilities and their usage and provider that you used in your project>>
Tools Usage Provider Red Ridge 3.0 Provides examples for user interface and system functionality, CSC is helpful in the development of prototype PEAR Creates a framework and distribution system for reusable PHP Open source components
5 A.2. Resources
<< Identify the following information in order to estimate the software cost: - Estimated CSCI577a Effort : X team members at X hrs/week for 12 weeks - Estimated CSCI577b Effort : X team members at X hrs/week for 12 weeks - Total estimated effort - Budget information - Project duration - Component modules in your development project. - Programming language used
You should provide rationale for every cost driver and scale factor of each module.
Note: Refer to Barry W. Boehm, et al, Software Cost Estimation With COCOMO II, Prentice all PTR, New Jersey, 2000 on how to estimate software cost . >>
Table 2: COCOMOII Scale Driver
Scale Driver Value Rationale
Table 3: COCOMOII Cost Driver
Cost Driver Value Rationale
<< Provide screenshot of your COCOMO II analysis result and interpret what does that mean to your project. Please note the number of COCOMOII Cost Driver tables is equal to the number of software modules in your project. >>
<< ------The following is an example of section 5 ------>>
In this section, we present the project effort and schedule estimation of the project using COCOMO II.
The following conditions were used to estimate the cost of our system, the Plant Service Tracking System. 1. This project has no budget for our development efforts. However, the client must provide some necessary equipment for development and testing, e.g. handheld device.
6 2. The duration of the project is 24 weeks, which are 12 weeks in CSCI477a and 12 weeks in CSCI477b. 3. There are ten developers. 4. There are five modules in this system. a. Plant Service Recording module b. Plant Service Management module c. Authentication module d. Utility module e. Barcode Generating module (NDI) 5. All modules are developed with Java technology, i.e. JSP, Java bean and JavaScript. 6. Only one NDI for Barcode Generating module is calculated effort because we never use it and need effort to research and test. 7. The SLOC of NDI, Barbecue java library, in Barcode generating module is counted with USC CodeCount toolset.
The following is module listed in the system and its estimated size with Source Lines of Code (SLOC)
Table 4: Module lists and SLOC of each module - example
No. Module Name Brief Description SLOC REVL 1 Plant Service Recording Provide plant service recording system 500 10% for worker 2 Plant Service Management Provide plant service management 2000 10% system for manager 3 Authentication User authentication and authorization 300 5% mechanism 4 Utility Provide essential utilities supporting the 200 5% system 5 Barcode Generating Generate barcode using NDI, Barbecue 3561 0% java library
The following is COCOMOII Scale Drivers and rationales of choosing the values.
Table 5: COCOMOII Scale Drivers - example
Scale Driver Value Rationale PREC HIGH The development team is familiar with this type of online application. Although, concurrent development associates with extensive new hardware and operational procedures. FLEX HIGH The system needs to considerably conform to pre-established requirement from the client and external interface specifications, e.g. GPRS services and Internet protocols. RESL HIGH All critical risk items, schedule, budget and internal milestones
7 are identified. However, there is some uncertainty in hardware compatibility. TEAM HIGH Each stakeholder has considerable consistency of objectives and cultures, and considerable ability and willingness to accommodate others’ objectives. In addition, the stakeholders have basic experience in operating as a team. PMAT NOMINAL The development team follows ICSM guidelines, which the processes are defined and repeatable but the result may not be consistent, CMM Level 2.
//Since each module is not the same as other modules in various aspects, then you should have one cost driver table for one module. If you have 5 modules, you should have 5 tables of cost drivers. //
The following is COCOMOII Cost Drivers of each module and rationales of choosing the values.
Table 6: COCOMOII Cost Drivers of Module 1 - Plant Service Recording module - example
Cost Driver Value Rationale RELY NOMINAL Although, some modules in this project depend on this module, the effect of the software failure is moderate and losses are easily recoverable. DATA LOW The ratio of bytes in the testing database to SLOC in the program is approximately less than 10 because the database will store only information of plant services, which are employee id, check-in time, check-out time, each plant conditions, and short comments, of 20 locations in each week. DOCU NOMINAL Because the development process follows ICSM, the document for life-cycle needs is normal. CPLX NOMINAL It contains simple message passing control, standard math and statistical routines for generating reports, and simple I/O process includes device selection from bar code scanner or user interface, status checking of bar code scanner, and error processing. Additionally, it has simple structural changes and uses simple widget set. RUSE LOW It is not intended to be reused for the future project. TIME NOMINAL The percentage of available execution time expected to be used by the system and subsystem consuming the execution time resource is less than 50% because this system is used when a worker does plant services which are preformed once a week, and this system is used by a manager to review plant service reports which at most couple times a week. STOR NOMINAL The percentage of available storage expected to be used by the system and subsystem is less than 50% because the most data is general text and the information of plant services such as plant conditions and comments are condensed.
8 PVOL LOW Major changes of the platform, i.e. Apache Tomcat, JDK, MySQL, and web browsers, are approximately every year. ACAP VERY The analysts have the ability to analyze, design, communicate, HIGH and cooperate very well. PCAP VERY Programmers are capable, efficient and thorough. They are able HIGH to communicate and cooperate very well. PCON NOMINAL We have 10 team members in CSCI477a and 8 team members in CSCI477b that suitable for our project sizing. APEX NOMINAL The average experience of the team members for this online web- based application is about one year. LTEX NOMINAL The development team plans to develop this web-based application with JSP, HTML, and Java script, and uses SQL language to query information from the database. The tools for programming are Dreamweaver and Eclipse. Therefore, the language and tool experience is nominal because team members have at least one year experience with these languages and tools. PLEX LOW The server platform is web server Apache Tomcat with JDK version 1.5, and database is MySQL. Although, all developers have this platform experience, this module need implementation an user interface on handheld device which our developers have less experience. TOOL LOW The software tools development team plan to use is just simple, frontend, backend CASE, and supporting little integration. There is no support for life-cycle. SITE VERY In CSCI477a, six of eight team members are on-campus students, HIGH In CSCI477b, four of six team members are on-campus students; only two team members are off-campus students. Additionally, we use wideband electronic communication and occasional video conference. SCED NOMINAL The schedule is fixed for 12 weeks in Fall semester and 12 weeks in Spring semester.
The following is the result from COCOMOII estimation based on Scale Drivers and Cost Drivers discussed above.
9 Figure 1: COCOMO Estimation Result
The form of schedule our project uses is the Independent Variable (SAIV) strategy, 24–week schedule drives development of a set of top priority core capabilities. Therefore, the estimates show the effort required for the project.
According to COCOMO II Estimates for CSCI477, one team member effort = 0.83 COCOMO II person months. The pessimistic effort from the COCOMO estimation above is 5.1, so the total team members need for this project = 5.1/0.83 = 6.14
Since, we have 10 people, from this effort estimation; we would be able to finish the project in time. >>
10 6. Iteration Plan 6.1 Plan
<< Provide a high-level overview of the content of the given iteration. Indicate which Life cycle milestones will be addressed. >>
6.1.1 Capabilities to be implemented
<< For the milestone identified above, identify the capabilities that will be implemented in the upcoming iteration. Identify the features, requirements or use–cases that are being developed (implemented, tested, etc.) for this iteration. Each component should be accounted for in at least one iteration. All requirements should be implemented and tested (or re-negotiated) by the completion of all the iterations. Be mindful of implementation dependencies. Document complex dependencies and communicate them to the appropriate development staff. >>
Table 7: Construction iteration capabilities to be implemented
ID Capability Description Priority Iteration < ID > < Capability > < comments >
6.1.2 Capabilities to be tested
<< For the milestone identified above, identify the capabilities that will be tested in the upcoming iteration.
Identify the software features and combinations of software features to be tested this iteration. This may also include non-functional requirements or extra-functional requirements, such as performance, portability, and so forth.
Additionally you may need to test every requirement listed in the WinWin Agreements DC package, non-requirement component features such as COTS capabilities and quality, API functionality, etc. >>
Table 8: Construction iteration capabilities to be tested
ID Capability Description Priority Iteration < ID > < Capability > < comments >
11 6.1.3 Capabilities not to be tested
<< Identify notable features, and significant combinations of features, which will not be tested this iteration and why (e.g. a given feature uses a feature which will be implemented in following iteration). >>
6.1.4 CCD Preparation Plans
<< Identify the clients and other users who will be involved in the Core Capability Drive- through, the usage scenarios that it will support, and the specific CCD preparation plans and milestones. These may include
- user context-setting - site preparation dry runs, - feedback forms, and - CCD risk management plans. >> 6.2 Iteration Assessment
6.2.1 Capabilities Implemented, Tested, and Results
<< Describes, in brief, the capabilities that were implemented and the test results. The capabilities implemented and tested do not necessarily need to match the ones listed in section 6.1 because some capabilities may have been pushed to the next iteration. >>
Table 9: Capabilities implemented, tested, and results
ID Capability Test Case Test Results If fail, why? < ID > < Capability > < TC-XX > Pass/Fail < comments > …
6.2.2 Core Capabilities Drive-Through Results
<< Briefly summarize the feedback you received from your client(s). You need to be specific enough to cover the critical capabilities or scenarios that were discussed, demoed, or shown. Your descriptions MUST, but not limited to, cover the following areas: Positive feedbacks Improvements needed/suggested
Changes to‐be considered (Reprioritized capabilities, requirements, GUI, etc.)
Risks (New risks introduced, risks mitigated, etc.)
12 Note: Make sure to be specific to the capabilities shown/demonstrated/driven-through. Simply stating that the clients liked the capabilities is not sufficient. >> 6.3 Adherence to Plan
<< Describe how well the iteration ran according to plan. Was it on budget and on time? Is there any uncertainty in the Software Development Status? Provide some insight to avoid mistakes for future iterations. >>
13