Life Cycle Plan (LCP)

Transcription

1 LCP_FCP_F14a_T07_V2.0 Version 2.0 Life Cycle Plan (LCP) Mission Science irobots Team 07 Ashwini Ramesha Chen Li Farica Mascarenhas Jiashuo Li Ritika Khurana Siddhesh Rumde Sowmya Sampath Yun Shao OCE, Requirements Engineer Requirements Engineer, Feasibility Analyst IV&V, Quality Analyst Prototyper, Software Architect Project Manager Life Cycle Planner, Requirements Engineer Software Architect, Prototyper Feasibility Analyst, OCE LCP_FCP_F14a_T07_V2.0 10/10/14

2 Version History Date Author Version Changes made Rationale 09/20/14 FM, SR 1.0 Original for CSCI577; Tailored from ICSM OCD Template To fit CS577 course content 09/28/14 SR 1.1 Update old contents To meet course requirements 10/10/14 SR 2.0 Sections 2, 3.1, 3.2, 4, 5 are added. To modify version 1.0 according to the requirements of the FC package LCP_FCP_F14a_T07_V2.0 ii 10/10/2014

3 Table of Contents Life Cycle Plan (LCP)... i Version History... ii Table of Tables... iv Table of Figures... v 1. Introduction Purpose of the LCP Status of the LCP Assumptions Milestones and Products Overall Strategy Project Deliverables Responsibilities Project-specific stakeholder s responsibilities Responsibilities by Phase Skills Approach Monitoring and Control Methods, Tools and Facilities Resources LCP_FCP_F14a_T07_V2.0 iii 10/10/2014

4 LCP_FCP_F14a_T07_V2.0 Version 2.0 Table of Tables Table 1: Artifacts Deliverables in Exploration Phase... 3 Table 2: Artifact deliverable in Valuation Phase... Error! Bookmark not defined. Table 3: Stakeholder's Responsibilities in each phase... 5 Table 4: Skills... 9 Table 5: Tools and Usage Table 6: Module List and Their SLOC Table 7: COCOMO II Scale Drivers Table 8: COCOMO II Cost Drivers for Navigaion Module Table 9: COCOMO II Cost Drivers for Sensor Detection Module Table 10: COCOMO II Cost Drivers for Light and Sound Module LCP_FCP_F14a_T07_V2.0 10/10/14

5 LCP_FCP_F14a_T07_V2.0 Version 2.0 Table of Figures Fig. 1: COCOMO II Analysis Result..17 LCP_FCP_F14a_T07_V2.0 10/10/14

6 1. Introduction 1.1 Purpose of the LCP The purpose of the life cycle plan is to streamline the project into various phases so that the entire development team and client can achieve improved development speed, improved quality, improved project tracking and control, improved relations and minimal exposure to risks. 1.2 Status of the LCP Current version of the life cycle plan is the initial of the life cycle plan, which is version 1.0. This version of the LCP will include the artifacts developed in the Exploration phase. Also it describes each member s roles and skills in the same phase. The list of deliverables and the overall strategy to develop the project along with the responsibilities of each stakeholders are also added. The resources of the project required for the project are also estimated to analyze the project s feasibility within 24 weeks. 1.3 Assumptions The duration of the project is 24 weeks, which are 12 weeks in Fall 2014 and 12 weeks in Spring The team will get a licensed version of all the software to be used for the project. Each team member will stick to his responsibilities mentioned in section 2 during each phase and will perform them accordingly. The elementary schools will like the GUI which has been developed for the irobot. There will be regular meetings with the client, to discuss the progress, issues and other concerns. There are eight people working on the project including one DEN student is an optimum number of staff required to do this project in the given schedule. LCP_FCP_F14a_T07_V /10/2014

