Life Cycle Plan (LCP)

Transcription

1 Life Cycle Plan (LCP) Women at Work Team No: 14 Sr no Name Role 1 Srikant Madhava Project Manager 2 Sanath Bhandary Operational Concept Engineer 3 Rohit Kudva Feasibility Analyst 4 Varma Maryala Life Cycle Planner 5 Praneet Surana Requirements Engineer 6 Dinesh Yeduguru Software Architect 7 Nishant Jani Prototyper 8 Brian Bousman IIV&V 09/27/2014

2 ii

3 Version History Date Author Version Changes made Rationale 09/27/14 Nishant Jani 1.0 Added skills and role for each member of the team To get a complete understanding of roles and skills of each team member for planning future tasks related to the project. iii

4 Table of Contents Life Cycle Plan (LCP)...i Version History... iii Table of Contents...iv Table of Tables... v Table of Figures...vi 1. Introduction Milestones and Products Responsibilities Responsibilities by Phase Skills Approach Monitoring and Control Methods, Tools and Facilities Resources Iteration Plan Plan Capabilities to be implemented Capabilities to be tested Capabilities not to be tested CCD Preparation Plans Iteration Assessment Capabilities Implemented, Tested, and Results Core Capabilities Drive-Through Results Adherence to Plan iv

5 Table of Tables Table 1: Stakeholder's responsibilities... 3 Table 2: COCOMOII Scale Driver... 7 Table 3: COCOMOII Cost Driver... 7 Table 4: Module lists and SLOC of each module - example... 8 Table 5: COCOMOII Scale Drivers - example... 8 Table 6: COCOMOII Cost Drivers of Module 1 - Plant Service Recording module - example... 9 Table 7: Construction iteration capabilities to be implemented Table 8: Construction iteration capabilities to be tested Table 9: Capabilities implemented, tested, and results v

6 Table of Figures Figure 1: COCOMO Estimation Result vi

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

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

9 3. Responsibilities 3.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. >> Name: <<name>> Role: << role name>> Exploration <<responsibilities>> Valuation <<responsibilities>> Foundations <<responsibilities>> Development- <<responsibilities>> Construction Iteration Development- <<responsibilities>> Transition Iteration Table 1: Stakeholder's responsibilities 3.2 Skills Team members Role Skills Srikant Madhava Project Manager, Operational Concept Engineer Current Skills: + Interpersonal skills + Client interaction + Java/PHP programming experience. Required Skills: + Project planning + COCOMO II + Neon CRM 3

10 Sanath Bhandary Rohit Kudva Varma Maryala Praneet Surana Operational Concept Engineer/ Requirement Engineer Feasibility Analyst / Project Management Life Cycle Planner/ Software Architect Requirement Engineer/ Life Cycle Planner + Schedule management + Project management tools like Mantis or JIRA Current Skills: +Communication and interpersonal skills + Java/ PHP programming skill. Required skills: + System analysis skills + COCOMO II + Neon CRM + UML Modelling Current skills: + Java/PHP/ JavaScript, HTML5 programming skill. + Web Server management Required Skills: + UML Modeling + System analysis + Feasibility and risk analysis Current Skills: + PHP/ Java/ JavaScript programming. Required Skills + Life Cycle plan delivery + Risk analysis and mitigation + Quality Management + UML Modeling Current skills: + Communication and interpersonal skills + Client interaction + HTML5 and CSS3 programming. Required Skills: + Familiarity with tools like WINBOOK and Bugzilla + Feasibility analysis + Requirement Negotiation. Dinesh Yeduguru Software Architect Current skills: + PHP, JavaScript 4

11 Nishant Jani Prototyper/ Requirement Engineer programming experience. + Experience with WordPress CMS + Communication and interpersonal skills. Required skills: + Project Scoping + Neon CRM + REST/SOAP API + UML Modeling Current skills: + PHP, JavaScript, HTML5, CSS3 programming experience. + Experience with prototyping tools like pencil project, google drawing. + Client interaction Required Skill: + WordPress CMS + Neon CRM + UML Modeling Brian Bousman IIV&V / Tester Current Skills: + Excellent communication + Good project scoping + Client Interaction + Unit Testing and Quality Control Required Skills: + Familiarity with WinBook and Bugzilla + Value based document review 5

12 4. Approach 4.1 Monitoring and Control << Identify the approach you are using in monitoring and controlling your project. Examples are Progress Report, Project plan, and etc. >> Closed Loop Feedback Control << Explain how your team gets and provides feedback internally within the team. >> Reviews <<Describe various kinds of review that your team is using to control your project. >> 4.2 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 <Tool> <Usage> <Tool Provider> 6

13 5. 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 <Driver name> <value> <comments> Table 3: COCOMOII Cost Driver Cost Driver Value Rationale <Driver name> <value> <comments> << 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 >> 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. 2. The duration of the project is 24 weeks, which are 12 weeks in CSCI477a and 12 weeks in CSCI477b. 7

14 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 % for worker 2 Plant Service Management Provide plant service management % 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 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 are identified. However, there is some uncertainty in hardware compatibility. 8

15 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 STOR 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. 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. PVOL LOW Major changes of the platform, i.e. Apache Tomcat, JDK, MySQL, and web browsers, are approximately every year. 9

16 ACAP VERY HIGH The analysts have the ability to analyze, design, communicate, and cooperate very well. PCAP VERY HIGH Programmers are capable, efficient and thorough. They are able 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 webbased 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 SITE SCED VERY HIGH is no support for life-cycle. In CSCI477a, six of eight team members are on-campus students, 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. 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. 10

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

18 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. >> 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 > <value> <value> 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 > <value> <value> 12

19 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). >> CCD Preparation Plans << Identify the clients and other users who will be involved in the Core Capability Drivethrough, 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 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 > 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.) Note: Make sure to be specific to the capabilities shown/demonstrated/driven-through. Simply stating that the clients liked the capabilities is not sufficient. >> 13

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