Life Cycle Plan (LCP) - Spring 2018 · Life Cycle Plan (LCP) Smart Locks Control Team 05 ... Risk and Defects Report Bi-weekly Wednesday .xlsx Soft copy Project Plan Bi-weekly Wednesday

Life Cycle Plan (LCP)

Smart Locks Control

Team 05

Team Member:

Vaibhav Vishal Project Manager, Life Cycle Planner,

Trainer

Diego Brandao IV&V, Software Architect, Developer

Zhe Wang Feasibility Analyst, NDI/NCS Acquirer

Mohammadreza Barazesh Software Architect, Developer

Alejandro Monroy Prototyper, Evaluator, Tester, Developer

Hao-Yun Yang Requirements Engineer

Katarzyna Ruszowska Quality Focal Point, UML Modeler,

Developer

12/4/17

Life Cycle Plan (LCP) Version 1.8

LCP_TRR_F17_T05_V1.8 12/04/17

Version History

Date Author Version Changes made Rationale

10/13/17 Vaibhav Vishal 1.0 Created the original document

with the midterm deliverables

Initial draft for use with phase plan

for foundation, development,

operation.

10/16/17 Zhe Wang 1.1 Create section 6.1. Add

COCOMO II Results

Create future plan for next iteration

12/3/17 Vaibhav Vishal 1.5 Added User Manual in

Development Phase

Modified Iteration Plan

Added Iteration Assessment

Document required for product

deployment.

Iteration plan more relatable after

testing was completed.

12/04/17 ZW 1.6 COCOMO II Results Update COCOMO II Results

12/04/17 VV 1.8 Format of headers and footers Reflecting the current version


LCP_TRR_F17_T05_V1.8 iii Version Date: 12/04/17

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

1.1 Purpose of the LCP ............................................................................................................................................ 1

1.2 Status of the LCP ............................................................................................................................................... 1

1.3 Assumptions ....................................................................................................................................................... 1

2. Milestones and Products .................................................................................................................................... 1

2.1 Overall Strategy ................................................................................................................................................. 2

2.2 Project Deliverables ........................................................................................................................................... 2

3. Responsibilities ................................................................................................................................................... 6

3.1 Project-specific stakeholder’s responsibilities ................................................................................................. 6

3.2 Responsibilities by Phase ................................................................................................................................... 6

3.3 Skills .................................................................................................................................................................... 9

4. Approach .......................................................................................................................................................... 11

4.1 Monitoring and Control .................................................................................................................................. 11

4.2 Methods, Tools and Facilities .......................................................................................................................... 11

5. Resources .......................................................................................................................................................... 13 6. Iteration Plan .................................................................................................................................................................. 19

6.1 Plan ........................................................................................................................................................................... 19

6.1.1 Capabilities to be implemented ............................................................................................................................ 19

6.1.2 Capabilities to be tested ........................................................................................................................................ 20

6.1.3 Capabilities not to be tested .................................................................................................................................. 20

6.1.4 CCD Preparation Plans ........................................................................................................................................ 21 6.2 Iteration Assessment ............................................................................................................................................... 21

6.2.1 Capabilities Implemented, Tested, and Results .................................................................................................. 21

6.2.2 Core Capabilities Drive-Through Results ........................................................................................................... 22 6.3 Adherence to Plan ................................................................................................................................................... 22


LCP_TRR_F17_T05_V1.8 12/04/17

Table of Tables

Table 1: Artifacts Deliverables in Exploration Phase ................................................................................................... 3 Table 2: Artifact deliverable in Exploration Phase ....................................................... Error! Bookmark not defined. Table 3: Artifact deliverable in Valuation Phase .......................................................................................................... 3 Table 4: Artifact deliverable in Foundations Phase ...................................................................................................... 4 Table 5: Artifact deliverable in Development Phase ..................................................................................................... 5 Table 6: Stakeholder's Responsibilities in each phase .................................................................................................. 6 Table 7: COCOMOII Scale Driver .............................................................................................................................. 13 Table 8: COCOMOII Cost Driver ............................................................................................................................... 13 Table 9: Application Count: Screens ........................................................................................................................... 14 Table 10: Application Count: Reports ........................................................................... Error! Bookmark not defined. Table 11: Application Count: 3GL components ............................................................ Error! Bookmark not defined. Table 12: Application Point Parameters ....................................................................... Error! Bookmark not defined. Table 13: Construction iteration capabilities to be implemented ................................................................................ 19 Table 14: Construction iteration capabilities to be tested ........................................................................................... 20 Table 15: Capabilities implemented, tested, and results ............................................................................................. 21


