1 - greenbay.usc.edu€¦ · Web viewLead in code Review of final project artifacts. Secondary...

Life Cycle Plan (LCP)

MoveIntel Web App

Team 6

Guangyu Li Project ManagerYu Deng Quality Focal PointAustin Klein Operational Concept EngineerSheng Luo Requirements EngineerYitong Song Feasibility AnalystSebastian Val IIV & VXining Wang PrototyperHeng Yan Life Cycle PlanWeijie Ye Software Architect

Life Cycle Plan (LCP) Version 1.3

Version HistoryDate Author Version Changes made Rationale09/26/2020

HY 1.0 Original LCP template. Added Scope, Objectives, Stakeholders and Stakeholders’ Responsibility

Initial LCP draft. To reflect goals, scope of project. To identify stakeholders and their responsibilities

10/02/2020

HY 1.1 Added Timeline To be consistent with requirements of CSCI 577

10/13/2020

HY 1.2 Removed Scope, Objectives Revised Stakeholders’

Responsibility Added cost estimation, Project

Plan, to Cocomo II table

To be consistent with requirements of CSCI 577

10/14/2020

HY

YD

SL

1.3 Revised Project Plan Add assignee, status column,

duration to table 1 Change Cocomo Parameters Add cost driver and scale driver

table

To be more specific about who will take which capability. How capability will be implemented

Version Date: 10/22/20


Table of ContentsLife Cycle Plan (LCP)............................................................................................................................................. i

Version History................................................................................................................................................... ii

Table of Contents............................................................................................................................................... iii

Table of Tables................................................................................................................................................... iv

1. Introduction..............................................................................................................................................11.1 Purpose of the LCP...........................................................................................................................11.2 Status of the LCP..............................................................................................................................11.3 Assumptions....................................................................................................................................1

2. Milestones and Products...........................................................................................................................22.1 Overall Strategy...............................................................................................................................22.2 Project Deliverables.........................................................................................................................3

3. Responsibilities.........................................................................................................................................63.1 Project-specific stakeholder’s responsibilities.................................................................................63.2 Responsibilities by Phase.................................................................................................................73.3 Skills...............................................................................................................................................15

4. Approach.................................................................................................................................................174.1 Monitoring and Control.................................................................................................................174.2 Methods, Tools and Facilities........................................................................................................18Resources....................................................................................................................................................19

6. Iteration Plan................................................................................................................................................ 27

6.1 Plan.................................................................................................................................................................276.1.1 Capabilities to be implemented...............................................................................................................286.1.2 Capabilities to be tested..........................................................................................................................316.1.3 Capabilities not to be tested....................................................................................................................336.1.4 CCD Preparation Plans.............................................................................................................................34

document.docx iii Version Date: 10/22/20


Table of TablesTable 1: Phases, duration, deliverables, milestone........................................................................................................2Table 2: Project Milestones............................................................................................................................................3Table 3: Artifacts Deliverables in Exploration Phase...................................................................................................3Table 4: Artifact Deliverables in Valuation Phase........................................................................................................3Table 5: Artifact Deliverables in Foundations Phase in CSCI577a..............................................................................4Table 6: Artifact deliverable in Development Phase.....................................................................................................5Table 7: Project Manager's responsibilities in each phase...........................................................................................7Table 8: Life Cycle Planner's responsibilities in each phase.........................................................................................8Table 9: Requirement Engineer’s responsibilities in each phase..................................................................................9Table 10: Software Architect’s responsibilities in each phase....................................................................................10Table 11: Feasibility Analyst's responsibilities in each phase.....................................................................................10Table 12: IIV&V’s responsibilities in each phase........................................................................................................11Table 13: QFP's responsibilities in each phase...........................................................................................................12Table 14: Operational Concept Engineer 's responsibilities in each phase................................................................13Table 15: Prototyper 's responsibilities in each phase.................................................................................................14Table 16: Client's responsibilities in each phase.........................................................................................................15Table 17: Development Team members; skills.............................................................................................................16Table 18: Tools Being Used in the Project..................................................................................................................18Table 19:Budget Table.................................................................................................................................................19Table 20: Rationale for Project Scale Factors.............................................................................................................20Table 21: Rationale for Cost Drivers of Module 1 – UI module..................................................................................20Table 22: Rationale for Cost Drivers of Module 1 – Video Management module.......................................................21Table 23: Rationale for Cost Drivers of Module 1 – Analysis Process module...........................................................22Table 24: Rationale for Cost Drivers of Module 1 – Notification Application module...............................................23Table 25: Rationale for Cost Drivers of Module 1 – User Management module........................................................24Table 26: Rationale for Cost Drivers of Module 1 – Report Management module.....................................................25Table 27: Iteration Plan...............................................................................................................................................27Table 28: Construction iteration capabilities to be implemented Iteration1...............................................................28Table 29: Construction iteration capabilities to be implemented Iteration2...............................................................29Table 30: Construction iteration capabilities to be implemented Iteration3...............................................................30Table 31: Construction iteration capabilities to be tested Iteration1..........................................................................31Table 32: Construction iteration capabilities to be tested Iteration2..........................................................................31Table 33: Construction iteration capabilities to be tested Iteration3..........................................................................32Table 34: Construction iteration capabilities not to be tested Iteration1....................................................................32



