Life Cycle Plan (LCP) · Web viewTable 11: COCOMO-II Cost Drivers for Module 2 22 Table 12: COCOMO-II Cost Drivers for Module 3 24 Table 13: COCOMO-II Cost Drivers for Module 4 26

Life Cycle Plan (LCP)

Data Information Analytics - Managed Online Network Database:

DIAMOND

Team 01

Samantha Cote Project Manager, Life Cycle Planner

Haiwen Chen Requirements Engineer

Danny Diaz Ayon Verification & Validation, Quality Focal Point

Shijie Ding Software Architect/UML Modeler

Meghana Kolasani Prototyper

Dzung Phan Software Architect/UML Modeler, Prototyper

Derek Wang Feasibility Analyst

Drew Webb Operational Concept Engineer

Life Cycle Plan (LCP) Version 2.0

October 21st, 2020

LCP_FCP_F20a_T01_V2.0.docx Version Date: 10/21/20

Version History

Date

Author

Version

Changes made

Rationale

10/15/20

Samantha Cote

1.0

· initialized template for project

· added team members, roles

· completed section 1

Initialize the document for further completion

10/17/20

Samantha Cote

1.2

· completed sections 2 & 3

· added tables for COCOMO scale drivers and cost drivers

To keep the document consistent with our COCOMO estimation

10/20/20

Samantha Cote

1.3

· Completed sections 4 & 5

Maintain consistency with FC Package expectations

10/21/20

Samantha Cote

2.0

· updated stakeholders to be consistent with other team members’ artifacts

To comply with ARB Presentation Feedback; Final version to be submit for FC Package

Table of Contents

Life Cycle Plan (LCP)Version History1Table of Contents2Table of Tables3Table of Figures41.Introduction51.1Purpose of the LCP51.2Status of the LCP51.3Assumptions52.Milestones and Products72.1Overall Strategy72.2Phases 72.3 Project Deliverables93.Responsibilities123.1Project-specific stakeholder’s responsibilities123.2Responsibilities by Phase123.3Skills154.Approach164.1Monitoring and Control164.2Methods, Tools and Facilities175.Resources18


LCP_FCP_F20a_T01_V2.0.docx Version Date: 10/21/20

Table of Tables

Table 1: Artifacts Deliverables in Exploration Phase9Table 2: Artifact deliverable in Valuation Phase9Table 3: Artifact deliverable in Foundations Phase10Table 4: Artifact deliverable in Development Phase11Table 5: Stakeholder's Responsibilities in each phase12Table 6: Skills Required for Each Role16Table 7: Methods, Tools and Facilities17Table 8: Modules and Estimated SLOC19Table 9: COCOMO-II Scale Drivers19Table 10: COCOMO-II Cost Drivers for Module 120Table 11: COCOMO-II Cost Drivers for Module 2 22Table 12: COCOMO-II Cost Drivers for Module 324Table 13: COCOMO-II Cost Drivers for Module 426


Table of Figures

Figure 1: COCOMO Estimation Result with 4 Modules 28Figure 2: Most Likely Estimated Person-Months 29

1. Introduction

1.1 Purpose of the LCP

The purpose of the Life Cycle Plan (LCP) for the DIAMOND project is to plan for each phase of the project’s timeline, monitor the project’s compliance with the Win-Win Negotiations, and adapt if needed to ensure that the project will succeed within its available effort and schedule. The document is currently at the Foundations Commitment (FC) Package state.

1.2 Status of the LCP

The status of the LCP document is currently at Foundations Commitment (FC) Package version 2.0. This is the version that was presented at the ARB FCR presentation and will be submitted as part of the FC Package for the Foundations phase. Major changes from the previous version include:

· Edits in the list of stakeholders that were provided as feedback at the ARB FCR presentation.

· Contains content for LCP sections 1-5 as requested for the FC Package.

There are no differences between the contents of the LCP and the Win-Win Negotiations.