LCP_TRR_F17_T05_V1.8 12/04/17

Table of Figures

No table of figures entries found.


LCP_TRR_F17_T05_V1.8 1 Version Date: 12/04/17

1. Introduction

1.1 Purpose of the LCP

Develop Project Plan, track resource spent and estimate cost in each of the incremental phase.

• Define the workflow and identify individual and team responsibility.

• Track and update progress over each iteration of the project.

1.2 Status of the LCP

The status of the LCP is currently at the Foundation Commitment Package version no 1.0. This

is the initial version that is being developed at the end of FCR-ARB presentation.

The major attributes of this package are:

• Foundation phase work

• Development Phase and Operation Phase plan

• Cost Estimation using COCOMO II

1.3 Assumptions

• The duration of the project is 12 weeks in Fall 2017.

• The overall strategy that the team will be following is NDI/NCS.

• The team will be using 7 personnel, 6 on campus students and 1 DEN student.

• The plan is being followed as drawn in MS Project without any delay.



2. Milestones and Products

2.1 Overall Strategy

The overall strategy that our project is following is of Incremental Development with the tasks

being divided into 4 phases, Exploration, Foundation, Development and Operation.

The ICSM process that we have adopted for the project is NDI/NCS as our system uses

COTS/services like PHP, AngularJS and SQLite.

Exploration Phase

Duration: 08/23/17 – 09/13/17

Concept: Identify operational concept, system and software requirements and,

life cycle plan for the next phase.

Deliverables: Client Meeting Notes

Milestone: Valuation Commitment Review

Strategy: One Incremental Commitment Cycle, Project deliverable strategy,

Win-Win Negotiation Session #1 with the client.

Valuation Phase

Duration: 09/14/17 – 09/29/17

Concept: Identify project requirement, user hierarchy, Constraints and Priorities,

Gather data on project feasibility evidence, prototype the top risk items,

plan and manage project.

Deliverables: Prototype Presentation, Progress Report and Risk/Defects Report

Milestone: Prototype Presentation

Strategy: Risk Analysis Assessment, Core Capabilities Identification,

Win-Win Negotiation Session, Planning Poker

Foundation Phase

Duration: 09/30/17 – 10/15/17

Concept: Project Requirements, Plan and Manage Project, Project Quality,

Develop Prototype, Fix Defects, Develop Software Architecture

Deliverables: Development Commitment Package,

Draft Transition Readiness Review Package

Milestone: Development Commitment Review

Strategy: One Incremental Commitment Cycle, Risk assessment analysis

Development Phase

Duration: 10/16/17 – 12/5/17

Concept: Core Capability Drive, Developing and implementing the full system

with required features, performing unit, Project plan, Training the

client, Transition Readiness Review.

Deliverables: Core Capability Drive-Through Report, Transition Readiness



Review Package

Milestone: CCD, Transition Readiness Review

Strategy: Development, Testing, Training, Development

Operation Phase

Duration: 12/6/17 – 12/6/17

Concept: Product Deliverable

Deliverables: Final service of the project.

Milestone: Commercial Release of the project

Strategy: Deployment

2.2 Project Deliverables

This section consists of project deliverables in each phase for Smart Locks Control project and

its due date, format and medium.

2.2.1 Exploration Phase

Table 1: Artifacts Deliverables in Exploration Phase

Artifact Due date Format Medium

Client Interaction Report 09/13/2017 .doc, .pdf Soft copy

Win Condition Report 09/16/2017 .pdf Soft copy

Jira Weekly Survey Weekly Monday Jira ticket Jira website

Risk and Defects Report Bi-weekly Wednesday .xlsx Soft copy

Project Plan Bi-weekly Wednesday .mpp Soft copy

Progress Report Bi-weekly Wednesday .xlsx Soft copy

2.2.2 Valuation Phase