1.Introduction

1.1 Purpose of the LCP The purpose of the Life Cycle Plan is to plan, monitor, and control the progress of the project in order to maximize the productivity of people and resources throughout the system’s life cycle for development and after delivery.

1.2 Status of the LCP The status of the LCP is currently at the Development Commitment Package version number 1.0. This is the version that will be delivered to the client. The major change from Foundations phase is we will enter into development and build an UI system within several weeks

1.3 AssumptionsThe assumptions are the following:

1. The duration of the project is 12 weeks, which is 12 weeks in Fall 2020 2. Each development team member must follow the project schedule.3. The core requirements will be stable. System capability requirements are:

The system shall allow patients to upload videos, practitioners to pass videos to AI algorithm

The system shall allow patients to receive instructions from practitioners. The system shall be autonomous to collect videos and store videos in AWS S3. The system shall allow practitioners to enroll patients under their name and manage

their patients The system shall allow users to update their personal profile

4. All project artifacts must follow the Instructional ICM-Sw Guidelines. 5. Client and AI team will collaborate with the team#6 throughout the software

development life cycle.



2.Milestones and Products

2.1 Overall StrategyThe App is following Architected Agile process because there is no Non-Development Item or Web service that would fit to most of the core capabilities. With this strategy, the entire project will be broken down into distinct parts to be executed. It will improve the overall result and help in approaching complicated decisions better. The schedule for this project is 12 weeks. The process model implemented in this project is the Incremental Commitment Model (ICM), which will mainly emphasize on stakeholders’ commitment and risk analysis

The development period can be categorized as follows:

Table 1: Phases, duration, deliverables, milestone

Phase Duration Deliverables Milestone

Exploration 11 SEP – 18 SEP Client Interaction Report, Win-Win Negotiation, Team Website, Biweekly Package

#1

Win-Win Negotiation

Valuation 19 SEP – 25 SEP Top Risk Prototype Presentation

Top Risk Prototype Presentation

Foundation 25 SEP – 16 OCT Biweekly Package #3 #5, DCR ARB

DCR ARB

Development

Construction Increment 1

17 OCT – 8 Nov ARB #1 Package, Biweekly Package #7

ARB

Development

Construction Increment 2

9 Nov – 16 Nov Biweekly Package # 9CCD / prototype progress Report

Core Capability Drive-Through

Transition Increment

17 Nov – 24 Nov Biweekly Package # 11, Project Archive, DC Package, DCR ARB

Project Archive

document.docx 2 Version Date: 10/22/20


2.2 Project DeliverablesThe following is the list of major milestones of the project.

Table 2: Project Milestones

Milestone DateWin-Win Negotiation 09/16/2020Top Risk Prototype Presentation 09/25/2020Foundation Commitment Review 10/15/2020Development Commitment Review 11/18/2020Project Archive 11/24/2020

2.2.1 Exploration PhaseTable 3: Artifacts Deliverables in Exploration Phase

