Life Cycle Plan (LCP)

Transcription

1 Life Cycle Plan (LCP) Version 1.0 Life Cycle Plan (LCP) Software Quality Analysis as a Service (SQAaaS) Team No.1 Kavneet Kaur Requirement Engineer George Llames IIV & V Aleksandr Chernousov Life Cycle Planner Supicha Phadungsilp Feasibility Analyst Reza Khazali Software Architect Jincheng He Quality Focus Point Aditya Kathuria Prototyper Chris Harman Operation Concept Engineer 10/15/2017 LCP_FCP_F17a_T01_V1.0.doc 10/15/2017

2 Version History Date Author Version Changes made Rationale 10/15/17 AC Initial LCP ii

3 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 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 iii

4 Life Cycle Plan (LCP) Version 1.0 Table of Tables Table 1: Artifacts Deliverables in Exploration Phase... 3 Table 2: Artifact deliverable in Valuation Phase... 3 Table 3: Artifact deliverable in Foundations Phase... 3 Table 4: Stakeholder's Responsibilities in each phase... 4 Table 5: Development Team s Skills... 7 Table 6: Tools used for the Project... 9 Table 7: COCOMOII Scale Driver Table 8: COCOMOII Cost Driver. Module 1: Statistical Page (2000 SLOC, 15% REVL) Table 9: COCOMOII Cost Driver. Module 2: Profiling System (5000 SLOC, 15% REVL) Table 10: COCOMOII Cost Driver. Module 3: HTTPS (1000 SLOC, 15% REVL) LCP_FCP_F17a_T01_V1.0.doc 10/15/2017

5 Life Cycle Plan (LCP) Version 1.0 Table of Figures No table of figures entries found. LCP_FCP_F17a_T01_V1.0.doc 10/15/2017

6 1. Introduction 1.1 Purpose of the LCP LCP helps us to complete project on time (not to overrun its time and costs). Careful and precise ning, finding out and addressing risks on each phase, eliminating technical debts- all of those helps us to finish all the task and modules on time, not to be too optimistic (along with not being too pessimistic), not to overrun the costs of the project (in case of CSCI 577 it helps not to overrun time constraints). LCP also helps to keep all the team members and stakeholders on the same page and clearly understand the purpose and final aim of the project. 1.2 Status of the LCP Current version of LCP is 1.0. It is an initial LCP for finding out the goals of Foundation Phase of ICSM. This version is going to be updated as the time goes on, new ICSM phases take place and project s progress is evaluated. 1.3 Assumptions The project s duration is 24 weeks- 12 weeks in Fall 2017 and 12 weeks in Spring 2018 Eight members will work in Fall Seven members will work in Spring 2018 (all members exept for Aditya Kathuria, who is graduating this semester). Requirements for Sping 2018 won t contradict with stated in Fall

7 2. Milestones and Products 2.1 Overall Strategy SQAaaS is a project that had a prototype that was used as an example- the project was almost written from a scratch. We use some COTS in this project (D3). This project is based on ReactJS for front-end and node.js for backend. Furthermore this project communicates with other parts of this project using JSON data. Exploration phase Duration: 09/06/ /13/2017 Concept: Identify overall system s state,, architecture. Plan the overall software cycle. Deliverables: Risk Deflect report, WinBook, Overall system architecture. Milestone: Requirements list Strategy: One IC cycle, Risk analysis, Win-Win negotiations. Valuation phase: Duration: 09/14/ /25/2017 Concept: Find out most important and analyze final, analyze risks, make LCP clearer, make UI prototype (mockup), find out project feasibility. Deliverables: UI prototype (mockup), Initial architecture design, Prototype Presentation Milestone: Prototype Presentation Strategy: One IC cycle, Risk Analysis, Win-Win negotiations, Prototyping, Planning Poker Foundation phase Duration: 09/26/ /25/2017 Concept: Work on Statistical page, Profiling System prototypes and implementation, HTTPS implementation, learning technologies and languages used in project by team members Deliverables: Working initial system Milestone: End of CSCI 577a Strategy: One IC cycle, Risk analysis, development 2.2 Project Deliverables Below is the list of all deliverables on each phase. 2