Table 2: Artifact deliverable in Valuation Phase


Top Risk Prototype

Presentation

09/29/2017 .pptx Soft Copy

Jira Weekly Survey Weekly Monday Jira

ticket

Jira website

Risk and Defects

Report

Bi-weekly Wednesday .xlsx Soft copy

Project Plan Bi-weekly Wednesday .mpp Soft copy

Progress Report Bi-weekly Wednesday .xlsx Soft copy



2.2.3 Foundations Phase

Table 3: Artifact deliverable in Foundations Phase


Development

Commitment Review

Presentation

10/13/2017 .pptx, .pdf Hard Copy, Soft Copy

Development

Commitment Package

• Operation

Concept

Description

(OCD)

• Life Cycle Plan

(LCP)

• Prototype (PRO)

• System and

Software

Architecture

Description

(SSAD)

• Feasibility

Evidence

Document (FED)

• Test Planning

and Cases (TPC)

10/16/2017 .doc, .pdf Soft Copy


Risk and Defects Report Bi-weekly

Wednesday

.xlsx Soft copy

Project Plan Bi-weekly

Wednesday

.mpp Soft copy

Progress Report Bi-weekly

Wednesday

.xlsx Soft copy



2.2.4 Development Phase

Table 4: Artifact deliverable in Development Phase


Transition Readiness

Review Presentation

11/27/2017 .pptx, .pdf Hard Copy, Soft Copy

Transition Readiness

Review Package

• Operation

Concept

Description

(OCD)

• Life Cycle Plan

(LCP)

• Prototype (PRO)

• System and

Software

Architecture

Description

(SSAD)

• Feasibility

Evidence

Document (FED)

• Test Planning

and Cases (TPC)

• User Manual

(UM)

12/4/2017 .doc, .pdf Soft Copy


Risk and Defects Report Bi-weekly

Wednesday

.xlsx Soft copy

Project Plan Bi-weekly

Wednesday

.mpp Soft copy

Progress Report Bi-weekly

Wednesday

.xlsx Soft copy

Technical Debt Report Bi-weekly Friday .doc, .pdf Soft Copy



3. Responsibilities

3.1 Project-specific stakeholder’s responsibilities

Other than typical stakeholders of CSCI577ab which are client, user, maintainer, developer and

IIV&V, we do not have any project-specific stakeholder.

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 Name: Igor

Shneyderman

Role: Client,

Maintainer,

Program

Coordinator, Smart

Locks Control

Primary

Responsibility

Explain the

project

deliverables

Secondary

Responsibility

Provide details of

the core features

that need to be

implemented.

Primary

Responsibility

Deliver the Locks

and Hubs

required for the

project

Secondary

Responsibility

Identify any

existing system or

current system he

is using.

Primary

Responsibility

-Discuss new

project model.

-New user

hierarchy

description.

Secondary

Responsibility

Identify target

customers.

Develop

Business Model.

Primary

Responsibility

Review the

progress and final

implemented

product.

Secondary

Responsibility

Identify any

project deliverable

that may become

obsolete.

Primary

Responsibility

Receive Training

for the new

system.

Secondary

Responsibility

Understand how

to maintain the

same.

Name: Vaibhav

Vishal

Role: Project

Manager, Life

Cycle Planner,

Trainer

Primary

Responsibility

-Create and

follow up action

items.

-Schedule

Weekly

meetings.

Secondary

Responsibility

-Record project

progress.

-Identify

responsibilities

and skills.

Primary

Responsibility

-Facilitate client

interaction and

follow up after

win win sessions.

-Create and

follow up action

items.

-Schedule

Weekly meetings.

Secondary

Responsibility

-Record project

progress bi-

weekly.

Primary

Responsibility

-Create and

follow up action

items.

-Facilitate review

of prototype

presentation with

client for new

project

deliverables.

-Schedule

weekly work

schedule.

Secondary

Responsibility

Primary

Responsibility

-Create and follow

up action items.

-Schedule Weekly

work.

- Review the

project with the

client.

Secondary

Responsibility

- Record project

bi-weekly

progress.

- Plan for risk

mitigation and

Primary

Responsibility

-Create and

follow up action

items.

-Schedule

