Feasibility Evidence Description (FED)Version 2.1
Feasibility Evidence Description (FED)
United Direct Marketing
Team 9
Chun-Ling Chen – Project manager/ Prototyper
Chun-Pei Su – Lifecycle Planner
Shao-yen Cheng – System Architect
Yuan-Chang Chang – Feasibility Analyst
Stewart Allen – IIV&V/ Requirements Engineer
Yen-Kuo Kao – Operational Concept Engineer
October 22, 2012
Version History
Date / Author / Version / Changes made / Rationale10/03/12 / Yuan Chang Chang / 1.0 /
- Update section 5:Risk Assessment
- Identify the risks and mitigation plans
10/04/12 / Shao Yen Cheng / 1.1 /
- Correct information on header and footer sections.
- Delete legacy information from the template file and correct version numbers.
10/09/12 / Yuan Chang Chang / 1.2 /
- Update section 5:Risk
Add contents in section 1 /
- Correct reported errors and vague points in risk assessment section and add new contents in section 1
10/22/12 / Yuan Chang Chang / 2.0 /
- Add contents in section 2,3,4
- Add business case study, capability feasibility and evaluate the best developing process,
10/22/12 / Shao Yen Cheng / 2.1 /
- Section 1.2, footer and header.
- Update the document status and correct typos.
Table of Contents
Feasibility Evidence Description (FED)
Version History
Table of Contents
Table of Tables
Table of Figures
1. Introduction
1.1Purpose of the FED Document
1.2Status of the FED Document
2. Business Case Analysis
2.1Cost Analysis
2.2Benefit Analysis
2.3ROI Analysis
3. Architecture Feasibility
3.1Level of Service Feasibility
3.2Capability Feasibility
3.3Evolutionary Feasibility
4. Process Feasibility
5. Risk Assessment
6. NDI/NCS Interoperability Analysis
6.1Introduction
6.2Evaluation Summary
Table of Tables
Table 1: Personnel Costs
Table 2: Hardware and Software Costs
Table 3: Benefits of UDI System
Table 4: ROI Analysis
Table 5: Level of Service Feasibility
Table 6: Capability Requirements and Their Feasibility Evidence
Table 7: Rationales for Selecting Architected Agile Model
Table 8: Risk Assessment
Table 9: NDI Products Listing
Table 10: NDI Evaluation
FED_FCP_F12a_T09_V2.1.doc1
Feasibility Evidence Description (FED)Version 2.1
Table of Figures
Figure 1: ROI Analysis Graph
FED_FCP_F12a_T09_V2.1.doc1
Feasibility Evidence Description (FED)Version 2.1
1.Introduction
1.1Purpose of the FED Document
This document is to analyzethe feasibility of this project. In section 2, we provide business case study including analysis of cost, benefit, and ROI to evaluate its market value, so that we can decide whether it is worth to make it or not. In section 3 and 4,we go into the analysis of thelevel of service, capability, evolutionary and process. It evaluates the feasibility of the functions that we would implement and helpus prioritize the implementing order.In section 5, we provide risk assessment, listing the potential risk, rank and mitigating plan.In the last section, we list the NDIs and NCSs that we might use in this project and briefly describe its use. FED document is a report for us to evaluate the risk of the whole project. We can adjust our developing plan in advance according to it, assuring its success.
1.2Status of the FED Document
This document is a part of Draft FC package. Sections 1-5 are completed.
2.Business Case Analysis
2.1Cost Analysis
2.1.1Personnel Costs
Table 1: Personnel Costs
Activities / Time Spent (Hours) / $ Equivalent ($35/hour)Development Period (24 weeks)
Valuation and Foundations Phases: Time Invested (CS577a, 12 weeks)
Client: Time spent to discuss with the developing team via email, phone, and other channels
[3 hrs/week * 12 weeks *1 person] / 36 / $1260
WinWin negotiation session
[1.5 hrs * 2 times *1 person] / 3 / $105
Architecture Review Boards
[2 hrs * 2 times * 1 person] / 4 / $140
Development and Operation Phases: Time Invested (CS577b, 12 weeks)
Client: Meeting via email, phone, and other channels [2 hrs/week * 12 weeks * 1 person] / 24 / $840
Architecture Review Boards and Core Capability Drive-through session
[1.5 hrs * 3 times * 1 person] / 4.5 / $157.5
Deployment of system in operation phase
[6 hrs * 2 times * 1 person] / 12 / $420
Training & Support
[5 hrs * 2 times * 1 person] / 10 / $350
Total / 93.5 / $3272.5
Maintenance Period (1 year)
Maintenance [2 hrs/week * 52 weeks * 1 person] / 104 / $3640
Total / 104 / $3640
2.1.2Hardware and Software Costs
Table 2: Hardware and Software Costs
Development phaseType / Cost / Rationale
Software –Notepad++ / 0 / Free software
Software –Aptana / 0 / Free software
Hardware – Web Host / 0 / In developing process, developing team would build everything on USC server which is free.
Operation phase
Type / Cost / Rationale
Hardware – Web Hosting / $60/year / The client needs to apply a web host for this website. Usually the fee is less than $5/month.
Hardware – Web Domain name / $10/year / To apply and keep a domain name for a website comes with a fee.
2.2Benefit Analysis
Following table summarizes the benefits in terms of number of hours of work saved mainly through automation of activities. Note that the values used are yet to be confirmed by the clients. Thus there will be changes after incorporating client's input.
Table 3: Benefits of UDI System
Current activities & resources used / % Reduce / Time Saved (Hours/Year) / $ Equivalent ($35/hour)It would be easier to change the content of the website dynamically
(4hr/month) / 80% / 38.4 / 1344
Reduce the effort to trace clients’ latest requests. The system will notify the ownerif there is a change in requests.
(0.5hr/time*12times/month) / 90% / 64.8 / 2268
Reduce the time to provide produce detailed information through E-mail. The website would generate a template dedicated to each client to view their product related information.
(owner: 1.5hr/product * 5products/month) / 70% / 63 / 2208
Total / 166.2 / 5817
2.3ROI Analysis
The following table shows the cost and the benefit in the following 5 years. We can see that our client would achieve positive balance from 2014.
Cost(developing) : personnel cost = 3272.5
Cost(operation) : maintenance cost + hardware software cost = 3710
Benefit : benefit analysis = 5817
Table 4: ROI Analysis
Year / Cost / Benefit(Effort Saved) / Cumulative Cost / Cumulative Benefit / ROI
2012 / 3272.5 / 0 / 3272.5 / 0 / -1.000
2013 / 3710 / 5817 / 6982.5 / 5817 / -0.167
2014 / 3710 / 5817 / 10692.5 / 11634 / 0.088
2015 / 3710 / 5817 / 14402.5 / 17451 / 0.212
2016 / 3710 / 5817 / 18112.5 / 23268 / 0.285
Figure 1: ROI Analysis Graph
3.Architecture Feasibility
3.1Level of Service Feasibility
Table 5: Level of Service Feasibility
Level of Service Requirement / Product SatisfactionLOS-1: Compatible to the browsers used by the majority of users. / Product Strategies: Focus on the major browsers that users in this domain use to view the website.
Process Strategies: Use as much as cross-template programming language as possible. Test this project on the major browsers.
Analysis: The major browsers used by users in this domain are chrome, IE8 and IE9. Our team has related experience on these browsers.
3.2Capability Feasibility
Table 6: Capability Requirements and Their Feasibility Evidence
Capability Requirement / Product SatisfactionUC-1: User Login / Software/Technology used: HTML, Javascript, PHP, SQL
Feasibility Evidence: Store the account and password in the database in advance. Every time users try to login, validate them with the stored information.
Referred use case diagram: SSAD Process Diagram
UC-2:User Logout / Software/Technology used: HTML, Javascript, PHP
Feasibility Evidence: We can use session to record user’s login state. To logout, just mark the session state to logout.
Referred use case diagram: SSAD Process Diagram
UC-3:Create marketing director account / Software/Technology used: HTML, Javascript, PHP, SQL
Feasibility Evidence: Use SQL statement “insert into” to add an account.
Referred use case diagram: SSAD Process Diagram:
UC-4:Delete marketing director account / Software/Technology used: HTML, Javascript, PHP, SQL
Feasibility Evidence: Use SQL statement “delete” to delete an account.
Referred use case diagram: SSAD Process Diagram
UC-5:View marketing director accounts / Software/Technology used: HTML, Javascript, PHP, SQL
Feasibility Evidence: Use SQL statement “select * from tablename” to view director accounts in table.
Referred use case diagram: SSAD Process Diagram
UC-6:Create micro website / Software/Technology used: HTML, Javascript, PHP, SQL
Feasibility Evidence: Use SQL statement to retrieve the related user information and show it in HTML.
Referred use case diagram: SSAD Process Diagram
UC-7:Edit Micro Website / Software/Technology used: HTML, Javascript, PHP, SQL
Feasibility Evidence: Use SQL statement “update” to edit the data stored in the database.
Referred use case diagram: SSAD Process Diagram
UC-8:Delete Micro Website / Software/Technology used: HTML, Javascript, PHP, SQL
Feasibility Evidence: Use SQL statement “delete” to delete the data stored in the database.
Referred use case diagram: SSAD Process Diagram
UC-9:List Micro Websites and hit rates / Software/Technology used: HTML, Javascript, PHP, SQL
Feasibility Evidence: Retrieve users’ information in the database and show them as a list of micro websites. Furthermore, to implement the hit counter, we leave a column in table to store this information which would increase each time when users click on the button linking to their own micro website.
Referred use case diagram: SSAD Process Diagram
UC-10:View micro website / Software/Technology used: HTML, Javascript, PHP, SQL
Feasibility Evidence: Retrieve user information from the database and show them in micro website form.
Referred use case diagram: SSAD Process Diagram
UC-11:Viewing a package illustration on a micro website / Software/Technology used: HTML, Javascript, PHP, SQL
Feasibility Evidence: Upload the proposal to the database and relate it to the corresponding micro website.
Referred use case diagram: SSAD Process Diagram
UC-12:Viewing case studies on a micro website / Software/Technology used: HTML, Javascript, PHP, SQL
Feasibility Evidence: Upload the case studies to the database and relate them to the corresponding micro website.
Referred use case diagram: SSAD Process Diagram
UC-13:Email micro website link / Software/Technology used: Email, HTML, Javascript
Feasibility Evidence:Create a button to send the e-mail containing the micro website link.
Referred use case diagram: SSAD Process Diagram
UC-14:Edit website content / Software/Technology used: HTML, Javascript, PHP, SQL
Feasibility Evidence:Store website content in the database, which makes it editable by administrator.
Referred use case diagram: SSAD Process Diagram
UC-15:Attaching files to the website content / Software/Technology used: HTML, Javascript, PHP, SQL
Feasibility Evidence: Create a uploading section for administrator to upload their files, and bind these files to the place they want to put..
Referred use case diagram: SSAD Process Diagram
UC-16:View proposal / Software/Technology used: HTML
Feasibility Evidence: Incorporating the proposal link into the micro website.
Referred use case diagram: SSAD Process Diagram
UC-17:Comment proposal / Software/Technology used: HTML, Javascript, PHP, SQL
Feasibility Evidence: Build proposal table in the database to manage the files and leave a column to store the comments relating to it.
Referred use case diagram: SSAD Process Diagram
UC-18:Sign an electronic signature on a proposal / Software/Technology used:RSA
Feasibility Evidence: Users generate their own private key to sign theirproposals and give their public key to the website to validate their signature.
Referred use case diagram: SSAD Process Diagram
UC-19:Confirm electronic signature / Software/Technology used: RSA
Feasibility Evidence: The website manages users’ public key. When users’ upload their files to the website, the website validate their signature with the public key.
Referred use case diagram: SSAD Process Diagram
UC-21:Search thecontent of the website / Software/Technology used: HTML, Javascript, PHP, SQL
Feasibility Evidence: We can create a table to store all the website content. When we do search, we can just search this table.
Referred use case diagram: SSAD Process Diagram
3.3Evolutionary Feasibility
There is no evolutionary requirement as of new.
4.Process Feasibility
From the process evaluation website, the most suitable process for this project would be architected Agile.
Importance Rating Scale: How importance is this criteria for this project?
1 (Low), 2 (Medium) and 3 (High)
Criteria Rating Scale: How likely the given criteria fits the project?
0 (Very Low),1 (Low),2 (Medium),3 (High) and 4 (Very High)
Table 7: Rationales for Selecting Architected Agile Model
Criteria / Rationales30 % of NDI/NCS features / This project will be built from the scratch, we may not use too many of NDI.
Single NDI/NCS / The client asks for lots of interface design and functions for the website, using a single UDI doesn’t match our need on this project.
Unique/ inflexible business process / The business process is not unique.
Need control over upgrade / maintenance / It must be a website to have complete administrative interface, assuring our client is able to maintain it by herself in the future.
Rapid deployment / The website and the information on it should be deployed rapidly, assuring its customers are able to receive latest information.
Critical on compatibility / It should be a cross template website, its customers may use different browser to surf the website.
Internet connection independence / It should not be an independence internet. Its customers come from all over the world.
Need high level of services / performance / It is not specified but better performance can gain better clients’ experience.
Need high security / Need electronic signature mechanism. It involves several security issue.
Asynchronous communication / It doesn’t need a real time communication function.
Be accessed from anywhere / Its customers come from all over the world.
Critical on mass schedule constraints / It is not specified, but expected to be finished in two semesters.
Lack of personnel capability / It’s a small company with only several personnel.
Require little upfront costs / Its budget is very limited, so has to be built with minimal cost.
Require low total cost of ownership / The maintaining cost of ownership should be as cheap as possible.
Not-so-powerful local machines / Local machines are basic laptops/desktops.
The architected agile process has only three non-conforming points, which is lower than any others. It would be better to follow architected agile process.
5.Risk Assessment
Table 8: Risk Assessment
Risks / Risk Exposure / Risk MitigationsPotential Magnitude / Probability Loss / Risk Exposure
The information and materials that client actually wants us to put on website or integrate into the system is not clear. It may cause some major modification later. / 8 / 9 / 72 / Use prototypes to get as much information as possible.
No one in group can do interface design, so its aesthetic facet may not satisfy the client. / 7 / 8 / 56 / Talk to client and try to find an interface designer.
4 of our members may not take 577b next semester / 7 / 8 / 56 / Build from the top priority and document all details and requirements of this project, making sure the people taking over this project next semester would not have much difficulty to continue.
Because the client is still finding other solutions, project scope is likely to be changed in the future. / 8 / 6 / 48 / Keep negotiating with client and start from other doable parts.
Having no knowledge about electronic signature and it may incur legal issues. / 5 / 8 / 40 / Seek an existing electronic signature service to avoid the legal issue.
Lack of knowledge of the host the client’s system currently built on. Time spent on learning may delay the schedule. / 8 / 4 / 32 / Negotiate with the client and get this information as soon as possible so that team members can start early.
The client may not spend extra money to subscribe online electronic signature service. / 3 / 6 / 18 / Either persuade the client to use it or adjust the project scope.
6.NDI/NCS Interoperability Analysis
6.1Introduction
6.1.1COTS / GOTS / ROTS / Open Source / NCS
Table 9: NDI Products Listing
NDI/NCS Products / Purposes6.1.2Connectors
6.1.3Legacy System
6.2Evaluation Summary
Table 10: NDI Evaluation
NDI / Usages / CommentsFED_FCP_F12a_T09_V2.1.doc1