Feasibility Evidence Description (FED) for Architected Agile Template Version 1.1

Feasibility Evidence Description (FED)

Mobile Application for Mobile-Controlled Lighting

Team 13

Saumil Kasbekar / Feasibility Analyst
Sayali Sakhalkar / Software Architect
Anuradha Saini / Life Cycle Planner
Priyank Mishra / Project Manager
Sagar Sarda / Requirements Engineer
Ashutosh Kale / Prototyper
Corey Stall / Requirements Engineer/Shaper

10/11/2014

Version History

Date / Author / Version / Changes made / Rationale /
09/28/14 / Team / 1.0 / ·  Added Risk Assessment section 3 / ·  Valuation Commitment Package Draft
10/11/14 / Team / 1.1 / ·  Completed the fisrt 5 sections / ·  Foundations Commitment Package

Table of Contents

Feasibility Evidence Description (FED) i

Version History ii

Table of Contents iii

Table of Tables iv

Table of Figures v

1. Introduction 1

1.1 Purpose of the FED Document 1

1.2 Status of the FED Document 1

2. Business Case Analysis 2

2.1 Cost Analysis 3

2.2 Benefit Analysis 3

2.3 ROI Analysis 4

3. Architecture Feasibility 5

3.1 Level of Service Feasibility 5

3.2 Capability Feasibility 5

3.3 Evolutionary Feasibility 6

4. Process Feasibility 7

5. Risk Assessment 8

6. NDI/NCS Interoperability Analysis 9

6.1 Introduction 9

6.2 Evaluation Summary 9

Table of Tables

Table 1: Personnel Costs 3

Table 2: Hardware and Software Costs 3

Table 3: Benefits of xxx System 3

Table 4: ROI Analysis 4

Table 5: Level of Service Feasibility 5

Table 6: Capability Requirements and Their Feasibility Evidence 5

Table 7: Evolutionary Requirements and Their Feasibility Evidence 6

Table 8: Rationales for Selecting Architected Agile Model 7

Table 9: Risk Assessment 8

Table 10: NDI Products Listing 9

Table 11: NDI Evaluation 9

FED_VCP_F14a_T13_V1.0.doc ii Version Date: 08/17/12

Feasibility Evidence Description (FED) for Architected Agile Template Version 1.1

Table of Figures

Figure 1: ROI Analysis Graph 4

FED_VCP_F14a_T13_V1.0.doc ii Version Date: 08/17/12

Feasibility Evidence Description (FED) for Architected Agile Template Version 1.1

1.  Introduction

1.1  Purpose of the FED Document

The purpose of the FED is required for the analysis of the requirements. Also, it provides details of the business feasibility, technology feasibility, process feasibility, schedule constraint.

Feasibility evidence document is required as it serves as a reference for the scope of the project and accordingly the planning of the project can be performed.

1.2  Status of the FED Document

-  The risk of incompatible system modules has been removed like the requirement to unify the protocols http and mqtt.

-  The risk of project out of scope has been removed. As, the requirement to build IOS application in the given small time frame has been removed as per the time constraint.

-  The risk of inflated expectations has been tackled by removing the challenging requirement like zero server downtime. Rather, the requirement has been approximated range and it is categorized as bonus.

2.  Business Case Analysis

Assumptions
·  User is willing to adopt using the system for use instead of conventional switches
Stakeholders
(Who is accountable for the initiatives) / Initiatives
(What to do to realize benefits) / Value Propositions
(Benefits i.e Why) / Beneficiaries
(Who derives value)
·  Developers
·  Maintainers
·  Advanchip / ·  Develop System
·  Marketing
·  Training Users / ·  Reduced Energy Wastage
·  Increased Convenience
·  Improved safety. / ·  Enterprise customers
·  Home users
·  Old people
2.1  Cost Analysis
2.1.1  Personnel Costs

Table 1: Personnel Costs

Activities / Time Spent (Hours)
Exploration Phase, Valuation Phase and Foundation Phase: (CS577A, 8 weeks)
Activities involving the stakeholder: Client –
Meeting via email, phone, and other channels
[2 hrs/week * 8 weeks * 1 person] / 16
Attended 2 WinWin Negotiations
[2hrs/time * 2 times * 1 person] / 4
FCR ARB [2hr * 1 person] / 2
Prototype, database schema review by emails
[1hr/time* 2 times *2 person] / 4
Total / 26
2.1.2  Hardware and Software Costs

