Feasibility Evidence Description (FED) for Architected Agile Template Version 2.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/17/2016>
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
10/17/2016 / MA / 2.0 / • Changed few sections based on feedback
• Completed rest of document / • Updated version for ARB packet
Version History
Table of Contents
Feasibility Evidence Description (FED) 1
Version History 3
Table of Contents 4
Table of Tables 5
Table of Figures 6
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 2
2.2. Benefit Analysis 4
2.3. ROI Analysis 5
3. Architecture Feasibility 7
3.1. Level of Service Feasibility 7
3.2. Capability Feasibility 8
3.3. Evolutionary Feasibility 9
4. Process Feasibility 10
5. Risk Assessment 13
6. NDI/NCS Interoperability Analysis 15
6.1. Introduction 15
6.2. Evaluation Summary 15
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.doc 6 Version Date: 10/17/2016
Feasibility Evidence Description (FED) for Architected Agile Template Version 2.0
Table of Figures
Figure 1: ROI Analysis Graph 4
IICSMSw_FED_Architected Agile_Template.doc 6 Version Date: 10/17/2016
Feasibility Evidence Description (FED) for Architected Agile Template Version 2.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
Modified a few sections below based on feedback from ARB presentation and on client feedback. Completed rest of document sections that were not completed for the draft. Should be up-to-date with the plan we have for the project.
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
Client: Meeting with different sources to collect information that will be helpful for application, features, content, questions.
(3 hours/week * 2 persons * 12 weeks) / 72 hours
Developer and Foundation Phases (CSCI 577b, 12 weeks total)
Client and team meetings: Through video calls or in person:
(3 hours/week * 12 weeks * 1 person) / 36 hours
Architecture Review Board and Core Capability Drive-through:
(1.5 hours * 1 person * 2 sessions) / 3 hours
Deployment of System in Operation phase and training
- Installation and Deployment (5hrs * 2 times * 1 person)
- Training and Support (4hrs * 3 times * 2 persons) / 34 hours
Total / 172.5 hours
Maintenance Period (1 year)
Maintenance (2.5 hrs/week * 52 weeks) / 130 hours
2.1.2. Hardware and Software Costs
Type / Cost / RationaleApple Developer Program Membership / $99/year / To launch iOS application through the iOS store.
Firebase / Free to launch
$25/month for 50GB of storage
$0.026/GB^2 (if more storage needed) / 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.
Table 2: Hardware and Software Costs
2.2. Benefit Analysis
Calculating the cost is difficult to quantify because the time that an entrepreneur spends getting help varies with each user. In addition, the cost for the mentor also varies with each mentor. This cost calculates hours being spent, since there is no monetary value that is being spent when entrepreneurs get help. However, for this analysis, we will assume that on average, an entrepreneur spends 100 hours a year getting help. This includes time to get to location and time to get selected to mentor that can best suit their needs. Also, we assume that a mentor spends 200 hours on average a year to look through entrepreneurs and see which one he could help, depending on the needs of the entrepreneur, and preparing information to best help the mentor.
Table 3: Benefits of System
Current activities & resources used / % Reduce / Time Saved (Hours/Year)Entrepreneurs seeking help must go to physical location to get mentorship / 95 / 95 hours/year
Mentors looking through list of entrepreneurs to see which they could help based on entrepreneur need / 95 / 190 hours/year
Total / 285 hours/year
2.3. ROI Analysis
Since the application will not generate income, we will exclude the cost of software and hardware, since the ROI will only consider time being saved. We will assume that ‘cost’, which is time spent, to increase by 10% each year
Table 4: ROI Analysis
Year / Cost / Benefit(Effort Saved) / Cumulative Cost / Cumulative Benefit / ROI
2016 / 172.5 / 0 / 172.5 / 0 / -1
2017 / 130 / 285 / 302.5 / 285 / -0.05
2018 / 143 / 285 / 445.5 / 570 / 0.27
2019 / ~157 / 285 / ~602 / 855 / 0.42
2020 / ~172 / 285 / ~774 / 1140 / 0.5
Figure 1: ROI Analysis Graph
3. Architecture Feasibility
3.1. Level of Service Feasibility
Table
5: Level of Service Feasibility
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 SatisfactionCR-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: Refer to use case in SSAD
CR-2: User Profile - users can create/delete/edit profiles / Software/Technology used: Firebase, iOS framework
Feasibility Evidence: Prototype iOS app where a user can create a profile that will be saved in Firebase, and then implement edit feature and delete feature to show feasibility of this requirement.
Referred use case diagram: Refer to use case in SSAD
CR-3: Mentor Defined Curriculum - mentor can create/delete/edit curriculum / Software/Technology used: Firebase, iOS framework
Feasibility Evidence: Prototype iOS app where a user logged in as mentor can perform all operations listed on the side. All information will be stored in Firebase.
Referred use case diagram: Refer to use case in SSAD
CR-4: Communication: Users can communicate through private messaging or through a forum. / Software/Technology used: Firebase, iOS framework
Feasibility Evidence: Already created a prototype to show private messaging between users. Further develop prototype to have users post to a forum and be able to delete or edit the posts.
Referred use case diagram: Refer to use case in SSAD.
3.3. Evolutionary Feasibility
Evolutionary Requirement / Product SatisfactionER-1: Application scalability to support more users / Software/Technology used: Firebase and AWS
Feasibility Evidence: Increase the usage of the COTS to handle the influx of users and information being used.
Referred use case diagram:N/A
ER-2: Add/improve features in application / Software/Technology used: iOS framework/SDK
Feasibility Evidence: Be able to improve certain features implemented early on and ability to add more features
Referred use case diagram: N/A
ER-3: Expand to Android system / Software/Technology used: Android Studio
Feasibility Evidence: Create same application, but for Android users, copy all features from iOS application for this application, which has been done before for multiple applications that are used in both iOS and Android.
Referred use case diagram: N/A
Table 7: Evolutionary Requirements and Their Feasibility Evidence
4. Process Feasibility
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
Criteria / Importance / Project Status / Rationales30 % of NDI/NCS features / 3 / 4 / We will be using multiple NDI, like the database, server, possible login API, for the application.
Single NDI/NCS / 1 / 0 / We need to use multiple NDI features, so not possible to use a single NDI
Unique/ inflexible business process / 2 / 2 / While we want entrepreneurs to use the application to get matched with mentors to get help, entrepreneurs could ask help through forum or possibly support allowing entrepreneurs picking mentor by looking at list of mentors.
Need control over upgrade / maintenance / 3 / 4 / Need to be able to maintain and upgrade system for second semester to add more features, or improve on already implemented ones.
Rapid deployment / 2 / 2 / Want to have key features, like matching, done this semester, but other features don’t have to be done so rapidly.
Critical on compatibility / 1 / 0 / Only worried about deploying application on iOS now, may consider Android variant in second semester.
Internet connection independence / 1 / 0 / Application relies on internet connectivity, since all information and matching computation is done online. Need internet to communicate or post anything on the forum.
Need high level of services / performance / 2 / 3 / Need to have high level of services and great performance.
Need high security / 2 / 2 / NDI will be providing security for data.
Asynchronous communication / 3 / 4 / Needed for getting information from database and forum, private messaging communication.
Be accessed from anywhere / 2 / 2 / For now, only should be accessed inside the United States, maybe in the future expansion to other locations, but no plans at this time.
Critical on mass schedule constraints / 1 / 0 / Not critical on mass schedule constraints
Lack of personnel capability / 1 / 2 / Some personnel don’t have much experience with iOS programming, and once those that leave at the end of the semester, this can become more critical.
Require little upfront costs / 1 / 0 / Only the Apple Developer Membership of cost is required, but other than that, more cost will come later in the application.
Require low total cost of ownership / 1 / 1 / Cost not much of a concern, but like to keep it low.
Not-so-powerful local machines / 1 / 2 / User devices won’t have to worry about having power, since most computation will be done through online servers. Little power required.
Table 8: Rationales for Selecting Architected Agile Model
5. Risk Assessment
Risks / Risk Exposure / Risk MitigationsPotential 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.
Scalability issue: How to handle a large influx of users such that we have enough space in COTS and prices don’t become too much to handle. / 7 / 3 / 21 / For our client, cost doesn’t seem to be much of an issue, so we can always increase the plan of the COTS to handle more users as demand grows. Of course, we will still choose the cheapest options available in the COTS being used such that it satisfies the demands of the application.
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.
3 team members that will lead the iOS development will leave after this semester, need to be replaced. / 4 / 4 / 16 / Help rest of team with iOS development before team members leave. Either find other team members to take those roles, or another plan is to have two of the leaving team members take next course as independent study and continue with the project.
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.
Table 9: Risk Assessment