Weekly work.

- Training

session with

client.

Secondary

Responsibility

- Record project

bi-weekly

progress.

- Plan for risk

mitigation and



-Identify Life

Cycle

Management

Approach.

-Estimation on

project effort and

schedule.

-Assign issues to

team on JIRA and

track progress.

-Record project

bi-weekly

progress.

- Plan for risk

mitigation.

- Prepare the

team for

documentation.

- Assign issues to

team on JIRA

and track

progress.

technical debt

identification.

- Review the

development

iteration.

-Develop

transition plan.

- Assign issues to

team on JIRA and

track progress.

technical debt

identification.

-Develop

Support plan.

- Assign issues to

team on JIRA

and track

progress.

-Review the

transition

iterations.

Name: Mohammadreza Barazesh Role: Software Architect, Operational Concept Engineer, Developer

Primary Responsibility -Analyze the current system Secondary Responsibility Identify Shared Vision

Primary Responsibility - Analyze NDI Interoperability for NDI / NCS project - Assess and evaluate NDI and NCS components Candidates Secondary Responsibility - Explore Alternatives - Identify Objectives, Constraints and Priorities

Primary Responsibility - Assess System Architecture -Review Feasibility evidence for NDI NCS project Secondary Responsibility - Establish New Operational Concept

Primary Responsibility - Specify Architecture Styles, Patterns and Frameworks - Develop and implement backend. -Review the frontend and backend codes and merge the work. Secondary Responsibility - Assess Operational Concept

Primary Responsibility - Review the implemented features. Secondary Responsibility - Verify whether the implemented system satisfies the operational concept.

Name: Alejandro Monroy Role: Software Developer, Prototyper, Evaluator, Tester

Primary Responsibility -Understand the current system

Primary Responsibility - Analyze and understand SmartThings API and the trigger commands on the application - Explore alternatives for developing the frontend. Secondary Responsibility - Analyze and Prioritize Capabilities to Prototype

Primary Responsibility - Develop Frontend Prototype -Make changes as per API call events.

Primary Responsibility - Develop and implement the features in detail. -Fix Defects after review - Integrate Components

Primary Responsibility - Fix defects if any - Upload the system over the client’s server.

Name: Hao-Yun Yang

Primary Responsibility







Role: Requirements Engineer

- Understand the features of current system

- Capture and Score MMF and Win-conditions - Capture progress of win-win negotiation

- Develop the Database queries for storing user information. Secondary Responsibility - Test the functionality of the Database.

- Verify whether the implemented features address all the win conditions and all the requirements are satisfied. Secondary Responsibility - Check the architecture and the OCD diagrams are according to the system implemented.

- Final Review of implemented features to match with requirements Secondary Responsibility - Verify the fixed defects. -Final round of testing the system.

Name: Diego Brandao Role: IV and V, Software Architect, Developer

Primary Responsibility -Analyze the current system Secondary Responsibility Check the SmartThings API

Primary Responsibility - Analyze Business Case - Explore Alternatives -Assess and Plan to Mitigate Risks Secondary Responsibility Assess and evaluate NDI and NCS components Candidates - Provide recommendation about NDI /NCS components

Primary Responsibility - Develop the API calls for the SmartApp. Secondary Responsibility - Verify and validate the prototype.

Primary Responsibility - Verify and Validate REST API Calls and the backend PHP.

Primary Responsibility - Verify and Validate all the implemented features of the website

Name: Zhe Wang Role: Feasibility Analyst, NDI/NCS Acquirer.

Primary Responsibility -Understand the current system Secondary Responsibility Acquire NDI or NCS components

Primary Responsibility - Analyze and Prioritize Capabilities to Prototype - Analyze and understand NDI/NCS required for feature implementation Secondary Responsibility -Explore alternatives for

Primary Responsibility - Develop Prototype -Make changes as per feedback Secondary Responsibility - Provide Feasibility Evidence for NDI NCS project

Primary Responsibility - Develop and implement the features in detail. - Implement the front-end deliverable. -Fix Defects after review - Integrate Components

Primary Responsibility - Fix defects if any - Transition the System



developing features.

Name: Katarzyna Ruszowska Role: Quality Focal Point, UML Modeler, Tester.

