University of Southern California Department Computer Science LEMA Pilot School Integrated Family accountability System Development Commitment Review USC

University of Southern California Department Computer Science

LEMA Pilot School Integrated Family accountability System

Development Commitment ReviewUSC CSCI577 Team04

November 29 2011

1

• Agenda

NAME ROLE PRESENTS

Teawon Han Project Manager Architecture

Ziming Wei OCE Operational concept Description

Zhen Huang Feasibility Analyst

Feasibility Evidence Description / Architecture

Ying Yang Lifecycle Planner Life Cycle Plan

Ian Williams RE / Prototyper Prototype / SSRD

Kimberly Krause

IIV&V, SRE Acceptance Test Plan and cases

2

Acceptance Test Plan and Cases

Kimberly Krause

3

• Strengths: Weaknesses:

• Team worked well together • Team was knowledgeable

about most areas of the process that we needed for the project to this point

• Understanding of COCOMO

• SW Architecture

• Only 1 team member is continuing to 577b. Risk that the new team

wont have the right skill set to follow through on the plans we have laid out.

4

• Major Features to Test

• Entering grades and attendance

• Parent Notification

• Allocation of Resources

• Viewing Reports

• Calling parent or other teacher meetings

• User Authentication

• Data Imports

• Level of Service Tests

5

• Example Test Cases – Parent Notification

• Nominal Cases- Manual notification by email / by text- Automatic notification by email / by text- Notifications being properly logged

• Error cases- Unable to send email- Unable to send text- Out of text messages- Message blocked- Database error when logging information

6

• Agenda

NAME ROLE PRESENTS




Feasibility Evidence Description


Ian Williams RE / Prototyper Prototype / SSRD

Kimberly Krause

IIV&V, SRE Quality Focal Point

7

Operational Concept Description

Ziming Wei

8

• Content

1. System Purpose

2. Proposed New System

3. Benefits Chain Diagram

4. System Boundary

5. Desired Capabilities and Goals

6. New Business Workflow

9

• Content

1. System Purpose To develop a web based system that teachers can manage

students’ information(attendance, grade,resources) and notify parents,

and that can provide ‘students’ performance for teachers, parents, students,

thus to help increase students learning.

2. Proposed New System - The type of system to be built : 3 main functionalities: a. Provide various reports for teachers, students and parents

to know students’ performance better. b. Parent notification via email and text c. Book reservation

10

Benefit-ChainDiagramBenefit-ChainDiagram

11

12

• Desired Capabilities and Goals

• Capability Goals• OC-1 Multi-School Support• OC-2 Scatterplot Reporting• OC-3 Reservation System• OC-4 Statistical Data• OC-5 Pie Chart for Grade Magnitude• OC-6 Daily Reporting• OC-7 Student Progress Over Time• OC-8 Data Format• OC-9 Level of Access• OC-10 Import from Easy Grade Pro• OC-11 Missing Assignments

13


• Level of Service Goals

Level of Service Goals Priority Level

Referred SSRD requirements

System response time(6 minutes for max time for generating reports, and 5-10 seconds for other page response)

Must have

LOS-1

Number of students: 300-1000 Must have

LOS-2

14


• Organizational Goals• OG-1: Save time via more efficient data processing.• OG-2: Improve student management via more useful information and statistics.• OG-3: Better communication with parents via parents notification function.• OG-4: Improve students study by providing more useful

data.• OG-5: Help teachers to manage school resources via resource reservation function.

15

• Element Relationship Diagram

UsernamePassword User

AUTHENTICATION

Administrator/Maintainer

Data Management

System Teachers Input dataView Reports

Students Request/ViewReports

Parents Request/ViewReports

System Error Reporter

Database

Parent Notification

LEMA Integrated Family Accountability System

View log

System Errors

Maintain/Update

Attendance/Grade

Records

Book/ResourceRecords

Message

Legend:

Process System and Stakeholders

Teacher

Student

Parent

Input Module

Report Generator

Resource Reservation

External Email System

External SMS Gateway

Email

Text

Request Processing

Module

LEMA Scheduling

System(By Team 12)

Teacher/Student Infomation

Query/Response

16

Business Workflow

17

• Agenda

NAME ROLE PRESENTS






Ian Williams

RE / Prototyper Prototype / SSRD

Kimberly Krause


18

Prototype

Ian Williams

19

• Changes Made

1. UI- Grade Report

- 5-week, 10-week, 15-week, final- Click on student to see detailed view

- Teacher view only- Grade Input

- Changed to grade upload- Accepts files (plain text as well as XML-

formatted) exported from Easy Grade Pro