1.3 Assumptions

The assumptions are the following:

1. The Client will respond within at most 2-3 days when approvals or answers to team questions are required.

2. There will be no drastic changes to project requirements after win-win negotiation has been completed.

3. The duration of the project lifecycle is 24 weeks; 12 weeks in Fall 2020, 12 weeks in Spring 2021.

4. The Client will deliver sample data, table structures, and forms to the development team early in the fall so that prototypes can align with the client’s desired data structures.

5. The Client will purchase a production Salesforce license at the start of the Spring 2021 semester.

6. 5 of the 8 team members will be able to continue on to 577B, allowing us to keep the majority of the team the same.

7. Software Availability: Salesforce will remain available 24/7.

8. The Client will meet regularly with the team to discuss progress and give desired feedback on progress.

9. Team members will complete work and artifacts that align with their project roles by the time that it is due.

2. Milestones and Products

2.1 Overall Strategy

The overall ICSM strategy for the DIAMOND project is a NCS-Driven process model, due to the fact that the Salesforce platform is a net-centric web service that offers us a development environment and many custom libraries to help the team build out the system. The majority of our early efforts therefore rely on rigorously prototyping both the Salesforce system itself and the libraries we would like to use for other capabilities to ensure that all will be compatible with one another and to ensure that the system will be buildable using these different tools within the schedule and effort that has been allocated for the project.

The project also depends on the Schedule As Independent Variable concept, due to the fact that it is being built as part of a university course, and the schedule resources are therefore limited for team members.

Our process includes the following milestones:

1. Valuation Commitment Review (VCR)

2. Top Risk Prototype

3. Foundations Commitment Review (FCR)

4. Prototype Progress Presentation

5. Development Commitment Review (DCR)

6. Re-baselined Development Commitment Review (RDCR)

7. Core Capability Drivethrough (CCD)

8. Transition Readiness Review (TRR)

9. Operational Commitment Review (OCR)

2.2 Phases

· Exploration Phase

· Duration: 8/2020 - 9/14/2020

· Concept: Form teams, meet client, understand basic project scope and requirements, determine stakeholder win conditions

· Deliverables: Client Interaction Report, Win Conditions Report, Team Website, Bi-Weekly Package

· Milestone: Valuation Commitment Review (VCR)

· Valuation Phase

· Duration: 9/14/2020 - 10/23/2020

· Concept: Begin prototyping, perform resource estimation, prioritize win conditions, develop initial feasibility evidence, develop operational concept, explore architecture options

· Deliverables: OCD, SSAD, LCP, & FED (FC Package), Top Risk Prototype, Bi-Weekly Package

· Milestones: Top Risk Prototype, Foundations Commitment Review (FCR)

· Foundations Phase

· Duration: 10/23/2020 - 2/19/2021

· Concept: Continue risk-driven prototyping, finalize architecture decisions, further develop the life cycle plan, prepare for development

· Deliverables: Larger prototype, DC Package, Bi-Weekly Package, Re-baselined DC Package

· Milestones: Prototype Progress Presentation, Development Commitment Review (DCR), Re-baselined Development Commitment Review (RDCR)

· Development Phase

· Duration: 2/19/2021 - 5/07/2021

· Concept: Develop the system, integrate, testing, and preparation for transition to operation within the client’s environment

· Deliverables: Updated OCD, FED, SSAD, & LCP, CCD Report, TP, SP, ATPR, UM, Bi-Weekly Package

· Milestones: Core Capability Drivethrough (CCD), Transition Readiness Review (TRR)

· Operation Phase

· Duration: 5/07/2021 - 5/15/2021

· Concept: Install the product, execute the transition plan, receive client feedback

· Deliverables: Close Out Report, Client Evaluations, Final Deliverables

· Milestones: Operational Commitment Review (OCR)

2.3 Project Deliverables

Project type: 2-semester NCS-Driven Project