Artifact Due date Format MediumClient Interaction Report 9/11/2020 .doc Soft copyWin-Win Negotiation 9/16/2020 .doc Soft copyValuation Commitment Package Operational Concept Description

(OCD) Early Section Life Cycle Plan (LCP) Early

Section Feasibility Evidence Description

(FED) Early Section

09/28/2020 .doc, .pdf Soft copy

Project Plan Every Tuesday .mpp, .pdf Soft copyProgress Report Every Tuesday .xls Soft copy

2.2.2 Valuation PhaseTable 4: Artifact Deliverables in Valuation Phase

Artifact Due date Format MediumTop Risk Prototype 09/26/2020 Null NullRequirement Priority List 09/26/2002 .doc, .pdf Soft copyProject Plan Every Tuesday .mpp, .pdf Soft copyProgress Report Every Tuesday .xls Soft copy



2.2.3 Foundations PhaseTable 5: Artifact Deliverables in Foundations Phase in CSCI577a

Artifact Due date Format MediumDraft Foundations Commitment Package Operational Concept Description System and Software

Requirements Definition System and Software

Architecture Description UML Model Life Cycle Plan Feasibility Evidence Description Supporting Information

Document


Foundations Commitment Package Operational Concept Description System and Software



Document

10/15/2020 .doc, .pdf, Soft copy

Project Plan Every Tuesday .mpp, .pdf Soft copyProgress Report Every Tuesday .xls Soft copy



2.2.4 Development PhaseTable 6: Artifact deliverable in Development Phase

Artifact Due date Format MediumARB Package DC 10/23/2020 .doc, .pdf Soft copyAcceptance Criteria and Definition of Done


Retrospective Analysis 10/30/2020 .doc, .pdf Soft copyDraft Development Commitment Package Operational Concept Description System and Software


Architecture Description UML Model Life Cycle Plan Feasibility Evidence DescriptionSupporting Information Document


Development Commitment Package Operational Concept Description System and Software



Document

11/20/2020 .doc, .pdf, Soft copy

Project Archive, DC Package 11/24/2020 .doc, .pdf, Soft copyProject Plan Every Tuesday .mpp, .pdf Soft copyProgress Report Every Tuesday .xls Soft copy



3.Responsibilities

3.1 Project-specific stakeholder’s responsibilitiesThese are the current responsibilities for each team member. Each one plays different roles and responsibilities.

Guangyu Li Project ManagerYu Deng Quality Focal PointAustin Klein Operational Concept EngineerSheng Luo Requirements EngineerYitong Song Feasibility AnalystSebastian Val IIV & VXining Wang PrototyperHeng Yan Life Cycle PlanWeijie Ye Software Architect

3.2 Responsibilities by PhaseTable 7: Project Manager's responsibilities in each phase

Stakeholder:Role Guangyu Li: Project ManagerExploration Primary Responsibility

Coordinate with clientsSecondary Responsibility Analyze current workflow

Valuation Primary Responsibility Manage project Coordinate with all stakeholders

Secondary Responsibility Review artifacts Analyze current workflow

Foundations Primary Responsibility Manage project Coordinate with all stakeholders


Development- Development Increments

Primary Responsibility Manage project Coordinate with all stakeholders Plan for project transition, and support


Development-Transition Increment

Primary Responsibility Manage project Coordinate with all stakeholders




Table 8: Life Cycle Planner's responsibilities in each phase

Stakeholder/Role

Heng Yan: Life Cycle Planner

Exploration Primary Responsibility Analyze current business workflow Analyze related artifacts Draft project plan

Secondary Responsibility Coordinate with clients and

team members

Valuation Primary Responsibility Generate project plan and estimate

cost Review project artifacts

Secondary Responsibility Coordinate with team

members

Foundations Primary Responsibility Update project plan and cost

estimation Review project artifacts

Secondary Responsibility Plan for testing Coordinate with team

membersDevelopment- Development Increments

Primary Responsibility Review project artifacts Prepare for project transition and

support

Secondary Responsibility Prepare for training


Primary Responsibility Coordinate with Teams 0, 1, 2 Finalize all project documents

Secondary Responsibility Provide initial support

Table 9: Requirement Engineer’s responsibilities in each phase

