Feasibility Rationale Description (FRD) - University of ... · Web viewThe document indicates the...

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 Changed in ROI section 2.3 Better version to present in ARB

10/22/06 RK, Deepak Pandey

1.2 Changed in Process feasibility 4.0

Added section 6.1,6.2,6.5 Worked upon risk assessment

section 5.0

To present in LCO package

10/23/06 RK, DP 1.3 Added section 6.1,6.2,6.5 To present in LCO package

10/24/06 RK 1.4 Changed some grammar error in 2.1.2

After IV&V evaluation

11/05/06 RK 1.5 Changed some errors in Section 3.0

After IV&V evaluation

11/19/06 RK 2.0 Done section 6.3,6.4 Added more evaluation in

section 6.5

To present in LCA Draft

12/01/06 RK 2.1 Change in Risk Assessment Change in benefit analysis Change in ROI

To present in ARB

12/03/06 RK 2.2 Changed in 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.


Date Author Version Changes made Rationale04/01/07 PD 7.0 Update section 1.1, 5 Update status of document to

be construction phase04/30/07 ID 8.0 Update section 1.1,1.2, 1,3, 3

and 4 Session 1.1, change status of

document Session 1.2, change reference

document version Session1.3, change document-

change summary Session 3 in table 4, take out

CR5-award tracking and CR2-Gernerating certification out of core capability list.

Session 4, update risks.05/16/08 Itti

Charoenthongtrakul

9.0 Remove section 1.2 Reference

Remove section 1.3 Change Summary

Add section 1.1 Purpose of the FED Document

Added 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

To comply with ICM guidelines


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


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


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 and evidence that the requirements presented in various artifacts is feasible to be developed in the delivered system.

The document indicates the 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 fact that 2 of the team members did not continue on the project to CS577b

class 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 and moved from the core to add-on capabilities in order to satisfy the schedule.

Also, the addition of team 0 and the integration with teams 1 and 2, the project schedule was delayed and additional requirement (the person information management module) was added.

More details on the COCOMO size estimation are described in the LCP document.


2. Business Case Analysis2.1 Cost Analysis

There is no monetary budget for the project. As the client would 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 which would be required. In other words, the development team will either be using free COTS products or products available as open sources or which 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 term of time resources that the clients spent. Those include the period that the client representatives spent during the 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 & 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 CCD session [1.5 hrs * 3 times * 2 people] 9Deployment 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 set of system.

Special Note: To demonstrate this section of the document, an example of hardware and software costs is shown below. It is not related to the project.

The following table describes the hardware and software costs 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 the current system, significant amount of human resources are required to complete

the process. The following table describes the benefits gained in the form of time 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 value 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 help increase the convenience 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, 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 optimization.Process Strategies:Performance Analysis, Prototyping, Simulation, Load testing.

Analysis:For desired level, 100% of system service uptime excluding network and server downtimeFor accepted level, 95% of system service uptime excluding network and server downtimeTesting tool1 is used to test the availability of the system by continuously requesting the system functions for a period of time and mark down for any unsuccessful response.

LOS-2: Query correctness Product Strategies:Data verification for all data entry function.Process Strategies:Follow testing strategy and test cases to ensure quality of product.Analysis:Correctness of data only includes data from function executions and excluding 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 Exploitation.Process Strategies:Benchmarking, Modeling, Performance Analysis, Prototyping, Simulation.Analysis:Less than 1 second for page advancing and 10 second for report generation (not over 1,000 rows of data) based on intranet environment and up to 3 sec for searching feature (not over 1000 volunteer records), under 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 is developed with modular and layer design for future evolutions, integration testing.Process Strategies:Interface change control, Interoperation Involvement, Specification Verification, Prototyping.Analysis:System should be implemented up to that level that it can integrate with the products from team 1 and team 2.

1 Apache JMeter, http://jakarta.apache.org/jmeter/index.html

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


System should be modular in design so that can adapt other application.

LOS-7: Concurrent user Product Strategies:Scoping, Domain Architecture driven, Optimization (Code/ Algorithm), Platform-feature Exploitation.Process Strategies:Benchmarking, Modeling, Performance Analysis, Prototyping, Simulation, Load testing.Analysis:System should be able to handle requests from 30 concurrent users with no more than 25% of the increased 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 application2. CR-2: Track volunteer clock in/ out hours3. CR-3: Track working hours4. CR-4: Track communication5. CR-5: Submit job requests6. CR-6: Schedule volunteers7. CR-7: View volunteer profile8. CR-8: Edit volunteer profile9. CR-9: Manage person 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 to 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 the future requirement the does not require any other

knowledge that the development team already have.4. ER-4: Generate Certificates - This is the future requirement the does not require any

other knowledge that the development team already have.


5. ER-5: Generate reports - With many free tools to generate report and PDF documents such as PHP Report Generator2, it is possible to be done.

6. ER-6: Upgradeable – Although COTS products are being used, they are very well-known and somehow 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.

4. Process FeasibilityFrom the choices of cases provided in the process decision tables, this project will be

using the case#3, Architected Agile, with the plan-driven elements. The following describe the reasons:

- The use of NDI products – numbers of COTS products will be used.- Time/build: 2-4 weeks – this complies with the characteristics of 577a/b class which

recommends the team to come up with lots of builds during the development.- Time/increment: 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 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 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.

2 PHP Report Generator, http://sourceforge.net/projects/repgen/

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

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


5. Risk AssessmentIn this section we determine the risk in the project, actions taken to mitigate them. We

also measure the potential magnitude and probability magnitude 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#0By having to communicate and work with other 2 teams especially 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 concerning the unpredictable problems and the members’ responsibility of 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 work load 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 requirementPerson 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.2.3 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 - Clients 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 - Clients requirementNegative points - No maintenance support

PHP(5.2.0) Server scripting Positive points - Freeware


- Opensource - Fully compatible with MySql - Clients requirement - Widely usedNegative points - No negative points

PHP/MySql Connector Connector Positive points - Freeware - Clients requirement - Widely used and trustworthy for performanceNegative points - No Negative point

AJAX GUI Positive points: - Freeware - Clients 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 in between.

Feasibility Rationale Description (FRD) - University of ... · Web viewThe document indicates the...

Documents

Transcript of Feasibility Rationale Description (FRD) - University of ... · Web viewThe document indicates the...