20

• Changes Made

1. UI

21

• Changes Made

1. UI

22

• Changes Made

1. UI

23

• Added Risk

1. Uploading grades from Easy Grade Pro- Two versions

- Entire Gradebook- Contains everything, down to

assignment grades per class, per student

- Report card letter grades- Perfect for the 5-week interval letter

grades- Created test Gradebook and exported it to an

XML file

24

• Added Risk (Resolved)<class> <classrecord> <cr_classsubjectname>Math</cr_classsubjectname> </classrecord>

<assignments> <assignment> <ass_id>1</ass_id> <ass_name>HW 1</ass_name> <ass_maxscore>100</ass_maxscore> </assignment> </assignments>

<student> <stud_recordinfo> <stud_id>020</stud_id> <stud_displayname>Smith, John</stud_displayname> </stud_recordinfo> <stud_grades> <score assid="1"> <score_raw>99/100</score_raw> <score_percent>99.0</score_percent> <score_grade>A+</score_grade> </score> </stud_grades> </student></class><class> …

25

Math------------------------------------Smith, John (020)Assignment 199/10099.0A+

Assignment 2100/100100.0A+

Assignment 398/10098.0A+-----Johnson, Sally (001)Assignment 1100/100100.0A+…

Math------------------------------------Smith, John (020)Assignment 199/10099.0A+

Assignment 2100/100100.0A+

Assignment 398/10098.0A+-----Johnson, Sally (001)Assignment 1100/100100.0A+…

• Resolved Risks

1. Text Messaging- Pay by text message, not by month- Mozeo

- Friendly API, sample client in PHP- Kimberly produced a page that accepts a

phone number and a message and sends a text message.- http://greenbay.usc.edu/csci577/fall2011/

projects/team04/test.php

26

• Resolved Risks

2. Report Content- Received a list of all desired reports from

client

3. Cross Project Collaboration- Shared relevant portions of database schema

through a Google Doc- Student information (such as ID and name)

will be stored in a single database- Don’t have to worry about matching

student IDs

27

• Agenda

NAME ROLE PRESENTS






Ian Williams

RE / Prototyper Prototype / SSRD

Kimberly Krause


28

Requirement

Ian Williams

29

• Win Condition Ranking

30

• Win Condition Ranking

31

• Changes Made

1. Many new requirements added- Clients provided a list of reports that they

would like to be added- Performance Reports

- Also added a few new capabilities- Behavior referrals section- Stored conversation threads per student

- Too many to commit to in one semester- New column in Prioritization Sheet to lower

the priority of the new items only

32

• High Priority Requirements

1. Student-Understandable Data- Business Value: 9/9- Penalty if not Implemented: 9/9- Ease of Realization: 2 (1 is easiest)- Derived Requirement: Data Format (CR – 8)- Ensure that the system represents numbers

of tardies, absences, and missing assignments as whole numbers instead of percentages- 3 absences better than 8% absent

- Very easy to do since we will receive the number of absences/tardies directly from the teachers every day. 33


2. Must Support 300 – 1000 Students- Business Value: 9/9- Penalty if not Implemented: 9/9- Ease of Realization: 3 (1 is easiest)- Derived Requirement: Number of Students

(LOS – 2)- Ensure that the system can support the

current number of students and have the ability to scale to 1000 if the school grows to that size.- Easy to set aside enough database size.- Easy to test once the database is

populated with information (add more students, teachers, and parents) 34


3. Daily Performance Report- Business Value: 9/9- Penalty if not Implemented: 9/9- Ease of Realization: 4 (1 is easiest)- Derived Requirement: Daily Reporting (CR –

6)- The system must accept daily attendance and

weekly grade information to show the most up-to-date reports.- Used to be daily grade input, but clients decided to

use Easy Grade Pro and upload grades once a week (see CR – 12)

- Accept new attendance data several times a day per student. 35


4. Students Should be Able to See Their Rank- Business Value: 9/9- Penalty if not Implemented: 8/9- Ease of Realization: 4 (1 is easiest)- Derived Requirement: Statistical Data (CR –

4)- Just like it sounds – students must be able to

see where they rank against their peers- Easy to implement- Calculate GPA and sort

36


5. IE, Chrome, Firefox Support- Business Value: 8/9- Penalty if not Implemented: 9/9- Ease of Realization: 4 (1 is easiest)- Derived Requirement: Provide Online

Interface (SR – 4)- System site must be compatible with IE,

Chrome, Firefox- Will take a little time, but easy to ensure

because these browsers are free

37

• Agenda