Primary Responsibility - Understand the features of current system

Primary Responsibility - Identify Quality Management Strategy -Identify Configuration Management -Construct Traceability Matrix

Primary Responsibility - Assess Quality Management Strategy Secondary Responsibility - Test the prototype.

Primary Responsibility - Perform unit, integration and regression testing for implemented features.

Primary Responsibility - Final round of regression testing.

3.3 Skills

Team members Role Skills

Vaibhav Vishal Project Manager, Lifecycle Planner, Trainer

Current Skills: Project management, configuration management, COCOMO and MS project Java, HTML5, CSS, MySQL Required Skills: IoT enabled Locks and SmartThings API, COCOMO II

Mohammadreza Barazesh Software Architect, Operational Concept Engineer, Developer

Current Skills: HTML5, CSS, PHP, JavaScript, AngularJS , MySQL, NodeJS Required Skills: IoT enabled Locks and SmartThings API

Alejandro Monroy Software Developer, Prototyper, Evaluator,

Tester

Current Skills: C/C++, SQL, HTML, CSS, JavaScript, PHP, jQuery Required Skills: IoT enabled Locks and SmartThings API

Hao-Yun Yang Requirements Engineer Current Skills: Winbook, QoS, C/C++, IP/ MPLS, Routing and Switching, Automation Testing,



Required Skills: IoT enabled Locks and SmartThings API

Zhe Wang Feasibility Analyst, NDI/NCS Acquirer

Current Skills: HTML5, CSS, PHP, JavaScript, MySQL Required Skills: IoT enabled Locks and SmartThings API, COCOMO II

Katarzyna Ruszowska Quality Focal Point, UML Modeler, Tester

Current Skills: Quality Management HTML, CSS, JavaScript, Unit Testing Required Skills: IoT enabled Locks and SmartThings API

Diego Brandao IIV and V, Developer, Software Architect

Current Skills: MySQL, HTML, CSS, JavaScript, REST API, Visual Paradigm Required Skills: IoT enabled Locks and SmartThings API



4. Approach

4.1 Monitoring and Control

➢ Bi-Weekly reports: o Project Plan: Plan for the next 2 weeks work and assign jobs to team members. o Progress Report: Track the progress of the project, list third-party

components, and SLOC. o Risk and Defect Report: Analyses top risks, defects, problems and concerns

about project. ➢ Jira: Tracking issue, and project progress. ➢ Win Book: Catch requirements and their priority. Make sure about design

consistency. ➢ Team Meetings: Have team meetings at least 4 days in a week, discuss about project

progress, risks and their mitigation strategy. Discuss the progress on the development of frontend and backend.

➢ Client Meeting: Collect feedback from client often, check requirements consistency.

4.1.1 Closed Loop Feedback Control

➢ Slack: We have created a team group in Slack for team members to discuss project, check schedule, assign work and share documents.

➢ Jira: Assign tasks to team members, check progress of each task, and log the work. ➢ Team meetings: We have team meetings at least 4 times a week. ➢ Google Drive: Upload documents and create shared doc, ppt files that everyone can

work on at the same time.

4.1.2 Reviews

➢ Peer Review: Teammates do review for each other with respect to feature implementation.

➢ Client Review: Collect feedback from client often with respect to functionalities of website.

➢ ARB: Collect feedback from clients and reviewers. Check if we are on the right track,

and check if there are any change in feature requirements and win conditions.

4.2 Methods, Tools and Facilities



Tools Usage Provider

MS Office Bi-weekly reports and project documents. Microsoft,

USC

Winbook Capture win conditions and prioritize them. USC

Slack Discuss project related work, schedule team meetings and

keep track of the progress and documents.

Slack

Project

Website

Store information about the project, and store all the

documents.

USC

JIRA To log time and effort spent on each task of the project by

different members of the team

USC

COCOMO II Estimate the project cost estimation USC

SmartThings

API

To create event calls to interact with the locks over the

internet.

Samsung

POSTMAN Test the event calls over the web. POSTMAN



5. Resources

Below is the required information in order to estimate the software cost: - Estimated CSCI577a Effort: 7 team members at 12 hrs/week for 10 weeks - Total estimated effort: 12 hrs/week x 7 members x 10 weeks = 840 hours - Budget information: $0 - Project duration: 12 weeks - Component modules in your development project: Device Status, Lock Management