Stakeholder/Role

Sheng Luo: Requirement Engineer

Exploration Primary Responsibility Collect all stakeholders’ interests

Secondary Responsibility Analyze business workflow

Valuation Primary Responsibility Gather win conditions Generate requirements specification Facilitate WinWin negotiation

Secondary Responsibility Define operational concepts Review project artifacts

Foundations Primary Responsibility Maintain consistencies between win

conditions and requirements Verify prototype

Secondary Responsibility Review system architecture Facilitate WinWin negotiation


Primary Responsibility Maintain consistencies between win

conditions and requirements

Secondary Responsibility Review project artifacts




Primary Responsibility Finalize all project documents

Secondary Responsibility Perform final test Provide initial support

Table 10: Software Architect’s responsibilities in each phase

Stakeholder/Role

Weijie Ye: Software Architect

Exploration Primary Responsibility Analyze current system and its

environment

Secondary Responsibility Analyze core capabilities

Valuation Primary Responsibility Define operational concepts and

initial system architecture Analyze all possible COTS

Secondary Responsibility Develop prototype

Foundations Primary Responsibility Define system architecture Generate UML models Revise prototype

Secondary Responsibility Review requirement

specification


Primary Responsibility Develop software modules Integrate software modules Frontend development

Secondary Responsibility Perform integration testing


Primary Responsibility Prepare for system release Provide initial support

Secondary Responsibility Prepare operational

environment

Table 11: Feasibility Analyst's responsibilities in each phase

Stakeholder/Role

Yitong Song: Feasibility Analyst

Exploration Primary Responsibility Identify project feasibility and risk

Secondary Responsibility Analyze possible software and

hardware usedValuation Primary Responsibility

Analyze investment analysisSecondary Responsibility Analyze all possible COTS

Foundations Primary Responsibility Maintain consistencies between win

conditions, requirements, and system architecture

Secondary Responsibility Verify prototype


Primary ResponsibilityMaintain consistencies between win conditions, requirements, and system architecture

Secondary Responsibility Review project artifacts




Primary Responsibility Finalize all project documents

Secondary Responsibility Perform final test Provide initial support

Table 12: IIV&V’s responsibilities in each phase

Stakeholder/Role

Sebastian Val: Integrated & Independent Validation and Verification

Exploration Primary Responsibility Analyze project business cases

Secondary Responsibility Identify project risk

Valuation Primary Responsibility Develop prototype Verify and validate all project

artifacts

Secondary Responsibility Facilitate WinWin negotiation

Foundations Primary Responsibility Verify and validate project

artifacts

Secondary Responsibility Prepare acceptance test cases


Primary Responsibility Verify and validate all project

artifacts

Secondary Responsibility Prepare final project artifacts


Primary Responsibility Verify and validate project

artifacts Perform acceptance test

Secondary Responsibility Prepare for project release

Table 13: QFP's responsibilities in each phase

Stakeholder/Role

Yu Deng: Quality Focal Point

Exploration Primary Responsibility Collect all stakeholder’s interests

Secondary Responsibility Identify project feasibility and

riskValuation Primary Responsibility

Review Risk PrototypeSecondary Responsibility Coordinate in identifying and

tracking risksFoundations Primary Responsibility

Technical debt Review FC Package

Secondary Responsibility Coordinate in identifying and

tracking risksDevelopment- Development Increments

Primary Responsibility Lead in code Review of final

project artifacts

Secondary Responsibility Practitioner View Page

Development- Primary Responsibility Secondary Responsibility



Transition Increment

Lead the review of transition documents and logs

Prepare for project release

Table 14: Operational Concept Engineer 's responsibilities in each phase

Stakeholder/Role

Austin Klein: Operational Concept Engineer

Exploration Primary Responsibility Start creating OCD Document

Secondary Responsibility Identify characteristic of the

proposed system, success-critical stakeholders, operational concepts, core capabilities

Valuation Primary Responsibility Complete OCD Document

Secondary Responsibility Identify business workflow,

system transformation, and expected benefits, as well as provide foundational concepts of the project

Foundations Primary Responsibility Refine OCD Document as

necessary

Secondary Responsibility Provide clarifications of

operational concept to team members to help ensure other project artifacts are aligned with OCD


Primary Responsibility Refine OCD Document as

necessary

Secondary Responsibility Ensure development is aligned

with Operational Concept Description


Primary Responsibility Refine OCD Document as

necessary

Secondary Responsibility Endure transition is aligned with

Operational Description

Table 15: Prototyper 's responsibilities in each phase

Stakeholder/Role

Xining Wang: Prototyper

Exploration Primary Responsibility Analyze current system and its

environment

Secondary Responsibility Analyze core capabilities

Valuation Primary Responsibility Develop Prototype

Secondary Responsibility Analyze business workflow

Foundations Primary Responsibility Secondary Responsibility



Develop Prototype Manage Frontend Plan

Analyze business workflow


Primary Responsibility Manage Frontend Plan

Secondary Responsibility Prepare final project artifacts


Primary Responsibility Manage Frontend Plan

Secondary Responsibility Prepare for project release

Table 16: Client's responsibilities in each phase

Stakeholder/Role

Dr. Steve Grosserode: Client

Exploration Primary Responsibility Express interests on the project

Secondary Responsibility Show current workflow

Valuation Primary Responsibility Provide support and collaboration

to the development team Express win conditions Approve and commit to the

selected project technologies

Secondary Responsibility Provide feedback to development

team

Foundations Primary Responsibility Provide support and collaboration

to the development team Approve and commit to the

selected project progress

Secondary Responsibility Provide supporting data Provide feedback about prototype


Primary Responsibility Provide support and collaboration

to the development team Approve and commit to the

project development

Secondary Responsibility Provide necessary support Provide feedback about

developed modules


Primary Responsibility Provide feedback about

developed modules

Secondary Responsibility Provide necessary support

3.3 SkillsIn this section, we present all development team members’ skills required in project.

Table 17: Development Team members; skills

Team members Role Skills



Guangyu Li Project Manager Project management, MS project , Flask, DynamoDB, S3, GitHub

Heng Yan Life cycle planner COCOMO, MS project, React, GitHub

Weijie Ye System Architect UML, Lucid Chart, React, GitHubXining Wang Prototyper React, GitHubYitong Song Feasibility Analyst React, GitHubYu Deng Quality Focal Point React, GitHub, Ant Design, Sonar

QubeAustin Klein Operational Concept

EngineerReact, GitHub

Sebastian Val IIV&V Flask, DynamoDB, S3, GitHubSheng Luo Requirements Engineer Flask, DynamoDB, S3, GitHub,

React



4.Approach

4.1 Monitoring and ControlThe purpose of monitoring and control for AI Video Analysis System is to ensure the appropriate quality of software work products. Every team member is responsible for the quality of the product when it meets the deliverable date and milestones. The strategies for monitoring and control used in this project are the following:

1. Weekly Team Meeting Every Tuesday, developers hold meetings to discuss plans, issues, and status of

the project. The weekly meeting can also become daily meeting depends on class schedule and project progress etc.

2. Win-Win negotiation Meeting This ensures make win-win conditions among all stakeholder. It is a key for a

success of the project 3. Top Risk Prototype

Identify top risk and build a prototype about top risks. Top risk prototype will buy information to reduce risks which prevents huge potential losses

4. Project schedule ManagementGantt chart and Trello are prepared to determine tasks and responsibilities for

each member. This helps monitor and control project plan and make everyone aware of upcoming dateline and critical issues.

5. Software Cost Estimation (USC COCOMO II) Estimated schedule and effort is calculated for the completion of the project.

4.1.1 Closed Loop Feedback Control

Closed-loop feedback control involves monitoring progress and resource expenditures in planning, which are achieved through the Weekly Team Meeting, Progress report, and Risk&Defect report. If problem occurs, the team can plan and reschedule to resolve them shortly. In addition, it assesses the balancing of the workload for each team member.

4.1.2 Reviews

There are many kinds of review conducted in the project life cycle. Reviews determine the maturity of the artifacts and readiness to continue to the next phase.

1. Review Board – At the end of each phase, the review board meeting is held to determine the readiness and commitment level of the project. Required participants are all critical stakeholders. There are four Architecture Review Boards (ARB) as follows:



a. Valuation Commitment Reviewb. Foundation Commitment Reviewc. Development Commitment Reviewd. Transition Readiness Reviewe. Close Out Report

2. Core Capability Drive-through (CCD) – Towards the end of the development phase, the development team presents the project’s core capabilities to the client. The client will conduct hands-on review and testing of the system.

3. Peer Review – Team members will help each other to check the correctness, completeness, and consistency of all project artifacts.

4. Quality Focal Point Review – This review is conducted by QFP student who acts as an independent reviewer.

5. Agile Independent Review – This review is conducted by IIV&V student who acts as an independent reviewer.

4.2 Methods, Tools and FacilitiesThe following table shows the methods, tools, and facilities that will be used in the project in preparing and operating the project facilities.

Table 18: Tools Being Used in the Project

Tools Usage ProviderMicrosoft Word 2003 Constructs documents for all artifacts. USCMicrosoft Project 2003 Creates Gantt charts for Progress reports and LCP USCMicrosoft PowerPoint 2003

Creates presentation for client meeting and ARB reviews

USC

Internet Explorer and Mozilla Firefox

Downloads course material and medium for communication among stakeholders

USC

WikiWinWin tool Facilitates and supports Win-Win negotiation USCRational Software Architect V6.0

Creates UML, sequence diagram, and other diagrams for SSAD

USC

Trello Creates tasks and assign tasks to each team member

Open source

Adobe Acrobat 6.0 Used for documentation dissemination DeveloperDART tools Assesses and mitigates risks in the system

development life cycleUSC

Ant Design Pro Is a web template for building UI system Open sourceCOCOMO II Is a cost and effort estimation tool USCSonarQube to write cleaner and safer code Open source



5. ResourcesThis section describes the result of using COCOMO II tool to estimate cost for the project

development in terms of effort and schedule. Since we are using SAIV, the estimates will tell us

the effort required for the given project specification.

Estimated Effort: Eight team members at 20 hrs/week for 12 weeks

Total estimated Effort: 2160 hours

The following are conditions applied for estimating the cost of the CSC Volunteer Tracking System:

1. Project schedule is 12 weeks

2. Budgets include:

Table 19:Budget Table

Type CostHardware – Backend Server (AWS EC2)

$230/year

Hardware – Frontend Server (AWS EC2)

$230/year

Hardware – DynamoDB $40/year Hardware – AWS S3 $40/year Software – React $0

Total $540

3. There are nine developers in 577a and zero developers in 577b4. There are four modules in the project:

a. UI module – Frontend Web pagesb. Video Management module – Upload and manage videosc. Analysis Process module – request and perform movement analysisd. Notification Application module – send and view notificatione. Report Management module – View and edit reportsf. User Management module – User information and patient management

5. Most modules use React framework

The rationale for choosing the values of the scale factors is discussed below.



Table 20: Rationale for Project Scale Factors

Scale Factor Value RationalePREC Low Most team members have react experience but a few team

members have AWS experienceFLEX High There are multiple options for Cloud, frontend and backend

toolsRESL Low No risks pose extreme dangerTEAM Nominal All team meeting is virtual. Team members can meet daily or

weeklyPMAT High ICSM process is well-defined

Table 21: Rationale for Cost Drivers of Module 1 – UI module

Cost Driver Value RationaleRELY High All modules in this project depend on this module. There is

huge financial lost.DATA LOW UI module is essential to the system, but the data/program size

ratio less than 10 d/p, and the database size is not too big; hence, it does not require a large amount of test data.

CPLX Nominal This module requires moderate user interface management operations

RUSE LOW This module is not intended to be reused in the project.DOCU Nominal This module requires some moderate amount of

documentation.TIME High The percentage of available execution time, expected to be

used by the system, is greater than 50%.STOR Nominal This module does require moderate amount of storage at

execution time.PVOL Low The major change of the platform could happen every 12

months.ACAP High The analysts are able analyze, design, communicate, and

cooperate very well.PCAP High Programmers are capable and efficient. They are able to

communicate and cooperate very well. APEX Nominal The average experience of the team members for this online