2.3.1 Exploration Phase

Table 1: Artifact deliverables in Exploration Phase

Artifact

Due date

Format

Medium

Client Interaction Report

9/14/20202

.doc(x), .pdf

soft copy

Win Conditions List

9/16/2020

.doc(x)

soft copy

Team Website

9/18/2020

website

website

Project Plan

every other Friday

.mpp, .pdf

soft copy

Progress Report

every other Friday

.xls

soft copy

Trello Board Document

every other Friday

.pdf

soft copy

Project Risk and Defect Report

every other Friday

.xls

soft copy

2.3.2 Valuation Phase

Table 2: Artifact deliverables in Valuation Phase

Artifact

Due date

Format

Medium

OCD (FC-Draft)

10/12/2020

.doc(x), .pdf

soft copy

FED (FC-Draft)

10/12/2020

.doc(x), .pdf

soft copy

LCP (FC-Draft)

10/12/2020

.doc(x), .pdf

soft copy

SSAD (FC-Draft)

10/12/2020

.doc(x), .pdf

soft copy

Top Risk Prototype

9/25/2020

code

soft copy

Top Risk Prototype Presentation Material

9/25/2020

.pptx

soft copy

OCD (FC-Package)

10/23/2020

.doc(x), .pdf

soft copy

FED (FC-Package)

10/23/2020

.doc(x), .pdf

soft copy

LCP(FC-Package)

10/23/2020

.doc(x), .pdf

soft copy

SSAD (FC-Package)

10/23/2020

.doc(x), .pdf

soft copy

Project Plan

every other Friday

.mpp, .pdf

soft copy

Progress Report

every other Friday

.xls

soft copy


every other Friday

.pdf

soft copy


every other Friday

.xls

soft copy

Technical Debt Report

every other Friday

.xls

soft copy

2.3.3 Foundations Phase

Table 3: Artifact deliverables in Foundations Phase

Artifact

Due date

Format

Medium

Acceptance Criteria & Definition of Done

10/26/2020

.pdf

soft copy

Team Retrospective Analysis

10/30/2020

.pdf

soft copy

Prototype Progress Report

11/13/2020

.doc(x), .pdf

soft copy

OCD (DC-Draft)

11/16/2020

.doc(x), .pdf

soft copy

FED (DC-Draft)

11/16/2020

.doc(x), .pdf

soft copy

SSAD (DC-Draft)

11/16/2020

.doc(x), .pdf

soft copy

LCP (DC-Draft)

11/16/2020

.doc(x), .pdf

soft copy

OCD (DC-Package)

11/24/2020

.doc(x), .pdf

soft copy

FED (DC-Package)

11/24/2020

.doc(x), .pdf

soft copy

SSAD (DC-Package)

11/24/2020

.doc(x), .pdf

soft copy

LCP (DC-Package)

11/24/2020

.doc(x), .pdf

soft copy

Project Plan

every other Friday

.mpp, .pdf

soft copy

Progress Report

every other Friday

.xls

soft copy


every other Friday

.pdf

soft copy


every other Friday

.xls

soft copy


every other Friday

.xls

soft copy

2.3.4 Development Phase

Table 4: Artifact deliverables in Development Phase

Artifact

Due date

Format

Medium

Updated OCD

2/19/2021

.doc(x), .pdf

soft copy

Updated FED

2/19/2021

.doc(x), .pdf

soft copy

Updated LCP

2/19/2021

.doc(x), .pdf

soft copy

Updated SSAD

TBD Spring 2021

.doc(x), .pdf

soft copy

CCD Report

3/13/2021

.doc(x), .pdf

soft copy

Transition Plan

4/16/2021

.doc(x), .pdf

soft copy

SP

4/16/2021

.doc(x), .pdf

soft copy

ATPR

4/16/2021

.doc(x), .pdf

soft copy

UM

4/16/2021

.doc(x), .pdf

soft copy

Project Plan

