View
194
Download
1
Category
Tags:
Preview:
Citation preview
Feasibility Rationale Description (FRD)
California Science Center Volunteer Tracking System
Team #3
Phongphan Danphitsanuphan Project Manager
Charlie Lormanometee Project Coordinator / QA
Deepak Pandey System Analyst / Tester
Pongtip Aroonvatanaporn Software Architect / Programmer
Natachart Laoteppitak Software Architect / Programmer
Amit Shah Quality Focal Point Personnel
Jeremy Stoller Client
Vincent Tsan Maintainer
April 27, 2007
FRD_ABS_S07b_T03_V8.0.doc Version Date: 4/27/07
Feasibility Rationale Description (FRD) Version no 8.0
Version History
Date 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 Ritesh Kothari
1.1 Changed in ROI section 2.3 Better version to present in ARB
10/22/06 RK, DP 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 PD/CL 6.0 Update session 1.2, 3 Update according to updated OCD and SSRD
01/15/07 Phongphan 6.2 Update session 1.2, 2, 3, 5.3. Update according to OCD, Risk management tool.
04/01/07 Phongphan 7.0 Update session 1.1, 5 Update status of document to be construction phase
04/30/07 Phongphan 8.0 Update session 1.1,1.2, 1,3, 3 and 4
Session 1.1, change status of document
FRD_ABS_S07b_T03_V8.0.doc ii Version Date: 4/27/2007
Feasibility Rationale Description (FRD) Version no 8.0
Date Author Version Changes made Rationale
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.
FRD_ABS_S07b_T03_V8.0.doc iii Version Date: 4/27/2007
Feasibility Rationale Description (FRD) Version no 8.0
Table of ContentsFEASIBILITY RATIONALE DESCRIPTION (FRD).......................................................................I
VERSION HISTORY......................................................................................................................II
TABLE OF CONTENTS...............................................................................................................IV
TABLE OF TABLES.....................................................................................................................V
TABLE OF FIGURES..................................................................................................................VI
1. Introduction............................................................................................................................................................................1
1.1 Status of the FRD Document.........................................................................................................................................1
1.2 References.....................................................................................................................................................................1
1.3 RLCA Change Summary...............................................................................................................................................2
1.4 Business Case Analysis.................................................................................................................................................3
1.5 Cost Analysis:................................................................................................................................................................3
1.6 Benefit Analysis:...........................................................................................................................................................5
1.7 ROI Analysis:................................................................................................................................................................5
2. Level of Service Feasibility....................................................................................................................................................6
3. Process Feasibility..................................................................................................................................................................9
4. Risk Assessment...................................................................................................................................................................12
5. Analysis Results...................................................................................................................................................................12
5.1 Introduction.................................................................................................................................................................13
5.2 System Structure..........................................................................................................................................................14
5.3 COTS, Legacy, Custom Components and Connectors Description............................................................................14
5.4 Component Interaction Evaluation..............................................................................................................................21
6.5 Evaluation Summary.............................................................................................................................................23
FRD_ABS_S07b_T03_V8.0.doc iv Version Date: 4/27/2007
Feasibility Rationale Description (FRD) Version 8.0
Table of TablesTable 1: Personnel Costs................................................................................................................................................4
Table 2 : ROI Analysis....................................................................................................................................................5
Table 3: Level of Service Feasibility..............................................................................................................................6
Table 4: Requirement prioritization (must have only)....................................................................................................9
Table 5: Critical Process Drivers.................................................................................................................................10
Table 6: Risk Assessment..............................................................................................................................................12
Table 7: MySQL Database Management System Component Description..................................................................14
Table 8 : Web Server: Apache web server 2.2.3..........................................................................................................15
Table 9 : PHP 5.2.0......................................................................................................................................................17
Table 10 : GUI - Ajax Framework................................................................................................................................18
Table 11 : MYSQL Connector/PHP..............................................................................................................................19
Table 12 : Symphony PHP Framework........................................................................................................................20
Table 13 : Test Table for a test of the interaction of MySQL-PHP Connector, and MySQL database........................22
Table 14 : COTS Evaluation.........................................................................................................................................23
FRD_ABS_S07b_T03_V8.0.doc v Version Date: 4/13/2023
Feasibility Rationale Description (FRD) Version 8.0
Table of FiguresFigure 1: ROI Analysis Graph........................................................................................................................................6
Figure 2: Win Win Spiral Model..................................................................................................................................10
Figure 4 : Volunteer Tracking System Structure..........................................................................................................14
Figure 5 : Interaction Testing Diagram.........................................................................................................................22
FRD_ABS_S07b_T03_V8.0.doc vi Version Date: 4/13/2023
Feasibility Rationale Description (FRD) version 8.0
1. Introduction
1.1 Status of the FRD Document
Current state of this document is IOC#2. All FRD issues have been resolved yet such as development framework leading to precisely software size estimation
1.2 References
LeanMBASE Guidelines version 1.7 http://greenbay.usc.edu/csci577/spring2007/site/guidelines/LeanMBASE_Guidelines_V1.7.pdf
LeanMBASE Version 1.0 Templates for FRD http://greenbay.usc.edu/csci577/spring2007/site/guidelines/LeanMBASEtemplates/LeanMBASE_v1.0_templates_for_FRD.doc
Win-Win Negotiation Report version 2.0http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCO/EWW_LCO_F06a_T03_V2.0.doc
Operational Concept Description (OCD) for LCA version 7.0http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCA/OCD_LCA_S07b_T03_V7.0.doc
System and Software Requirements Definition (SSRD) version 7.0http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCA/SSRD_LCA_S07b_T03_V7.0.doc
System and Software Architecture Description (SSAD) for LCA version 7.0 http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCA/SSAD_LCA_F06_T03_v7.0.doc
Life Cycle Plan (LCP) for LCA version 7.0http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCA/LCP_LCA_F06a_T03_V7.0.doc
FRD_ABS_S07b_T03_V8.0.doc 1 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
1.3 IOC#2 Change Summary1) Session 1.1, change status of document 2) Session 1.2, change reference document version3) Session1.3, change document-change summary4) Session 3 in table 4, take out CR5-award tracking and CR2-Gernerating certification out of
core capability list.5) Session 4, update risks.
FRD_ABS_S07b_T03_V8.0.doc 2 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
1.4 Business Case Analysis
1.5 Cost Analysis:
The overall monetary budget for the project would be $0. As the client would not be spending any money for the development of the project as the system is being developed by a team of students as 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 source or which are already being used in the client’s organization. It has been decided that client would not be spend any money on hardware as there would be no extra hardware required for the deployment of the system.
1.5.1 Personnel Costs:
The effort spent by the development team does not account for the personnel costs incurred during development of the project. The effort spent by the client would be personnel costs in terms of time which representatives would spend during the development of the project and the maintainer of the system would spend once the system is deployed by the client. Client has already appointed the Web engineer, who will be maintaining the client’s web based applications.
Project conditions and assumption, 1.) No investment on hard ware because we can use legacy hard ware system.2.) We assume that cost/person is equal for every role so we will find ROI based on
number of hours3.) For operational period, 1 semester 12 weeks
FRD_ABS_S07b_T03_V8.0.doc 3 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
Cost = number of hours
Table 1: Personnel Costs
Inception and Elaboration Time Invested (CS577a, 12 weeks)
Time spent by client (include meeting, Email, phone and other communication time)- 3hrs/week x12 weeks 36 hours
2 Client representative (include meeting, Email, phone and other communication time) ~2hrs/week x 12 week
24 hours
Time spent on Architecture Review Board6 hours
Total (Inception and Elaboration Time) 66 Hours
Construction and Transition Time Invested (CS577b, 12weeks)
Time spent by client (include meeting, Email, phone and other communication time)- 5hrs/week x12 weeks
24 Hours
Maintainer (include meeting, Email, phone and other communication time) ~8hrs/12 week
96 Hours
Architecture Review Board x 2 people 18 Hours
Deployment of system in transition phase + training50 Hours
Total (Construction/Transition Time) 197 Hours156 Hours Maintenances (per year) 3hr x 52 weeks
Grand total , Investment time (Without maintenance time) 263 Hours
We did not discuss the salary of the client and their representatives. So, their investment of time will use hour’s unit and will be calculated as it is.
FRD_ABS_S07b_T03_V8.0.doc 4 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
1.6 Benefit Analysis:
Currently, California Science Center spends 1 volunteer administrator (full time, 40 hours / week (2080 hours/year) to handle volunteer tracking process and generated reports to concerned department. Also, each department spends about 1 hour / week for request volunteer to do jobs and doing some administrative work. There are 7 departments i.e. 7 x 1 x 52 = (~364 hours / year). However, California Science Center hired new technician to maintain this project with estimated of his 3 hours per week (~36 hours/12weeks).
We believe that new volunteer tracking system can reduce the time factor by 50% of operation time of volunteer administrator work load (as he has to do no manual input of volunteers information) so it will be = (2080/3) x .5 = 1040 and reduce 50% operation time of user from each department = (182 hours/ year).
Total time saved by new web based system = 1040+ 182 = 1222 hours/ year
1.7 ROI Analysis:
Table 2 : ROI Analysis
First year Second year Third year Forth year
Effort Expended 263 156 171 188Effort Saved 0 1222 1222 1222Cum. Net Cost C 263 419 590 778Cum. Net Benefit B 0 1222 2444 3666ROI = Cum (B-C)/C -1 1.91647 3.14237 3.71208
The following table summarizes the various costs incurred and benefits realized by the client at the end of each year. Assuming 10% increase in maintenance cost because as per the client web engineer’s salary will increase 10% every year. Other than that 10% increase in benefit every year because California Science Center tracks record indicates 10% increase in number of employers.
FRD_ABS_S07b_T03_V8.0.doc 5 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
Figure 1: ROI Analysis Graph
Break Even Point Analysis: - It is clear from the chart that break-even point is somewhere in later of the first year.
2. Level of Service FeasibilityTable 3: Level of Service Feasibility
Level of Service Product SatisfactionLOS-1:Reliability of software system (availability)
Product Strategies: System load and stress testing, code optimization.
Process Strategies:Performance Analysis, Prototyping, Simulation
Analysis:For desired level, 100% software system uptime in 1 month period. For Acceptable level, 100% software system uptime in 1 week period.References: SSRD Section 5.0, WinWin report V2, OCD Section 3.0
LOS-2: Correctness of data storage and retrieval by system
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.
FRD_ABS_S07b_T03_V8.0.doc 6 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
References: SSRD Section 5.0, WinWin report V2, OCD Section 3.0
LOS-3:Performance1: Response time for page advancing
Product Strategies:Scoping, Domain Architecture driven, Optimization (Code/ Algorithm), Platform-feature ExploitationProcess Strategies:Benchmarking, Modeling, Performance Analysis, Prototyping, SimulationAnalysis: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 networkReferences: SSRD Section 5.0, Win Win Negotiations Win -57 , OCD Section 3.0
LOS-4:Performance2: Response time for report generation
Product Strategies:Scoping, Domain Architecture driven, Optimization (Code/ Algorithm), Platform-feature ExploitationProcess Strategies:Benchmarking, Modeling, Performance Analysis, Prototyping, SimulationAnalysis:Report generation (not over 1,000 rows of data) based on intranet environment and up to 5 sec and up to 10 sec report that have over 1000 rows under 10 concurrent users.References: SSRD Section 5., WinWin report V2, OCD section 3.0
LOS-5:Performance3:Response time for database searching
Product Strategies:Scoping, Domain Architecture driven, Optimization (Code/ Algorithm), Platform-feature ExploitationProcess Strategies:Benchmarking, Modeling, Performance Analysis, Prototyping, SimulationUp to 3 sec for database searching feature fewer than 10 concurrent users.
References: SSRD Section 5., WinWin report V2, OCD section 3.0
FRD_ABS_S07b_T03_V8.0.doc 7 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
LOS-6:Interoperability
Integration with other applications
Product Strategies:System is developed with modular and layer design for future evolutions.
Process Strategies:Interface change control, Interoperation Involvement, Specification Verification, PrototypingAnalysis:
System should be implemented up to that level that it can integrate with team 1 and team 2.
System should be modular in design so that can adapt other application. Therefore it necessary to that all the application should be developed under same version .i.e. version specification References: WinWin report V2, SSRD Section .5.0, OCD section 3.0
FRD_ABS_S07b_T03_V8.0.doc 8 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
3. Process Feasibility
This section will show that how our process model fits into our project and satisfies all the requirements. The system’s priorities can be traced to the Easy Win-Win negotiations. We can follow the requirements from SSRD sec 2,3,4,5.
In SAIV the 12- or 24–week schedule drives development of a set of (top priority) core capabilities. We are following schedule as Independent Variable (SAIV) strategy since time is one of the major factors in this project. We have prioritized our requirement as in the table given below, so the high priority requirement will be given highest priority in development.
Table 4: Requirement prioritization (must have only)
REQUIREMENT REFERENCE PRIORITYSystem can facilitate and process volunteer applications submitted online.
CR-1 1
Authorization and Authentication CR-2 2Track volunteer hours and performance CR-3 3
Generate reports CR-6 5Use California Science center’s existing template
IR-1 6
Future maintenance by CSC LSR-2 7Communication Tracking CR-4 8Job requests CR-8 9
Our choice of the Win-Win Spiral process model is appropriate for the system characteristics because it provides for incremental development, which is useful in a project where the client has IKIWISI effects. We have and will continue to develop several versions of prototypes, which will first give the client a look and feel of the system and will overcome the IKIWISI phenomenon. Subsequent prototypes and the incremental development of the actual system will allow more functional aspects to become apparent.
FRD_ABS_S07b_T03_V8.0.doc 9 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
Table 5: Critical Process Drivers
Growth Envelope:• The growth envelope for this project is medium. This is because the growth of capabilities and requirements is predicted as neither too much nor too low.
Understanding of Requirements:• The level of understanding of requirements among the developing team is medium. This is a learning experience for the team.
Robustness:• The robustness of the project is medium. This is a simple project of volunteer tracking. There is not a high demand for any application of it.
Available Technology:• No available technology
Architecture Understanding:• The development team’s architectural understanding is medium. This is due to the developers’ average understanding of the problem domain .The customer maintains constant communication with the developers, which assists in the developers’ understanding of the system.
Figure 2: Win Win Spiral Model
FRD_ABS_S07b_T03_V8.0.doc 10 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
Project is tightly constrained to 24 weeks i.e. two semesters. There is no budget as it is an academic project. In these condition spiral model allows to develop the components 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 are completed and only low priority items get left behind.
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. So, no developer is assigned more than 2 tasks. The team divides the roles evenly as shown below. These divisions were set up so that each person can both contribute at all times, but also not be over-burdened:
Management of team, Operational concept: Phongphan Danphitsanuphan Operational concept, Life Cycle Plan: Charlie Lormanometee Architecture of system, Operational Concept: Natachart Laoteppitak Requirements, feasibility: Phongphan Danphitsanuphan Prototyping, Requirements: Deepak Pandey Test plan and cases: Phongphan and Deepak Prototyping, UML expertise, review of documentation: Pongtip Aroonvatanaporn
Effort and schedule feasibility:-
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.
FRD_ABS_S07b_T03_V8.0.doc 11 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
4. Risk Assessment
In this section we determine the risk in the project, actions taken to mitigate them. We will also measure the potential magnitude and Probability magnitude of loss if risk is exposed.
Table 6: Risk Assessment
RISK-01: Keep a waiting for modules from team 1 and team 2 to be integrated
Description: Keep a waiting for modules from team 1 to be integrated
Risk Exposure:Potential Magnitude = 9Probability Loss = 9R.E.= 81
Risk Mitigation: Talk with Ed Colbert to postpone project deadline.
RISK-02: Time constraint
Description: Development team don't have time to code because they have to take 2 final exams in during final weeks
Risk Exposure:Potential Magnitude = 8Probability Loss = 10R.E.=80
Risk Mitigation:
5. Analysis Results
FRD_ABS_S07b_T03_V8.0.doc 12 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
5.1 Introduction
The new system will provide for several advantages over the current system. New proposed different applications integrated will save good amount of time from doing back and forth between the two systems. The applications are web based, which includes intranet and internet. Through this volunteers will be able to register them self and fill up their information by themselves, so HR Manager’s work is reduced.
5.1.1 Definitions
COTS products: COTS products can be defined as those components of theproject development which are not mainly developed by the developers and are acquired if needed modified and are customized according to the product needs.These are the examples of COTS product used in this project:• Database server MySQL (5.0),• Apache web server (version 2.2.3)• Pear (Liveuser 0.16.12, MDB2 2.3.0)- It is just to make PHP better. It will be used with
PHP.• AJAX framework (Scriptaculous 1.6.5)• Symphony framework for PHP
Connectors: connectors are the software’s which are developed by thedevelopers or acquired from third party vendors mainly used to connect the various COTS product and product developed also its serves a kind of channel used for data transfer or controlling rules regarding using the productSome of the examples of connectors used in this project are:• MYSQL Connector/PHP
Legacy system: Legacy system can be defined as those system which werepart of the old system hardware or software and will be used in new product which will help in reducing the cost of the project.In this project we are developing new software to track volunteer performance, so there is no legacy system which will be used in this project. YES , CSC is using a software called red ridge. We as a developer only take data from that and we will enter in our new system. WE are not taking anything else or making our software on top of that.
FRD_ABS_S07b_T03_V8.0.doc 13 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
5.2 System Structure
Figure 3 : Volunteer Tracking System Structure
5.3 COTS, Legacy, Custom Components and Connectors Description
Table 7: MySQL Database Management System Component Description
Name MySQL Database Management System
Version 5.0
Function Storage and retrieval of data
Granularity & Packaging Independently executing package
Type Component
Inputs MySQL queries transmitted via PHP
FRD_ABS_S07b_T03_V8.0.doc 14 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
Outputs Record Set depending upon the programming language and connection driver used
Binding Topologically Dynamic Binding
Information flow Asynchronous and Synchronous
Software Dependencies No known dependencies
Hardware Dependencies No known dependencies
Target Platform Windows NT, 2000,XP,2003 Server Linux, Unix, OSX
Architecture Style Client-Server
Non Functional
Requirements
Response Time: Query response within 3 seconds for 1000 records
Data Security: Only authorized users should be able to access the data in
the DBMS
Known Issues No known issues
Table 8 : Web Server: Apache web server 2.2.3
Name Apache web server
Version 2.2.3
Function Web Server
Granularity & Packaging Independently executing package
Type Component
Inputs Requests send by URL
Outputs Pages as in requested
FRD_ABS_S07b_T03_V8.0.doc 15 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
Binding Dynamic Binding
Information flow Asynchronous and Synchronous
Software Dependencies Depends on OS
Hardware Dependencies Depends on OS
Target Platform Windows NT, 2000,XP,2003 Server Linux, Unix, OSX
Architecture Style Client-Server
Non Functional
Requirements
Response Time: Response for request.Reliability: No session data should be lost
Known Issues No known issues
Table 9 : PHP 5.2.0
Name PHP
Version 5.2.0
Function Business logic ( server scripting)
Granularity & Packaging Independently executing package
Type Component
Inputs Programming instruction/GUI data
Outputs Connectivity with database and GUI data
Binding Dynamic Binding
Information flow Asynchronous and Synchronous
Software Dependencies Not at all
Hardware Dependencies Not at all
FRD_ABS_S07b_T03_V8.0.doc 16 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
Target Platform Windows NT, 2000,XP,2003 Server Linux, Unix, MAC
Architecture Style Object call
Non Functional
RequirementsResponse Time: Response for request.Reliability: No session data should be lost
Known Issues No known issues
Table 10 : GUI - Ajax Framework
Name AJAX framework
Version 1.6.5
Function Graphical user interface
Granularity & Packaging Independently executing package
Type Component
Inputs Data
Outputs No lose of data and no screen change after submitting data
Binding Dynamic Binding
Information flow Asynchronous and Synchronous
Software Dependencies Not at all
Hardware Dependencies Not at all
Target Platform Windows NT, 2000,XP,2003 Server Linux, Unix, OS
Architecture Style Client-Server
Non Functional
FRD_ABS_S07b_T03_V8.0.doc 17 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
Requirements ----------
Known Issues No known issues
Table 11 : MYSQL Connector/PHP
Name MYSQL Connector/PHP
Version 3.1
Function Connects a PHP embedded in HTML to MySQL database
Granularity & Packaging Object library in PHP
Type Connector
Inputs Database information (name, location, username, password) and queries
Outputs Record Set
Binding Mixed (Compile time Dynamic Binding and Runtime Dynamic Binding)
Information flow Synchronous
Software Dependencies On PHP
Hardware Dependencies No known dependencies
Target Platform Windows NT, 2000,XP,2003 Server Linux, Unix, OSX
Architecture Style Object calls
FRD_ABS_S07b_T03_V8.0.doc 18 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
Table 12 : Symphony PHP Framework
Name Symphony
Version
Function Implement the MVC architectural pattern
Granularity & Packaging Object library in PHP, Provide the models, views and controllers folders and procedures for developers to fill in source code
Type Framework
Inputs N/A
Outputs HTML pages
Binding Mixed (Compile time Dynamic Binding and Runtime Dynamic Binding)
Information flow Synchronous
Software Dependencies On PHP, Apache
Hardware Dependencies No
Target Platform Windows NT, 2000,XP,2003 Server Linux, Unix, OSx
Architecture Style MVC pattern
5.4 Component Interaction Evaluation
Component combinations are MY SQL Database My SQL – PHP connector
FRD_ABS_S07b_T03_V8.0.doc 19 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
5.4.1 Interaction testing
Ajax is GUI and Pear is an extra advantage to PHP so diagram shows only main interaction component as the former does not create ant interfere.
Figure 4 : Interaction Testing Diagram
Table 13 : Test Table for a test of the interaction of MySQL-PHP Connector, and MySQL database
Name MySQL-PHP Database Connector, MySQL database
Test Purpose Testing:
To check if PHP business logic can interact with a MySQL database via a
FRD_ABS_S07b_T03_V8.0.doc 20 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
MySQL-PHP connector
To determine the datatypes that can be exchanged.
Test procedure Developed a test code in PHP that creates compile-time static connection to the classes provided by the MySQL-PHP connector. Provided database information to establish connection. Upon successful connection ran a series of insert, select, update and delete queries for data types involving strings, date & time, integer.
Input specifications Dummy date for strings, data & time, integer.
Expected output Data as inserted or updated
Architectural changes made None
Glue ware developed No significant glue ware developed
Test Results The interaction successfully returned and data was updated successfully.
Notes None.
6.5 Evaluation Summary
Table 14 : COTS Evaluation
COTS Usage Comments Apache (version 2.36)
Web Server Positive points : A free software, Widely Used Documentation available
FRD_ABS_S07b_T03_V8.0.doc 21 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
Clients requirement
Negative points:
No negative pointsMYSQL(5.0) Database Positive points:
MYSQL is free one(open source) Ii is Robust and Freeware Suitable for large/Small scale systems. Clients requirement Widely used and trustworthy for performance
Negative points:
No maintenance support,
PHP(5.2.0) Server scripting
Positive points
Open source Combination with MYSQL is very good Clients requirement Widely used Better with pear
Negative points
No negative points
MY SQL /PHP Connector
Connector Positive points: free one(open source) Suitable for PHP/MY SQL Clients requirement Widely used and trustworthy for performance
Negative points:
No Negative point
FRD_ABS_S07b_T03_V8.0.doc 22 Version Date: 4/27/2007
Feasibility Rationale Description (FRD) version 8.0
AJAX
Framework
1.6.5
GUI Positive points: free one(open source) Clients requirement Makes GUI easy to use
Negative points:
Difficult to implement New technology
FRD_ABS_S07b_T03_V8.0.doc 23 Version Date: 4/27/2007
Recommended