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

[email protected]

Chenglu Wang Feasibility Analyst [email protected]

Junjun Ji Prototyper [email protected]

Ye Tao Life Cycle Planner [email protected]

mailto:[email protected]











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


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


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


FED_DCP_F13a_T14_V3.2.doc v 12/09/2013

Table of Figures

Figure 1: ROI Analysis Graph .................................................................................................................................... 14


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


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.


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.


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.


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


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


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


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


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 winwin 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.


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.


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


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:


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


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


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


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.

Feasibility Rationale Description (FRD) · FED_DCP_F13a_T14_V3.2.doc ii 12/09/2013 Version History...

Documents

Transcript of Feasibility Rationale Description (FRD) · FED_DCP_F13a_T14_V3.2.doc ii 12/09/2013 Version History...