Table 2: Hardware and Software Costs – Development phase

Type / RamNode Server / Hardware
Ownership cost / 14$/month / 50$/piece
Operational Cost / 0$ / 0$
Material/Hardware Costs / 0$ / 10$/set
Total / 14$ / 60$

Hardware and Software Costs – Operational phase

Type / RamNode Server / Hardware
Ownership cost / 14$/month / 50$/piece
Operational Cost / 0$ / 0$
Material/Hardware Costs / 0$ / 10$/set
Total / 168 / 60$
2.2  Benefit Analysis

Table3: Benefits of Mobile Controlled Lighting System

Current activities & resources used / % Reduce / Time Saved (Hours/Year)
Automation: The control of light control switches is handled by the android application.
Time taken to switch on/off the light
0.5 hr/day / 99% / 182.5
Construction cost saved: The building construction costs and wiring costs will be reduced by using the system
47.39$ / 99%
Total / 47.39*100= 4739$
2.3  ROI Analysis

1.  Cost during development: 2014

a)  For the development labor cost = 0 $

b)  For the hardware and software cost: 228$

c)  Total: $228

2.  Cost during operation

From 2015- 2016: 80H *52biweekly* $15/H * 110%= $2288

From 2016- 2017: 80H *52biweekly* $15/H * (110%)2 = $2516.8

From 2017- 2018: 80H *52biweekly* $15/H * (110%)3 = $2768.48

From 2018- 2019: 80H *52biweekly* $15/H * (110%)4 = $3045.328

Calculate the benefit.

Also the benefit can only be calculated starting from 2014 mid, since the project can only be delivered in the middle of 2014.

From 2015- 2016: 4739* 110%= $5212.9

From 2016- 2017: 4739* 110%= $5734.19

From 2017- 2018: 4739* 110%= $6307.61

From 2018- 2019: 4739* 110%= $6938.37

Calculate the ROI:

ROI = (Cumulative Benefit – Cumulative Cost) / Cumulative Cost

Table 4: ROI Analysis

Year / Cost / Benefit
(Effort Saved) / Cumulative Cost / Cumulative Benefit / ROI
2014 / 228 / 0 / 228 / 0 / -1
2015 / 2288 / 5215.9 / 2516 / 5215.9 / 1.07
2016 / 2516.8 / 5734.19 / 5032.8 / 10949.9 / 1.17
2017 / 2768.48 / 6307.61 / 7801.3 / 17256.9 / 1.212
2018 / 3045.328 / 6938.37 / 10846.3 / 24194.95 / 1.23

Figure 1: ROI Analysis Graph

3.  Architecture Feasibility

3.1  Level of Service Feasibility

Table 5: Level of Service Feasibility

Level of Service Requirement / Product Satisfaction
LOS-1: System response should be within 10 sec / Product Strategies: Efficient architecture of the system.
Process Strategies: Use highly responsive and available servers
Analysis: Quality will decrease if the system is not responisve
3.2  Capability Feasibility

Table 6: Capability Requirements and Their Feasibility Evidence

Capability Requirement / Product Satisfaction
CR-1: Android Programming / Software/Technology used: adt, sdk android ,eclispe
Feasibility Evidence: 577 team have experience with the android project and programming.
Referred use case diagram: Screens ,gui in the android application
CR-2: SQLite / Software/Technology used:SQLite
Feasibility Evidence: 577 team have experience with SQL queries
Referred use case diagram: get access control data from the database, store images
3.3  Evolutionary Feasibility

No Evolutionary requirements in our project curently

4.  Process Feasibility

