Feasibility Evidence Description (FED) for Architected Agile Templateversion 1.0

Feasibility Evidence Description (FED) for Architected Agile TemplateVersion 1.0

Feasibility Evidence Description (FED)

Focus

Team 08

Name / Role
Steven Holland / Requirement Engineer, Prototyper
Arik Oganesian / Operation Concept Engineer, Software Architect
Marco Alvarez / Feasibility Architect, Software Architect
Pin-Chih (Bill) Lin / Prototyper, Software Architect
Tatsuhiko (Tats) Tomita / Lifecycle Planner, Software Architect
Hamed Sadeghi / Project Manager, Prototyper
Dennis Xiang / IIV&V, Quality Focal

10/12/2016>

Version History

Date / Author / Version / Changes made / Rationale
10/12/2016 / MA / 1.0 / Original template for use with Focus v1.0, completed most sections / Initial draft for ARB packet draft

Feasibility Evidence Description (FED)

Version History

Table of Contents

Table of Tables

Table of Figures

Introduction

1.1.Purpose of the FED Document

1.2.Status of the FED Document

Business Case Analysis

2.1.Cost Analysis

2.2.Benefit Analysis

2.3.ROI Analysis

Architecture Feasibility

3.1.Level of Service Feasibility

3.2.Capability Feasibility

3.3.Evolutionary Feasibility

Process Feasibility

Risk Assessment

NDI/NCS Interoperability Analysis

6.1.Introduction

6.2.Evaluation Summary

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

IICSMSw_FED_Architected Agile_Template.doc1Version Date: 10/12/2016

Feasibility Evidence Description (FED) for Architected Agile TemplateVersion 1.0

Table of Figures

Figure 1: ROI Analysis Graph...... 4

IICSMSw_FED_Architected Agile_Template.doc1Version Date: 10/12/2016

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

1.Introduction

1.1.Purpose of the FED Document

The purpose of the FED document is to make sure we choose the correct NCS/NDI for our project and make sure that we can integrate them in the application. In addition, we check if investment in application will yield any profit, whether monetary or in time. This analysis makes sure that we have chosen the correct NDI for the project such that we stay within budget, is doable within the time frame, and the project will have a return of investment. This way, we reduce risks later on in the project and can be more confident in the success of the project.

1.2.Status of the FED Document

First version of FED. Here we identify the NDI that would be best to use for the application. Considered major risks and came up with plans to mitigate the risks. Completed business case analysis, cost analysis, benefit analysis, LOS and Capability feasibility, risk assessment, and NDI interoperability analysis. Still need to do the ROI analysis, Evolutionary Feasibility, and Process Feasibility.

2.Business Case Analysis

Assumptions
•Entrepreneurs need mentorship
•Entrepreneurs need a community to share their ideas and seek potential collaborations
•Mentors want to help
Stakeholders / Initiatives
/ Value Propositions
/ Beneficiaries
•Entrepreneurs
•Mentors
•Developers
•Client
•Maintainers / •Develop the app
•Gather Information for questionnaire
•Marketing
•Innovative Ideas
•Maintain the system / Facilitate entrepreneur-mentor relationship
Build a community
Increase the success rate of start ups
Gain experience in app development / Entrepreneurs
Mentors
Developers
Client
Maintainers
Cost
Database
Online computing server
Marketing
Maintenance
Developer’s License / Benefits
•Number of entrepreneurs being helped by mentors increase
•Application gains more users
•Mentors able to help more entrepreneurs and share their knowledge

2.1.Cost Analysis

Considering cost of time client spends on project and include all costs of NDI.

2.1.1.Personnel Costs

Table 1: Personnel Costs

Activities / Time Spent (Hours)
Valuation and Foundation Phases (CSCI 577a, 12 weeks total)
Client and team meetings: Through video calls or in person:
(2hr/week * 12 weeks * 1 person) / 24 hours
WinWin Session (1 hour * 1 person * 2 sessions) / 2 hours
Architecture Review Board (ARB)
(1.5 hours * 1 person * 1 session) / 1.5 hours
Total / 27.5 hours

2.1.2.Hardware and Software Costs

< Identify all hardware and software-related cost from exploration phase to operation phase. Example can be found at ICSM EPG>Task: Analyze Business Case >

Table 2: Hardware and Software Costs

Type / Cost / Rationale
Apple Developer Program Membership / $99/year / To launch iOS application through the iOS store.
Firebase / Free to launch
$25/month for 50GB of storage / Need a database to store all information of mentors and entrepreneurs. Also need this to store mentor curriculum/homeworks
AWS Cloud Computing / Free for first 12 months
$0.034/hour / Online computing server to have algorithm perform computation here. This will help make the application not be so demanding on phones.

2.2.Benefit Analysis

Table 3: Benefits of xxx System

Current activities & resources used / % Reduce / Time Saved (Hours/Year)
Entrepreneurs seeking help must go to physical location to get mentorship / 90 / Difficult to Quantify
Total / Difficult to Quantify

2.3.ROI Analysis

