download

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


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


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

http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCA/LCP_LCA_F06a_T03_V7.0.doc

http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCA/LCP_LCA_F06a_T03_V7.0.doc

http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCA/SSAD_LCA_F06_T03_v7.0.doc

http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCA/SSAD_LCA_F06_T03_v7.0.doc

http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCA/SSRD_LCA_S07b_T03_V7.0.doc

http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCA/SSRD_LCA_S07b_T03_V7.0.doc

http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCA/OCD_LCA_S07b_T03_V7.0.doc

http://greenbay.usc.edu/csci577/spring2007/projects/team3/LCA/OCD_LCA_S07b_T03_V7.0.doc

http://greenbay.usc.edu/csci577/fall2006/projects/team3/LCO/EWW_LCO_F06a_T03_V2.0.doc

http://greenbay.usc.edu/csci577/fall2006/projects/team3/LCO/EWW_LCO_F06a_T03_V2.0.doc

http://greenbay.usc.edu/csci577/fall2006/site/guidelines/LeanMBASEtemplates/LeanMBASE_v1.0_templates_for_FRD.doc

http://greenbay.usc.edu/csci577/fall2006/site/guidelines/LeanMBASEtemplates/LeanMBASE_v1.0_templates_for_FRD.doc

http://greenbay.usc.edu/csci577/spring2007/site/guidelines/LeanMBASE_Guidelines_V1.7.pdf


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.



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



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.



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.



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.



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



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



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.



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



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.



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



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.



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



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


Type Component

Inputs Requests send by URL

Outputs Pages as in requested



Binding Dynamic Binding


Software Dependencies Depends on OS

Hardware Dependencies Depends on OS



Non Functional

Requirements

Response Time: Response for request.Reliability: No session data should be lost


Table 9 : PHP 5.2.0

Name PHP

Version 5.2.0

Function Business logic ( server scripting)


Type Component

Inputs Programming instruction/GUI data

Outputs Connectivity with database and GUI data



Software Dependencies Not at all

Hardware Dependencies Not at all



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


Table 10 : GUI - Ajax Framework

Name AJAX framework

Version 1.6.5

Function Graphical user interface


Type Component

Inputs Data

Outputs No lose of data and no screen change after submitting data



Software Dependencies Not at all

Hardware Dependencies Not at all

Target Platform Windows NT, 2000,XP,2003 Server Linux, Unix, OS


Non Functional



Requirements ----------


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


Architecture Style Object calls



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



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



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



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



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


download

Documents

Transcript of download