Feasibility Evidence Description (FED)

PROJECT TITLE LEMA FAMILY ACCOUNTABILITY SYSTEM

TEAM NO#04

TEAM MEMBERS & ROLES

NAME ROLESTeawon Han Project ManagerZhen Huang Feasibility AnalystZiming Wei Operational Concept Engineer

Xiali Ma Life Cycle PlannerYing Yang Life Cycle Planner

Ian Williams Requirements EngineerKimberly Krause IIV&V /

System Requirements Engineer

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

12/04/2011

document.doc ii Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

Version HistoryDate Author Version Changes made Rationale

09/23/11 Zhen Huang 1.0 Original template for use with

LEMA v1.0 Initial draft for use with LEMA

v1.0

09/28/11 Zhen Huang 1.2

Add risks into risk assessment section

Modify the cost analysis

Consistent format Move to Supporting Information

Document

09/30/11 Teawon Han 1.3

Review format of document and update history section.

Update report format by using consistence terms and

expressions.

10/5/11 Zhen Huang 2.1

Update the cost of time and analysis of benefits

Update the risk assessment

The project progress cost and benefits are record in this documents.

10/13/11 Zhen Huang 2.2 Update the session from 2 to 3 To update the architecture

feasibility and calculate the ROI.

10/23/11 Zhen Huang 2.3 Update the ROI and risk

assessment To update the ROI and risk

assessment by the ARB review

11/3/11 Zhen Huang 2.4

Update the ROI and risk assessment , also change the requirement to make them more accurate.

To update the ROI and risk assessment by the PR and clients meeting.

11/20/11 Zhen Huang 3.1

Update the risk assessment and CR feasibility evidence. Requirement Prioritization.

To update the risk assessment and CR feasibility evidence according the new requirements from clients.

12/04/11 Zhen Huang 3.2

Finish the section 6 and update the risk assessment.

The final deliver package required to finish the final section and fix the bugs.

document.doc iii Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

Table of Contents Feasibility Evidence Description (FED).......................................................................................................................iVersion History..............................................................................................................................................................iTable of Contents.........................................................................................................................................................iiiTable of Tables.............................................................................................................................................................ivTable of Figures.............................................................................................................................................................v

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...................................................................................................................................................5

3. Architecture Feasibility.........................................................................................................................................7

3.1 Level of Service Feasibility............................................................................................................................7

3.2 Capability Feasibility.....................................................................................................................................7

3.3 Evolutionary Feasibility...............................................................................................................................10

4. Process Feasibility................................................................................................................................................12

5. Risk Assessment...................................................................................................................................................14

6. NDI Interoperability Analysis............................................................................................................................15

6.1 Introduction..................................................................................................................................................15

6.2 System Structure..........................................................................................................................................16

6.3 Evaluation Summary....................................................................................................................................16

document.doc iv Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

Table of TablesTable 1: Personnel Costs................................................................................................................................................2

Table 2: Hardware and Software Costs..........................................................................................................................3

Table 3: Benefits of LEMA System..................................................................................................................................4

Table 4: ROI Analysis.....................................................................................................................................................5

Table 5: Level of Service Feasibility..............................................................................................................................7

Table 6: Capability Requirements and Their Feasibility Evidence................................................................................7

Table 7: Evolutionary Requirements and Their Feasibility Evidence..........................................................................11

Table 9: Rationales for Selecting Architected Agile Model..........................................................................................12

Table 10: Requirement Prioritization...........................................................................................................................13

Table 11: Risk Assessment............................................................................................................................................14

Table 12: NDI Products Listing....................................................................................................................................15

Table 13: NDI Evaluation.............................................................................................................................................17

document.doc v Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.1

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

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

1. Introduction1.1 Purpose of the FED DocumentThe purpose of the Feasibility Evidence Document is to provide all stakeholders with the necessary evidence to demonstrate the feasibility of developing the LEMA Pilot School Integrated Family Accountability System. Evidence is compiled from a number of sources including the OCD, SSAD, PR and LCP.

1.2 Status of the FED DocumentThe client had a meeting with us. They offered the details about the usability and business flow which would help us to meet to LEMA Pilot School Integrated Family Accountability System requirements. For version 1.0