Criteria / Importance / Project Status / Rationales
30 % of NDI/NCS features / 3 / 2 / 1.  Importance=3
Because this project highly depend on NDI/NCS.
2.  Project Status=2
Not Many of the tools utilized in this project are NDI or NCS.
Single NDI/NCS / 3 / 2 / 1.  Importance=3
Because this project highly depend on NDI/NCS.
2.  Project Status=4
Most of the tools utilized in this project are NDI or NCS.
Unique/ inflexible business process / 2 / 1 / 1.  Importance=2
2.  Project Status=1
This application’s design is not dependent on the business workflow.
Need control over upgrade / maintenance / 3 / 4 / 1.  Importance=3
The maintenance is very important for this project, because the client might upgrade the hardware to be robust.
2.  Project Status=4
The client will maintain the hardware by themselves in future.
Rapid deployment / 2 / 3 / 1.  Importance=2
It is important for our system because we need to match with the competitors.
2.  Project Status=3
Important because if we reach the market late, we might loose business to competitors.
Critical on compatibility / 0 / 0 / Because the product is developed from our end , so there is no criteria of compatibility.
Internet connection independence / 4 / 4 / 1.  Importance=4
The system is dependent on internet connection.
2.  Project Status=4
The project will not run without internet.
Need high level of services / performance / 3 / 3 / 1.  Importance=3
The system cannot run well without high level of services.
2.  Project Status=3
This system is currently based on medium level of performance and runs great.
Need high security / 3 / 3 / 1.  Importance=3
System login need security to limit access to switches.
2.  Project Status=3
Currently, project has 1st level of access control.
Asynchronous communication / 4 / 4 / 1.  Importance=4
This system should allow asynchronous communication.
2.  Project Status=4
Currently, the application uses HTTP protocol, which supports async communication.
Be accessed from anywhere / 4 / 4 / 1.  Importance=4
This system should be accessed from any mobile or
2. Project Status=4
Android application can be accessed from anywhere in the world if you have a web browser.
Critical on mass schedule constraints / 2 / 2 / 1.  Importance=2
The mass schedule constraints are generally important.
2.  Project Status=2
There are some mass schedule constraints for our project.
Lack of personnel capability / 4 / 2 / 1.  Importance=4
The developers’ skillsets are important for this project.
2. Project Status=2
Our 577 team can has to learn protocol MQTT which is new to us..
Require little upfront costs / 4 / 2 / 1.  Importance=4
Cost is a crucial issue for a non-profit organization.
2.  Project Status=2
Currently, the upfront cost is only need to buy hardware.
Require low total cost of ownership / 4 / 2 / 1.  Importance=4
Cost is a crucial issue.
2.  Project Status = 2
The cost for maintenance and other fees of maintaining the data server.
Not-so-powerful local machines / 3 / 3 / 1.  Importance=3
This system need to run on powerful local hosts to maintain high availability
2.  Project Status=3
Currently, application can be run on many local machines as long as the local machine supports dataload.

5.  Risk Assessment

Table 9: Risk Assessment

Risks / Risk Exposure / Risk Mitigations
Potential Magnitude / Probability Loss / Risk Exposure
Scope of the project too large to meet the deadline / 500 / 0.7 / 350 / Negotiate on the scope of the project in the win win negotiation
Developers are not very familiar with the existing server technologies , protocols and languages / 250 / 0.35 / 87.5 / Buying Information- Training and prototyping the system.
Too much expectation from the client
(Inflated Expectation) / 100 / 0.6 / 60 / Set the scope of the project in win win negotiation
Inconsistent involvement of stakeholders / 50 / 0.1 / 5 / Project manager will make sure to involve all the stakeholders.
Risk of unifying the protocols in the architecture which may lead to incompatibility / 250 / 0.1 / 25 / Analysis of the technology feasible prevents the incompatible architecture.

6.  NDI/NCS Interoperability Analysis

6.1  Introduction

Identify the Non-Developmental Item (NDI) and Net-Centric Services (NCS) including open source software or libraries that you are using/ plan to use in your project and analyze their interoperability. >

6.1.1  COTS / GOTS / ROTS / Open Source / NCS

Identify all candidate commercial off-the-shelf, government-off-the-shelf, research-off-the-shelf, open source software, libraries, and net-centric services component that you are using/ plan to use. Also identify the purpose of each component.

Table 10: NDI Products Listing

NDI/NCS Products / Purposes
6.1.2  Connectors

Identify the connector, for example

-  “In this project, we use PHP/MySQL Connector to enable the PHP web application to retrieve and query data from the database”. >

6.1.3  Legacy System

Identify the connector, for example

-  “In this project, the development system has to be able to interoperate and works well with “BusinessWorks” version 5.2, which is a software system that the client is currently using.” >

6.2  Evaluation Summary

< Summarize the final selection of your interoperable NDI/NCS, its usage and its comment. Example can be found in ICSM EPG> Task: Analyze NDI Interoperability for NDI / NCS project. >

Table 11: NDI Evaluation

NDI / Usages / Comments

FED_VCP_F14a_T13_V1.0.doc ii Version Date: 08/17/12