7 2. Milestones and Products 2.1 Overall Strategy The development of the GUI for Mission Science irobot is going to be from the scratch. The project will use the ARCHITECTED AGILE process of the Incremental Commitment Spiral Model as all the components are going to be custom made. Exploration Phase Duration: 09/12/14 09/26/14 Concept: The team should focus on understanding the current system and design the business work flow in the Exploration phase and would conduct regular weekly meetings with the client to discuss and understand current system, requirements, concerns and progress. Deliverables: Valuation Commitment Package Milestone: Valuation Commitment Review Strategy: One Incremental Commitment Cycle Valuation Phase Duration: 09/29/14 10/24/14 Concept: To evaluate the risks, the SCS excluding the students and teachers, and the developers will have win-win negotiations. The team will gather requirements and then along with the Stakeholders they will prioritize the requirements and a proposed system will be defined by these win-win negotiations. Based on this definition the team prepares initial prototypes of the high risk win conditions. Deliverables: Core Foundations Commitment Package, Draft Foundations Commitment Package, Project Effort Reports, Project Plan, Progress Reports, Prototype Report, System and Software Architecture Description, Supporting Information Document. Milestone: ARB FCR Strategy: One Incremental Commitment Cycle Foundations Phase Duration: 10/20/ /1/2014 Concept: In this phase, the feasibility of each requirement (Win condition) is determined and development starts with, usually, the most feasible and required conditions. Continue risk assessment process, regular stakeholder meetings are to be taken every week, regular progress reports and effort reports to be submitted every Monday and every other Monday respectively, project plans are to be prepared and released on project web-page, risk resolution, assessing project status, sharing implementation jobs Deliverables: Draft DC Package, DC Package. Milestone: Development Commitment Review. Strategy: One Incremental Commitment Cycle LCP_FCP_F14a_T07_V /10/2014

8 2.2 Project Deliverables Exploration Phase Table 1: Artifacts Deliverables in Exploration Phase Artifact Due date Format Medium Client Interaction Report 09/22/2014.doc,.pdf Soft copy Valuation Commitment Package 09/29/2014.doc,.pdf Soft copy Operational Concept Description (OCD) Early Section Life Cycle Plan (LCP) Early Section Feasibility Evidence Description (FED) Early Section Evaluation of Valuation 10/11/2014.xls Soft copy Commitment Package Project Plan Every alternate.mpp,.pdf Soft copy Wednesday Progress Report Every alternate Wednesday.xls Soft copy Valuation Phase Table 2: Artifact deliverable in Valuation Phase Artifact Due date Format Medium Draft Foundations Commitment Package: Operational Concept Description (OCD) Feasibility Evidence Description (FED) Life Cycle Plan (LCP) System and Software Architecture Description (SSAD) Prototype report (PRO) Evaluation of Draft Foundations Commitment Package Response to Evaluation of Draft Foundations Commitment Package Foundations Commitment Package: Operational Concept 10/13/2014.doc,.pdf Soft copy 10/13/2013.doc,.pdf, Soft copy, Bugzilla Bugzilla 10/15/2013.doc,.pdf, Soft copy, Bugzilla Bugzilla 10/20/2013.doc,.pdf Soft copy LCP_FCP_F14a_T07_V /10/2014

9 Description (OCD) Feasibility Evidence Description (FED) Life Cycle Plan (LCP) System and Software Architecture Description (SSAD) Prototype report (PRO) System and Software Requirements Definition Bugzilla report Every Monday Text Bugzilla Website Project Plan Progress Report Every alternate Wednesday Every alternate Wednesday.mpp,.pdf.xls Soft copy Soft copy LCP_FCP_F14a_T07_V /10/2014

10 3. Responsibilities 3.1 Project-specific stakeholder s responsibilities Except for the client and developer team, the Mission Science irobot project has two other success critical stakeholders: Elementary Students: These students will use the GUI to generate instructions which can be used to operate the robot. Undergraduate Students: The undergraduate students will continuously monitor the GUI during development and train the elementary school students and teachers about how to operate the GUI. Elementary School Teachers: The teachers guide the elementary school students in using the GUI to develop logical statements. 3.2 Responsibilities by Phase The following table is a template for stakeholder s responsibilities in each phase. Table 3: Stakeholder's Responsibilities in each phase Team Member / Role Prof. Darin Gray Client Ritika Khurana Project Manager, Life Cycle Planner / Exploration Valuation Foundations Development- Construction Iteration - Explain scope and primary requirement - Contribute to the win conditions - Clarify the problems from development team - Plan the project - Plan the schedule - Contact clients - Manage client interaction - Update Bugzilla - Plan project life - Assess work artifacts and provide feedback - Identify shared vision, goal, and concepts - Create detail project plan - Record project individual effort - Record project progress - Create and follow action items - Provide feedback for prototypes - Record Project progress - Create detailed project plan- Manage client interaction - Test system development modules - Provide feedback of system features - Record Project progress - Modify detailed project plan - Develop system - Manage client interaction Development- Transition Iteration - Accept the training - Prepare for system transition - Manage client interaction - Deliver final project artifacts LCP_FCP_F14a_T07_V /10/2014