We had finished the ARB presentation. And I changed some risk assessments for I had made mistakes. I had already redo the benefits and cost part according to the feedback from TA and clients. As a result, I also changed the ROI analysis to make it more accurate.For version 2.3

I changed some risk assessments for some risks no longer exist and I changed the mitigation.The capability requirements also changed for the client meeting had mentioned some new requirements.For version 2.4

Changed some risk assessments for some risks no longer exist and update the risks according to the PR document. Also, I changed the requirement feasibility according to the last version of SSRD document.For version 3.1

Update the risk assessment by the Project Report. In order to finish the section 6 , I use the SSAD document to describe the system structure. Update the ROI part and feasibility evidence part.For version 3.2

document.doc 1 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

2. Business Case Analysis

2.1 Cost AnalysisNOTE: The tables below indicate the cost including the personnel , software and hardware cost for the LEMA system. The cost is analyzed by the feasibility analyst base on the developing conditions.

2.1.1 Personnel Costs

This part will analyze the personnel cost the client spend during the developing period. I use hours to calculate the cost. I also give a brief description to each cost activities.

Table 1: Personnel Costs

Activities Time Spent (Hours)Development Period (12 Weeks)

Exploration, Valuation and Foundation Phases: Time Invested (cs577a, 6 weeks)

Client: Meeting via email, phone, and other channels [5 hrs/week*2 People *12 Weeks]

Client: Extra arranged meeting with developing team:Location / Time&date : Lema school/ 3.5hrs * 1person / 9/21/2011Location / Time&date : Lema school/ 3 hrs * 1 person / 9/22/2011Location / Time&date: Lema school/ 3 hrs * 1person / 10/4/2011 ARB meeting : 2 hrs * 2 person in SSL 10/20/2011

Client: Regular meeting in person with Full Team & Individual [ 10 hrs/week * 2 People * 12 Weeks]

373.5

Architecture Review Board(s) 4Development and Operations Phases: Time Invested (CS577b, 12 weeks)

Client: communication via email, phone and/or other channels 72

document.doc 2 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

[3 hrs/week * 12 weeks * 2 person]Client: Review the development process by meeting.[6 hrs/week * 12 weeks * 2 people]

144

Architecture Review Boards & Core Capability Drive-Through Session [3hrs * 2 times * 2people]

12

Installation & Iterative Deployment of System in Operation Phase[3hrs * 2 times * 2 people]

12

Development Period Total 605.5

The teacher in LEMA school is paid 50$/hr The development cost should be: 605.5hrs * 50$/hr =30275$

2.1.2 Hardware and Software Costs

Identify all hardware and software-related cost from exploration phase to operation phase.

Table 2: Hardware and Software Costs

Type Cost RationaleExpected cost: Ez grade Pro 0 $ Used in the current system ,we could use the

program to analyze the client requirements and generate our prototype.

Expected cost: School Max 0 $ Used in the current systemPossible Expected cost: Server 0 $ The hardware may be used in the desired

system , but the client mentioned that the server will not include in the project

Possible expected cost: text service , Mozeo text service

460$/year The text service may be used in sending the student performance reports to the parents.

Expected cost: Email service 0$ The email service may be used in sending the student performance reports to the parents.

2.2 Benefit AnalysisNOTE: The numbers in the table below were based on the analysis of Huang Zhen, the Feasibility analyst of developing team. Also, we use the winwin negotiation book to analyze the benefits. All the benefits are base on clients description.

Table 3: Benefits of LEMA System

Current activities & resources used % Reduce Time Saved (Hours/Year)

document.doc 3 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

There is no function to send student performance report to the parents and students in old system. Teacher have to send the report to parents by themselves. But now they can save time by the new system.Personnel Staff (using current system)20 person *3 min /report * 1 reports * 180 days/year = 10800 min /year

80% 144

New system will allow student to review their performance in school more directly and efficient. They used to have to open several page to get their performance information and get confused by the old system. They will save lots of time by the new system.Personnel Staff (using current system)20 person *1.5 min / page * 2 pages * 180 days/year = 10800 min /year

75% 135

New system make the information more convenient to teachers by simplifying the process of student information managements. The design of the new system fully considered the requirements of the teachers.The teachers will save lots of time by using the new system.Personnel Staff (using current system)20 person * 3 min /page * 3 pages * 180 days/year =32400 min/year

