feasibility rationale description (frd) · web viewthis document indicates both completeness and...

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


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


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


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


Table of FiguresFigure 1: ROI Analysis Graph........................................................................................................................................5

Figure 2 : Volunteer Tracking System Structure..........................................................................................................11

document.doc vi Version Date: 05/16/2008


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


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



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.



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



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.



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


http://jakarta.apache.org/jmeter/index.html


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.



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/


http://sourceforge.net/projects/repgen/


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


http://greenbay.usc.edu/csci577/fall2006/projects/team3/FD/index.html

http://greenbay.usc.edu/csci577/spring2008/site/coursenotes/ec/charts/EC26=LifeCycleManagement.ppt


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.



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.



6.2 System StructureFigure 2: Volunteer Tracking System Structure

More information can be found in SSAD.



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.


feasibility rationale description (frd) · web viewthis document indicates both completeness and...

Documents