NAME ROLE PRESENTS

Teawon Han

Project Manager

Architecture





Ian Williams RE / Prototyper Prototype

Kimberly Krause


38

Architecture

Teawon Han

39

• System Context

40

• System Context

SYSTEM made by USC

ID/PWID/PW

Scheduling System

41

• Hardware System Structure

42

• Hardware Component Class

SYSTEM made by USC

ID/PWID/PW

Scheduling System

ID/PWID/PW

Class InfoClass Info

43

• Communication between team04 and team12

SYSTEM made by USC

Scheduling System

Class InfoClass InfoUser InfoUser Info

Grade Info

Grade Info

AttendanceInfo

AttendanceInfo

Login System

Login System

ID/PWID/PW

Token

Token

USER ID & PERMISSIONUSER ID & PERMISSION

List of ClassList of Class

44

• USE Case Diagram

45


Focusing on USER Relationships

Focusing on USER Relationships

ID/PWID/PW

External

Systems

External

Systems

External Text ServiceExternal Text Service

46


After Login into

the system

After Login into

the system

ID/PWID/PW

Focusing on Authorized User

Focusing on Authorized User

47


Focusing on AdministratorFocusing on Administrator

IncludeInclude

48

UserUser

UserUserUserUser


extendextend

Focusing on Parent & Student

Focusing on Parent & Student


49

IncludeInclude

Focusing on Teacher and Supervisor

Focusing on Teacher and Supervisor



Grade Info

Grade Info

IncludeInclude ExtendExtend

50


Login pageLogin page

Login pageLogin page

Administrator management

page

Administrator management

page

UserInfomanagement

page

UserInfomanagement

page

Update UserInfo

page

Update UserInfo

page

Input UserInfo

page

Input UserInfo

page

Review Errorpage

Review Errorpage

Input message page

Input message page

Manage Resource

page

Manage Resource

page

Input Resourcepage

Input Resourcepage

Update Resource

page

Update Resource

page

Manage Student performance

page

Manage Student performance

page

UploadStudent grade page

UploadStudent grade page

Input Student Attendance page

Input Student Attendance page

S/W component class Diagram

S/W component class Diagram

51

• Deployment Diagram

52

Chrome ver16

Chrome ver16

• Sequence Diagram

53

• Agenda

NAME ROLE PRESENTS

Teawon Han Project Manager Strong & Weak points / Requirement / Architecture




Ying Yang Lifecycle Planner

Life Cycle Plan


Kimberly Krause


54

Life Cycle Plan

Ying Yang

55

• Agenda

NAME ROLE PRESENTS

Teawon Han Project Manager Requirement / Architecture


Zhen Huang

Feasibility Analyst

Feasibility Evidence Description / Architecture



Kimberly Krause

IIV&V, SRE Strong & Weak Point /Quality Focal Point

56

• Seven modules will be implemented in 577b

1. Grade data import module

2. Data request processing module

3. Attendance data input system module

4. Notification system module

5. Performance report module

6. Resource management module

7. System management module57

• Cost estimation for implementing the modulesBelow shows the total effort of implementing the modules estimated using COTIPMO:Below shows the total effort of implementing the modules estimated using COTIPMO:

The number in red box indicates that the project is doable within budget with a 7 person development team within 24 weeks development cycle.

The number in red box indicates that the project is doable within budget with a 7 person development team within 24 weeks development cycle.

58

• Cost estimation for implementing the modules

Scale factors of the estimation:Scale factors of the estimation:

COTIPMO cost drivers for each module:COTIPMO cost drivers for each module:

59

• Required skills and responsibility of new team members in 577b

1. Project Manager(needs 1 new member) a. Required skills: Project managing, Microsoft Project b. Responsibility: Manage project and track the project progress, track individual effort, progress report 2. Builder(needs 2 new members, 1 continuing member) a. Required skills: PHP, C/C++, Java, JavaScript, SQL b. Responsibility: Build the system3. Tester(needs 2 new member) a. Required skills: ability to use the testing tool, build test cases and to perform testing b. Responsibility: identify Test Plan, identify test procedures, perform testing, record test results 4. Trainer(needs 1 new member) a. Required skills: ability to make training plan, ability to communicate with

clients and users to provide proper training b. Responsibility: Prepare training plan, provide training

60

• Detail plan for 577b

• Re-baselined Foundation phase– 1/9/2012 to 2/11/12– Rebaseline the project status– Communicate with client and see if there is any change

• Development phase– Construction iteration: 2/15/2012 to 4/13/2012

