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)

Feasibility Feasibility AnalysisAnalysis

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)

Course Planning System Course Planning System Gantt ChartGantt Chart

Group #1 Precedence Group #1 Precedence GraphGraph

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:

Questions and Questions and CommentsComments