every other Friday

.mpp, .pdf

soft copy

Progress Report

every other Friday

.xls

soft copy


every other Friday

.pdf

soft copy


every other Friday

.xls

soft copy


every other Friday

.xls

soft copy

3. Responsibilities

3.1 Project-specific stakeholder’s responsibilities

This project does not have any project-specific stakeholders other than the project’s client, users, maintainer, developers, and IIV&V engineer.

3.2 Responsibilities by Phase

Table 5: Stakeholder's Responsibilities in each phase

Team Member / Role

Primary / Secondary Responsibility

Exploration

Valuation

Foundations

Development- Construction Iteration

Development- Transition Iteration

Samantha Cote

Project Manager,

Life Cycle Planner

Primary Responsibility

Coordinate meeting with clients

Secondary Responsibility

Organize team meetings and contact


Maintain a project plan that the team will follow, and coordinate meetings with client


Review artifacts and ensure all team assignments are delivered on time


Coordinate with team members and client, schedule necessary meetings, maintain a project plan




Coordinate with team members and client, schedule necessary meetings, maintain a project plan




Coordinate with team members and client, schedule transition training


Provide the transition training

Haiwen Chen

Requirements Engineer


Organize win conditions and maintain list of stakeholder requirements


Ensure all project progress is in line with requirements


Prioritize win conditions




Direct prototypers to follow top-risk requirements




Re-prioritize win conditions if necessary




Ensure that final system deliverable meets all requirements



Danny Diaz Ayon

IIV&V, Quality Focal Point


Determine best tools to use for team communication


Set up a Trello board to track team tasks


Manage Trello board to ensure team is following tasks


Verify that any progress on different parts of the project are consistent with others


Manage Trello board to ensure team is following tasks




Determine best testing strategy and implement a test suite




Final verification that system works as specified


Verify that project is consistent across the board

Drew Webb

Operational Concept Engineer, Developer


Develop initial win conditions


Begin to outline use cases and benefits of the proposed system


Develop the benefits chain diagram and Operational Concept


Contribute to top-risk prototype


Continually update the operational concept as project requirements change


Contribute to top-risk prototypes


Develop system features


Ensure that all development is in line with operational concept


Contribute to transition plan


Help with transition training

Meghana Kolasani

Prototyper, Developer


Explore NCS/NDI choices


Help to develop initial win conditions


Build top risk prototype


Ensure that prototypes are following project’s top risks


Develop further top risk prototypes






Ensure that all development is in line with project requirements





Dzung Phan

Prototyper, Developer


Explore NCS/NDI choices




Build top risk prototype




Develop further top risk prototypes











Shijie Ding

System Architect/UML Modeler,

Tester


Explore system architecture options


Identify stakeholders, users, etc.


Determine architecture to prototype, build UML diagrams


Work with prototypers to ensure prototypes are consistent with the architecture design


Continue to refine architecture diagrams


Work with prototypers to ensure prototypes are consistent with the architecture design


Develop tests for system features


Work with IIV&V to ensure system components work as intended





Derek Wang

Feasibility Analyst,

Developer


Analyze potential NDI choices




Analyze chosen NDI choices, compute benefit, ROI


Work with prototypers to decide what is top-risk


Analyze chosen NDI choices, update benefit, ROI as needed


Work with prototypers to decide what is top-risk









Dr. Darin Gray

Client/STEM Center Director


Meet with team and give project overview


Communicate desired system functionality to team


Provide team with sample data and forms


Meet with team frequently to give feedback and attend all team presentations


Provide team with any updated sample data and forms; prioritize capabilities


Meet with team frequently to give feedback and attend all team presentations


Meet with team frequently to give feedback on system development


Re-prioritize system features as necessary


Prepare for system transition


Attend transition training

TBD (To be hired by STEM Center)

Maintainer


N/A


N/A


N/A


N/A


N/A


N/A


N/A


N/A