• Will implement core capability first then full capability– Transition iteration: 4/13/2012 to 5/1/2012

• Transition the system• Provide training

61

• Detail plan for 577b

• Operation phase– 5/2/2012 to 5/6/2012– Get feedback from users and evaluation from clients and

provide additional support if necessary

• Major milestone

62

• Artifact deliverable in different phases

• In re-baselined development phase

63

• Artifact deliverable in different phases

• In development phase

64

• Iteration Plan

Detail plan for development phase construction iteration:

65

• Iteration Plan

• By March, 15th, all the Must-have capabilities requirements must be fulfilled

66

Requirement ID

Requirement Name

Description

CR - 1 Multi-School Support

In the future, there may be more than one LEMA school, so school codes must be added to each student's data to break data down according to school.

CR - 2 Scatter plot Reporting

The system must show scatter plots that show students where they stand for attendance and grades.

CR - 3 Reservation System

System must keep track of all materials, such as books, that have been borrowed by students.

CR - 4 Statistical Data

System must have aggregate student data calculations such as average and standard deviation for grades.

CR - 5 Pie Chart for Grade Magnitude

System must have a chart that shows how much of a student's grade is made up of each category of work (projects, test, hw, etc.)

CR - 6 Daily Reporting

System must have the ability to update student grade/attendance reports daily.

Requirement ID

Requirement Name

Description

CR - 11 Levels of Access The system must offer 5 levels of access: student, parent, 2 levels of teachers, and admin.

CR - 12 Export from Easy Grade PRO

The system must accept a text file, parse the information it contains, and store that information in a database.

CR - 14 Missing Assignments

The system must store missing assignments for each student separated by class

CR - 7 Student Progress Over Time

System must show data for student GPA, number of credits completed, and attendance rate for the current term and for previous months.

CR - 8 Data Format Number of missing assignments, tardies, and absences must be a whole number, not a percentage.

• Iteration Plan

• From 3/15/12 to 3/28/12, the major task will be to integrate

both systems – the family accountability system and the scheduling system

• The Core Capability Drive-through will be performed during

3/26/12 to 3/28/12

• After the Core Capability Drive-through, the should-have and

could-have capabilities will be implemented. 67

• Iteration Plan

• The should-have capability requirements

68

Requirement ID

Requirement Name

Description

CR - 9 Track Parent Notifications

The system should keep track of all communication between teachers and between teachers/parents that goes through this system.

CR - 10 Parent Communication Page

The system should support sending email and text messages between teachers and teachers/parents.

CR - 19 Failing Students The system should report on students who are receiving multiple D's or F's

CR - 25 Show Metrics Every 5 Weeks

The system should keep track of student letter grades for each 5 week term of a semester (after 5 weeks, 10 weeks, 15 weeks, and final)

Requirement ID

Requirement Name

Description

CR - 20 Performance Meter: Countdown

The system should be able to recognize when a student will no longer graduate on time.

CR - 21 Performance Meter: A - G

The system should track credits, number of failures, and estimated time of completion for both UC and CSU systems

CR - 22 Performance Meter: Core Classes

The system should track the number of math, science, and english classes left per student.

CR - 23 Performance Meter: Aggregate

The performance meter reports should run for each grade and school-wide

CR - 24 Missing Assignments to Grade Lost

The system should calculate the percentage of the total grade lost due to missing assignments

CR - 15 Behavior Referrals

The system could provide a web page for teachers to write/send referrals.

CR - 16 Achievement Awards

The system could provide a web page for teachers to write/send achievement awards to students

CR - 18 Calculate Attendance Metrics

The system could use attendance information to calculate the number of missed days, instructional minutes missed, and dollar amount wasted as a result.

• The could-have capability requirements

• Expectation for users and clientsValuation Foundations Development

Construction TransitionUsers Users role and functions

subsumed by ClientsUsers role and functions

subsumed by Clients.(if any user is available else

subsumed by Clients) Review and test the system

(or its increment) in development environment. Provide feedback about the

said system output and performance.

Review and test the system (or its increment) in

operational environment. Provide usage feedback to

Maintainer

Clients Clients, NN and Keun Lee, impart knowledge of

Opportunity Tree,Support definition and review of requirements

specification, operational concept and plan – accept

or reject options

NN monitors progress at milestones, review

designs, prototypes, plans and feasibility during ARB,

help refine Opportunity Tree knowledge, provide

alternative/enhanced concepts, Keun Lee provides empirical

information

Mentioned clients monitor progress at milestones.

Review and test the system by means of usage. Review the system performance.

Keun Lee provides empirical information

Named clients Monitor progress Review system