System, User Control System - Programming language/ Tools used: PHP, AngularJS, NodeJS, REST, HTML, CSS

Table 6: COCOMOII Scale Driver

Scale Driver Value Rationale

Precedentedness Low No existing system and new to SmartThings.

Development Flexibility

High Client amenable with regard to requirements. Some initial requirements removed by client.

Architecture/Risk Resolution

Nominal Majority of the risk can be mitigated by buying information.

Team Cohesion High Meeting almost every day and client is available most of the time.

Process Maturity Nominal Following ICSM guidelines.

Table 7.1: COCOMOII Cost Driver

Cost Driver Value Rationale

RELY High This module is required for the whole system to be

successful.

DATA Nominal Data is easily available based on requirements.

DOCU Nominal As this is completely new module and different from

client’s previous system, client does not have any

previous knowledge on this, it requires documentation

in detail.

CPLX Nominal This module is not complex to develop, as it requires

basic form designing.

RUSE Nominal It has nominal reusability, as form basic template

remains the same.

TIME Nominal There are many forms to develop, time is kept nominal

STOR Nominal It requires good amount of storage as it maintains all the

registration details

PVOL Low No complex hardware/software is required.

ACAP Very

High

Team have good understanding about the customer’s

requirements and priorities.



PCAP Very

High

Developers have basic experience in web development

platforms

PCON Very

High

Maintainer needs to keep updating the information as

and when required.

APEX Nominal Not everyone in team have experience in web

development

LTEX Nominal Team has not worked on PHP before.

PLEX Nominal Not much advance platforms are required to develop

this module.

TOOL Nominal This module needs to be show the user dashboard.

SITE Extra

High

One member is remote who is in Canada. We use Slack,

zoom, hangouts. In addition, we plan to have regular

meeting in person 4 times a week.

Table 7.2: COCOMOII Cost Driver - BackEnd


RELY High This module is based on PHP and RESTAPI and is

required for the whole system to be successful.

DATA Low Functions and data are present to test.



DOCU Nominal As this is completely new module and different from



in detail.

CPLX High This module is complex to develop, as it requires basic

form designing.

RUSE Nominal It has nominal reusability, as form basic template

remains the same.

TIME Nominal There are many calls to develop, time is kept nominal



PVOL Nominal No complex hardware/software is required.

ACAP Nominal Team have good understanding about the customer’s


PCAP High Developers have limited experience in backend

RestAPI.

PCON Very

High


and when required.

APEX High Not everyone in team have experience in RestAPI Calls.

LTEX High Team has not worked on IoT Projects before.

PLEX High Advance platforms are required to develop this module.

TOOL High This module needs to be integrated with Front End and

SmartApp.

SITE Very

High






Table 7.3: COCOMOII Cost Driver - SmartApp


RELY High The Module used is Samsung SmartThings, which needs

to be understood and tested.

DATA Low This module requires good testing, as there are separate

forms for each course.

DOCU High As this is completely new module and different from



in detail.

CPLX High This module is complex to develop, as it requires basic

event calls designing.

RUSE Nominal It has Nominal reusability, as basic application remains

the same.

TIME Nominal Since it is not hard to develop but there are many forms

to develop, time is kept nominal



PVOL Low No complex hardware/software is required.

ACAP High Team have good understanding about the customer’s


PCAP Nominal Developers have good experience in Android

application required to run the demo application.



PCON Very

High


and when required.

APEX Very

Low

Basic application is already available.

LTEX Nominal API calls are already present.

PLEX Very

Low

Not much advance platforms are required to develop

this module.

TOOL Low This module needs to be integrated with Front and

BackEnd

SITE Extra

High






COCOMO II Result:

Analysis Results: SLOC: 4515

Estimate Effort: 7.8 (most likely)

Assumptions:

10 of 12 weeks fill COCOMO II Construction phase

(72% of total effort estimate)

120 hrs/person-month

Member works 12 hrs/week

One team member effort:

12 hrs/week * 10 weeks = 120 hrs

(Factor) * (120 hrs/person-month) * (0.72) = 120 hrs