application form is about one year.PLEX Nominal The average experience of the team members for this

PEAR/Symfony is about one year.LTEX Nominal The average experience of the team members for React is

about one year.PCON Very high zero team members continue to CSCI577b.TOOL Nominal The tools are moderately integrated and provide various

functionalities.SITE High Team members can conduct virtual meeting weekly or dailySCED Nominal The schedule is fixed for 12 weeks



Table 22: Rationale for Cost Drivers of Module 1 – Video Management module




CPLX Nominal This module requires moderate user interface management operations

RUSE LOW This module is not intended to be reused in the project.DOCU Nominal This module requires some moderate amount of











Table 23: Rationale for Cost Drivers of Module 1 – Analysis Process module



ratio less than 10 d/p, and the database size is not too big;



hence, it does not require a large amount of test data.CPLX Nominal This module requires moderate user interface management

operationsRUSE LOW This module is not intended to be reused in the project.DOCU Nominal This module requires some moderate amount of











Table 24: Rationale for Cost Drivers of Module 1 – Notification Application module

Cost Driver Value RationaleRELY Low A few modules in this project depend on this module. There is

little financial lost.DATA Low UI module is essential to the system, but the data/program size


CPLX Low This module requires little user interface management operations, control operations, computational operations

RUSE Low This module is not intended to be reused in the project.DOCU Nominal This module requires some moderate amount of

documentation.TIME Nominal The percentage of available execution time, expected to be

used by the system, is less than 50%.STOR Nominal This module does require moderate amount of storage at











Table 25: Rationale for Cost Drivers of Module 1 – User Management module

Cost Driver Value RationaleRELY High Most modules in this project depend on this module. There is

huge financial lost.DATA Low UI module is essential to the system, but the data/program size


CPLX Nominal This module requires moderate user interface management operations, control operations, computational operations








application form is about one year.



PLEX Nominal The average experience of the team members for this PEAR/Symfony is about one year.

LTEX Nominal The average experience of the team members for React is about one year.

PCON Very high zero team members continue to CSCI577b.TOOL Nominal The tools are moderately integrated and provide various


Table 26: Rationale for Cost Drivers of Module 1 – Report Management module

Cost Driver Value RationaleRELY Nominal Some modules in this project depend on this module. There is

moderate financial lost.DATA Low UI module is essential to the system, but the data/program size


CPLX Nominal This module requires moderate user interface management operations, control operations, computational operations














The following is the result of COCOMO estimation based on discussed cost drivers and scale factors settings.

Figure 1: COCOMO Estimation Result of Six Modules

Estimated Code Size: 5285 SLOC

Estimated Man-Hours

Optimistic: 962.28 hrs

Most Likely: 1033.56 hrs

Pessimistic: 1108.8 hrs

Estimated Schedule Assume every member work 80 hrs/Mon

Optimistic: 1.3365 months

Most Likely: 1.4355 months

Pessimistic: 1.54 months



6. Iteration Plan6.1 Plan

Table 27: Iteration Plan

Iteration Duration Description1 11 SEP – 18

SEPWin-Win Negotiation

2 19 SEP – 25 SEP

Top Risk Prototype

3 26 SEP – 4 OCT

DCR Draft

4 4 OCT – 16 OCT

DCR ARB

5 17 OCT – 23 OCT

ARB Package

6 24 OCT – 13 NOV

CCD

7 14 NOV – 24 NOV

Project Archive

6.1.1 Capabilities to be implementedTable 28: Construction iteration capabilities to be implemented Iteration1

ID Capability Description Assignee Status Duration Date Iteration1 Sign Up Users can sign

up with a username and

password

Xining 2 days

19 OCT

—

25 OCT

1

2 Authentication Users can be authenticated

to use the system

Guangyu, Sebastian

3 days

3 Video Upload Page

Layout of Video Upload Page. Users

can select files or drag files to

upload

Xining, Sebastian

3 days

4 Video Upload Backend

Check for video size, resolution,

Yitong, Weijie

2 day



FPS. Warning users if any of those data is

incorrect5 Video Upload

BackendUpload video to AWS S3

Heng, Yu 3 days

6 Process Video Fetch uploaded videos and