Meet with team to understand system functionality and get admin account


Attend transition training to prepare for the system’s life cycle maintenance.

3.3 Skills

Table 6: Skills Required for each Role

Team members

Role

Skills

Samantha Cote

Project Manager, Life Cycle Planner

Project management, organization, communication skills, good time management, good understanding of MS Project and COCOMOII

Haiwen Chen

Requirements Engineer

Organization, Negotiation skills

Danny Diaz Ayon

IIV&V, QFP

Quality Management, Testing experience, Trello/JIRA

Drew Webb

Operational Concept Engineer, Prototyper

Good understanding of benefit chains and use cases, good organization,

JS, XML, Salesforce, HTML, database systems

Meghana Kolasani

Prototyper


Dzung Phan

Prototyper


Shijie Ding

System Architect/ Prototyper

Good understanding of UML diagrams, system architecture. JS, XML, Salesforce, HTML, database systems

Derek Wang

Feasibility Analyst

good organizational skills, good understanding of ROI, risk and risk management

New Member

Developer


New Member 2 (Potentially)

Tester

Salesforce testing capabilities, general software testing methods

4. Approach

4.1 Monitoring and Control

Each team member is responsible for the artifacts assigned to their role, but we have monitoring and control methods that we use as a team to track project progress, manage risk, identify defects, and plan for the project life cycle. Some of the methods of monitoring and control that our team are using are:

1. Progress Reports: A bi-weekly report that tracks the project size (SLOC), keeps track of the COTS being used, and any new ones that have been recently considered, and tracks the work that has been done for the past two weeks and the work that is planned to get done in the following two weeks.

2. Project Plans: A bi-weekly MS Project Plan (Gantt chart) that outlines what work will be done by which team member over the upcoming two weeks. It outlines how long each task should take and when it should be completed by.

3. Risk & Defect Reports: A bi-weekly report that tracks all risks that the project has and their current P(L) and S(L) values, therefore tracking which are the highest risks for the project at any given time. This document also identifies any defects that the project has and the team’s plan for how to mitigate those defects.

4. Technical Debt Reports: bi-weekly reports that track any technical debt that the team has and how they plan to mitigate that.

5. Trello board: A team Trello board is used for task management to make sure that tasks are assigned to team members and that they get done on time.

6. Software Cost Estimation: COCOMOII Tool. This tools allows us to perform effort estimation for the project so that we can ensure that we have enough team members and schedule time to complete the project’s requirements.

7. Team Meetings: The team meets once a week to discuss what each team member is working on, and so that team members can give each other feedback.

4.1.1 Closed Loop Feedback Control

The team uses a Slack channel to give immediate feedback to each other on documents, prototypes, or other project work. Team members are distributed across different time zones but the Slack channel allows us to give each other immediate feedback on work being done.

4.1.2 Reviews

There are different kinds of reviews across the project’s lifecycle.

1. Team Reviews: The team meets once a week so that each member can demo what they’ve been working on that week. This allows other team members to give immediate feedback and review their work and also ensures that all work being done by different team members is consistent with all other work. Our shared Google Drive also allows all team members to view other team members’ artifacts and give feedback.

2. Review Boards: Throughout the project’s lifecycle, there are many review boards that provide the stakeholders and instructors to provide any feedback and to determine whether or not the project is ready to move on to the next phase. These review boards include:

a. Valuation Commitment Review

b. Foundations Commitment Review

c. Development Commitment Review

d. Transition Readiness Review

3. Top Risk Prototype, Prototype Progress, and Core Capability Drivethrough: These are milestones within the project life cycle that allow for stakeholder feedback of project features and developed prototypes. Users can get hands-on experience with the developed features so that if they would like to suggest any changes or improvements, they can do so while there is still time for the development team to change them.

4.2 Methods, Tools and Facilities

Table 7: Methods, Tools and Facilities

Tools

Usage

Provider

Slack

