university of southern california department computer science
DESCRIPTION
LEMA Pilot School Integrated Family accountability System Development Commitment Review USC CSCI577 Team04 November 29 2011. University of Southern California Department Computer Science. LEMA Pilot School Integrated Family Accountability System. Agenda. - PowerPoint PPT PresentationTRANSCRIPT
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
Teawon Han Project Manager Architecture
Ziming Wei OCE Operational concept Description
Zhen Huang Feasibility Analyst
Feasibility Evidence Description
Ying Yang Lifecycle Planner Life Cycle Plan
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
• Desired Capabilities and Goals
• 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
• Desired Capabilities and Goals
• 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
Text
Request Processing
Module
LEMA Scheduling
System(By Team 12)
Teacher/Student Infomation
Query/Response
16
Business Workflow
17
• Agenda
NAME ROLE PRESENTS
Teawon Han Project Manager Architecture
Ziming Wei OCE Operational concept Description
Zhen Huang Feasibility Analyst
Feasibility Evidence Description
Ying Yang Lifecycle Planner Life Cycle Plan
Ian Williams
RE / Prototyper Prototype / SSRD
Kimberly Krause
IIV&V, SRE Quality Focal Point
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
Teawon Han Project Manager Architecture
Ziming Wei OCE Operational concept Description
Zhen Huang Feasibility Analyst
Feasibility Evidence Description
Ying Yang Lifecycle Planner Life Cycle Plan
Ian Williams
RE / Prototyper Prototype / SSRD
Kimberly Krause
IIV&V, SRE Quality Focal Point
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
• High Priority Requirements
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
• High Priority Requirements
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
• High Priority Requirements
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
• High Priority Requirements
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
Ziming Wei OCE Operational concept Description
Zhen Huang Feasibility Analyst
Feasibility Evidence Description
Ying Yang Lifecycle Planner Life Cycle Plan
Ian Williams RE / Prototyper Prototype
Kimberly Krause
IIV&V, SRE Quality Focal Point
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
• USE Case Diagram
Focusing on USER Relationships
Focusing on USER Relationships
ID/PWID/PW
External
Systems
External
Systems
External Text ServiceExternal Text Service
46
• USE Case Diagram
After Login into
the system
After Login into
the system
ID/PWID/PW
Focusing on Authorized User
Focusing on Authorized User
47
• USE Case Diagram
Focusing on AdministratorFocusing on Administrator
IncludeInclude
48
UserUser
UserUserUserUser
• USE Case Diagram
extendextend
Focusing on Parent & Student
Focusing on Parent & Student
Class InfoClass Info
49
IncludeInclude
Focusing on Teacher and Supervisor
Focusing on Teacher and Supervisor
• USE Case Diagram
Class InfoClass Info
Grade Info
Grade Info
IncludeInclude ExtendExtend
50
• USE Case Diagram
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
Ziming Wei OCE Operational concept Description
Zhen Huang Feasibility Analyst
Feasibility Evidence Description
Ying Yang Lifecycle Planner
Life Cycle Plan
Ian Williams RE / Prototyper Prototype
Kimberly Krause
IIV&V, SRE Quality Focal Point
54
Life Cycle Plan
Ying Yang
55
• Agenda
NAME ROLE PRESENTS
Teawon Han Project Manager Requirement / 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
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
Feasibility Evidence Description
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