Feasibility Rationale Description (FRD) · FED_DCP_F13a_T14_V3.2.doc ii 12/09/2013 Version History...
Transcript of Feasibility Rationale Description (FRD) · FED_DCP_F13a_T14_V3.2.doc ii 12/09/2013 Version History...
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc i 12/09/2013
Feasibility Evidence Description (FED)
Healthy Kids Zone Survey App
Team 14
Name Primary Role Contact Email
Jessie Kim Client Representative [email protected]
Joseph Martinez Client Representative [email protected]
Malcolm Carson Client Representative [email protected]
Yang Wang Project Manager [email protected]
Qianyu Liao System Architect [email protected]
Chad Honkofsky IIV&V/QFP [email protected]
Xu Zhang Operational Concept
Engineer
Chenglu Wang Feasibility Analyst [email protected]
Junjun Ji Prototyper [email protected]
Ye Tao Life Cycle Planner [email protected]
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc ii 12/09/2013
Version History
Date Author Version Changes made Rationale
08/20/12 SK 1.0 Original for CSCI477; Tailored
from ICSM OCD Template To fit CS477 course content
10/13/13 Chenglu
Wang 1.1
Updated Sections1, 3 and 5,
Introduction, Business Case
Analysis and Risk Assessment
respectively
To determine project viability and
path forward
10/15/13 Chenglu
Wang 1.2
Add Section 2 Process Feasibility
Added Section 4 NDI/NCS
Feasibility Analysis
Added Section 6 Conclusion and
Recommendation
To add more sections about
NDI/NCS assessment evidence.
10/16/13 Chenglu
Wang 2.0
Change Section 3 risk assignment
Change Section 4 NDI/NCS
Feasibility Analysis
To add more sections about
NDI/NCS assessment evidence
10/17/13 Chenglu
Wang 2.1 Fix typo Make the document less mistaken
10/21/13 Chenglu
Wang 2.2
Update ROI analysis to start at
correct time
Add the risks of Survey Monkey
Incorporate Comments from FCR-
ARB
11/27/13 Chenglu
Wang 3.0
Updated Section 3,4,5,6, Risk
Assessment, NDI/NCS Feasibility
Analysis, Business Case Analysis
and Conclusions
To determine project viability and
path forward
11/28/13 Chenglu
Wang 3.1 Update section 4, level of service To add another level of service
12/09/13 Chenglu
Wang 3.2 Mitigate risks To fixed defects in DCR-ARB
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc iii 12/09/2013
Table of Contents
Feasibility Evidence Description (FED) ......................................................................................................................i
Version History ........................................................................................................................................................... ii
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. Process Feasibility ................................................................................................................................................ 2
3. Risk Assessment .................................................................................................................................................... 3
4. NDI/NCS Feasibility Analysis .............................................................................................................................. 5
4.1 Assessment Approach ................................................................................................................................... 5
4.2 Assessment Results ........................................................................................................................................ 5
4.3 Feasibility Evidence ....................................................................................................................................... 7
5. Business Case Analysis ....................................................................................................................................... 10
5.1 Cost Analysis ................................................................................................................................................ 10
5.2 Benefit Analysis ........................................................................................................................................... 12
5.3 ROI Analysis ................................................................................................................................................ 14
6. Conclusion and Recommendations ................................................................................................................... 16
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc iv 12/09/2013
Table of Tables
Table 1: Rationales for Selecting NDI/NCS Model ....................................................................................................... 2
Table 2: Risk Assessment ............................................................................................................................................... 3
Table 3: NDI/NCS Products Listing .............................................................................................................................. 5
Table 4: Evaluation Criteria – NDI /NCS Attributes ..................................................................................................... 5
Table 5: Evaluation Criteria - NDI/NCS features ......................................................................................................... 6
Table 6: Evaluation Results Screen Matrix for table 4 .................................................................................................. 6
Table 7: Level of Service Satisfiability Evidence ........................................................................................................... 7
Table 8: Level of Service Implementation Strategy ....................................................................................................... 7
Table 9: Capability Feasibility Evidence ...................................................................................................................... 8
Table 10: Evolutionary Feasibility Evidence ................................................................................................................ 9
Table 11: Program Model ........................................................................................................................................... 10
Table 12: Personnel Costs ........................................................................................................................................... 11
Table 13: Hardware and Software Costs .................................................................................................................... 12
Table 14: Benefits of Healthy Kids Zone survey APP ................................................................................................. 13
Table 15: ROI Analysis ................................................................................................................................................ 14
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc v 12/09/2013
Table of Figures
Figure 1: ROI Analysis Graph .................................................................................................................................... 14
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 1 12/09/2013
1. Introduction
1.1 Purpose of the FED Document
This FED Document provides the feasibility analysis about the Healthy Kid Zone (HKZ) Survey
App. This document presents the feasibility analysis, risk assessment, NDI/NCS feasibility
analysis, and business case analysis. This feasibility study will allow the development team and
clients to make a “go/no-go” decision.
1.2 Status of the FED Document
The status of the FED Document is currently at the Development Commitment Package version
3.2. This document was concurrently completed for Exploration, Valuation and Foundation
phases with the following the major changes:
Add/change NDI/NCS feasibility analysis
Add/change some hardware and software cost
Redraw the ROI chart
Add/change Risk Assessment
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 2 12/09/2013
2. Process Feasibility
Table 1 shows the reasons for choosing NDI/NCS model for development.
Table 1: Rationales for Selecting NDI/NCS Model
Criteria Rationales
Size, Complexity There exists many open source NDI/NCS
frameworks and libraries for developing hybrid
mobile apps which will limit the size and
complexity of the code base
Criticality NDI/NCS will provide the interface into native
features which is more than 30% of the system
functionalities
NDI Support NDI will support most of major functionalities such
as pinning intersections by Google maps.
Change Rate % /Month Since NDI/NCS will not change frequently, it is
convenient to use.
Org/Personnel Capability Since development team members are not familiar
with NDI/NCS, we need time and effort to learn
how to use NDI /NCS and integrate them into the
whole system. Also, we don’t choose agile model
because we don’t have enough time to develop the
app together as the agile model requires.
Require low total cost of ownership All NDI/NCS being considered are open source or
free services.
Critical on compatibility Cross-platform compatibility was a strong desire by
the customer and the NDI/NCS being considered
supports this functionality.
Not-so-powerful local machines Mobile apps do not require powerful machines to
run the application.
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 3 12/09/2013
3. Risk Assessment
Risk Assessment consists of risk identification, risk analysis and risk prioritization. Table 2
contains the list of the top 5 risks which are the most frequent; it also contains risk exposure and
risk mitigations.
Table 2: Risk Assessment
Risks
Risk Exposure
Risk Mitigations Potential
Magnitude
Probability
Loss
Risk
Exposure
1. User Interface mismatch
Since our clients wishfully want
to see the User Interface on the
mobile app. What’s more, our
clients attach great importance to
the User Interface which may
decide the success of the mobile
app. Because if the development
team cannot design good User
Interface, this may not attract
more volunteers to participate in
doing the survey. That means our
clients cannot obtain sufficient
survey information from the
volunteers, so this mobile app will
be a failure.
8
6-7
48-56
Firstly, the development team should
do the prototype since it is a high
priority feature and present it to
clients during the Architecture Board
Review.
Secondly, according the persona, the
development team should adequately
analysis the features of the possible
users and discusses what kind of the
User Interface will appeal to users.
And then the development team
could design proper User Interface.
2. Call API limitation
When calling survey monkey
public API, it is possible that a
basic key has gone over its
throttle limit and developers will
be prevented by calling more API.
6
5-6
30-36
Do the test cases as frequently as
possible to see if the similar situation
always happens. If so, calling less
API per second and redesign code.
3. Skill deficiencies
Since we have never managed a
project by ourselves and only two
of us have developed an android
app. Besides, everybody in our
development team has little
experience as to using survey
monkey which is bought by the
clients. Thus, the skill deficiencies
may impose a lot of problems
when delivering the project.
5
6
30
At first, we need to hard working and
spend more time and effort on
studying how to use the survey
monkey and learn its API.
In the second place, for large models
in our project, we should analysis the
features carefully and need to
decompose them into small models
so that we can more easily
understand the whole system.
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 4 12/09/2013
Risks
Risk Exposure
Risk Mitigations Potential
Magnitude
Probability
Loss
Risk
Exposure
4. Technical deficiency
In the survey monkey, survey
questions can be edited in many
types. However, if we want to put
one picture and its relative
question together on one page, the
survey monkey does not provide
question type that can fulfill this
above requirement.
Besides, if we put the picture on
one page and put its question on
the next page, there may be data
memory error since we don’t
know the database how to store
these questions data.
5
5
25
Do the test cases as frequently as
possible to see if there exist some
data memory errors. If the problem
exists, we may find another way to
design survey questions.
Search for other’s relative examples
and to see if the current problem can
be solved in the similar way.
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 5 12/09/2013
4. NDI/NCS Feasibility Analysis
4.1 Assessment Approach
Choosing a suitable tool for building surveys is the primary goal for this assessment. The two NDI
candidate components analyzed are the SurveyMonkey and Qualtrics. For the purpose of
providing online survey information browsing service, we use apache tomcat as web server; For
the purpose of storing survey data, we use MySQL as database management system; for the
purpose of pin intersections accurately, we use Google Maps. For the purpose of mobile app
development framework, we have decided to use Titanium.
4.2 Assessment Results 4.2.1 NDI/NCS Candidate Components (Combinations)
Table 3: NDI/NCS Products Listing
NDI/NCS Products Purposes
NDI/NCS set 1
Survey Monkey To build surveys
Qualtrics To build surveys
NDI/NCS
Titanium To create a mobile cross-platform
cellphone application
Apache webserver To provide online survey information
browsing service
MySQL To store survey data
Google Maps To pin intersections accurately
FB/Twitter To share street score on FB/Twitter
Godaddy Server To store survey information and pictures
4.2.2 Evaluation Criteria
Table 4: Evaluation Criteria – NDI /NCS Attributes
No. Evaluation Criteria – NDI/NCS attributes Weight
1 Flexibility 15
2 Product performance 20
3 Functionality 20
4 Ease of use 45
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 6 12/09/2013
Total 100
Table 5: Evaluation Criteria - NDI/NCS features
No. NDI/NCS Features/ sub features Weight
1 Variety of questions types(tally) 40
2 Variety of API 25
3 Create/Upload custom charts/pictures 35
Total 100
4.2.3 Evaluation Results Screen Matrix
Table 6: Evaluation Results Screen Matrix for table 4
No W
Component 1
Survey Monkey AVG Total
Component 2
Qualtrics AVG Total
R1 R2 R3 R4 R1 R2 R3 R4
1 15 9 8 8 9 8.5 127.5 8 7 8 9 8 120
2 20 8 8 8 8 8 160 8 8 8 9 8.25 165
3 20 8 8 8 7 7.75 155 8 7 8 7 7.5 150
4 45 9 9 9 8 8.75 393.75 7 7 8 6 7 315
Total 100 836.25 750
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 7 12/09/2013
Table 7: Evaluation Results Screen Matrix for table 5
No W
Component 1
Survey Monkey AVG Total
Component 2
Qualtrics AVG Total
R1 R2 R3 R4 R1 R2 R3 R4
1 40 6 6 6 6 6 240 6 6 6 6 6 240
2 25 8 8 7 8 7.75 193.75 8 7 7 6 7 175
3 35 7 7 7 7 7 245 7 7 7 7 7 245
Total 100 678.75 660
4.3 Feasibility Evidence
4.3.1 Level of Service Feasibility
There are no specific LOS requirements, so we should negotiation with our client in the future.
Currently, we just list general LOS.
Table 7: Level of Service Satisfiability Evidence
Level of Service Win Condition Rationale
Response Time: the app response time should
be less than or equal to 2 seconds
Users have no enough patience to wait when
they are going to open a page
Concurrent users: can support a maximum of
200 users
The server is busy and it may be unable to
process users’ requests due to too much
traffic .Users have no enough patience to do
the survey if the app always crushes.
Table 8: Level of Service Implementation Strategy
Level of Service Win Condition Product Satisfaction
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 8 12/09/2013
Product Strategies:
Process Strategies:
Analysis:
4.3.2 Capability Feasibility
Table 9: Capability Feasibility Evidence
Capability Requirement Product Satisfaction
Survey Configuration:
The system is able to
allow the administrators to
define or manage paths,
schools and associations
between paths, schools
and surveys.
Software/Technology used: HTML, JavaScript, Survey Monkey,
MySQL, Apache
Feasibility Evidence: We can use JavaScript and HTML to develop
a web user interface for the administrators to create a survey, to
view the results and to save data into database.
Referred use case diagram: UC-1
Survey Import: The
system can allow
administrators to import
survey created in Survey
Monkey.
Software/Technology used: Survey Monkey, HTML, JavaScript,
MySQL, Godaddy Server
Feasibility Evidence: The team development can use Survey
Monkey API to create a survey. And then the administrators could
import questions and answers to create a complete survey.
Referred use case diagram:UC-2
Survey Database: The
system is able to store the
survey definitions and
survey results.
Software/Technology used: MySQL, Survey Monkey, Godaddy
Server
Feasibility Evidence: after creating the survey definitions, the
developers could store the survey definitions in the Godaddy Server.
Referred use case diagram: UC-2
Survey Completion: The
android app is able to
allow users to take survey
and submit their survey
results.
Software/Technology used: Titanium, Apache, MySQL
Feasibility Evidence: The mobile first downloads data from
database, and then finishes the survey. Before it submits the result,
the data will be stored in the mobile. After submission, the data will
be transferred to server and stored into database. Most functions in
mobile can be implemented by calling Titanium API.
Referred use case diagram: UC-1, UC-2
Survey Export: The
system can export survey
results as csv files.
Software/Technology used: Survey Monkey, HTML, JavaScript,
MySQL, Godaddy Server, PHP
Feasibility Evidence: the survey result will be exported as csv files
on the website by using PHP and JavaScript.
Referred use case diagram: UC-1, UC-2
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 9 12/09/2013
4.3.3 Evolutionary Feasibility
Table 10: Evolutionary Feasibility Evidence
There were no Evolutionary Win Condition specified in win- win negotiations
Evolutionary Win Condition Rationale
Add a win condition: “As an admin, I can
view results of surveys so that I can
identify and publish problems”
During our winwin negotiation, we mainly focus
on mobile app functions. We paid very little
attention on result display. So there’s no win
condition in survey results display. It is a big
mistake. We need to do further discussion with our
client about this feature.
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 10 12/09/2013
5. Business Case Analysis
Table 11: Program Model
Assumptions
1. Community is willing and able to adopt electronic surveys.
2.Survey will improve the health of community well-being
Stakeholders Initiatives Value Propositions
Beneficiaries
Clients
Residents
Volunteers
Developers
Maintainer
Develop new HKZ
Survey App
Promote the app
Provide training for
taking survey
process
Develop partnership
with agencies such
LAUSD, LADOR
Save time and
money(print survey
docs) for all to do
the survey
Increase geospatial
accuracy of
collected data
around schools
Increase survey
participation
Increase efficiency
in fixing
environment
problems
performing to
specific locations
Increase survey
adaption by other
agencies
Residents
Local schools
External agencies
Cost
Survey Monkey
Godaddy Server
Benefits
Survey Questionnaire Issuing
Collection and arrangement information
from surveys
Communities security improvement
Increase of new functionality
5.1 Cost Analysis
The current budget of clients is zero. Thus, all costs for clients include system development,
transition, operations, and maintenance is non-monetary, which means only time spent costs.
And also, development team costs are zero.
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 11 12/09/2013
5.1.1 Personnel Costs
All costs for clients include system development, transition, operations, and maintenance is non-
monetary, which means only time spent costs. And also, development team costs are zero. Since
one of the client representatives left the company, there will be two client representatives
presenting in the following Architecture Review Boards.
Table 12: Personnel Costs
Healthy Kids Zone
Activities Time Spent (Hours)
Development Period (24 weeks)
Valuation and Foundation Phases: Time Invested (CS577a, 10 weeks)
Client: negotiation with team representatives[2hrs * 1time * 2people] 4
Client Representatives: win-win negotiation[2.5hrs/week*2 weeks * 3 people, meeting via email, phone, and other channels [1hrs/week * 8 weeks * 3people + 1hrs/week *2 weeks * 2people]
43
Architecture Review Boards FCR_ARB [1.5hrs * 1 time * 3people] 4.5
Architecture Review Boards DCR_ARB[1.5hrs * 1 time * 2people] 3
Total (one time cost) 54.5
Development and Operation Phases: Time Invested (CS577b, 14 weeks)
Client Representatives: Meeting via email, phone, and other channels [1.5hrs/week * 14 weeks * 2 people]
42
Architecture Review Boards and Core Capability Drive-through session [1.5hrs * 3 times * 2 people]
9
Deployment of system in operation phase and training
- Installation & Deployment [ 3hrs * 1 time* 2 people]
- Training & Support [4 hrs * 2 times * 2 people]
22
Total (one time cost) 73
Maintenance period (semiannual year)
Backup Database [1.5hrs * 6 times] 9
Bug fixation [4hrs*3 times] 12
Update app to adapt to the Updating of the Android platform
[8hrs*1times]
8
Total (annual cost) 29
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 12 12/09/2013
5.1.2 Hardware and Software Costs
Since the clients have already bought and will pay for Survey Monkey per year for building
survey questionnaire. Besides they have purchased Godaddy Server. No additional budget is
required.
Table 13: Hardware and Software Costs
Type Cost Rationale
Development cost
Hardware- Server 0 The client already has a server to store data.
Besides, no budget is provided. So no cost is
required there
Titanium 0 Free & Open-source Cross-platform
Development framework
Apache webserver 0 The Apache webserver is available for free
download
MySQL 0 MySQL is open source database
Mobile Phone 0 Some of the development team members have
Mobile phones using Androids system
Google Maps 0 Google map is free to use.
Survey Monkey 200 per
year
The clients will pay for this per year.
Godaddy Server 180.30 The clients have paid for this.
Operation cost
Hardware- Server 0 The development machine can be used as a
operation machine, no cost is required there
Titanium 0 Free & Open-source Cross-platform
Development framework
Apache webserver 0 The Apache webserver is available for free
download
MySQL 0 MySQL is open source database
Google Maps 0 Google map is free to use.
5.2 Benefit Analysis
In benefit analysis, non-financial benefits are included. These contain reduced operating costs
and increase of new functionality.
Non-monetary benefits:
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 13 12/09/2013
Reduce operating costs of issuing survey questionnaire: Using the app, the volunteers would not
send paper-survey to users and only need time to advertise app to let the users do survey through
this app.
Collection and arrangement information from surveys: Administrator can obtain all survey data
easily from database after users do surveys and upload to the database, which save a lot of time.
Communities’ security improvement: According to the survey data collections and analysis,
residents including kids can know HKZ ratings about their communities and communities can
advocate for a policy change in order to improve security.
Obtain additional useful information from surveys (photos about streets): Administrator can
obtain photos about streets taken by users to analysis the situation/environment of communities.
Table 14: Benefits of Healthy Kids Zone survey APP
Reduced operating costs % Reduce Time Saved (Hours/Year)
Survey Questionnaire Issuing
Volunteers can spend less time on issuing
survey questionnaire and waiting
surveyed residents for finishing the
survey.
(8mins*1000questionnaires=8000mins)
80 107
Collection and arrangement information from surveys
Administrators can save a lot of time for
collecting survey data and directly extract
survey data from database. Besides, they can
save money for not printing paper survey
questionnaire.
(9hrs*26times=234 hours)
85 199
Communities security improvement
According to the survey data collections and
analysis, residents including kids can know
HKZ ratings about their communities and
communities can advocate for a policy
change in order to improve security.
(3hrs*12times= 36hrs)
50 18
Total 324
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 14 12/09/2013
Increase of new functionality rationale
Obtain additional useful information
from surveys(photos about streets)
Administrator can obtain photos about streets
taken by users to analysis the
situation/environment of communities
5.3 ROI Analysis
Table 15: ROI Analysis
Year Cost Benefit
(Effort Saved)
Cumulative
Cost
Cumulative
Benefit ROI
2013.12 54.5 0 54.5 0 -1.00
2014.6 73 0 127.5 0 -1.00
2014.12 29 162 156.5 162 0.04
2015.6 30.2 162 186.7 324 0.74
2015.12 31.4 162 218.1 486 1.23
2016.6 32.7 162 250.8 628 1.50
In the ROI analysis, we only calculate time cost and benefit.
From the above table, the first row and second row (2013.12 and 2014.6) refers to the
development period and has no benefit. 54.5 and 73 hours is invested into the system and it is
considered as one-time cost. In the next four rows: 2014.12, 2015.6, 2015.12 and 2016.6, they
are considered to be in an maintenance period and require some personnel costs in terms of hours
needed to maintain the system. For semiannual cost, assume 4% increase semiannually
considering the possible increase of the times of backing up database, updating Android platform
updating or the increase of numbers of bugs.
The cost pays off will be in the second half of 2014.
Figure 1: ROI Analysis Graph
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 15 12/09/2013
-1.5
-1
-0.5
0
0.5
1
1.5
2
2013.12 2014.6 2014.12 2015.6 2015.12 2016.6
ROI
ROI
Feasibility Evidence Description Version3.2
FED_DCP_F13a_T14_V3.2.doc 16 12/09/2013
6. Conclusion and Recommendations
C1: The results of the NDI evaluation show that Survey Monkey is a good tool for building surveys.
Qualtrics is also available, but it cannot export survey results in CSV format well.
R1: Use Survey Monkey as a tool for building surveys.