send them to AI algorithm

for processing.

Sheng, Austin

3 days

Table 29: Construction iteration capabilities to be implemented Iteration2

Capability Description Assignee Status Duration

Date Iteration

7 User Profile Patients/Practitioners can edit their profile

Xining 1 day

26 OCT

—

7 NOV

2

8 Patient Management

Practitioners can enroll patients under

them

Heng, Sheng

2 days


Practitioners can access data of

patients in their list, such as profiles, video uploaded

Yu, Weijie

2 days

10 Patient Privacy

Patients’ data will only be visible to

his/her practitioner

Sebastian, Austin

2 days

11 Information storage

Video/ image uploaded will be stored on the S3

server under different user

accounts.

Sebastian, Guangyu

3 days

Table 30: Construction iteration capabilities to be implemented Iteration3

Capability Description Assignee Status Duration

Date Iteration

13 Report Generation

Fetch results from AI algorithm and generate reports

Xining, Weijie

2 days



7 NOV

—

15 NOV

3

14 Report Edition

Allow practitioners to edit reports,

comment reports

Sebastian, Yu

2 days

15 Security feature

Practitioners can access data of

patients in their list, such as profiles, video uploaded

Yu, Weijie

2 days

16 Track system

Patients’ data will only be visible to

his/her practitioner

Sebastian, Austin

2 days

17 Report sharing

Practitioners can share the reports to designated patients.

Yu, Yitong

2 days

6.1.2 Capabilities to be tested Table 31: Construction iteration capabilities to be tested Iteration1

ID Capability Assignee Status Duration

Date Iteration

1 Sign Up Xining 1 day

19 OCT

—

25 OCT

1

2 Authentication Guangyu, Sebastian

1 day

3 Video Upload Page

Xining, Sebastian

1 day


Yitong, Weijie

1 day


Heng, Yu 1 day

6 Process Video Sheng, Austin

1 day

Table 32: Construction iteration capabilities to be tested Iteration2

Capability Assignee Status

Duration Date Iteration



7 User Profile Xining 1 day

26 OCT

—

7 NOV

2


Heng, Sheng

1 day


Yu, Weijie

1 day

10 Patient Privacy

Sebastian, Austin

1 day


Sebastian, Guangyu

1 day


Heng, Sheng

1 day

Table 33: Construction iteration capabilities to be tested Iteration3

Capability Assignee Status

Duration Date Iteration

13 Report Generation

Xining, Weijie

1 day

7 NOV

—

15 NOV 3

14 Report Edition

Sebastian, Yu

1 day

15 Security feature

Yu, Weijie

1 day

16 Track system

Sebastian, Austin

1 day

6.1.3 Capabilities not to be testedTable 34: Construction iteration capabilities not to be tested Iteration1

Capability Reason Assignee Status Duration Date Iteration1 Billing

systemWill be tested if there is time to implement

it

Xining, Weijie

1 day

7 NOV



—

15 NOV

112 Educational

materialsWill be tested if there is time to implement

it

Sebastian, Yu

1 day

6.1.4 CCD Preparation PlansIn the Core Capability Drive - through, we will invite Steve Grosserode, who is the founder of MoveIntel, to get involved and try our system. Steve could also invite some potential users to try out the system too. At that time, our system will support all the requirements that have high priority.

We will provide users with a user's manual that describes how to use core capabilities. Implement and test all the features. Ensure that the system is well tested. During CCD, clients get a chance to use the system. They can create an account, and

log into the system. Then they can upload a video, analyze it, and get a report. Receive feedback from the clients and course faculty. Incorporate any necessary

changes in accordance with client’s feedback Prepare for the final delivery of the system

Feedback forms: During the tryout of the system, is everything straightforward and easy to understand? Is

there anything that makes you confused? Does the system work as you expected? How do you like the user interface? Do you find anywhere that causes a usability issue? Any suggestions for the final delivery?

CCD risk management plans: If the AWS server is down, there should be a backup server located in another region, so

the client can still use the service.


Date post:	18-Jan-2021
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

1 - greenbay.usc.edu€¦ · Web viewLead in code Review of final project artifacts. Secondary...

Documents