70% 378

New function allow teachers to share information among teachers, students, parents. By email or cell phone.Personnel Staff (using current system) 20 person * 4 min /documents * 2 documents * 180 days/year = 28800 min /year

80% 384

Total 1041

Benefits in total(teachers got paid 50$/hr) 52050 $

document.doc 4 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

2.3 ROI AnalysisNOTE: The table below describes the projected Return on Investment for the LEMA System we are building. Since LEMA systems will be operate in mid-2012, the year is distributed starting in July and ending in June of the following year. The year-to-year effort-cost assumes a 10% increase in employee salary, which explains, for instance, the jump from an effort cost of 156 in the 2013-2014 year to 171.6 in the 2014-2015 year.

The break-even point is where the ROI value is equal to the value of 0; that means the amount of cost is equal to the amount of returned value. From the ROI Analysis graph below, it can be concluded that LEMA system will get its return-on-investment almost the first year.The maintain cost is list as follow:

Maintenance Period (1 year)Maintenance(3 hrs/week * 52 weeks)

156

Maintenance Period Total 156

The maintainer is paid 50$/hr so the maintaining cost is :156 hr/year * 50$/hr = 7800$

The maintain cost increase every year by a rate of 10%.

Table 4: ROI Analysis

Year Cost Benefit(Effort Saved)

Cumulative Cost

Cumulative Benefit ROI

July 2012to

June 2013

30735 0 30735 0 -1.00

July 2013to

June 2014

8260 52050 38995 52050 0.33

July 2014to

June 2015

9040 52050 48035 104100 1.17

July 2015to

June 2016

9898 52050 57933 156150 1.69

July 2016 to

June 2017

10842 52050 68775 208200 2.02

document.doc 5 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

Figure 1: ROI Analysis Graph

document.doc 6 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

3. Architecture Feasibility3.1 Level of Service Feasibility

Table 5: Level of Service Feasibility

Level of Service Requirement Product SatisfactionLOS-1: The system response time must be 5 - 10 seconds

Product Strategies: PHP , MySQL .Process Strategies: Optimize databaseAnalysis: The current system always suffer responding time problem. So we could improve the responding time by optimize the algorithm and data structure. But it's hard to calculate the respond time so we may not able to guarantee the requirement.

LOS-2:The system must support up to 1000 students.

Product Strategies: PHP, MySQL.Process Strategies: Expand the databaseAnalysis: The current database is operated by the ISIS organization. We can't modify the database and the teachers can't share information among each others. In general, the database should be able to restore 1000 students information. Otherwise, we could redesign the database to satisfy this requirement.

3.2 Capability Feasibility

Table 6: Capability Requirements and Their Feasibility Evidence

Capability Requirement Product SatisfactionCR-1: In the future, there may be more than one LEMA school, so support must be added to break data down according to school.

Software/Technology used: PHP, MySQL, ApacheFeasibility Evidence: We could use specific ID code to represent different schools. Then we will use the database to record the school ID. By using the codes, the system can identify the school.Referred use case diagram: SSAD process diagram

CR-2: Students should be able to see where they stand for attendance and grades in the form of a scatter plot.

Software/Technology used: PHP, MySQLFeasibility Evidence: For this requirement, we will use PHP to build a certain page, in that page, students can review their performance in scatter plot chart. We could use the features PHP offered to analyze data in scatter plot chart.

document.doc 7 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

Referred use case diagram: SSAD process diagram

CR-3: Keeps track of all materials, such as books, that have been borrowed by students.

Software/Technology used: PHP, MySQLFeasibility Evidence: For this requirement, we will use PHP to build a certain page, then we will also use MySQL to build up the database. The record of resource can be saved into the database by using the page.Referred use case diagram: SSAD process diagram

CR-4: Client requires to aggregate student data such as average and standard deviation be presented by grades.

Software/Technology used: PHP, MySQLFeasibility Evidence: For this requirement, we will present this function in the student page. The PHP offers the capabilities to calculate the required data.Referred use case diagram: SSAD process diagram

CR-5: Client requires a chart that shows how much of a student's grade is made up of each category of work (projects, test, hw, etc.)