8 2.2.1 Exploration Phase Table 1: Artifacts Deliverables in Exploration Phase Artifact Due date Format Medium Team Website 09/13/2017.html Website hosted online WinBook 09/13/2017.html Online Website Jira tickets and report Every Monday.html Online Website Valuation Phase Table 2: Artifact deliverable in Valuation Phase Artifact Due date Format Medium Prototype presentation 09/27/2017.ppt In-class presentation Jira tickets and report Every Monday.html Online Website UI mockup 09/27/2017.bmpl Balsamiq /Foundations Phase Table 3: Artifact deliverable in Foundations Phase Artifact Due date Format Medium Jira tickets and report Every Monday.html Online Website ARB Presentation 10/13/2017.ppt In-class presentation LCP 10/13/2017.doc Team website Prototypes 10/13/2017.js Team Website, GitHub Software architecture 10/13/2017.vpp Team Website FED 10/13/2017.doc Team Website OCD 10/13/2017.doc Team Website 3

9 3. Responsibilities 3.1 Project-specific stakeholder s responsibilities We do not have project-specific stakeholders. The only project s specialty is that our will also be the maintainer (at least for now). 3.2 Responsibilities by Phase Table 4: Stakeholder's Responsibilities in each phase Team Member / Role Name: Kavneet Kaur Role: Manager & Team Leader/ Requirements Engineer Name: Aleksandr Chernousov Role: Life Cycle Planner/ Developer / Exploration Valuation Foundations Development- Construction Iteration Analyze scope of the project Arrange team meetings Arrange negotiation sessions with the Keep track of project progress Interact with the Gather project Fill in the Winbook Plan the project s life cycle Analyze the Share responsibilities between team Analyze scope of the project Arrange team meetings Arrange negotiation sessions with the Keep track of project progress Interact with the Gather project Make sure, that project progress meets the Update the Winbook Plan the project s life cycle Analyze the Share responsibilities Analyze scope of the project Arrange team meetings Arrange negotiation sessions with the Keep track of project progress Interact with the Gather project Make sure, that project progress meets the Plan the project s life cycle Analyze the Share responsibilities between team Development- Transition Iteration 4

10 Name: Supicha Phadungslip Role: Feasibility Analysis/ Developer Name: Reza Khazali Role: Systems and Software Architect/ Manager & Team Leader members - Gather the Analyze risks - Evaluate overall system Make initial system architecture assumption Arrange team meetings Arrange negotiation sessions with the between team members Estimate time and costs for each task Prototype project s features Gather the Analyze risks Figure out top risks of the project Suggest risks mitigation strategy Prototype project s features Evaluate specific system Make initial system architecture Make initial use cases Arrange team meetings Arrange negotiation sessions with the members Estimate time and costs for each task Implement project s features Analyze risks Figure out top risks of the project Suggest risks mitigation strategy Do Return On Investment analysis Do feasibility analysis on project s prototype Implement project s features Make system architecture Make use cases Make class and workflow diagrams Assign IDs to all use cases and diagrams Explain system architecture to other team members Arrange team meetings Arrange negotiation sessions with the 5

11 Name: Jincheng He Role: Developer/ Requirements engineer Name: Aditya Kathuria Role: Prototyper/ Developer Name: George Llames Role: Verification and Validation/ Operational Concept Engineer Gather Interact with the Gather project Fill in the Winbook Gather Make initial system s prototype design - Verify and validate work products and Get an overall system overview Make initial operational concept assumptions Prototype project s features Interact with the Gather project Make sure, that project progress meets the Update the Winbook Update initial system s prototype design Make UI mockups Make prototyping of most important modules Prototype project s features Verify and validate work products and Negotiate with team about issues in project development Develop operational concept Implement project s features Interact with the Gather project Make sure, that project progress meets the Make modules prototypes Make whole system prototype Identify problems that can arise during implementation of system Implement project s features Verify and validate work products and Negotiate with team about issues in project development Update operational concept to meet changing 6

12 Name: Chris Harman Role: Developer/ Verification and Validation Gather Verify and validate work products and Prototype project s features Verify and validate work products and Negotiate with team about issues in project development Implement project s features Verify and validate work products and Negotiate with team about issues in project development Name: Pooyan Behnamghader Role: Client, Maintainer Provide the Other stakeholders responsibilities Provide the Provide the Attend team s Attend team s Prototype ARB presentation Comment the Comment the development of development of the system the system 3.3 Skills Table 5: Development Team s Skills Team members Role Skills Kavneet Kaur Manager & Team Leader/ Requirements Engineer 7 Current Skills: COCOMO II, C/C++, Java, HTML, Javascript, MySQL, PostgreSQL Required Skills: JavaScript, ReactJS, HTML, CSS Aleksandr Chernousov Life Cycle Planner/ Developer Current Skills: C/C++, Java, HTML, Javascript, MS Access, C#, Objective-C Required Skills: JavaScript, ReactJS, HTML, CSS, COCOMO II, Life cycle ning understanding Supicha Phadungslip Feasibility Analysis/ Current Skills:

13 Reza Khazali Jincheng He Developer Systems and Software Architect/ Manager & Team Leader Developer/ Requirements engineer Java, Objective-C, JavaScript, MySQL, Oracle Required Skills: JavaScript, ReactJS, HTML, CSS, Feasibility analysis understanding Current Skills: Java, Python, JavaScript, MySQL, PostgreSQL Required Skills: JavaScript, ReactJS, HTML, CSS, Visual Paradigm, UML, Software architecting understanding Current Skills: C/C++, PHP, Python, JavaScript, MySQL, PostgreSQL Required Skills: JavaScript, ReactJS, HTML, CSS Aditya Kathuria Prototyper/ Developer Current Skills: Java, C/C++, JavaScript, AngularJS, ReactJS, PostgreSQL, MySQL Required Skills: JavaScript, ReactJS, HTML, CSS, prototyping understanding George Llames Chris Harman Verification and Validation/ Operational Concept Engineer Developer/ Verification and Validation Current Skills: Java, C/C++, Python, HTML, MySQL, MS Access Required Skills: JavaScript, ReactJS, HTML, CSS, IIV&V and OC understanding Current Skills: JavaScript, Python, HTML, PostgreSQL, Oracle, Node.js, AngularJS, Docker Required Skills: JavaScript, ReactJS, HTML, CSS, IIV&V understanding 8

14 4. Approach 4.1 Monitoring and Control The project is monitored using project, bi-weekly progress report, Jira tickets and Git repository. Project s risks, development, COTS usage are included to progress reports. Furthermore, weekly team meetings are being held to keep all team members on the same pace Closed Loop Feedback Control Our team uses Google Drive folder and team meetings to provide internal feedback to each other. Personal meetings between team members are also being held to discuss about certain concerns Reviews We have a team meeting every week (mostly on Tuesday, but day can vary according to team members availability). We discuss project updates, completed work and project issues. We use Git repository to update project s state frequently and easily. It also helps to understand project s current state before team meetings. Win-win negotiations help us to keep contact with the and to receive a feedback about our job and tasks. 4.2 Methods, Tools and Facilities Table 6: Tools used for the Project Tools Usage Provider GitHub Repository version control system to keep all code changes in GitHub one place Skype Skype is used during team meetings to have communication Microsoft with DEN students Slack Slack is used as a communication tool between team members Slack Technologies Jira Jira is used to monitor progress of each team member USC Google Drive Google Drive is used to share files between team members Google (especially files that are being updated constantly) Visual Paradigm Visual Paradigm is used to develop system architecture (UML diagrams) Visual Paradigm MS office MS Office is used to create files with important information Microsoft 9

15 that is needed to be shared between team members (Presentations, Timelines, Tasks) WinBook WinBook is used to understand and risks better USC and to identify win conditions for all stakeholders COCOMO II COCOMO II helps us to estimate cost and duration of project s USC development Balsamiq Balsamiq is used to create UI mockups Balsamiq ReactJS ReactJS is used to develop front-end part of the system Facebook React Bootstrap React Bootstrap is used to design better UI with less efforts Bootstrap Core Team Visual Studio Visual Studio Code is used to write source code of our project Microsoft Code Node.js Node.js is used to develop back-end part of our project Joyent PostgreSQL PostgreSQL is used manage our system s database PostgreSQL Global Development Group 10

16 5. Resources Estimated CSCI577a Effort: 8 team members at 12 hrs/week for 12 weeks Estimated CSCI577b Effort: 7 team members at 12 hrs/week for 12 weeks Total estimated effort: (8 members * 12 hrs/week * 12 weeks) + (7 members * 12 hrs/week * 12 weeks) = 2160 Budget information: $0 for CSCI577a. $122 for CSCI577b (Hosting + certificate costs) Project duration: 24 weeks Component modules: ReactJS, ReactBootstrap, Node.js, D3, Canvas Programming languages: Javascript, SQL, HTML, CSS Table 7: COCOMOII Scale Driver Scale Driver Value Rationale PREC LOW Only 37,5% of team members (3 out of 8) have experience in web development FLEX HIGH We don t have pre-established of external interface specifications RESL HIGH Most of the risks can be eliminated by buying information (prototyping) TEAM NOMINAL Most stakeholders objectives can be synchronized easily, but lack of users involvement can make things much harder later on PMAT NOMINAL Team has no expertise about CMM Maturity, but has a good understanding of it Table 8: COCOMOII Cost Driver. Module 1: Statistical Page (2000 SLOC, 15% REVL) Cost Driver Value Rationale RELY VERY Module failure will lead to slight inconvenience LOW DATA VERY There will be no database for this module LOW CPLX HIGH Coding is going to be pretty complicated. Large amounts of preprocessing is required before displaying data RUSE LOW This code is unlikely to be used in many other projects. But it can be used for showing data (specific task) DOCU HIGH Most of the module s code had to be documented to ease future changes in displaying data TIME HIGH Data needs to be shown very smoothly. Otherwise, project can become unsuccessful 11

