Feasibility Evidence Description (FED) for Architected Agile Version 3.2
Feasibility Evidence Description (FED)
Mobile Application for Mobile-Controlled Lighting
Team 13
Saumil Kasbekar / Feasibility AnalystSayali 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/18/2014
Version History
Date / Author / Version / Changes made / Rationale /08/20/05 / PP / 1.0 / · Original template for use with LeanMBASE v1.0 / · Initial draft for use with LeanMBASE v1.0
08/30/06 / SK, RT / 1.6 / · Add template table
· Remove Section 3. Requirement Traceability / · Consistent format
· Move to Supporting Information Document
10/06/06 / SK / 1.61 / · Removed Section 1.6 / · Section 1.6 was duplicated with section 1.7 due to Format error
09/14/07 / SK / 1.9 / · Updated Section 2 / · Consistent with LeanMBASE1.9
08/25/08 / IC / 2.0 / · Moved Section 1.1 to 1.2
· Add Section 1.2
· Updated Section 3 and add 3.1-3.3
· Updated Section 6, 6.3 / · Consistent with IICM-Sw
08/14/09 / SK / 2.1 / · Embedded description in each Table
· Removed Section 6.1.1 Definition / · To be consistent with ICM EPG template set standard V2.1
· To leanify the artifact
08/17/12 / TK / 2.2 / · Updated Section 2, 3, and 6 / · To be consistent with IICSM-Sw
09/28/14 / Team / 3.0 / · Added Risk Assessment section 3 / · Valuation Commitment Package Draft
10/11/14 / Team / 3.1 / · Completed the fisrt 5 sections / · Foundations Commitment Package
10/18/14 / Team / 3.2 / · Completed all the sections / · Draft TRR package
Table of Contents
Feasibility Evidence Description (FED) i
Version History Error! Bookmark not defined.
Table of Contents ii
Table of Tables iv
Table of Figures v
1. Introduction Error! Bookmark not defined.
1.1 Purpose of the FED Document Error! Bookmark not defined.
1.2 Status of the FED Document Error! Bookmark not defined.
2. Business Case Analysis 2
2.1 Cost Analysis 2
2.2 Benefit Analysis 3
2.3 ROI Analysis 3
3. Architecture Feasibility 4
3.1 Level of Service Feasibility 6
3.2 Capability Feasibility 6
3.3 Evolutionary Feasibility 7
4. Process Feasibility 8
5. Risk Assessment 8
6. NDI/NCS Interoperability Analysis 12
6.1 Introduction 13
6.2 Evaluation Summary 13
Table of Tables
Table 1: Personnel Costs Error! Bookmark not defined.
Table 2: Hardware and Software Costs Error! Bookmark not defined.
Table 3: Benefits of Mobile Controlled Lighting System Error! Bookmark not defined.
Table 4: ROI Analysis Error! Bookmark not defined.
Table 5: Level of Service Feasibility 6
Table 6: Capability Requirements and Their Feasibility Evidence 6
Table 7: Evolutionary Requirements and Their Feasibility Evidence Error! Bookmark not defined.
Table 8: Rationales for Selecting Architected Agile Model Error! Bookmark not defined.
Table 9: Risk Assessment Error! Bookmark not defined.
Table 10: NDI Products Listing 13
Table 11: NDI Evaluation 13
FED_DCP_F14a_T13_V3.2.doc ii Version Date: 10/18/14
Feasibility Evidence Description (FED) for Architected Agile Version 3.2
Table of Figures
Figure 1: ROI Analysis Graph Error! Bookmark not defined.
FED_DCP_F14a_T13_V3.2.doc ii Version Date: 10/18/14
Feasibility Evidence Description (FED) for Architected Agile Version 3.2
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 / HardwareOwnership 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 / HardwareOwnership 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
(collective time spent to control all the lights of an enterprise building/building with minimum 15 lights by the admin / users , given time to turn off one light : 2 min) / 99% / 182.5
Construction cost saved: The building construction costs and wiring costs will be reduced by using the system
47.39$
( this cost is the building and maintenance cost for the wiring required to build each conventional switch system in buildings/houses) / 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
Total hours spent in 2 weeks ( operational / maintenance) : 80 hrs
Approx. expected users using mobile control system = 52
Approx. salary of an employee for maintenance functions = $15 / hr
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 - 2015 / 228 / 0 / 228 / 0 / -1
2016 / 2288 / 5215.9 / 2516 / 5215.9 / 1.07
2017 / 2516.8 / 5734.19 / 5032.8 / 10949.9 / 1.17
2018 / 2768.48 / 6307.61 / 7801.3 / 17256.9 / 1.212
2019 / 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 1: Level of Service Feasibility
Level of Service Requirement / Product SatisfactionLOS-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 responsive
The team has tested main function APIs like getting the gateway responses from the server to and from the application. Eg: add/delete gateway does not return on time if the server is down and the status of the switches cannot be returned from the gateway to the application via server. Hence, the MQTT protocol being used in the system was tested that enables the communication between the gateway and the application to control the switches and the system can return the result quickly.
3.2 Capability Feasibility
Table 2: Capability Requirements and Their Feasibility Evidence
Capability Requirement / Product SatisfactionCR-1: Gateway Management / Software/Technology used: use node.js for the server, MongoDb for backend , Java for the frontend of gateway management.
Feasibility Evidence: the gateway management page is prototyped. The actions of user as an admin are modeled in SSAD 2.1.3 Behavior.
Referred use case diagram.
CR-2: Lighting Control / Software/Technology used: hardware, gateway, node.js, mongodb for database, display the frontend for controlling switches and validate users input, and use Nodejs for backend processing.
Feasibility Evidence: Nodejs will bring the gateway response to the application for processing and controlling the switches.
Referred use case diagram
CR -3 : Screen Management / Software/Technology used: Android Java for interacting with user, Nodejs on the backend saves all information for the current session.
Feasibility Evidence: The nodejs gives the favorite switches info stored and grouping the switches based on the saved data.
Referred use case diagram.
CR -4 : User Access Management / Software/Technology used: Android java for interacting with user, nodejs APIs for AES Encryption, to communicate between frontend and APIs, mongodb on the backend
Feasibility Evidence: User access management APIs have been tested. Details are provided in section 5 and 6.
Referred use case diagram.
3.3 Evolutionary Feasibility
No Evolutionary requirements in our project curently
4. Process Feasibility
Criteria / Importance / Project Status / Rationales30 % 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.
Process chosen : The NCS features are crucial for debugging (papertrail) and server availability.We must be able to debug the nessages coming from the gateway.
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.
Process chosen : We must be able to debug the messages coming from the gateway
Unique/ inflexible business process / 2 / 1 / 1. Importance=2
2. Project Status=1
This application’s design is not dependent on the business workflow.
Process chosen :The system was prototyped
The business process is very clear from the client and it is rather unlikely to change,
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.
Process chosen :
The team may get involved only if the APIs are upgraded for new enhancements in the coming new versions.
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 lose business to competitors.
Process chosen :
The mobile controlled system is targeted to de delivered in 2015 in the market.
Critical on compatibility / 0 / 0 / Because the product is developed from our end , so there is no criteria of compatibility.
Process chosen : The system must fulfill its goals.Otherwise, users would not use it.
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.
Process chosen: The system requires internet connection to use.
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.
Process chosen: Users could be controlling switches any time during the day. Therefore, high level of services and performance are required.
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.
Process chosen :
Users will be logged into the system using provided by the AES encryption technique APIs. Hence, security breach is still undesirable.
Asynchronous communication / 4 / 4 / 1. Importance=4
This system should allow asynchronous communication.
2. Project Status=4
Process chosen : 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
Process chosen : 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
Process chosen : 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
Process chosen : 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
Process chosen : 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
Process chosen : 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
Process chosen : Currently, application can be run on many local machines as long as the local machine supports dataload.
5. Risk Assessment
Table 9: Risk Assessment