Software/Technology used: PHP, MySQLFeasibility Evidence: For this requirement, we will present this function in the certain page. The PHP offers the capabilities of performing chart of certain data.Referred use case diagram: SSAD process diagram

CR-6: Client requires that student grade/attendance reports be updated daily

Software/Technology used: PHP, MySQLFeasibility Evidence: For this requirement, we will present this function in the student page. We will use PHP to generate a daily report.Referred use case diagram: SSAD process diagram

CR-7:Client requires that data for student GPA, completed number of credits, and attendance rate should be available both for the term and for the last month only

Software/Technology used: PHP, MySQLFeasibility Evidence: For this requirement, we will present this function in the student and teacher page. We will use PHP to generate a certain report with the constrains of date.Referred use case diagram: SSAD process diagram

CR-8: Client requires that report data should be understandable to students (number of days absent instead of percentage of time absent, for example)

Software/Technology used: PHP, MySQLFeasibility Evidence: For this requirement, we will present this function in the student page. We will design a more understandable report by performing the number of days absent.Referred use case diagram: SSAD process diagram

CR-9: Client requires that a communication log between teachers and parents be kept.

Software/Technology used: PHP, MySQLFeasibility Evidence: For this requirement, we will present this function by creating the communication log. This log is available to the teachers.Referred use case diagram: SSAD process diagram

document.doc 8 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

CR-10:Client requires that there is a way to communicate with parents through this site

Software/Technology used: PHP, MySQLFeasibility Evidence: For this requirement, we will design a certain function for the teacher to communicate with the parents. The function will present on the teacher page.Referred use case diagram: SSAD process diagram

CR-11:For all users, client needs five different levels to access data

Software/Technology used: PHP, MySQLFeasibility Evidence: For this requirement, we will design the certain function called access control. The administrator can use this function to manage the system. He/she will define the authorities of the users and the authorities will be classified into five levels.Referred use case diagram: SSAD process diagram

CR - 12:Export from Easy Grade PRO

Software/Technology used: PHPFeasibility Evidence: For this requirement, we will design the certain function to export/input data from Easy Grade PRO.Referred use case diagram: SSAD process diagram

CR - 13:Aggregate Attendance Data

Software/Technology used: PHPFeasibility Evidence: For this requirement, we will design the certain function to aggregate attendance data.Referred use case diagram: SSAD process diagram

CR-14: Missing Assignments

Software/Technology used: PHPFeasibility Evidence: For this requirement, we will design the certain function to store missing assignments for each student separated by class.Referred use case diagram: SSAD process diagram

CR-15:Behavior Referrals Software/Technology used: PHPFeasibility Evidence: For this requirement, we will design the certain page to enable teachers to write/send referrals.Referred use case diagram: SSAD process diagram.

CR-16:Achievement Awards Software/Technology used: PHPFeasibility Evidence: For this requirement, we will design the certain page to enable teachers to write/send achievement awards to students.Referred use case diagram: SSAD process diagram.

CR-17:Threaded Discussions Software/Technology used: PHP,MySQLFeasibility Evidence: For this requirement, we will design the certain page to enable teachers to talk to students and store their conversation.Referred use case diagram: SSAD process diagram.

CR-18:Calculate Attendance Metrics

Software/Technology used: PHP,MySQLFeasibility Evidence: For this requirement, we will design the certain function to calculate the number of missed days, instructional minutes missed, and dollar amount wasted as a result.Referred use case diagram: SSAD process diagram.

CR-19: Software/Technology used: PHP,MySQL

document.doc 9 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

Failing Students Feasibility Evidence: For this requirement, we will design the certain function to inform the students who are going to receive D's and F's.Referred use case diagram: SSAD process diagram.

CR-20:Performance Meter: Countdown

Software/Technology used: PHP,MySQLFeasibility Evidence: For this requirement, we will design the certain function to inform the students who are not going to graduate on time.Referred use case diagram: SSAD process diagram.

CR-21:Performance Meter: A - G

Software/Technology used: PHP,MySQLFeasibility Evidence: For this requirement, we will design the certain function to track credits, number of failures, and estimated time of completion for both UC and CSU systems.Referred use case diagram: SSAD process diagram.

CR-22:Performance Meter: Core Classes

