Rationale Feasibility Description (FRD)
USC CCR Web Application
Team 7
Andrew Hart (SSAD, Prototype) Kailash Karol (FRD, SSRD) Skanda Ramesh (LCP, OCD) Sutap Chatterjee (IV&V)
FRD_RLCA_S07b_T07_V3.0
Version Date: 5/2/2007
Feasibility Rationale Description (FRD)
Version no 3.0
Version History
Date 10/10/06 10/16/06 10/22/06 Author Kailash Karol Kailash Karol Kailash Karol Version 1.0 1.1 2.0 Changes made 10/24/06 Kailash Karol 2.1 11/06/06 Kailash Karol 2.2 11/16/06 Kailash Karol 2.3 11/20/06 Kailash Karol 2.4 11/28/06 Kailash Karol 2.5 Initial draft based on LeanMBASE Template version 1.61 Minor changes to remove inconsistency with other doc Added Section 6 Increase LOS requirements in section 3 Update hardware cost in section 2.1.1 Include COCOMO efforts result for process feasibility in section 4 Remove references to SID and include reference to SID link Other minor changes to maintain consistency with other documents Change content of one Monetary benefits Modified one of the risk to give better understanding Change Header and Footer Modified section 6.1 to give better understanding Numbered LOS according to SSRD. Changes made in Header and Footer Changes in LOS to give more consistency with SSRD Added section 6.5 Provide rational for section 6.4 Updated section 5 according to DART tool Corrected versioning inconsistency in references in section 1.2. Updated risk assessment table in section 5 Changes made after on basis of IV & V evaluation of LCO Package Changes made after receiving feedback from Professor, TA and Client in LCA ARB Final LCA Package version of FRD which is also Final deliverable. LCA draft version of FRD for submission Changes made after Comments from TA's in LCO Package. Corrected version after changes on basis of IV & V evaluation of LCO Draft Corrected version after changes on basis of IV & V evaluation of LCO Package. Rationale Initial draft version of FRD for submission as part of LCO draft. To be review in ARB Presentation for LCO part To fulfill exit criterion of LCO milestone To review things and update them to bring more accurate and complete version to be submitted as part of LCO Package To perform changes on basis of IV & V evaluation of LCO Draft
12/03/06
Kailash Karol
2.6
FRD_RLCA_S07b_T07_V3.0
ii
Version Date: 02/01/2007
Feasibility Rationale Description (FRD) Date 02/01/07 Author Kailash Karol Version 3.0 Changes made Remove some of LOS requirements Changes in header, footer and versioning of document Remove calendar and shared repository capability from section 4 Rationale
Version no 3.0
Changes made because of new team infrastructure Team size reduces from 577A, so eliminates some of LOS requirements. RLCA draft version of FRD to be submitted as part of RLCA draft
FRD_RLCA_S07b_T07_V3.0
iii
Version Date: 02/01/2007
Feasibility Rationale Description (FRD)
Version no 3.0
Table of Contents
FEASIBILITY RATIONALE DESCRIPTION (FRD).......................................................... I
....................................................................................................................................................................... i
VERSION HISTORY........................................................................................................ II TABLE OF CONTENTS................................................................................................. IV TABLE OF TABLES....................................................................................................... VI TABLE OF FIGURE...................................................................................................... VII
Introduction.................................................................................................................................................................... 1 Status of the FRD Document................................................................................................................................ 1 References.............................................................................................................................................................2 Business Case Analysis..................................................................................................................................................3 Cost Analysis:....................................................................................................................................................... 3 Benefit Analysis:.................................................................................................................................................. 5 ROI Analysis: ...................................................................................................................................................... 6 Level of Service Feasibility........................................................................................................................................... 7 Process Feasibility......................................................................................................................................................... 9 Risk Assessment.......................................................................................................................................................... 12 Analysis Results........................................................................................................................................................... 13 Introduction.........................................................................................................................................................13 System Structure................................................................................................................................................. 14 COTS, Legacy, Custom Components and Connectors Description................................................................... 15 Component Interaction Evaluation..................................................................................................................... 17 Evaluation Summary.......................................................................................................................................... 17
FRD_RLCA_S07b_T07_V3.0
iv
Version Date: 02/01/2007
Feasibility Rationale Description (FRD)
Version no 3.0
FRD_RLCA_S07b_T07_V3.0
v
Version Date: 02/01/2007
Feasibility Rationale Description (FRD)
Version no 2.6
Table of Tables
TABLE 1: SOFTWARE AND HARDWARE COSTS....................................................... 3 TABLE 2: PERSONNEL COSTS.................................................................................... 4 TABLE 3: ROI ANALYSIS............................................................................................... 6
FRD_LCA_F06a_T07_V2.6
vi
Version Date: 02/01/2007
Feasibility Rationale Description (FRD)
Version no 2.6
Table of Figure
FIGURE 1: BREAK EVEN POINT SUMMARY................................................................ 6 FIGURE 1: BREAK EVEN POINT SUMMARY................................................................ 6
FRD_LCA_F06a_T07_V2.6
vii
Version Date: 02/01/2007
Feasibility Rationale Description (FRD) version 2.1
Version no 3.0
Introduction
This document demonstrates consistency and achievability of RLCA components such as Operational Concept Description (OCD), System and Software Requirements Description (SSRD), System and Software Architecture Description (SSAD), Life Cycle Plan (LCP), and the system's related prototypes and models, both on process level and project level. It justifies needs of USC CCR (Civic and community relations) and ER (External relations) and show feasibility and completeness of our efforts to satisfy all stakeholders. Feasibility Rationale Document will also address the shortfalls in ensuring feasibility and consistency.
Status of the FRD Document
Majority of content in FRD document is according to Easy Win Win negotiation agreement, SSAD, OCD, LCP and SSRD. Initially there was an issue on choice of MS Access or MySQL. Now team decided to use MySQL. Also team decided to use PHP among choice of PHP and ASP.net. We are using DART tool for keeping track of risks. The server supporting the system will be Apache web server running on Solaris platform. ISD will provide web hosting for our application. Also open source COTS product is used to minimize the cost incurred in project. We eliminated calendar component and shared repository component due to new team structure, less number of team member in 577B. The above information regarding our project is up to date with RLCA draft version of FRD.
FRD_RLCA_S07b_T07_V3.0
1
Version Date: 02/01/2007
Feasibility Rationale Description (FRD) version 2.1
Version no 3.0
References
Lean MBASE Template for FRD version 1.6 http://greenbay.usc.edu/csci577/fall2006/site/guidelines/LeanMBASEtemplates/LeanMB ASE_v1.61_templates_for_FRD.doc Support Information Document version 2.8 for team 7 http://greenbay.usc.edu/csci577/fall2006/projects/team7/LCO/SID_LCA_F06a_T07_V2. 8.doc Updated Easy WinWin Report Version 1.5 of team 07 http://greenbay.usc.edu/csci577/fall2006/projects/team7/LCA/EWW_LCA_F06a_T07_V 1.5.doc SSRD document version 3.0 of team 07 http://greenbay.usc.edu/csci577/fall2006/projects/team7/LCO/SSRD_LCA_F06a_T07_V 2.6.doc OCD document version 3.0 of team 07 http://greenbay.usc.edu/csci577/fall2006/projects/team7/LCO/OCD_LCA_F06a_T07_V3 .0.doc SSAD document version 2.6 of team 07 http://greenbay.usc.edu/csci577/fall2006/projects/team7/LCO/SSAD_LCA_F06a_T07_V 2.6.doc LCP document version 1.6 of team 07 http://greenbay.usc.edu/csci577/fall2006/projects/team7/LCO/LCP_LCA_F06a_T07_V1. 6.doc
FRD_RLCA_S07b_T07_V3.0
2
Version Date: 02/01/2007
Feasibility Rationale Description (FRD) version 2.1
Version no 3.0
Business Case Analysis
The business case analysis describes the impact of operational and development cost on involved stakeholders of the system. It also explains the added value generated by the proposed system. One of the success criterions of any system is that whether it can return financial investment on it. In essence, we calculate return on investment or ROI for our system.
Cost Analysis:
Cost includes hardware, software and personnel cost. Personnel cost includes time invested by clients and users and may also include salary of any person responsible for maintenance. It is important to know that developer team costs are zero.
Software and Hardware Costs:
This includes software and hardware cost. Table below give brief description about software and hardware cost involved in our project
Table 1: Software and Hardware Costs
Type Software cost for Dreamweaver Version 8 Software cost for MySQL Hardware cost for space on Web server for hosting system
Cost $250 Free $370
PHP-Integrated Development Environment
Free
Rationale CCR needs to buy Dreamweaver during maintenance of system. It is one-time cost. MySQL is used in development of system and may require in maintenance phase. It is open source. It is a web-based application and CCR will not buy web server but use the one provided by USC. Therefore need to pay the hosting fee. This is recurring cost and hence $370/year will be spent. Open source Development tool which is also free
FRD_RLCA_S07b_T07_V3.0
3
Version Date: 02/01/2007
Feasibility Rationale Description (FRD) version 2.1
Version no 3.0
Personnel Costs:
Personnel Cost includes time and effort spent by client, users and other non-developer stakeholders. It also includes personnel cost in maintenance phase.
Table 2: Personnel Costs
Activity Inception & Elaboration Phase Time spent by CCR representative (include meeting, Email, phone and other communication time)- 3hrs/week x 12 weeks Time spent by ER representative (include meeting, Email, phone and other communication time)- 3hrs/week x12 weeks Time spent by program representative (include meeting, Email, phone and other communication time)- 15 min./week x 12 weeks Architecture Review Board Win-Win negotiations Construction & Transition Phase Time spent by CCR representative (include meeting, Email, phone and other communication time)- 2hrs/week x 12 weeks Time spent by ER representative (include meeting, Email, phone and other communication time)- 2hrs/week x 12 weeks Time spent by program representative (include meeting, Email, phone and other communication time)- 10 min./week x 12 weeks Architecture Review Board Win-Win negotiations Deployment of system in transition phase Training in transition phase Total(Development) Maintenance(per year) 2hrs/week x 52 weeks
Time spent 36 hours 36 hours 3 hours
6 hours 6 hours 24 hours 24 hours 2 hours
6 hours 6 hours 6 hours 10 hours 165 hours 104 hours
Note: - CCR and ER have their own technical person which is presently working with them. This person will be responsible for maintenance of the system. So they really do not need to hire any full-time worker just to spend 2hrs/week in maintenance. The Person they already have will invest 2hrs/week in maintenance.
FRD_RLCA_S07b_T07_V3.0
4
Version Date: 02/01/2007
Feasibility Rationale Description (FRD) version 2.1
Version no 3.0
After discussing with client about number of hours spent by client and wages receive by client we estimated that salary of CCR, ER and program personnel is approximately $35/hour (for each of them). Therefore total personnel cost incurred during development of project is $35 x 165 = $5,775 During discussion with client we also discussed about salary of the person who will be responsible to maintain the system. This person will get approximately $20/hour. Therefore total personnel cost incurred during maintenance of project is $20 x 104 = $2,080/year
Benefit Analysis:
The system would benefit the client and other user in following ways: First of all there is a monetary benefit. This is saving of money (and also saving of time because time and money are directly proportional to each other). With current manual system both CCR and ER are together spending 150 hours/year. The new proposed system will reduce time spent by factor of 1/3. So with the new web based application they need to spend only 50 hours per year. So actually they are saving 150-50 =100 hours/year. Therefore the time saved by CCR and ER personnel = 100 hours/year Similarly each program representative is spending 40 hours/year. In total, there are 29 programs. Therefore the time spent by all program representatives with current manual system is 40 x 29 = 1160 hours/year. With new web based system they need to spend only half of the time they are spending now. So program representatives will only spend 1160/2 = 580 hours/year with new system. Therefore time saves by program personnel = 580 hours/year So total time saves by new web based system is 100 + 580 = 680 hours/year As we estimated that $35/hour is the salary for each of them, therefore total saving in terms of money will be $35 x 680 = $23,800/year. Automate calculation of reports (such as interim). Users such as program directors can pulled out data whenever they need therefore the new system will provide ability to program directors to know about amount and kind of resources available at any time. Allow better utilization of resources Avoid overhead of maintaining manual records. Everything will be stored on the web. Enhances the reputation of CCR and ER. More and more students able to know about programs and therefore possibility of increase in number of volunteers that are applying.
FRD_RLCA_S07b_T07_V3.0
5
Version Date: 02/01/2007
Feasibility Rationale Description (FRD) version 2.1
Version no 3.0
ROI Analysis:
Assuming that 10% increase is there in both maintenance cost and benefits.
Table 3: ROI Analysis
OP- Year 06-07 OP- Year 07-08 Effort Expended 5775 2700 Saved Effort 0 23800 Net Effort Expended 5775 0 Net Effort Saved 0 21100 Cum. Net Cost C 5775 5775 Cum. Net Benefit B 0 21100 ROI = Cum (B-C)/C -1 2.65 (All figures in graph except ROI are money in $)
OP-Year 08-09 2970 26180 0 23210 5775 44310 6.66
OP-Year 09-10 3267 28798 0 25531 5775 69841 11.08
The graph shown below illustrate break-event point summary as defined in terms of ROI and years.
12 11.08 10 8 ROI 6 4 2 0 -2 OP- Year-1 06-07 OP- Year 07-08 OP- Year 08-09 OP- Year 09-10 2.65 6.66 Series1
Years
Figure 1: Break Even Point Summary Break Even Point Analysis: - It is clear from the chart that break-even point is somewhere in middle of first year. As we are assuming 10% increase in both benefits and maintenance cost therefore ROI is increasing with higher rate. The above chart shows four year analysis of ROI
FRD_RLCA_S07b_T07_V3.0
6
Version Date: 02/01/2007
Feasibility Rationale Description (FRD) version 2.1
Version no 3.0
Level of Service Feasibility
Level of services requirements specified in section 5 of SSRD is justified by analysis and reference to prototype and models. Table below summarizes all major level of services as defined in SSRD with their analysis and references
Table 4: Level of Service Feasibility
Level of Service LS-1 : Integrity - The system maintenance should be easy. Furthermore, any code changes should be relatively easy to incorporate. This shall create a system that is accurate and has a high level of integrity. LS-2 : Interoperability The system should be able to work well with other 3rd party software and systems
Product Satisfaction Product Strategies: Generality, Modularity Process Strategies: Maintainers and User Involvement Analysis: Modular architecture of system in which each component is doing specific task helps to understand the system and to make changes in the system easier. References: Easy Win Win negotiation Agreement WC-42 and WC-25, SSRD Section 5 LOS-1 Product Strategies: Modularity, Interface Specification Process Strategies: Interoperator Involvement, Specification Verification Analysis: System has modular architecture. There is not any tool involvement which required constraint for environment. Interfaces are well defined. In this way our system will easily work with other software such as MS Excel. References: Easy Win Win negotiation Agreement WC-456, SSRD Section 5 LOS-2 Product Strategies: Error reducing User Input/output, User-tailorability, UI consistency, Navigation, UI flexibility Process Strategies: User Interface tools, User Involvement, User Engineering Analysis: The system is prototyping to provide user friendly interface. Navigation between pages is easy and understandable. During prototyping we consider to maintain consistency and completeness throughout the project. References: Easy Win Win negotiation Agreement WC-12, SSRD Section 5 LOS-3
LS-3 : Usability - Any user with any amount of technical expertise should be able to easily use the system.
FRD_RLCA_S07b_T07_V3.0
7
Version Date: 02/01/2007
Feasibility Rationale Description (FRD) version 2.1
Version no 3.0
LS-4 : Atomicity - The system allows users to perform all needed actions through the use of the application in an atomic manner.
Product Strategies: User Input/Output, UI consistency Process Strategies: Prototyping, User Involvement Analysis: If there will be two actions on same set of record simultaneously then system will discard them and return to last saved state. It then prompt user to take the action again after some specified fraction of time. References: Easy Win Win negotiation Agreement WC-43, SSRD Section 5 LOS -4 Product Strategies: User-tailorability, Modularity , Layering, Understandability, Process Strategies: Maintainers & User Involvement, Prototyping, Benchmarking Analysis: Since this project may run for long period of time, so new capabilities may add to the system. The code will be easy to understand and certain things are taken from available open source code. New features can be incorporated without changing significant amount of existing code. Existing code is enough flexible to handle new features. References: Easy Win Win negotiation Agreement WC-458, SSRD Section 5 LOS-5
LS-5 : Adaptability - The system should be able to incorporate new features without major reconstruction.
FRD_RLCA_S07b_T07_V3.0
8
Version Date: 02/01/2007
Feasibility Rationale Description (FRD) version 2.1
Version no 3.0
Process Feasibility
This section defines the choice of process model used to develop system. Table below define value of process driver with the explanation and chosen value and thus giving rational for the choice of process model.
Table 5: Process Driver Analysis
Process Driver Growth Envelope
Criticality Medium
Understanding of Low Requirements Medium
Robustness
Medium
Available Technology Architecture Understanding
None LowMedium
Explanation The growth of our system in terms of size of data, capabilities and functionality is not much. We estimated that number of programs can increase by at most 3-4 per year. Also system capabilities will more or less remain same except few more features can add to it. Hence entire growth envelop is taken as high. For our team this project is a new experience. There is no existing project similar to us in terms of capabilities. For our client also this project is like a learning phase of requirements. Therefore understanding of requirements is Low to medium as we have limited knowledge of domain. Our system is not critical as far as loss due to impact of defects is concerned. The client requirement is to have backup in case of loss of data. Also all the transactions must be atomic means either transactions to be take place either fully or none. No partial transactions should be there. It prevents inconsistency in data. Our project is not using COTS or any other available reusable component to develop the system or part of the system. Therefore it is taken as none. As developer team knowledge of domain is not much and most of developers are at CMM Level 1 therefore understanding of architecture is Low to Medium. Therefore our team is paying more stress on interaction with client so that we can have more understanding of requirement and can get a more clear idea of architecture of proposed system.
FRD_RLCA_S07b_T07_V3.0
9
Version Date: 02/01/2007
Feasibility Rationale Description (FRD) version 2.1
Version no 3.0
Table 6: Process Model Decision Table
Objectives, Constraints Growth Understanding of Envelope Requirements Medium Low-medium
Robustness Medium
Alternatives Available technology None
Model Architecture Understanding Low-Medium Spiral
Figure 2: Win Win Spiral Model
This Win Win spiral model is described in a paper "Using Win Win Spiral model-A Case Study" by Dr. Barry Boehm, Alexander Egyed and Ray Madachy. The Reference link is: http://sunset.usc.edu/publications/TECHRPTS/1998/usccse98-512/usccse98-512.pdf Also we need to identify capabilities offered by developing system taking OCD as reference. Then we require to priorities those capabilities as High, Medium or Low. Table below defines capabilities with their description and priority.
FRD_RLCA_S07b_T07_V3.0
10
Version Date: 02/01/2007
Feasibility Rationale Description (FRD) version 2.1 Table 7: Capability priority
Version no 3.0
Capability Data collection and Analysis
Description Each of the 29 programs will be able to submit their semester report online and have access to prior reports. Other basic information such as ethnic breakdown, age group breakdown, and gender breakdown of participants; funding spent; and survey results can also be stored for later access. The clients have access to all submitted data and reports..
Priority
High
Also, because the project is tightly constrained to 24 student weeks across two semesters and there is no budget to speak of, the spiral model allows for high priority component to be developed during each increment, allowing for low priority components to wait until the end. If time runs out without every desired requirement completed, the spiral model's incremental development will ensure that the high priority items (entering bugs, viewing) are completed and only low priority items get left behind. The schedule is demonstrated to be feasible in the LCP document. The LCP shows assumptions made and then how those assumptions about project size translated to effort & schedule in the COCOMO II tool
FRD_RLCA_S07b_T07_V3.0
11
Version Date: 02/01/2007
Feasibility Rationale Description (FRD) version 2.1
Version no 3.0
Risk Assessment
In risk assessment we identify risks, priorities them and analyze them. I have defined current risks that we are facing in our project. With future progress, it may happen that few of these risks will be eliminate and new risks arise. Also their priority may change with time therefore this table may change in future versions. Initially there are many risks involved in the project. However we able to resolve majority of risks that we faced during 577A. At this point of time when we are at LCA Package phase, only three potential risks are left which are described in table below. Also define are their mitigation plan so as to handle each of them successfully.
Table 8: Risk Assessment
Ran k
Risk Item
1 Project is too large. . There are many features and it is difficult to implement all of them in given 577B schedule. Only 3 of 7team members from 577A continue in 577B 2 Open source code .n Integration Problem. Open source code may fail to coordinate...