Thus:

One team member effort = 1.39 CII person-month

Total team effort:

7 * 1.39 person-month = 9.73 CII person-month

Conclusion:

Since team effort is greater than COCOMO II estimate effort. Therefore, the project is most

likely finished on time.



6. Iteration Plan

6.1 Plan

This iteration plan is intended to accomplish major features and describe the detailed plan

for the iteration of the project. In this iteration, the requirements would be further analyzed,

implemented and tested. The team will be prioritizing the critical features and then the bugs

that are reported during the acceptance testing with the client. The first iteration is to deploy

the webpage for the client to test with all the capabilities that he had identified. The second

iteration will be at the end of the development phase and right before the operation phase

where the bugs reported during CCD will be fixed along with any additional suggestions

that will be provided during the final presentation.

6.1.1 Capabilities to be implemented

All the capabilities listed below are subcategories of these 3 capability goals:

1. Lock Management

2. User Control

3. Device Status

Table 2: Construction iteration capabilities to be implemented

ID Capability Description Priority Iteration

1.1 Add Code Allow new codes to be added to

a physical lock remotely.

High Development

Phase – 2

1.2 Edit Code Allow any existing code to be

edited remotely.

High Development

Phase – 2

1.3 Delete Code Allow any existing code and its

subsequent slot to be deleted

remotely.

High Development

Phase – 2

1.4 View Logs Allow to view interaction with

each lock associated with the

system.

High Development

Phase – 2

1.5 Manage

SmartThings

account

Allow authorization with the

SmartThings account and

register the locks/hubs to the

system.

High Development

Phase – 2

1.6 Grouping Lock Group the locks and perform

actions at the same time

Low Development

Phase - 1

2.1 Add User Allow to add new users in the

system.

High Development

Phase – 2

2.2 Edit User Allow to edit access level of the

existing users and associate

more locks to them.

High Development

Phase – 2



2.3 Delete User Allow to delete any inactive

user from the system and all its

associated locks.

High Development

Phase – 2

3.1 View Device Status Allow to view the status of the

hub, the status of the lock and

the battery percentage of the

latter.

High Development

Phase – 2

6.1.2 Capabilities to be tested

Table 3: Construction iteration capabilities to be tested

ID Capability Description Priority Iteration

1.1 Add Code Allow new codes to be added to a

physical lock remotely.

High Development

Phase -2

1.2 Edit Code Allow any existing code to be edited

remotely.

High Development

Phase -2

1.3 Delete Code Allow any existing code and its

subsequent slot to be deleted

remotely.

High Development

Phase -2

1.4 View Logs Allow to view interaction with each

lock associated with the system.

High Development

Phase -2

1.5 Manage

SmartThings

account

Allow authorization with the

SmartThings account and register the

locks/hubs to the system.

High Development

Phase -2

2.1 Add User Allow to add new users in the system. High Development

Phase -2

2.2 Edit User Allow to edit access level of the

existing users and associate more

locks to them.

High Development

Phase -2

2.3 Delete User Allow to delete any inactive user from

the system and all its associated locks.

High Development

Phase -2

3.1 View Device

Status

Allow to view the status of the hub,

the status of the lock and the battery

percentage of the latter.

High Development

Phase -2

6.1.3 Capabilities not to be tested

Every Capabilities in our project will be tested in the next iteration except Grouping Locks as the

product requirement was modified by the client and instead of the Grouping requirements, the

client provided a substitute feature of multiple selection and webhooks.



6.1.4 CCD Preparation Plans

The preparation plan for the CCD is mentioned below:

✓ Implement all the capabilities that are an integral part of the project.

✓ Deploy the latest build of the webpage on the server provided by the client.

✓ Prepare a navigational workflow for the client to access the webpage and each of the user

level.

✓ Record the feedback of the client and note any bugs/issues that arise during acceptance

testing.

✓ Prioritize the feedback collected from the client.

✓ Fix the reported bugs and issues.

✓ Deploy another version of the website for client testing after the bugs are fixed.

6.2 Iteration Assessment

6.2.1 Capabilities Implemented, Tested, and Results

The capabilities tested are the subcategories of 3 major capability goals, which are 1. Lock