performance of the system and its capability when deployed in real world

environment.

69


Zhen Huang

70

• Purpose of FED

1. Analyze cost / investment of the project and return on investment.

2. Provide architecture feasibility.

3. Provide process feasibility.

4. Risk analysis and mitigations.

71

• Purpose of cost Analysis

To identify the personnel cost , software and hardware

of the project.

72

• Personnel cost

Client: communication via email, phone and/or other channels[3 hrs/week * 12 weeks * 2 person]

72

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$

73

• Software and hardware costType Cost Rationale

Expected 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 system

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

74

• Purpose of benefit analysis

• To identify the benefits clients will have from the project.

• Our benefits analysis based on the win-win negotiation

with the client.

75

• Table 1

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 $76

• Purpose of ROI

• To identify the return of investment.

• Let the client know the project is valuable or not.

• To identify the break-even point that cost equal to benefit

77

• ROI = (Cumulative benefit – Cum.cost) / Cum.cost

Year CostBenefit

(Effort Saved)Cumulative

CostCumulative

BenefitROI

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

78

• ROI = (Cumulative benefit – Cum.cost) / Cum.cost

-1. 5

-1

-0. 5

0

0. 5

1

1. 5

2

2. 5

2012 2013 2014 2015 2016

ROI

79

• Purpose of Level of Services Feasibility

• To identify level of services client need.

• To identify the product and process strategies that used

to achieve the level of services.

• We have the information from win-win negotiation.

80

• Level of Services Feasibility LOS-1: The system response time must be 5 - 10 seconds

Product Strategies: PHP , MySQL .

Process Strategies: Optimize database

Analysis: The current system always suffer responding time problem. So we could improve the responding time by optimize the database and data structure.

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

Product Strategies: PHP, MySQL.

Process Strategies: Expand the database

Analysis: 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.

81

• Purpose of Capability feasibility

• To identify the client requirements.

• We have the information from win-win negotiation.

• To identify the strategies to achieve the capability

requirements.

82

• Capability Feasibility CR-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.Referred use case diagram: SSAD process diagram 83

• Evolutionary FeasibilityEvolutionary Requirement Product Satisfaction

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

Software/Technology used: MySQL , PHP

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.

84

• Rationales for Selecting Architected Agile Model

• Our project team had chosen the Architected Agile

Model to develop the project.

• The session provide the feasibility evidences why

choosing the Architected Agile Model is good.

85

• Rationales for Selecting Architected Agile ModelCriteria Rationales

Size, 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.

86

• Rationales for Selecting Architected Agile ModelOrg/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 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.

87

• Purpose of Requirement Prioritization

• To classify the requirement into certain kinds of cate-

gories like “MUST done” , “Could Have” and “Want to

Have”.

• To arrange our developing schedule with the help of this table.

• To identify why following the schedule will make the

project feasible. 88

• Requirement Prioritization

M Data Format CR-8 1

S Track Parent Notifications CR-9 2

M Parent Communication Page CR-10 2

M Security for data CR-11 1

M Export from Easy Grade PRO CR-12 1

W Aggregate Attendance Data CR-13 3

M Missing Assignments CR-14 1

C Behavior Referrals CR-15 2

C Achievement Awards CR-16 2

W Threaded Discussions CR-17 3

C Calculate Attendance Metrics CR-18 3

S Failing Students CR-19 2

C Performance Meter: Countdown CR-20 3

C Performance Meter: A - G CR-21 3C Performance Meter: Core Classes CR-22 3

89

• Purpose of risk assessment

• To identify the risk may exist in the developing period of the

project.

• To notify all the stakeholders of the risks.

• To generate the proper risk mitigations.

• We use RE(risk exposure) to describe how important the risk

will be. RE = P(L) * P(M)

• P(L): Probability Loss • P(M): Potential Magnitude

90

• Table 1

Risks

Risk Exposure

Risk MitigationsPotential Magnitud

e

Probability Loss

Risk Exposur

e

Requirement - Client want to interact our system with their scheduling system which will be developed by USC-team12. It may cause problems with communication with the other team and additional scope, lost time, etc.

5 6 30 -Discussion with other team members to know what kind of requirements should be satisfied for both project- The learn more about the project and ask for some developing documents from the other team.- Co-designing database and interfaces with the other team.

91

• Table 2

Risks

Risk Exposure

Risk MitigationsPotential Magnitud

e

Probability Loss

Risk Exposur

e

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.

92

Documents

University of Southern California Department Computer Science LEMA Pilot School Integrated Family accountability System Development Commitment Review USC