Feasibility Evidence Description (FED) Version 9.0
Feasibility Evidence Description (FED)
California Science Center Volunteer Tracking System
Team #3
Phongphan Danphitsanuphan Project Manager
Charlie Lormanometee Project Coordinator / QA
Deepak Pandey System Analyst / Tester
Pongtip Aroonvatanaporn System Architect / Programmer
Natachart Laoteppitak Software Architect / Programmer
Amit Shah Quality Focal Point Personnel
Jeremy Stoller Client
Vincent Tsan Maintainer
May 16, 2008
document.doc i Version Date: 05/16/2008
Feasibility Rationale Description (FRD) Table of Contents
Version HistoryDate Author Version Changes made Rationale
10/11/05 Ritesh Kothari
1.0 Initial Draft for FRD using LeanMBASE v1.0 for FRD
Draft version of FRD for submission as a part of LCO Draft
10/17/05 RK 1.1 Change in section 2.3, ROI Analysis
Better version to present in ARB
10/22/06 RK, Deepak Pandey
1.2 Change in section 4.0, Process Feasibility
Add section 6.1, 6.2, 6.5 Work upon section 5.0, Risk
Assessment
To present in LCO package
10/23/06 RK, DP 1.3 Add section 6.1, 6.2, 6.5 To present in LCO package
10/24/06 RK 1.4 Change some grammar errors in 2.1.2
After IV&V evaluation
11/05/06 RK 1.5 Change some errors in section 3.0
After IV&V evaluation
11/19/06 RK 2.0 Add section 6.3, 6.4 Add more evaluation in
section 6.5
To present in LCA Draft
12/01/06 RK 2.1 Change Risk Assessment Change Benefit analysis Change ROI
To present in ARB
12/03/06 RK 2.2 Change section 6.1, 6.3, 6.4, 6.5
To present in LCA package
02/01/07 Phongphan Danphitsanuphan, Charlie Lormanometee
6.0 Update section 1.2, 3 Update according to updated OCD and SSRD
01/15/07 PD 6.2 Update section 1.2, 2, 3, 5.3 Update according to OCD, Risk Management Tool
04/01/07 PD 7.0 Update section 1.1, 5 Update status of document to Construction phase
04/30/07 ID 8.0 Update section 1.1, 1.2, 1.3, 3 Section 1.1, change status of document.doc ii Version Date: 05/16/2008
Feasibility Rationale Description (FRD) Table of Contents
Date Author Version Changes made Rationale4 document
Section 1.2, change reference document version
Section 1.3, change document-change summary
Section 3 in table 4, take out CR5-award tracking and CR2-Gernerating certification out of core capability list.
Session 4, update risks05/16/08 Itti
Charoenthongtrakul, Pongtip Aroonvatanaporn
9.0 Remove section 1.2, Reference
Remove section 1.3, Change Summary
Add section 1.1, Purpose of the FED Document
Add section 2.1, Tables and H/W, S/W Costs
Add section 3.2, 3.3 Update section 4, Process
Feasibility Update section 6, remove
unnecessary subsections Update section 6.2, system
structure diagram
To comply with LeanICM guidelines
document.doc iii Version Date: 05/16/2008
Feasibility Rationale Description (FRD) Table of Contents
Table of ContentsFEASIBILITY EVIDENCE DESCRIPTION (FED).............................................................I
VERSION HISTORY........................................................................................................ II
TABLE OF CONTENTS................................................................................................. IV
TABLE OF TABLES.......................................................................................................V
TABLE OF FIGURES.....................................................................................................VI
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...........................................................................................................................................3
2.3 ROI Analysis...............................................................................................................................................4
3. Architecture Feasibility.......................................................................................................................................6
3.1 Level of Service Feasibility.........................................................................................................................6
3.2 Capability Feasibility...................................................................................................................................7
3.3 Evolutionary Feasibility...............................................................................................................................7
4. Process Feasibility..............................................................................................................................................8
5. Risk Assessment.................................................................................................................................................9
6. NDI Interoperability Analysis...........................................................................................................................10
6.1 Introduction................................................................................................................................................10
6.2 System Structure........................................................................................................................................11
6.3 Evaluation Summary.................................................................................................................................11
document.doc iv Version Date: 05/16/2008
Feasibility Rationale Description (FRD) Table of Contents
Table of TablesTable 1: Personnel Costs................................................................................................................................................2
Table 2: Hardware and Software Costs – Development................................................................................................3
Table 3: Hardware and Software Costs – Production....................................................................................................3
Table 4 : Benefits of California Science Center System.................................................................................................4
Table 5 : ROI Analysis....................................................................................................................................................4
Table 6: Level of Service Feasibility..............................................................................................................................6
Table 7: Requirement Prioritization (Must Have Only).................................................................................................8
Table 8: Risk Assessment................................................................................................................................................9
Table 9: NDI Products Listing......................................................................................................................................10
Table 10 : NDI Evaluation............................................................................................................................................11
document.doc v Version Date: 05/16/2008
Feasibility Evidence Description (FED) Version 9.0
Table of FiguresFigure 1: ROI Analysis Graph........................................................................................................................................5
Figure 2 : Volunteer Tracking System Structure..........................................................................................................11
document.doc vi Version Date: 05/16/2008
Feasibility Evidence Description (FED) Version 9.0
1. Introduction1.1 Purpose of the FED Document
The purpose of the Feasibility Evidence Description document (FED) is to show evidence that the requirements presented in various artifacts can feasibly be developed in the delivered system.
This document indicates both completeness and consistency between the documents presented throughout the course, in the senses that all the satisfaction of the requirements will result in satisfaction of WinWin agreements and an implementation of the system will satisfy all the product-related requirements. It also demonstrates that the execution of the project will result in the production of the desired system architecture/design within budget and schedule.
1.2 Status of the FED DocumentDue to the facts that two of the team members did not continue on to the CS577b class,
and thus continue to participate in the project, and that we are using the SAIV (Schedule as Independent Variable) strategy, the current version of this document will reflect the capabilities that were reduced together with some that were moved from the core to lower priority capabilities in order to satisfy the expected schedule.
Also, due to the addition of team 0 and its integration with teams 1 and 2, the project schedule was delayed and an additional requirement, the person information management module, was added.
More details on the COCOMO size estimation are in the LCP document.
document.doc 1 Version Date: 05/16/2008
Feasibility Evidence Description (FED) Version 9.0
2. Business Case Analysis2.1 Cost Analysis
There is no monetary budget for the project. The client will not be spending on the development, as the system is being developed by a team of students in an academic project. This budget includes the cost of any software or tools that might be required. In other words, the development team will either be using free COTS products, products available as open source, or products that are already being used in the client’s organization. It has been decided that the client would not spend any money on hardware, as there would be no extra hardware required for the deployment of the system. The software system will be deployed on their existing hardware.
2.1.1 Personnel Costs
The effort spent by the development team is not counted towards the personnel costs. However, there are personnel costs in terms of time resources that the clients spent. Those include the period that the client representatives spent during project development and also the time the client-appointed web engineer would spend on maintaining the system once it is deployed.
The following table describes the approximate personnel costs in the aspect of time spent by the client.
Table 1: Personnel Costs
Activities Time Spent (Hours)Development Period (24 weeks)
Valuation and Foundation Phases: Time Invested (CS577a, 12 weeks)Client: Meeting via email, phone, and other channels [3 hrs/week * 12 weeks] 36Client Representatives: Meeting via email, phone, and other channels [2 hrs/week * 12 weeks]
24
Architecture Review Board [1.5 hrs * 2 times * 2 people] 6Development and Operation Phases: Time Invested (CS577b, 12 weeks)
Client: Meeting via email, phone, and other channels [5 hrs/week * 12 weeks] 24Maintainer: Meeting via email, phone, and other channels [8 hrs/week * 12 weeks]
96
Architecture Review Board and Core Capability Drive-through session [1.5 hrs * 3 times * 2 people]
9
Deployment of system in operation phase and training- Installation & Deployment [5 hrs * 3 times * 2 people]- Training & Support [5 hrs * 2 times * 2 people]
50
Total 245
Maintenance Period (1 year)Maintenance [3 hr/week * 52 weeks] 156Total 156
document.doc 2 Version Date: 05/16/2008
Feasibility Evidence Description (FED) Version 9.0
2.1.2 Hardware and Software Costs
There is no hardware cost since the client will be using their current systems.
Special Note: To demonstrate this section of the document, an example of hardware and software costs is shown below. These are not related to the project.
The following table describes the hardware and software costs that would have been spent during the development period.
Table 2: Hardware and Software Costs – Development
Type Cost RationaleHardware – Web Server $1500 A new machine is needed to act as a web
server for the system.Hardware – Web Hosting $200 Although the CSC already has its own host,
this new system requires additional cost based on the annually hosting fee. Starting from fall 2006, until the end of spring 2007, this is an amount needed to be spent.
Software – Adobe Dreamweaver CS3
$399 Used in developing the system and the team website.
The following table describes the hardware and software costs spent after the development period.
Table 3: Hardware and Software Costs – Production
Type Cost RationaleHardware – Web Server $0 Since the development machine can be used as
a production machine, no cost is required here.Hardware – Web Hosting $200 Although the CSC already has its own host,
this new system still requires additional cost based on the annually hosting fee.
2.2 Benefit AnalysisWith their current system, a significant amount of human resources is required to
complete the process. The following table describes the benefits gained in the form of time that will be saved when the new system is launched.
document.doc 3 Version Date: 05/16/2008
Feasibility Evidence Description (FED) Version 9.0
Table 4: Benefits of California Science Center System
Current activities & resources used % Reduce Time Saved (Hours/Year)Application data entry
- Volunteer coordinator50 applications * 10 mins = 500 mins 90% 7.5
Time sheet data entry- Volunteer coordinator
5 hrs * 52 weeks 90% 234
Job request- Supervisor (7 departments)
7 * 1 hr * 52 weeks 50% 182
- Volunteer coordinator1 hr * 52 weeks 50% 26
Job assignment- Volunteer coordinator
10 hr * 52 weeks 60% 312
Total 761.5
Apart from the tangible benefits in the form of time saved, there are still some intangible benefits that could not be described as countable values. They are as follows:
- The increase of reliability and correctness of the system: Since all of the processes will be automated, human errors that previously might have occurred are now reduced.
- The ability for the volunteer to apply the application online: Not only would it be convenient for the volunteers, this ability also attracts more people to become volunteers due to the easiness of online application.
- The increase of system productivity: Due to the fact that assignments and reports can be done electronically, the supervisor will quickly receive useful information that would help improve the productivity of the system.
2.3 ROI AnalysisThe following table summarizes the various costs incurred and benefits realized by the
client at the end of each year. We assume that there is a 10% increase in maintenance cost based on a 10% yearly increase in web engineers’ salary. So, the 156 hours/year cost will be increased by 10% annually from the third year afterwards.
Table 5: ROI Analysis
Year Cost Benefit(Effort Saved)
Cumulative Cost
Cumulative Benefit ROI
2007 245 0 245 0 -1.002008 156 761.5 401 761.5 0.902009 171 761.5 572 1,523 1.662010 188 761.5 760 2,284.5 2.01
document.doc 4 Version Date: 05/16/2008
Feasibility Evidence Description (FED) Version 9.0
Using the above information, the ROI Analysis Graph can be plotted as follow
Figure 1: ROI Analysis Graph
-1.50
-1.00
-0.50
0.00
0.50
1.00
1.50
2.00
2.50
0 1 2 3 4 5
Year
ROI
With the break-even analysis, it is clear from the chart that break-even point will be in the very beginning of the third year.
document.doc 5 Version Date: 05/16/2008
Feasibility Evidence Description (FED) Version 9.0
3. Architecture Feasibility3.1 Level of Service Feasibility
Table 6: Level of Service Feasibility
Level of Service Requirement Product SatisfactionLOS-1: Availability Product Strategies:
Code optimizationProcess Strategies:Performance Analysis, Prototyping, Simulation, Load testing
Analysis:For desired level, there should be 100% of system service uptime excluding network and server downtime. For accepted level, there should be 95% of system service uptime excluding network and server downtime. Testing tool1 is used to test the availability of the system by continuously requesting the system functions for a period of time and make note of any unsuccessful responses.
LOS-2: Query correctness Product Strategies:Data verification for all data entry functionProcess Strategies:Follow testing strategy and test cases to ensure quality of productAnalysis:Correctness of data only includes data from function executions and excludes correctness of data input by users.
LOS-3: System response time to web browsing
Product Strategies:Scoping, Domain Architecture driven, Optimization (Code/Algorithm), Platform-feature ExploitationProcess Strategies:Benchmarking, Modeling, Performance Analysis, Prototyping, SimulationAnalysis:There should be less than 1 second for page advancing and 10 seconds for report generation (not over 1,000 rows of data) based on intranet environment and up to 3 seconds for searching feature (not over 1000 volunteer records), with fewer than 10 concurrent users. Optimization techniques would ensure that we satisfy this requirement. The system is web-based and will run on the intranet system at CSC, which will speed up the response time for the system with the server and network. Testing tool is used to generate the concurrent requests.
LOS-6: Interoperability Product Strategies:System development with modular and layer design for future evolutions, integration testingProcess Strategies:Interface change control, Interoperation Involvement, Specification Verification, PrototypingAnalysis:System should be implemented up to that level that it can integrate with the products from team 1 and team 2. System should be modular in design so that can adapt other application.
1 Apache JMeter, http://jakarta.apache.org/jmeter/index.html
document.doc 6 Version Date: 05/16/2008
Feasibility Evidence Description (FED) Version 9.0
LOS-7: Concurrent user Product Strategies:Scoping, Domain Architecture driven, Optimization (Code/Algorithm), Platform-feature ExploitationProcess Strategies:Benchmarking, Modeling, Performance Analysis, Prototyping, Simulation, Load testingAnalysis:System should be able to handle requests from 30 concurrent users with no more than 25% increase in response time. Testing tool is used to simulate the concurrence and measure the response times.
3.2 Capability FeasibilityThe following are the system’s capability requirements
1. CR-1: Provide online application
2. CR-2: Track volunteer clock in/out hours
3. CR-3: Track working hours
4. CR-4: Track communication
5. CR-5: Submit job requests
6. CR-6: Schedule volunteers
7. CR-7: View volunteer profile
8. CR-8: Edit volunteer profile
9. CR-9: Manage person’s information
These capabilities will be implemented in a web application using well-known COTS products. With the more details on the above capabilities described in section 4, Process Feasibility, it is feasible to implement all these functions.
3.3 Evolutionary FeasibilityThe following are the system’s capability requirements and the rationales on how they
can be satisfied.
1. ER-1: Provide database backup - MySql provides GUI tools to manage the data and the administrator can use them to backup the data.
2. ER-2: Provide database restore - MySql provides GUI tools to manage the data and the administrator can use them to restore the data.
document.doc 7 Version Date: 05/16/2008
Feasibility Evidence Description (FED) Version 9.0
3. ER-3: Track award - This is a future requirement that does not require any other knowledge than that which the development team already has.
4. ER-4: Generate Certificates - This is a future requirement that does not require any other knowledge than that which the development team already has.
5. ER-5: Generate reports - With many free tools to generate report and PDF documents, such as PHP Report Generator2, it is possible to do.
6. ER-6: Upgradeable – Although COTS products are being used, they are very well-known and proven to support many kinds of upgrades in the future.
7. ER-7: Scalability - Since this is a web application system, upgrading the machine would help scaling up the system capacity.
2 PHP Report Generator, http://sourceforge.net/projects/repgen/
document.doc 8 Version Date: 05/16/2008
Feasibility Evidence Description (FED) Version 9.0
4. Process FeasibilityFrom the choices of cases provided in the process decision tables3, this project will be
using the case #3, Architected Agile, with the plan-driven elements. The following describes the reasons:
- The use of NDI products – a number of COTS products will be used.
- Time/build of 2-4 weeks – this complies with the characteristics of 577a/b class, which recommends that the team come up with lots of builds during the development.
- Time/increment of 2-6 months – this also complies with 577a/b class, which allows the team to incrementally implement the system within 6 months.
- The LeanICM process is used.
- Scheduled artifacts during the entire course act as plan-driven constraints to the team.
The following is the list of prioritized capabilities.
Table 7: Requirement Prioritization (Must Have Only)
Priority Requirements References1 Provide online application CR-12 Track volunteer clock in/out hours CR-23 Track working hours CR-34 Submit job requests CR-55 Manage person’s information CR-9
All the developers are assigned primary and secondary roles for the artifacts to be developed in this project. This can be verified by looking at the LCP document and our MS-Project Plan.
We have used COCOMO tool to estimate effort and schedule for the project development. However, schedule is fixed by course schedules so only way that we can control development is to do project scope management for given project timeframe and human resource. Please see latest COCOMO analysis in recent LCP document, or see the COCOMO estimation and report at http://greenbay.usc.edu/csci577/fall2006/projects/team3/FD/index.html.
3 Jo Ann Lane, Life Cycle Experiences With Large-scale Systems http://greenbay.usc.edu/csci577/spring2008/site/coursenotes/ec/charts/EC26=LifeCycleManagement.ppt
document.doc 9 Version Date: 05/16/2008
Feasibility Evidence Description (FED) Version 9.0
5. Risk AssessmentIn this section, we determine the risks in the project and actions that will be taken to
mitigate them. We also measure the potential magnitude and probability of loss if they are exposed.
Table 8: Risk Assessment
RisksRisk Exposure
Risk MitigationsPotential Magnitude
Probability Loss
Risk Exposure
1. Integration with Team 1 and Team 2, integration of Team 0Having to communicate and work with another two teams, especially with the introduction of Team 0, it is very likely that many problems are going to occur because of the large number of members and the way they communicate.
9 9 81 - Setup a fixed schedule of meeting frequently and try to raise all the problems that most likely to occur.- Help finding solutions together or discuss with the 577 staff.
2. Time constraintDue to the large size of the project, with many required functionalities, the given period of time might not be enough for the development team to cover unpredictable problems and the demands of members’ other classes.
8 10 80 - Build the prototypes frequently.- Descope the requirements and focus on the core capabilities.- Increase the development team effort.
3. Testing environment unavailabilityNot having a development environment available on time will definitely hinder construction.
5 6 30 - Ask the client or the staff and ensure that they could provide a development server by the planned schedule or, in some ways, share with any of their current servers.- Ask the 577 staff to provide a development server.
4. Shortage of timing available from clientHaving to deal with 3 teams, it is hard for the client to give us all the time required concerning the weekly meetings and numbers of review board sessions.
6 5 30 - Assign some Jeremy’s workload to new web-engineer.- Assign other person to be in charge on his role or request for working remotely during out of town period.- Use a teleconference that every stakeholder can join remotely.
4. Addition of requirement(s)Person information management module might be required later by the client.
4 7 28 - Plan the schedule to cover this functionality and if necessary, inform the client that it cannot be done.
Special Notes: In the actual as-built version, this section should be empty because all the risks should be gone. But for the purpose of illustrating the document, risks are shown in this table.
document.doc 10 Version Date: 05/16/2008
Feasibility Evidence Description (FED) Version 9.0
6. NDI Interoperability Analysis 6.1 Introduction
This project involves many usages of NDI (Non-Development Item). The definitions and listings of these products and packages are described in the following sections.
6.1.1 Definitions
6.1.1.1 COTS / GOTS / ROTS / Open Source / Legacy Products
The following are products that are used in the project.
Table 9: NDI Products Listing
NDI Products PurposesMySQL Server 5.0 Database serverApache Web Server 2.3.6 Web serverScriptaculous 1.6.5 AJAX frameworkSymfony 1.0 PHP FrameworkPEAR (Liveuser 0.16.12, MDB2 2.3.0) PHP Extension
6.1.1.2 Connectors
In this project, we use PHP/MySql Connector to enable the PHP web application to retrieve and query data from the database.
6.1.1.3 Legacy System
There is no legacy system used in this project. Although the CSC is using software called Red Ridge, we as a developer, only take data from that system as an input to our system.
document.doc 11 Version Date: 05/16/2008
Feasibility Evidence Description (FED) Version 9.0
6.2 System StructureFigure 2: Volunteer Tracking System Structure
More information can be found in SSAD.
document.doc 12 Version Date: 05/16/2008
Feasibility Evidence Description (FED) Version 9.0
6.3 Evaluation SummaryTable 10: NDI Evaluation
COTS Usages CommentsApache (2.36) Web Server Positive points
- Freeware - Widely used - Documentations available - Client’s requirementNegative points - No negative points
MYSQL (5.0) Database Positive points - Freeware - Robust - Suitable for Large/Small scale systems - Widely used and trustworthy for performance - Client’s requirementNegative points - No maintenance support
PHP(5.2.0) Server scripting Positive points - Freeware - Open source - Fully compatible with MySql - Client’s requirement - Widely usedNegative points - No negative points
PHP/MySql Connector Connector Positive points - Freeware - Client’s requirement - Widely used and trustworthy for performanceNegative points - No negative point
AJAX GUI Positive points: - Freeware - Client’s requirement - Improve usability in GUINegative points - New technology
Special Note: Throughout the semesters, from ACR to DCR to the final phases, choices of NDI products may change due to the better understanding and more information of the system gathered.
document.doc 13 Version Date: 05/16/2008
Top Related