Management, 2. User Control and 3. Device Status. Each of the sub-categories are listed below

and against each one of them, a test case was constructed to test its functionality. The in-depth of

those test cases are explained in the Test Plan and Cases document for the same project.

As shown in the table below, the capabilities tested were to add/edit/delete codes associated with

the locks, viewing the user log files to indicate what action was taken against each of the locks

that will be eventually displayed in those logs. Add/Edit/Delete Users are tested against all the 3

users, administrator, house manager and house staff and their respective dashboards. Finally, the

last capability to be tested was view device status which indicate the current Hub status

(Offline/Online) and the Lock Status (locked/unlocked and the battery percentage).

Table 4: Capabilities implemented, tested, and results

ID Capability Test Case Test Results If fail, why?

1.1 Add Code TC-04 Pass x

1.2 Edit Code TC-05 Pass x

1.3 Delete Code TC-06 Pass x

1.4 View Logs TC-07 Pass x

1.5 Manage SmartThings account TC-09 Pass x

2.1 Add User TC-01 Pass x

2.2 Edit User TC-02 Pass x

2.3 Delete User TC-03 Pass x

3.1 View Device Status TC-08 Pass x



6.2.2 Core Capabilities Drive-Through Results

The CCD was an overall success as almost all of the capabilities was implemented and

functioning properly. The client was impressed with the overall product and gave positive and

constructive feedback on the capabilities implemented and the initial win conditions as was

decided by him. The critical scenario of the 3-user hierarchy was demonstrated. The client was

pleased with the user hierarchy dashboards as well as the capability to add/edit/delete lock codes

from the web interface.

The client suggested number of bugs/fixes that needs to be addressed before the system is

deployed for his use. All the improvements that were suggested were minor fixes like making the

User Interface friendlier, change the timestamp to indicate local time and to make exceptions in

the lock codes based on some combination rules and excluding the master code. Moreover, he

also suggested to make the different user level distinct when it comes to viewing the log files

from each of their dashboard. Other minor improvements included having multiple selection in

the locks and hubs columns of the dashboard.

Changes that were suggested by the client during the CCD have been implemented. All those

fixes were prioritized and the development team ensured that the final product will not have the

issues that were made aware to us during the CCD and even after that. One of the initial

requirement, Grouping Locks, was negated by the client and instead we were given a new

requirement of implementing webhooks. Furthermore, multiple selection requirement was added

by the client which added additional work on GUI of the web page.

Potential risks were also identified when the client was testing the “View logs” feature within the

webpage. Erroneous error like “Slot 255” was being displayed which is an output of the Device

Handler. The development team does not have access to it and hence any errors, which also

includes time delay, from the device handler cannot be addressed. Hence, this serves as a major

risk to the developed system. Another risk is the lack of comments in the code, hence once the

transition from the development team to the client is done and the client hires maintainers, it will

prove a little difficult to find particular functions.

The webpage doesn’t have SSL certification which is also one of the requirements which needs

to be addressed by the client once the system is deployed for commercial use. Currently, the

system has been hosted on the server provided by the client. A user manual is being prepared and

will be available at the end of the transition review. It will contain the basic navigation help for

potential users and will also contain documentation and installation guide for the maintainers.

6.3 Adherence to Plan

The iteration ran according to the plan for the development phase. The testing was performed

using the software suggested in the class and the results were good. The team finished the

development on time and any additional work that was done was for fixing the new bugs and

issues that were identified either during or after the CCD. New changes implemented resulted in

a new version of the webpage and the overall system which we are terming as the “Beta



version”. Resource allocation was done according to the requirement in each sub-category of the

component.

There is a slight certainty in the Software Development Status which can affect future iterations.

The requirements of the clients were not fixed as they were dependent on the version of the

website being released, hence for the future more time of client testing the system initially and

then after the new versions are deployed is very essential. Moreover, weekly status calls and risk

identification before each version is deployed will be a healthy practice for future maintainers.

Documents

Life Cycle Plan (LCP) - Spring 2018 · Life Cycle Plan (LCP) Smart Locks Control Team 05 ... Risk and Defects Report Bi-weekly Wednesday .xlsx Soft copy Project Plan Bi-weekly Wednesday