Provides a messaging tool that allows team members to communicate throughout the week and quickly get answers to questions.

Open source

Trello

A task management online platform that allows the team to manage who is doing what task and when.

Open source

Google Drive

The team is utilizing a shared drive which serves as a spot where we can store all team artifacts so that anyone on the team can contribute to them.

Open source

Salesforce

The cloud platform that we are using to build our remote data management system; Includes many built-in libraries for data objects, querying, and front-end widgets that are helping us to build out our platform.

Client will pay for the prod license

Einstein OCR API

An API within Salesforce that allows for Optical Character Recognition. The team uses this to build the OCR Engine, which is one of the project’s desired capabilities.

Open source

5. Resources

This section outlines the use of the COCOMO-II tool for effort estimation for the project. Due to the fact that we are using SAIV (Schedule As Independent Variable), we used COCOMO for effort estimation but not schedule estimation.

Estimated 577a Effort: 8 team members at 12hrs/week for 12weeks.

Total estimated effort: 1152 hours

Estimated 577b Effort: 6 team members at 12hrs/week for 12 weeks

Total estimated effort: 864 hours

Conditions applied for estimating effort cost for DIAMOND:

1. Project schedule is fixed: 12 weeks in Fall 2020 (Exploration, Valuation, Foundation) and 12 Weeks in Spring 2021 (Development, Transition, Operation).

2. Budget for the Salesforce production license will be supplied by the client.

3. Eight members in 577A and 6 members in 577B.

4. There are 4 modules in this project:

a. Salesforce Database - backend object and table storage in the cloud.

b. Data Management Dashboard - Front-end interactive capabilities for the data management system.

c. Query System - System for building and executing custom SQL queries.

d. OCR Engine - System for Optical Character Recognition from a .pdf or .jpeg

5. All modules use a combination of JavaScript, XML, HTML, and CSS.

Modules & Estimated SLOC

Table 8: Modules and Estimated SLOC

No.

Module Name

Brief Description

SLOC

1

Salesforce DB

backend object and table storage in the cloud

3000

2

Data Management Dashboard

Front-end interactive capabilities for the data management system

1500

3

Query System

System for building and executing custom SQL queries

800

4

OCR Engine

System for Optical Character Recognition from a .pdf or .jpeg

1000

Scale Drivers

The values for each of the scale drivers and the rationale for choosing those values is shown below:

Table 9: COCOMOII Scale Drivers

Scale Driver

Value

Rationale

PREC

Nominal

The team is familiar with database systems, but not in the cloud and not using the Salesforce NCS. Development within the platform is largely unprecedented for the team members.

FLEX

Low

The team has been given rigorous requirements as to how data input must be done, and what the table schema needs to be, but implementation details of queries is left up to the team.

RESL

VHigh

The team has made it a priority (due to risk-driven ICSM principles) to reduce risk early and eliminate where possible. Trade studies and prototypes have been created for areas of risk within the architecture and team members feel largely comfortable moving forward into development that the large risks have been mitigated.

TEAM

VHigh

Team members, clients, and stakeholders have been highly attentive, cooperative, and prompt with their assignments and expected contributions.

PMAT

Nominal

The team is adhering to guidelines from the ICSM principles, using a set of standard processes that are defined. Processes are suited for this specific project. CMM Level 3 - Defined.

Cost Drivers (Module 1)

Table 10: COCOMOII Cost Drivers for Module1

Cost Driver

Value

Rationale

RELY

Nominal

Though the data being stored in the system is important to the operation of the K-12 STEM Center, Salesforce provides great support for backups and recovery, so any data losses are easily recoverable.

DATA

Nominal

The ratio of database size to SLOC of the project is estimated to be more than 10, but less than 100. Data will be stored for participants, parents, programs, and survey data.

DOCU

Nominal

Salesforce documentation for the platform itself is plentiful, and the documentation we are writing during development will cover the life-cycle needs of the system without going overboard.