Software/Technology used: PHP,MySQLFeasibility Evidence: For this requirement, we will design the certain function to track the number of math, science, and English classes left per student.Referred use case diagram: SSAD process diagram.

CR-23:Performance Meter: Aggregate

Software/Technology used: PHP,MySQLFeasibility Evidence: For this requirement, we will design the performance meter reports that run for each grade and school-wide.Referred use case diagram: SSAD process diagram.

CR-24:Missing Assignments to Grade Lost

Software/Technology used: PHP,MySQLFeasibility Evidence: For this requirement, we will design certain function to calculate the percentage of the total grade lost due to missing assignments.Referred use case diagram: SSAD process diagram.

CR-25:Show Metrics Every 5 Weeks

Software/Technology used: PHP,MySQLFeasibility Evidence: For this requirement, we will design certain function to keep track of student letter grades for each 5 week term of a semester (after 5 weeks, 10 weeks, 15 weeks, and final).Referred use case diagram: SSAD process diagram.

3.3 Evolutionary FeasibilityBy analyze the SSRD document, I find the evolutionary requirement. The following part offers the evolutionary feasibility.

Table 7: Evolutionary Requirements and Their Feasibility Evidence

Evolutionary Requirement

Product Satisfaction

Software/Technology used: MySQL , PHP

document.doc 10 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

ER-1: Use School code to identify the different school ( The system may be used in different schools)

Feasibility Evidence: We could use specific ID code to represent different schools. Then we will use the database to record the school ID. By using the codes, the system can identify the school.Referred use case diagram: There is no specific diagram for this requirement.

document.doc 11 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

4. Process FeasibilityTable 8: Rationales for Selecting Architected Agile Model

Criteria RationalesSize, Complexity After analyze the capabilities that client required, the project is

medium size. The database will support almost 1000 students information. The system should allow teachers, parents and students to log in to review the students information. What's more, the system should be able to email or text student reports to the parents.The complexity of the project is medium. The clients want a system which make the management of students information efficiently. The system should also can send email and texts of student information to parents. Due to the workflow, we decide to adopt the Architected Agile Model.

Change Rate % /Month For most of the requirements is quite stable and we have many negotiation with clients for the final requirements. So the change rate may low as 2%/month.

Criticality Medium. The system is not that critical for the clients now using EZ grade to manage the information and the system perform well. However, if our system begin to operate, the stability and safety of the database is very important. It can have significant effect on the clients if the system miss the data.

NDI Support The project will use PHP, MySQL and Apache . Also, the EZ grade provided by clients as prototype will analyzed by the developing team.

Org/Personnel Capability There are at least two members with PHP developing experience in our team. The two off-campus students are both with high specific capabilities. And the architecture design is generated by the whole team. We are familiar with the workflow.

Key Stage I Activities : Incremental Definition

Since the system we are developing have settle down lots of certain capabilities requirement, the early definition of the project can help to generate the agile design. In the Valuation and Architecting phases, our team will have commitment review. Then we have to finish the prototype to identify the core capabilities.

Key Stage II Activities: Incremental Development, Operations

After identifying the core capabilities in the Stage I Activities. The developing team will focus on the core capabilities committed to deliver. Then we can improve the system by promoting and adding the features to the early version. We will estimate the system by the client feedback and have

document.doc 12 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

commitment review. Time per Build;Time per Increment

Time Per build:8-10 weeks, the schedule is enough to complete the required system and then we can assess the feedback from the client.Time per Increment: We may use 2-3 months, according to the schedule of the course 577 a/b, it's more safe to arrange enough time to update and fix the defects. The improvement of low priority requirements should also be considered.

Table 9: Requirement Prioritization

Priority Requirements References Increment #M Multi-School Support CR-1 1M Scatter plot Reporting CR-2 1M Reservation System CR-3 1M Statistical Data CR-4 2M Pie Chart for Grade Magnitude CR-5 1M Daily Reporting CR-6 1M Student Progress Over Time CR-7 1M Data Format CR-8 1S Track Parent Notifications CR-9 2M Parent Communication Page CR-10 2M Security for data CR-11 1M Export from Easy Grade PRO CR-12 1W Aggregate Attendance Data CR-13 3M Missing Assignments CR-14 1C Behavior Referrals CR-15 2C Achievement Awards CR-16 2W Threaded Discussions CR-17 3C Calculate Attendance Metrics CR-18 3S Failing Students CR-19 2C Performance Meter: Countdown CR-20 3C Performance Meter: A - G CR-21 3C Performance Meter: Core Classes CR-22 3C Performance Meter: Aggregate CR-23 3C Missing Assignments to Grade Lost CR-24 3S Show Metrics Every 5 Weeks CR-25 2