11 Chen Li Requirements Engineer, Feasibility Analyst Yun Shao Feasibility Analyst, Operational Concept Engineer cycle phases - List deliverables - Identify responsibilities and skills of team members - Gather the current system details. - Analyses of Requirements - Negotiation of requirements. -Identify Risks -Risk Assessment -Identify Risks -Risk Assessment - Review the work products/ deliverables - Shaper of project plan - Provide evaluation of work products - Manage client interaction - Identify responsibilities and skills -Update Bugzilla - Capture and score MMF and win-conditions - Capture progress of winwin negotiation -Analyze the Business Case -Identify the most appropriate process -Assess and plan to mitigate risks - Assess feasibility evidence -Analyze the Business Case -Identify the most appropriate process -Assess and plan to mitigate risks -Assess feasibility evidence -Analyze and prioritize capabilities to prototype - Prepare development / production environment - Create life cycle plan - Assess life cycle content - Create detail project plan - Identify system and software requirements definition - Update website -Mitigate Risks -Plan Test Cases - Document feasibility evidence description - Assess feasibility evidence -Mitigate Risks -Plan Test Cases - Document feasibility evidence description - Assess feasibility evidence - Create operational concept description - Assess operational concept - Analyze and prioritize capabilities to prototype - Develop system - Assess system architecture and monitor alignment of system development with system architecture - Identify test plan and procedures - Test system - Develop system - Fix defects - Test system LCP_FCP_F14a_T07_V /10/2014

12 Siddhesh Rumde Life Cycle Planner Requirements Engineer Ashwini Ramesha Operational Concept Engineer Requirements Engineer - Plan project life cycle phases - List deliverables - Identify responsibilities and skills of team members - Gather the current system details. - Analyses of Requirements - Negotiation of requirements. - Review the work products/ deliverables - Shaper of project plan - Provide evaluation of work products -Interact with client - Gather the current system details. - Analyses of Requirements - Negotiation of requirements. - Create detail project plan - Identify responsibilities and skills of team members - Capture and score MMF and win-conditions - Capture progress of winwin negotiation - Analyze and prioritize capabilities to prototype - Prepare development / production environment - Capture and score MMF and win-conditions - Capture progress of winwin negotiation - Record Project progress - Create detailed project plan - Create life cycle plan - Assess life cycle content - Identify system and software requirements definition - Create operational concept description - Assess operational concept - Analyze and prioritize capabilities to prototype - Identify system and software requirements definition - Record Project progress - Modify detailed project plan - Develop system - Manage client interaction - Develop system - Test system - Assess system architecture and monitor alignment of system development with system architecture - Manage client interaction - Deliver final project artifacts - Develop system - Fix defects Jiashuo Li Prototyper Software Architect -Create the progress report -Analyze the current System -Assist in developing the OCD -- Create project plan for week 1 - Help with various documents for VCP -Create the progress report - Assist in developing the LCP -Develop the prototype. -Take feedback of the client and the undergraduate students. -Add features to the base system -Develop the GUI in conjunction to the feedback received in the Valuation phase. - Define technology dependent architecture -Create the progress report -Implementing the project and take feedback on it. -Assess system architecture and monitor alignment of system development with system architecture -Create the progress report LCP_FCP_F14a_T07_V /10/2014

13 -Physical and logical architecture -Use case diagram -System Context diagram -Artifacts and information diagram - Decide on style, patterns and frameworks - Create required UML models - Complete SSAD Sowmya Sampath Software Architect Prototyper - Create project plan for week 1 - Help with various documents for VCP -Create the progress report -Analyze the current System -Assist in developing the OCD -Physical and logical architecture -Use case diagram -System Context diagram -Artifacts and information diagram -Create the progress report - Assist in developing the LCP -Develop the prototype. -Take feedback of the client and the undergraduate students. - Define technology dependent architecture - Decide on style, patterns and frameworks - Create required UML models - Complete SSAD -Add features to the base system -Develop the GUI in conjunction to the feedback received in the Valuation phase -Help with the implementation of the project -Ensure the implementation is true to the architecture specified -Assess system architecture and monitor alignment of system development - Help perform core-capability drive-through - Create user manual - Make required changes specified by the client Farica Mascrenhas IV & V Quality Analyst -Review the project artifacts. - Keep track of the win Conditions being the shaper of the project using Winbook. -Update Bugzilla by reviewing the various tickets. - Review the project artifacts. - Keep track of the win Conditions being the shaper of the project using Winbook. -Check the quality of the prototype in conformance with the existing standards. -Update Bugzilla -Review the project artifacts. - Keep track of the win Conditions being the shaper of the project using Winbook. -Check the quality of the prototype in conformance with the existing standards -Update -Review the project artifacts. - Keep track of the win Conditions being the shaper of the project using Winbook. -Check the quality of the prototype in conformance with the existing standards -Update Bugzilla -Review the project artifacts. - Keep track of the win Conditions being the shaper of the project using Winbook. -Check the quality of the prototype in conformance with the existing standards -Update Bugzilla LCP_FCP_F14a_T07_V /10/2014