CPLX

Nominal

This project relies heavily on Data Management Operations (Nominal), User Interface Management (High), and Computational Operations (Nominal). It will support complex database queries, and will work on customizing the Salesforce widget library for the front-end. Nominal computational operations will be done in the processing of the data.

RUSE

Low

This system is not intended to be reused for other projects.

TIME

Nominal

The system will be used when STEM Center staff members are entering new data to the system, or querying current data, but otherwise will be mostly idle, simply storing data objects in the cloud, using expectedly <50% of the available execution time.

STOR

Very High

The STEM Center has years worth of historical program data that they would like to store in the system, and the size of the database will grow each year as new programs begin and new participants join existing programs.

PVOL

Nominal

Salesforce releases a major product update with new features and enhancements 3 times a year (in the Spring, Summer, and Winter). They commit to this schedule, and new changes can be expected at these three milestones each year. Browser updates will typically only be once/yr.

ACAP

VHigh

Our project’s analysts and designers communicate well and promptly, are very thorough, and follow project requirements when making design decisions.

PCAP

VHigh

Though collectively unfamiliar with Salesforce and its development console at the start of the project, the programmers have gained much experience with the platform through prototyping and are feeling very capable with it as we approach the Development phase.

PCON

Nominal

We have 8 members currently working on the project in 577A and it is estimated that ~5 of those will continue on to 577B. It is likely that 1-2 new members will join the team in 577B.

APEX

Nominal

The experience of the project team with cloud data management systems is low, ~6mos. for most team members, however many have experience with database systems and data management systems in general.

PEXP

Low

The project team has some experience working with SQL databases, but no experience working with the Salesforce platform before, which is the main platform of this system.

LTEX

High

The team will be developing the cloud data management system with XML, CSS, and JavaScript, and many team members have lots of experience with those languages and tools.

TOOL

Nominal

Our project will be moderately integrated, both frontend and backend will be integrated in the cloud and basic life-cycle tools and documentation for said tools will be available from the Salesforce NCS.

SITE

Low

Teammates are distributed internationally (because of COVID), across 5 different time zones, and often have completely opposite waking hours. We do have a Slack messaging system that allows us to retain sufficient communication, however video conferences are limited because there aren’t many times that everyone can make due to time zone issues.

SCED

Nominal

The schedule is fixed; 12 weeks in fall semester, 12 weeks in spring semester.


Table 11: COCOMOII Cost Drivers for Module 2

Cost Driver

Value

Rationale

RELY

Low

The front-end will not cause drastic problems if it is temporarily unavailable as it just provides widgets to access tables.

DATA

Nominal


DOCU

Nominal

Salesforce documentation for the front-end aspects of the platform itself is plentiful, and the documentation we are writing during development will cover the life-cycle needs of the system without going overboard.

CPLX

Low

This module relies heavily on User Interface Management (High), and Computational Operations (Low). This module will include high levels of interface management, including customizing the Salesforce widget library.

RUSE

Low


TIME

Nominal


STOR

Low

The front-end module does not require much storage at all.

PVOL

Nominal


ACAP

VHigh


PCAP

VHigh

Though collectively unfamiliar with Salesforce and its development console at the start of the project, the programmers have gained much experience with the platform through prototyping and are feeling very capable with it as we approach the Development phase. We have one prototyper who has gotten very familiar with front-end capabilities in Salesforce.

PCON

Nominal


APEX

VHigh

The experience of the project team with building front-end user interface systems is very high, and the team feels comfortable building the front-end module.

PEXP

Nominal

The project team has experience building front-end UIs but never within the Salesforce platform.

LTEX

High

The team will be developing the front-end with XML, CSS, and JavaScript, and many team members have lots of experience with those languages and tools.

TOOL

Nominal


SITE

Low


SCED

Nominal




Cost Driver

Value

Rationale

RELY

Low

