Course Planning System for Efficient Academic Advising

1. ITEC 370: Software EngineeringProject Group 1October 8, 2002 Mike Frey Kevin Conrad Brian Fanzo Clint Bennett Ryan Bushnell Samantha Blevins Margaret Hale Nycole Capps Eric Adams

2. Project Planning Eric Adams Nycole Capps Margaret Hale

3. Course Planning System • Project Objectives • The Business Need as identified by Dr. Salter (The Project Sponsor) is to: • The goal of the Course Planning System is to develop a tool that will use the information in the student’s recordand the business rules for the completion of the student’s degree to project a complete plan for the student’s completion of the tenure at RU. • The Expected Value is an increased efficiency along with effectiveness of the advising process. • Business Process Automation (BPA)

4. Feasibility Analysis

5. Technical Feasibility • Familiarity with application (moderate) • Familiarity with technology (low) • Project size (high)

6. Economic Feasibility • Development Costs • Operational Cost • Tangible Benefits • Intangible Benefits

7. Organizational Feasibility • Project Champion • Dr. Christine Salter, ITEC Faculty Academic Advisor • Steering Committee • There is a strong support of the project within the Steering Committee • Jim Graham, RU IS Department • Becky Alls, RU Registrar’s Office • Susan Underwood, RU CIST Advising Coordinator • Users

8. Project ManagementWork PlanStaffing PlanControlling and Directing Project

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

10. Project Group #1 Staffing Plan

11. Time Estimation – Tracking TasksControlling and Directing the Project Based on Industry Standards for Business Applications Note: implementation not included Assuming 65% project completion of SDLC 14 week project Start Date = August 27, 2002 Completion date = November 26, 2002

12. Timeboxing • Due to limited time constraints and a large system scope, group 1 is using timeboxing techniques. • System Delivery: November 26 • Prioritize functionality • Graduation plan for degrees for CIST • Build the core of the system • Postpone functionality within the time frame • Deliver the system with core functionality • Repeat steps 3 through 5, to add refinements and enhancements

13. Tracking Tasks with PERT PERT Results (Version 1)

14. Course Planning System Gantt Chart

15. Group #1 Precedence Graph

16. Other Project Controls • Created group website to communicate, coordinate, and share resources • Risk assessment table to Manage Risk

17. Requirements Determination Mike Frey Kevin Conrad Brian Fanzo

18. AS-IS System • Box DB (Common Database) • Home address • Local address • Biographical/demographical data • Rim DB (Registrars Information Module) • Current classes • Class history • Degree detail • Previous degree detail • TR credit detail (transfer courses) • Course master (pre-requisites) • Dap (Degree Audit Program) • Proposed course projection • html format

19. AS-IS System

20. To-Be System • Leave the GUI completely the same visually online. • When the degree audit is printed it will be printed exactly as the html document is displayed on the screen. • Students/Advisors have permissions set to gain access. • Advisors are only allowed to view each of their advisees’ information. • The RIM DB sends all its stored information about each individual student to the data warehouse. This includes current classes, class history, degree detail, previous degree detail, TR credit detail, and the course master. • When the course catalog is updated in the physical form, the Course Master in the RIM DB will also be immediately updated.

21. To-be System (continued) • The BOX DB is the central module that all other modules reference for biographical/demographical data. All addresses are stored here so that they will be consistent throughout all the software modules and there is no duplication of this type of data. In the new system it is being renamed Common Data Base. • The DAP projects the students remaining classes. • Calls the individuals premade degree audit from the data warehouse, and displays it on the screen. It gives the user a choice to process a proposed course projection, which is already compiled within the data warehouse • The data warehouse creates the actual degree audit for each student and stores it. It also will create the proposed course projection by comparing the student’s current classes, class history, and the course master.

22. TO-BE System

23. Requirements Specifications Clint Bennett Ryan Bushnell Samantha Blevins

24. Use Case Diagram

28. Questions and Comments