14 by reviewing the various tickets. Bugzilla by reviewing the various tickets. by reviewing the various tickets. by reviewing the various tickets. 3.3 Skills Table 4: Skills Team members Role Skills Ritika Khurana Project Manager Current skills: Programming in C, good communication skills, Project documentation, identify skills, project planning Required skills: need to brush up usage of visual studio and negotiation skills Ashwini Ramesha OCE Current skills: C programming, Requirement analysis, Buying information, Project documentation, identify skills Required skills: UML, Visual studio, Negotiation skills Chen Li Requirements Engineer Current skills: Java, C, SQL, HTML, CSS, JavaScript, Buying information, Project documentation, Requirement analysis Required skills: Visual Studio, Website development, Analytical skill Sowmya Sampath Software Architect Current skills: C++, Java, Creating UML, Documentation, Analytical skill Required skills: Visual Studio Siddhesh Rumde Life Cycle Planner Current skills: Java, C++, SQL, Visual Studio JavaScript, Project Documentation LCP_FCP_F14a_T07_V /10/2014

15 Required skills: Negotiation skills, C Programming, Requirement analysis, Visual Paradigm Jiashuo Li Prototyper Current skills: UML, Visual Studio, Java Required skills: Embedded software development, analytical skills Yun Shao Feasibility Analyst Current skills: C, C++, php/html, mysql, obj-c, project documentation, analytical skills Required skills: visual studio Farica Mascarenhas IV&V Current skills: Shell scripting, Perl, Java, C++, SQL, AutoShell, HTML, JavaScript, Negotiation skills, Analytical Skills Required skills:.net LCP_FCP_F14a_T07_V /10/2014

16 4. Approach 4.1 Monitoring and Control Closed Loop Feedback Control The weekly progress reports identify the activities undertaken and completed in the week. Project Plan provides the baseline for the activities. Any deviation from this baseline is identified, its severity is analyzed and action, as appropriate, is taken The progress reports records planned and actual efforts and tasks spent. If the difference is outside acceptable limits, then the Project Manager can initiate action by calling in team meeting and discuss this issue and follow up measures and tasks for next week The weekly risk analysis ensures that all risks identified have a mitigation plan. This will help to stay on track with the project schedule. The Winbook lists all the requirements and the risks and also prioritizes the requirements. The Team uses Google drive to communicate all the matters within the members and to keep all the artifacts organized. The team also uses the DEN discussion forum and blog for sharing files and for communicating Reviews Weekly group review: This review is made every week so that each team member can contribute their work. IIV&V: By the den student, all artifacts are reviewed and bugs are released for each one of them. Win-Win Negotiations: Negotiations and review in which all values from the SCS are noted. Also help to estimate and, prioritize and order the requirements Review by Undergraduate Students: The undergraduate students incrementally monitor the GUI of the system and give their feedback which can be used by the developer team for further improvements. LCP_FCP_F14a_T07_V /10/2014

17 4.2 Methods, Tools and Facilities Table 5: Tools and Usage Tools Usage Provider Microsoft Word Constructs documents for all artifacts. Also used for USC 2012 developing client interaction reports. Microsoft Project Creates Gantt charts for Progress reports and LCP USC 2003 Microsoft Creates presentation for client meeting and ARB reviews USC PowerPoint 2012 Mozilla Firefox and Downloads course material and medium for USC Google Chrome communication among stakeholders Winbook tool Facilitates and supports Win-Win negotiation USC Subversion Implements version control system to maintain artifact Open Source integrity and traceability Microsoft Visual Build.NET framework USC Studio 2012 Mockflow Online Creates throwaway prototype for the project. Open Source Tool Visual Paradigm Creates UML diagrams that are used for documenting the USC use cases and sequence diagrams WinAVR Compiler for C programs after creating set of instructions to be implementedin Visual Studio. Open Source LCP_FCP_F14a_T07_V /10/2014

18 5. Resources - Estimated CSCI577a Effort : 8 team members at 12 hrs/week for 24 weeks - Most Likely estimated effort: 2304 hours - Budget information: This project has no budget for our development efforts, while the software is provided and tools are free. - Project duration: 12 weeks (Fall 2014) + 12 weeks(spring 2015) - Component modules in your development project: Single GUI including linking tool like GTK+ for compiling the generated C instructions. - Programming language used: Visual Basic C++ and C. Table 6: Module Lists and their SLOC No. Module Name Brief Description SLOC REVL 1 Navigation Module Provide navigation for the irobot to move in any direction % 2 Sensor Module Provide sensation of the external environment to the irobot % 3 Light & Music Module Enable the light and music feature of the irobot % Table 7: COCOMOII Scale Driver Scale Driver Value Rationale PREC NOM There is a considerable understanding of the product s objectives, experience in developing such GUI and some need for innovative data processing and architectures. FLEX VHI There is a very high need for GUI conformance with preestablished requirements and external interface specifications. RESL NOM All major risks are documented with mitigation plans for each module; however there is a considerable amount of uncertainty pertaining to the success of User Interface and COTS software. TEAM VHI No extra efforts are needed to synchronize stakeholders and they are ready to accommodate other stakeholder s objectives. PMAT NOM (Level 2) ICSM Principles and Guidelines are followed strictly by the developer team LCP_FCP_F14a_T07_V /10/2014

19 Table 8: COCOMOII Cost Driver for Navigation Module Cost Driver Value Rationale RELY NOM If the system fails it will deter the elementary students to use the irobot. However, it will not have a catastrophic effect on the use of irobot by the students. DATA NOM There will be moderate test cases for testing the navigation module. DOCU NOM Nominal Documentation is required for future maintenance CPLX HI Highly structured programming with nested controls and extensions will be required for this module. RUSE NOM The code in this module can be used for developing the other two modules. TIME NOM The system consumes nominal time and resources in this module. STOR HI The navigation module requires high storage PVOL LO The platforms are stable and do not require frequent upgrades ACAP NOM Analysts have basic experience PCAP HI Most of the team members have the ability to code in various aspects required for the project. PCON VLO Not all the team members are continuing with 577b. APEX VLO All of the team members have low experience related to this module LTEX LO Low programming language and software tool experience PLEX NOM Few team members have high platform experience TOOL NOM The tools used are moderately mature and basic SITE HI All team members and client are on campus; whereas the elementary school students are in the same city. Table 9: COCOMOII Cost Driver for Sensor Detection Module Cost Driver Value Rationale RELY NOM If the system fails it will deter the elementary students to use the irobot. However, it will not have a catastrophic effect on the use of irobot by the students. DATA HI There will be large number of test cases for testing the sensor module. DOCU NOM Nominal Documentation is required for future maintenance CPLX VHI A lot of complex tasks like task synchronization, recursive coding and complex calls is involved. LCP_FCP_F14a_T07_V /10/2014

20 RUSE NOM The code in this module can be used for developing the other two modules. TIME HI The system consumes larger time and resources in this module. STOR VHI The sensor detection module require very high storage PVOL LO The platforms are stable and do not require frequent upgrades ACAP NOM Analysts have basic experience PCAP HI Most of the team members have the ability to code in various aspects required for the project. PCON VLO Not all the team members are continuing with 577b. APEX VLO All of the team members have low experience related to this module LTEX LO Low programming language and software tool experience PLEX NOM Few team members have high platform experience TOOL NOM The tools used are moderately mature and basic SITE HI All team members and client are on campus; whereas the elementary school students are in the same city. SCED NOM There is a nominal schedule constraint. Table 10: COCOMOII Cost Driver for Light & Sound Module Cost Driver Value Rationale RELY NOM If the system fails it will deter the elementary students to use the irobot. However, it will not have a catastrophic effect on the use of irobot by the students. DATA NOM There will be moderate test cases for testing the light and sound module. DOCU NOM Nominal Documentation is required for future maintenance CPLX HI Highly structured programming with nested controls and multimedia extensions will be required for this module. RUSE NOM The code in this module can be used for developing the other two modules. TIME NOM The system consumes nominal time and resources in this module. STOR HI The Light and Sound module requires high storage capacity. PVOL LO The platforms are stable and do not require frequent upgrades ACAP NOM Analysts have basic experience LCP_FCP_F14a_T07_V /10/2014

21 PCAP HI Most of the team members have the ability to code in various aspects required for the project. PCON VLO Not all the team members will be continuing in 577b. APEX VLO All of the team members have low experience related to this module LTEX LO Low programming language and software tool experience PLEX NOM Few team members have high platform experience TOOL NOM The tools used are moderately mature and basic SITE HI All team members and client are on campus; whereas the elementary school students are in the same city. SCED NOM There is a nominal schedule constraint. LCP_FCP_F14a_T07_V /10/2014

22 Fig. 1: COCOMO II Analysis Result If we use the most likely approach, the project can be completed by seven personnel in the given schedule. However, if we use the pessimistic approach, then we are short staffed by a smaller margin. This can be resurrected if the personnel who join the project in the next semester have larger experience in terms of applications, language and platform. This will definitely help the team in completing the project. LCP_FCP_F14a_T07_V /10/2014