The query system going down would have no effect on the stored data itself, so data loss would not occur if the query system went down temporarily.

DATA

Nominal


DOCU

Nominal

Salesforce documentation for the platform itself is plentiful, however we will be writing the query system from scratch, so Salesforce documentation will not be as helpful here.

CPLX

Nominal

This module relies heavily on Data Management Operations (Nominal), and Computational Operations (Nominal). It will perform complex database queries. Nominal computational operations will be done in the processing of the data.

RUSE

Low


TIME

Nominal

The system will be used when STEM Center staff members are entering new data to the system, or querying current data, but otherwise will be mostly be idle, simply storing data objects in the cloud, using expectedly <50% of the available execution time.

STOR

Low

This module is very small and will not require much storage at all.

PVOL

Nominal


ACAP

VHigh


PCAP

VHigh

Though collectively unfamiliar with Salesforce and its development console at the start of the project, the programmers have gained much experience with the platform through prototyping and are feeling very capable with it as we approach the Development phase.

PCON

Nominal


APEX

VHigh

The experience of the project team with database systems and querying databases is very high.

PEXP

Nominal

The project team has lots of experience working with SQL queries but no experience integrating them in Salesforce.

LTEX

VHigh

The team will be developing the queries using SQL, and many team members have lots of experience with SQL.

TOOL

Nominal


SITE

Low


SCED

Nominal




Cost Driver

Value

Rationale

RELY

Low

This module is not essential to project operation and can be seen as a “would like to have” capability. Therefore, if it were ever temporarily unavailable, there wouldn’t be a large effect on the system.

DATA

Nominal


DOCU

High

The Einstein OCR API offers lots of documentation and samples of its use, so we have a lot we can reference.

CPLX

Low

Though the API itself performs Computational Operations (High), the developers on our team do not have to build out any of that complex functionality ourselves.

RUSE

Low


TIME

Nominal


STOR

Low

The OCR module will not require much storage at all.

PVOL

Nominal


ACAP

VHigh


PCAP

High

Though collectively unfamiliar with the Einstein OCR API when we began this project, the programmers have gained much experience with the API through prototyping and are feeling more comfortable with it.

PCON

Nominal


APEX

Nominal

The experience of the project team with OCR is low, however we have much more experience using other Vision APIs.

PEXP

Nominal

The project team has some experience working with Computer Vision APIs, but not this Salesforce API in particular, so we are less sure of how it interacts with the Salesforce platform.

LTEX

High

The team will be developing the OCR system with XML, CSS, and JavaScript, and many team members have lots of experience with those languages and tools.

TOOL

Nominal


SITE

Low


SCED

Nominal


COCOMO-II Resource Estimation Result

Figure 1: COCOMOII Resource Estimation Result with Four Modules

Analysis

Assuming:

· 12 hrs/week of effort per person

· 10 of the 12 weeks of the spring semester contribute to the Construction Phase (72% of total)

· 100 hrs/person-month for COCOMO Estimates

1 577B team member effort = (10 weeks)(12 hrs/week) = 120 hrs

1.67(estimated hrs/person-month COCOMO-II) = (1.67)(100 hrs)(0.72) = 120 hrs

One 577B team member effort = 1.67 CII person-months

If we only have 5 team members for 577B:

5 * 1.67 = 8.35 CII person-months

If we have 6 team members for 577B (the expected scenario):

6 * 1.67 = 10.02 CII person-months

Figure 2: Most Likely Estimated Person-Months

As can be seen in our estimation, the most-likely estimate for effort for the Construction piece of our project is 10.0 CII person-months, and as identified above, with 6 team members for 577B (the expected scenario), we will meet that estimate.

Documents

Life Cycle Plan (LCP) · Web viewTable 11: COCOMO-II Cost Drivers for Module 2 22 Table 12: COCOMO-II Cost Drivers for Module 3 24 Table 13: COCOMO-II Cost Drivers for Module 4 26