< Calculate Return on Investment by using your cost and benefit analysis results and identifythe breakeven point. Note, if you have hardware and software cost, it must be included in ROI calculation. For effort cost, if you use a salary as your calculation base, assume 10% annually increase. Example can be found at ICSM EPG>Task: Analyze Business Case>

Table 4: ROI Analysis

Year / Cost / Benefit
(Effort Saved) / Cumulative Cost / Cumulative Benefit / ROI

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: iOS application should render nicely and work with older versions of iPhones including 5, 5s, SE, 6, 6s / Product Strategies: iOS framework
Process Strategies: Choose iOS documentation to help with resizing
Analysis: iOS framework provide ways to make apps work with older versions by auto resizing to fit the screen best. Many applications today are able to resize to fit the phone resolution best, so we know it is possible.

3.2.Capability Feasibility

Table 6: Capability Requirements and Their Feasibility Evidence

Capability Requirement / Product Satisfaction
CR-1: Matching Algorithm on cloud service(remote server) / Software/Technology used: AWS
Feasibility Evidence: Develop prototype and have simple algorithm perform computation in AWS, and return result to iOS app.
Referred use case diagram: < identify related use case diagram >
CR-2: Use backend database to store and retrieve information and display on iOS application / Software/Technology used: Firebase
Feasibility Evidence: Prototyped iOS app to retrieve information from Firebase and displayed results in iOS app. Further develop prototype to show how profiles are loaded and displayed on app.
Referred use case diagram:
Software/Technology used:
Feasibility Evidence:
Referred use case diagram:

3.3.Evolutionary Feasibility

Table 7: Evolutionary Requirements and Their Feasibility Evidence

Evolutionary Requirement / Product Satisfaction
ER-1: < ER name > / Software/Technology used: <identify the software/technology that is/are used to develop this capability requirement>
Feasibility Evidence: < briefly provide rationale of how this capability could be developed to satisfy the requirements. >
Referred use case diagram: < identify related use case diagram >
Software/Technology used:
Feasibility Evidence:
Referred use case diagram:
Software/Technology used:
Feasibility Evidence:
Referred use case diagram:

4.Process Feasibility

< Based on process decision table provided in ICSM EPG> Concept: Process Decision Selection Guidelines, Identify which process model you are following and provide rationale why that model would fit your development project. Note: Development team discusses with stakeholders on important drivers and project status

Decision Criteria Rating Scale; 0:Very Low; 1:Low; 2: Medium; 3:High; 4:Very High

Importance Rating Scale: 1:Low; 2: Medium; 3:High

Table 8: Rationales for Selecting Architected Agile Model

Criteria / Importance / Project Status / Rationales
30 % of NDI/NCS features
Single NDI/NCS
Unique/ inflexible business process
Need control over upgrade / maintenance
Rapid deployment
Critical on compatibility
Internet connection independence
Need high level of services / performance
Need high security
Asynchronous communication
Be accessed from anywhere
Critical on mass schedule constraints
Lack of personnel capability
Require little upfront costs
Require low total cost of ownership
Not-so-powerful local machines

5.Risk Assessment

Table 9: Risk Assessment

Risks / Risk Exposure / Risk Mitigations
Potential Magnitude / Probability Loss / Risk Exposure
Correct implementation of matching algorithm, with correct elements being considered / 6 / 9 / 54 / Collect all factors to be considered in algorithm. Prototype different versions of algorithm to compare response time and correctness.
COTS interoperability (Backend services) with mobile application. / 5 / 5 / 25 / Create prototypes to evaluate the feasibility of combining COTS services with iOS application. Evaluate COTS and keep API up-to-date.
Make UI/UX nonintuitive, lacking features / 3 / 6 / 18 / Create UI prototypes to show layout of application. Speak with potential users to get feedback on how they would like to communicate with application. Speak with client for any final UI changes.
Lack of iOS developmental knowledge within team lead to messy or incorrect code / 3 / 5 / 15 / Promote collaborative development, and study documentation to create up-to-date iOS code
LinkedIn login feature / 2 / 1 / 2 / Test login feature in a prototype, using LinkedIn provided API. To avoid any problems, we will only use LinkedIn as an alternative login feature and not pull data constantly during the day.

6.NDI/NCS Interoperability Analysis

6.1.Introduction

The following will discuss the NDI that we will use to help with the implementation of the application. This will discuss the feasibility of integrating the NDI with each other.

6.1.1.COTS / GOTS / ROTS / Open Source / NCS

Table 10: NDI Products Listing

NDI/NCS Products / Purposes
iOS SDK / Mobile Development for iOS
Firebase / Backend Database
AWS / Cloud Computing Server
LinkedIn Login API / Optional user login

6.1.2.Connectors

6.1.3.Legacy System

There is no legacy system, this will be the first version of the system.

6.2.Evaluation Summary

Table 11: NDI Evaluation

NDI / Usages / Comments
iOS SDK / Mobile Development for iOS / Free to use and provides vast support for iOS development
Firebase / Backend Database / Suitable for real time applications and has vast support. Easily integratabtle for iOS applications
AWS / Cloud Computing Server / Mature system, providing reliability and support.
LinkedIn Login API / Optional user login / Easy way for users to login, but will be optional. There will still be a regular login process for application. iOS SDK provided by LinkedIn