17 STOR HIGH This module takes most of the computational time PVOL NOMINAL We expect this module to be changed pretty often- every 6 months ACAP HIGH Team members have good analytical skills PCAP HIGH Team members are capable of completing complex tasks PCON VERY HIGH We are expecting that only one team member will not be present for CSCI577b APEX NOMINAL We have some team members with big amount of experience along with team members with almost no experience PLEX HIGH Most of team members have experience with platforms LTEX HIGH Most of team members have experience with used programming languages TOOL HIGH We use advanced tools to aid us during the development SITE LOW We don t use much communication for this module SCED LOW We expect to be able to complete this module a little bit ahead of schedule Table 9: COCOMOII Cost Driver. Module 2: Profiling System (5000 SLOC, 15% REVL) Cost Driver Value Rationale RELY NOMINAL Module failure can lead to unrestricted access to data DATA LOW There will be no big database for this module (assuming 2 tables right now) CPLX NOMINAL Coding is not going to be too complicated RUSE HIGH Profiling system can be reused in many other projects DOCU HIGH Most of the module s code had to be documented to ease future changes in profiling system TIME LOW Time constraints are not tight at all- even 5-10 seconds response will be acceptable STOR NOMINAL This module doesn t take many of computational time PVOL LOW We don t expect this module to be changed more often than once per year ACAP NOMINAL Team members have good analytical skills, but this module can be hard to analyze PCAP NOMINAL Team members are capable of completing complex tasks, but this module can be hard to get done PCON VERY HIGH We are expecting that only one team member will not be present for CSCI577b APEX LOW None of our team members have decent experience in creating profiling systems PLEX LOW None of our team members have decent experience in platforms needed for this module LTEX HIGH Most of team members have experience with used programming languages 12

18 TOOL HIGH We use advanced tools to aid us during the development SITE NOMINAL Decent communication will be needed for this module SCED NOMINAL We expect this module to be completed on time Table 10: COCOMOII Cost Driver. Module 3: HTTPS (1000 SLOC, 15% REVL) Cost Driver Value Rationale RELY LOW Module failure won t lead to critical situations DATA VERY No database will be used for this module LOW CPLX LOW Coding is not going to be too complicated RUSE NOMINAL This module may be reused in other projects DOCU LOW Low amount of documentation is needed for this module TIME LOW Time constraints are not tight at all- even 5-10 seconds response will be acceptable STOR VERY This module takes almost no computational time at all LOW PVOL VERY We don t expect changes to this module LOW ACAP LOW Team members have good analytical skills, but this module can be hard to analyze PCAP LOW Team members are capable of completing complex tasks, but this module can be hard to get done PCON VERY HIGH We are expecting that only one team member will not be present for CSCI577b APEX VERY LOW None of our team members have decent experience in creating HTTPS PLEX LOW None of our team members have decent experience in platforms needed for this module LTEX HIGH Most of team members have experience with used programming languages TOOL NOMINAL There is no big difference in tools that can be used to get this module done SITE LOW Low level of communication will be needed for this module SCED LOW We expect this module to be completed ahead of schedule 13

19 Assumption: COCOMO II doesn t allow to set Hours/PM less than 120 and more than 184. Our team members work 12 hours/week, which is approximately 50 Hours/PM. Setting Hours/PM to 150 in COCOMO II we assume that if we multiply estimated staff by 3 then we can get real estimated data for our project. By letting this assumption we can leave other estimated data unchanged. Estimation: Total Lines of Code: 9200 Effort needed (Pessimistic): 26.1 person-months Schedule (Pessimistic): 10.3 Each member works: 12 Hours/week for 12 weeks 50 Hours/PM for 3 months Time spent by members: 12 Hours/week * 12 weeks * 8 persons = 1152 person-hours = person-months Project development can run out of time in the pessimistic case, but it will be done in the most likely case. 14