document.doc 13 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

5. Risk AssessmentTable 11 contains a list of the projects most critical risks. Each risk includes an estimate of the impact if this risk was to occur and the probability that the risk will occur. These numbers are multiplied to obtain the risk exposure. The last column contains strategies the team will useto mitigate the risk.

Table 10: Risk Assessment

RisksRisk Exposure

Risk MitigationsPotential Magnitude

Probability Loss

Risk Exposure

Consistence:Team04,12, and external systems(ISIS) should use same information (student's ID or Class ID)

2 2 4 -Before applying system, we need get data from ISIS.

Interaction between EZ grade Pro and mysql system- Client want our system to interact with EZ grade pro by import and export function. If export file is not appropriate type to interact with mysql, our system cannot get data form EZ grade- In addition, even though interaction is possible, if the size of data is too big, there can be data loss.

2 2 4 -Build simple prototype and testwe tested it successfully, however, if clients want to input different kinds of information, we have to test different type of possible cases.

Uncertain information for report - Client suggested a lot of new requirements. If we accepted all, we cannot finish the project in time.

2 3 6 -Follow the prioritization list to develop the core requirements in order to catch up the schedule.

document.doc 14 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

6. NDI/NCS Interoperability Analysis 6.1 Introduction The NDI/NCS services help in the system are in order to make the system efficiently. They helps in integrating the system with various already well-established services. The various NDI/NCS services that are being used in our system are as follows:

Gmail Mozeo text service Apache PHP MySQL

6.1.1 COTS / GOTS / ROTS / Open Source / NCSTable 11: NDI Products Listing

NDI/NCS Products PurposesGmail It's used in the system to send report to

parents.Mozeo text service It's used in the system to send message

to parents.Apache It is an open source software used to

develop the web pages of the system.PHP This is also used for the development

and management of web pages. It is also a COTS component.

MySQL It's used to build the database of the system.

6.1.2 Connectors- In this project we are using the PHP/MySQL connector to connect to the database,

query it and get the result.- In order to send text to the parents , the project will need interface connector to

connect the Mozeo text service.- In order to send e-mail to the parents , the project will need to use the API of Gmail to

connect the system.- In this project Apache Tomcat server is used to develop and support the web

application functionalities.

document.doc 15 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

6.1.3 Legacy System- The LEMA FAMILY ACCOUNTABILITY SYSTEM is similar with the EZ grade

which is using in LEMA school now. Our critical stakeholder described in win-win negotiation that the main idea of this system is produce a system which is similar with the EZ grade but have more functions. The current prototype of the project could be compared with EZ grade.

6.2 System Structure

6.3 Evaluation Summary

document.doc 16 Version Date: 12/04/11

Feasibility Evidence Description (FED) for LEMA Family Accountability System Version 3.2

Table 12: NDI Evaluation

NDI Usages Comments1.Gmail Used for send

e-mail to the parents.

Gmail is a free service support by google. It allow the system to send e-mail.

2.Mozeo text service Used for send text message to parents.

Mozeo is a paid text service, the clients decide to buy this text service to implement in the system.

3.Apache It is an open source software used to develop and maintain web pages.

The new versions of Apache web server are compatible with all the OS i.e. Mac/Windows. Apache does not impose any limit on the number of concurrent users. It depends on the hardware that the system is going to utilize and some good scripting skills to distribute the load.

4.PHP It is a web scripting language used for developing the dynamic pages of our system.

New version PHPBB 5.3 is compatible with 32 or 64 bit Windows, the older version was compatible only with 32 bit windows.

5.MySQL It is an RDBMS used to help multiple users to interact with the database.

MySQL version is compatible with windows/Mac. Even MySQL does not specify any limit explicitly on the number of users.

document.doc 17 Version Date: 12/04/11