ITEC 370: Software ITEC 370: Software EngineeringEngineeringProject Group 1Project Group 1
October 8, 2002October 8, 2002
Margaret HaleMargaret Hale
Nycole CappsNycole Capps
Eric AdamsEric Adams
Clint BennettClint BennettRyan BushnellRyan Bushnell
Samantha Samantha BlevinsBlevins
Mike FreyMike FreyKevin ConradKevin ConradBrian FanzoBrian Fanzo
Project PlanningProject Planning
Eric AdamsEric Adams
Nycole CappsNycole Capps
Margaret HaleMargaret Hale
Course Planning SystemCourse Planning System• Project ObjectivesProject Objectives
– The The Business NeedBusiness Need as identified by Dr. as identified by Dr. Salter (The Project Sponsor) is to:Salter (The Project Sponsor) is to:• The goal of the Course Planning System is to The goal of the Course Planning System is to
develop a tooldevelop a tool that will use the that will use the information in information in the student’s recordthe student’s record and the business rulesand the business rules for for the completion of the student’s degree to the completion of the student’s degree to project a complete plan for the student’s project a complete plan for the student’s completion of the tenure at RUcompletion of the tenure at RU..
– The The Expected ValueExpected Value is an increased is an increased efficiency along with effectiveness of the efficiency along with effectiveness of the advising process.advising process.
– Business Process Automation (BPA)Business Process Automation (BPA)
Technical FeasibilityTechnical Feasibility
• Familiarity with application Familiarity with application (moderate)(moderate)
• Familiarity with technology (low)Familiarity with technology (low)
• Project size (high)Project size (high)
Economic FeasibilityEconomic Feasibility
• Development CostsDevelopment Costs
• Operational CostOperational Cost
• Tangible BenefitsTangible Benefits
• Intangible BenefitsIntangible Benefits
Organizational Organizational FeasibilityFeasibility
• Project ChampionProject Champion– Dr. Christine Salter, ITEC Faculty Dr. Christine Salter, ITEC Faculty
Academic AdvisorAcademic Advisor
• Steering CommitteeSteering Committee– There is a strong support of the project There is a strong support of the project
within the Steering Committeewithin the Steering Committee– Jim Graham, RU IS DepartmentJim Graham, RU IS Department– Becky Alls, RU Registrar’s OfficeBecky Alls, RU Registrar’s Office– Susan Underwood, RU CIST Advising Susan Underwood, RU CIST Advising
CoordinatorCoordinator
• UsersUsers
Project Project ManagementManagement
Work PlanWork PlanStaffing PlanStaffing Plan
Controlling and Directing Controlling and Directing ProjectProject
Work Plan Deliverables Est. Hours Actual Hours Assigned To
Planning
Project Management
Create Work Plan Work Plan 8 8 Project Mgr. – Margaret
Staff the Project Staffing Plan 4 2 Project Mgr.
Control/Direct Project PERT/Gantt Task Tracking 3/week Project Mgr.
Project Initiation
Technical Feasibility Feasibility analysis 12 Planning Phase
Economic Feasibility 10 Planning Phase
Organizational Feasibility 5 Planning Phase
Time Records Time Sheets of members 1/week Individual Responsibility
Analysis
Requirements Gathering
Analysis Strategy Determination 4 Req. Determination Phase
As-Is System As-Is System 15 Req. Determination Phase
Identify Improvements Improvements list 10 Req. Determination Phase
To-Be System Concept System Concept 20 Req. Determination Phase
Requirements Specification
Use Case Modeling Use Case Documentation 20 Req. Specification Phase
Structural Modeling Structural Models 20 Req. Specification Phase
Behavioral Modeling Behavioral Models 20 Req. Specification Phase
Design System Specification
System Architecture Design Architecture Design 20 Design Phase
User Interface design Interface Design 20 Design Phase
Database & File design Database & File Specification 20 Design Phase
Program Design Program Design 20 Design Phase
Change Management Change Mgnt. Tracking Docs.
Update Work Plan/ Time Est. Revised Work Plan/Time Est. 2/week Change Mgnt. Group
Track Request for changes Documentation Change Mgnt. Group
Testing
Develop Testing Plans Test Plans 2/week Testing Group
DeliverablesW o rk P la n
T im e S h e e ts
E r ic A da m s
Project PlanningP h a s e M a n a ge rN yco le C a pps
DeliverablesF e a s ib ility A n a lys is
S ys te m C o n ce p t
K e v in C o n ra dB ria n F a n zo
R eq. Determ ination
M ike F re y
DeliverablesS ys te m P ro po s a l
P ro to typ e ( s )
R ya n B u s h n e llS a m a n th a B le v in s
R eq. Specification
C lin t B e n n e tt
AnalysisP h a s e 1P h a s e 2
DeliverablesS ys te m S pe c ifi ca tio nE n h a n ce d P ro to type
T im C a rr
DesignP h a s e M a n a ge rK im be rly B la k e
DeliverablesC h a n ge M gn t
T ra ck in g D o cu m e n ts
D o n F e n s
Change M anagem entP h a s e M a n a ge rT im D lu ga s ch
DeliverablesT e s t P la n s
P a u l B ra b ro o k
TestingP h a s e M a n a ge rS co tt fl o r
Project M anagem entM a rga re t H a le
Project Group #1Staffing Plan
Time Estimation – Tracking TasksTime Estimation – Tracking TasksControlling and Directing the Controlling and Directing the
ProjectProject
Planning Analysis Design
23% 31% 46% 3.25 weeks 4.3 weeks 6.5 weeks
Based on Industry Standards for Business ApplicationsNote: implementation not included
Assuming 65% project completion of SDLC
14 week project Start Date = August 27, 2002
Completion date = November 26, 2002
TimeboxingTimeboxing
• Due to limited time constraints and a Due to limited time constraints and a large system scope, group 1 is using large system scope, group 1 is using timeboxing techniques.timeboxing techniques.
1.1. System Delivery: November 26System Delivery: November 26
2.2. Prioritize functionalityPrioritize functionality1.1. Graduation plan for degrees for CISTGraduation plan for degrees for CIST
3.3. Build the core of the systemBuild the core of the system
4.4. Postpone functionality within the time framePostpone functionality within the time frame
5.5. Deliver the system with core functionalityDeliver the system with core functionality
6.6. Repeat steps 3 through 5, to add Repeat steps 3 through 5, to add refinements and enhancementsrefinements and enhancements
Tracking Tasks with Tracking Tasks with PERTPERT
Program Evaluation and Review Technique (PERT)
Optimistic
Time Most Likely
Time Pessimistic
Time Prec 1 Prec 2 Prec 3 Project Planning 2 3.25 4 Req. Determination 2 2.25 3 Project Planning
Req. Specification 2 2.25 3 Req. Determination
Change Management Testing
Change Management 1 1.5 2 Project Planning Testing 1.5 2 3 Project Planning
Design 5 6.45 7 Req. Specification Change Management Testing
Activity time
Early Start
Early Finish
Late Start
Late Finish
Slack
Standard Deviation
Project 14.13 0.52 Project Planning 3.16 0 3.16 0 3.16 0 0.33 Req. Determination 2.33 3.16 5.5 3.16 5.5 0 0.16 Req. Specification 2.33 5.5 7.83 5.5 7.83 0 0.16 Change Management 1.5 3.16 4.66 4 5.5 0.83 0.16 Testing 2.08 3.16 5.25 3.41 5.5 0.25 0.25 Design 6.3 7.83 14.13 7.83 14.13 0 0.33
PERT Results (Version 1)
Other Project Other Project ControlsControls
•Created group website tCreated group website to communicate, coordino communicate, coordinate, and share resourcesate, and share resources
•Risk assessment table to Risk assessment table to Manage RiskManage Risk
Requirements Requirements DeterminationDetermination
Mike FreyMike Frey
Kevin ConradKevin Conrad
Brian FanzoBrian Fanzo
AS-IS SystemAS-IS System
• Box DB (Common Database)Box DB (Common Database)– Home addressHome address– Local addressLocal address– Biographical/demographical dataBiographical/demographical data
• Rim DB (Registrars Information Rim DB (Registrars Information Module)Module)– Current classesCurrent classes– Class historyClass history– Degree detailDegree detail– Previous degree detailPrevious degree detail– TR credit detail (transfer courses)TR credit detail (transfer courses)– Course master (pre-requisites)Course master (pre-requisites)
• Dap (Degree Audit Program)Dap (Degree Audit Program)– Proposed course projectionProposed course projection– html formathtml format
AS-IS SystemAS-IS System
RIM (Registrarts Information Module)
BOX (Common Database)
Data Warehouse
n
n
n
n
Student
Advisor
Management (IT)
DAP (Degree Audit Program)
1
n
<<include>>
<<include>>
1
n
n
n
n
n
To-Be SystemTo-Be System
• Leave the GUI completely the same visually online. Leave the GUI completely the same visually online. • When the degree audit is printed it will be printed When the degree audit is printed it will be printed
exactly as the html document is displayed on the exactly as the html document is displayed on the screen.screen.
• Students/Advisors have permissions set to gain access.Students/Advisors have permissions set to gain access.– Advisors are only allowed to view each of their advisees’ Advisors are only allowed to view each of their advisees’
information.information.
• The RIM DB sends all its stored information about each The RIM DB sends all its stored information about each individual student to the data warehouse. This includes individual student to the data warehouse. This includes current classes, class history, degree detail, previous current classes, class history, degree detail, previous degree detail, TR credit detail, and the course master.degree detail, TR credit detail, and the course master.– When the course catalog is updated in the physical form, the When the course catalog is updated in the physical form, the
Course Master in the RIM DB will also be immediately updated.Course Master in the RIM DB will also be immediately updated.
To-be System To-be System (continued)(continued)
• The BOX DB is the central module that all other The BOX DB is the central module that all other modules reference for modules reference for biographical/demographical data. All addresses biographical/demographical data. All addresses are stored here so that they will be consistent are stored here so that they will be consistent throughout all the software modules and there is throughout all the software modules and there is no duplication of this type of data. In the new no duplication of this type of data. In the new system it is being renamed Common Data Base.system it is being renamed Common Data Base.
• The DAP projects the students remaining classes. The DAP projects the students remaining classes. – Calls the individuals premade degree audit from the Calls the individuals premade degree audit from the
data warehouse, and displays it on the screen. It gives data warehouse, and displays it on the screen. It gives the user a choice to process a proposed course the user a choice to process a proposed course projection, which is already compiled within the data projection, which is already compiled within the data warehousewarehouse
– The data warehouse creates the actual degree audit The data warehouse creates the actual degree audit for each student and stores it. It also will create the for each student and stores it. It also will create the proposed course projection by comparing the student’s proposed course projection by comparing the student’s current classes, class history, and the course master.current classes, class history, and the course master.
TO-BE SystemTO-BE System
RIM (Registrarts Information Module)
BOX (Common Database)
Proposed Course Projection
Data Warehouse
n
n
n
n
<<include>>
n
n
n
n
<<include>>
Student
Advisor DAP (Degree Audit Program)
1
1
1
1
<<extend>>
1
n
1
nManagement (IT)
Requirements Requirements SpecificationsSpecifications
Clint BennettClint Bennett
Ryan BushnellRyan Bushnell
Samantha BlevinsSamantha Blevins
Use Case DiagramUse Case Diagram
Get Student Information
AdministratorForce/Add/Drop CourseAdvisor
Student
Advising Student
Use case name: Advising Student ID: 1 Importance Level: high
Primary Actor: Advisor Use case type: Overview, Essential
Stakeholders and interests:AdvisorStudent
Brief Description:This use case describes how the advisor goes about getting a list of the advisee’s previous classes
Trigger:Student visits advisorType:
Relationships: Association: Advisor Included: Graduation Plan, Class Availability Extend: Generalization:
Normal flow of events:1.Advisor submits a search request for students previous academic history and degree plan2.The system provides a list of classes that have been taken and a list of classes left to take in the degree3.The advisor will choose to put the classes into a graduation plan4.The advisor will save the graduation plan to the database and print one for the student.5.Advisor will lot out of system
Subflows:
Alternative/exceptional flows:3a-1. The advisor will submit a search for availability for the classes that are for the upcoming semester.3a-2. The advisor iterates over step 2 through 3 until satisfied with the plan.
Use case name: Force/Add/Drop Course ID: 2 Importance Level: high
Primary Actor: Administrator Use case type: Overview, Essential
Stakeholders and interests:AdvisorAdministratorStudent
Brief Description:This use case describes how the advisor goes about forcing a student into a class or dropping a student from a class.
Trigger: Student goes to an administrator and requests to be added or dropped from a class.Type:
Relationships: Association: Administrator Included: Class availability, Current class plan, Graduation plan Extend: Generalization:
Normal flow of events:1.Student goes to administrator to drop/add/change a class.2.Administrator accesses system for the student’s current class plan.3.Administrator accesses system for the graduation plan.4.Administrator accesses system for the class availability.5.Administrator makes the changes that the student requests.
Subflows:
Alternative/exceptional flows:4a-1. This step may be skipped if the student is not adding a class.
Use case name: Get Student Information ID: 3 Importance Level: high
Primary Actor: Student Use case type: Overview, Essential
Stakeholders and interests:Student – Wants to know academic history, graduation plan, and class availability.
Brief Description:This use case describes how a student will access their academic history, graduation plan and class availability.
Trigger: Student wants to know academic history, graduation plan and class availability.Type:
Relationships: Association: Student Included: Class availability, Academic history, Graduation plan Extend: Generalization:
Normal flow of events:1.Student logs onto the system
If the student wants to access their academic history S-1: Academic history subflow is performed.If the student wants to access their graduation plan S-2: Graduation plan subflow is performed.If the student wants to access the class availability S-3: Class availability subflow is performed.
Subflows:S-1: Academic History:1. The student accesses their academic history over the internet.S-2: Graduation Plan:1. The student accesses their graduation plan over the internet.S-3: Class Availability1. The student accesses their class availability over the internet.
Alternative/exceptional flows: