course scheduling system software development plancba.winthrop.edu/css/documentation/css_sdp.pdf ·...

Course Scheduling System Software Development Plan 22 April 2003 Document: Course Scheduling System -SDP

______________________________________________ CSCI 680 Project Leader Randy Jackson

CSS Software Development Plan

Page i

Contents CONTENTS................................................................................................................................................... I

REVISION SHEET......................................................................................................................................II

REVIEW HISTORY....................................................................................................................................II 1. INTRODUCTION.....................................................................................................................................1

1.1 Project Overview.........................................................................................................................1 1.2 Project Deliverables....................................................................................................................1 1.3 Evolution of the Plan ...................................................................................................................2

2. PROJECT ORGANIZATION .....................................................................................................................3 2.1 Structure ......................................................................................................................................3 2.2 Project Tasks ...............................................................................................................................4

1.2.1 Initiation Phase....................................................................................................................................... 4 System Concept Development Phase................................................................................................................... 4 Planning Phase..................................................................................................................................................... 5 Requirements Analysis Phase .............................................................................................................................. 5 Design Phase........................................................................................................................................................ 5 Development Phase.............................................................................................................................................. 5 Integration and Test Phase ................................................................................................................................... 5 Implementation Phase.......................................................................................................................................... 6 Operations and Maintenance Phase ..................................................................................................................... 6 Disposition Phase................................................................................................................................................. 6

2.3 Project Changes ..........................................................................................................................7 3. TECHNICAL APPROACH ........................................................................................................................7

3.1 Work Packages ............................................................................................................................7 3.2 Tools, Techniques and Methods ..................................................................................................8 3.3 Design..........................................................................................................................................8 3.4 Implementation..........................................................................................................................15 3.5 Testing .......................................................................................................................................15 3.6 Installation, Acceptance and Sign-off........................................................................................15

4. MANAGERIAL PROCESS......................................................................................................................16 4.1 Objectives and Priorities ...........................................................................................................16 4.2 Risk Management and Lessons Learned....................................................................................16 4.3 Monitoring and Controlling Mechanisms .................................................................................16

APPENDIX A REQUIREMENTS...........................................................................................................17

APPENDIX B PROJECT PLAN .............................................................................................................18 APPENDIX C ACRONYMS, DEFINITIONS, AND REFERENCES.......................................................................19

C.1 Acronyms...................................................................................................................................19


Page ii

Revision Sheet

Revision Number

Date

Brief summary of changes

POC

V.0 3/7/03 Baselined Robert Roulhac

V.01 4/1/03 1st Review Robert Roulhac

V.02 4/22/03 2nd Review (still need to update

Detail Design section with new

screen prints)

Robert Roulhac

V.03 4/28/03 Added Screen Prints Robert Roulhac

Review History

Reviewed by Date Reviewed Comments

Chlotia Garrison 4/17/03 Need to update with recommendations discussed in class


Page 1

1. Introduction

1.1 Project Overview The Associate Dean, and Department Chairs, and Director need a software application that enables them to schedule courses. The Course Scheduling System (CSS) will enable the Department Chairs to enter information such as faculty name, course, time, and a tentative room number into an existing grid that will serve as a course schedule. Each of these users will be able to see a full grid of what has already been entered by others. They may also perform maintenance functions such as adding a new course, instructor, or room. The CSS will present an error (flag) for various conflicting entries. The faculty will be able to use this application to view and print a variety of reports. These reports can be obtained by selecting the type of report desired. The Associate Dean will be able to perform all previously listed functions, and will be able to make any changes or modifications to the main schedule. The primary goal of the CSS is to provide a convenient means for the Department Chairs to schedule courses. This system should drastically reduce the time and complexity of the manual process that is currently in place, allowing the Chairs to initially enter a schedule that will require only a few changes. By seeing a common grid possible conflicts before they occur, and warning ‘flags’, this objective will be obtainable. With the implementation and utilization of the CSS, the entire course scheduling process will become more effective and efficient, benefiting the Associate Dean and the Department Chairs. This Software Development Plan (SDP) also provides a summary of the project objectives, the product to be delivered, major work activities, major work products, major milestones, required resources, and a master schedule.

1.2 Project Deliverables Artifact Date Due Created by Delivered to Software Development Plan

4/1/2003 Robert Roulhac Professor

Software Requirements Specification

4/28/2003 Kevin Lavender Professor

RTM 4/28/2003 Kevin Lavender Professor Test Plan 4/18/2003 Randy Jackson Professor User Guide 4/1/2003 (review) Jeremy Taylor Professor Maintenance Document

4/29/2003 Robert Roulhac Professor

Prototype 3/18/2003 Class Users Final Deployment 4/28/2003 Class Users/Professor All project documentation will exist at: http://cba.winthrop.edu/css/documentation/


2 Introduction Version 1.0

1.3 Evolution of the Plan Robert Roulhac will be responsible for updating the SDP as well as the Microsoft Project Plan. Both will reside on Birdnest so that everyone has access to it. This SDP and project schedule should be reviewed periodically to ensure that the project meets its target dates.


Page 3

2. Project Organization

2.1 Structure

Chlotia GarrisonProfessor

Jeremy TaylorSoftware Engineer

Kevin LavenderSoftware Engineer

Randy JacksonProject Lead

Robert RoulhacSoftware Engineer

UsersFaculty


Page 4

2.2 Project Tasks

The Software Process will consist of ten phases:

1.2.1 Initiation Phase

The initiation of the CSS system began when Dr. Garrison discovered that there was a need for an automated process for scheduling classes, which previously had been done manually. Randy Jackson has been appointed Project Leader to manage the project. There is no truly Conceptual Proposal; however, the mandate from the professor will suffice.

System Concept Development Phase

Since this business need was approved as a requirement for CSC680, there is no need for funding. However, the scope of this project will be identified in the requirements specification document.


Page 5

Planning Phase

To ensure the products and /or services provide the required functionality on time, the project resources, schedules, tools, and reviews will need to be defined. The project resources will consist of the project members mentioned in the project organization section of this SDP. The tools that will be used in the creation of this software package are:

• Microsoft Visual Interdev 6.0

• Microsoft SQL Server 2000

• Microsoft Windows XP Pro

• Microsoft IIS

• Microsoft Internet Explorer (5.5 or higher)

• CBA and Birdnest Web Servers

Requirements Analysis Phase

Functional requirements will be formally defined in the requirements specification document. All requirements are defined to a level of detail sufficient for systems design to proceed. All requirements need to be measurable and testable and will be traced back to the RTM.

Design Phase

The physical characteristics of the system will be designed during this phase. The logical data model, use cases, screen prototype and ERD will be developed in this phase. Appropriate tools and environment will be deployed for which the system will reside.

Development Phase

The requirements specifications will be translated into an executable artifact. The artifact will be unit tested, integrated, and retested in a systematic manner.

Integration and Test Phase

The components from the unit test will be integrated and tested to ensure that the functional requirements as outlined by the SRS have been met. The users will have a chance to review the prototype to ensure that it has met the functional requirements as defined in the SRS. A test plan will be developed and will address both system and UAT activities.


Page 6

Implementation Phase

There has been a website and SQL database secured for deploying the application into production. If the users signoff on UAT testing, Jeremy will install all components into production.

Operations and Maintenance Phase

All maintenance activities will be minimal but ongoing support will need to be addressed by the next class or appropriate authorities.

Disposition Phase

Data, databases, and documentation will need to be archived for future access. The archives will reside on the website as well.

Planning Document

RTM Plan C R R R R F * * Configuration Management Plan (manual) C R R R F * * Project Management Plan C R R R F * Specification Requirements Document C F Test Plan C R R F * * System Test (SIT) C R F User Guide C R F * * Software Development Plan Document C R F * Test Files/Data/Databases C F * Test Problem Report C UAT Acceptance C/F Deployed System C/F * Maintenance Document C KEY: C=Created R-Revised F=Finalized *=Updated if needed


Page 7

2.3 Project Changes All requirements whether functional or nonfunctional will be communicated through Kevin Lavendar. He will update the SRS and RTM with the appropriate changes while reviewing with the users and other team members.

3. Technical Approach

3.1 Work Packages Below is a table listing Report/Screen names and the resource assigned for that particular coding effort or work unit:

Type Report/Screen Report Breakdown Resource Grid Faculty Schedule All professors

All Dept Discipline Professor

Randy

List Faculty Schedule All professors All Dept Discipline Professor

Kevin

List Professor Course Load All professors All Dept Discipline Professor

Jeremy

Grid Room Grid N/A Robert Maintenance Screens Class Rooms N/A Randy Maintenance Screens Courses N/A Kevin Maintenance Screens Instructors N/A Jeremy Maintenance Screens Semesters N/A Robert


Page 8

3.2 Tools, Techniques and Methods There are several tools that will be used to ensure that this project is a success. The database will be stored on an SQL database. SQL Server 2000 will be used to access the information. ASP webs pages will be used to create the online view on the application as well as interfaces (ADO) with SQL. Visual Studio and Interdev will be used to create the artifacts for the system (dependent upon what each programmer has access to). A website on Birdnest will be used for the application. Jeremy Taylor will perform all updates to the ASP and SQL on Birdnest. He is manually conducting version control since this project does not have the resources to house a configuration management tool (other team members do have access in case Jeremy is unavailable). Peer reviews will be facilitated by Dr. Garrison on the workplan schedule, user guide, code design and test plan at times that will be decided by team members. A prototype will be created for the users with minimal functionality. Randy Jackson will execute the prototype on his laptop.

3.3 Design At this point we did not truly do a Detail Designed Document because of the problems with getting the functional requirements so late in the project. However, a sequence diagram, use cases, ERD, and screen snapshots for creating the prototype were done to expedite the design of the system (documentation listed below). Also, some class sessions were devoted to designing the system.


Page 9

Sequence Diagram:

Web Data Access Database

Sequence Diagram For Schedule Course

intRetVal()

spInsertSchedule()

Execute()

DataAccessScheduleSummary

intRetVal()

RunSP()

InsertSchedule()

CloseDialog()()

ShowDialog(ScheduleAddEdit)()

Modif y Schedule(CourseID)()

SQL


Page 10

Logical Database Design for CSS (ERD):

Schedule

ScheduleID

SemesterID (FK)CourseID (FK)RoomID (O) (FK)UserID (O) (FK)DayCodeID (FK)TimeCodeID (FK)

Course

CourseID

DesignationID (FK)CourseNumberSectionNumberCallNumberHoursDescription

DayCode

DayCodeID

DayCodeTextSelectionTextDescription (O)SortOrder (O)

Semester

SemesterID

Description (O)StartDate (O)EndDate (O)

TimeCode

TimeCodeID

Description

DayCodeTimeCode

DayCodeID (FK)TimeCodeID (FK)

Users

UserID

RoleID (FK)FirstNameLastNameInitials

Designations

DesignationID

CodeDescription (O)

Role

RoleID

DescriptionRoleDesignations

RoleID (FK)DesignationID (FK)

Room

RoomID

DescriptionBuildingNumberCapacity (O)

Use Case for Scheduling A Course:

Use case: Schedule A Course

ID: UC1 Actors: Associate Dean, Department Chair Preconditions:

1. The User has been authenticated by the system.

Flow of events: 1. This use case begins when the user selects “Schedule Courses” 2. The system displays a web page which consists of two frames. One

frame lists all courses which the current user is authorized to schedule. The second frame displays the current schedule (see prototype screen css1.jpg).

3. The user selects a course from the list of courses. 4. The system displays a dialog box which contains course details and

selection lists for room, instructor, day(s), and time of the course (see prototype screen css2.jpg).

5. The user selects the appropriate day and time for the course and optionally selects a room and an instructor.

6. The system filters the time selection list based on the appropriate day(s) selected for the course (i.e., if MWF is selected then TTH time blocks are not shown)


Page 11

7. The user clicks the save button. 8. The system saves the user’s choices and redisplays the screen to show

the refreshed grid containing the new scheduling entry (see prototype screen css3.jpg).

Secondary scenarios: Postconditions:

1. The course is successfully scheduled.


Page 12

Use Case for Editing A Course: Use case: Editing A Course

ID: UC1 Actors: Associate Dean, Department Chair Preconditions:

1. The User has been authenticated by the system. 2. The course information has been previously scheduled.

Flow of events: 1. This use case begins when the user selects (clicks on a hyperlink for) a

previously scheduled course in the schedule table. All schedule table entries will be hyperlinked.

2. The system displays a dialog box which contains course details and selection lists for room, instructor, day(s), and time of the course (see prototype screen css2.jpg).

3. The user modifies the previously saved day and time for the course and optionally modifies the room and/or instructor selection.

4. The system filters the time selection list based on the appropriate day(s) selected for the course (i.e., if MWF is selected then TTH time blocks are not shown)

5. The user clicks the save button. 6. The system updates the user’s choices and redisplays the screen to

show the refreshed grid containing the updated scheduling entry Secondary scenarios: Postconditions:

2. The course schedule is successfully updated.


Page 13

The following three screen snapshots will be used to prototype the application:


Page 14


Page 15

3.4 Implementation

There has been a website and SQL database secured for deploying the application into production. If the users signoff on UAT testing, Jeremy will install all components into production.

3.5 Testing Randy Jackson will create the Software test plan. SIT will start the week of 4/14/03 and end approximately 4/21/03.

3.6 Installation, Acceptance and Sign-off UAT will be conducted the week of 4/21/2003 with the deployment to production slated for the following week pending user signoff. All signoffs will be required from the users before the application is actually installed into production.


Page 16

4. Managerial Process

4.1 Objectives and Priorities The Project Leader will have responsibility for managing the project with the support of the project team, professor, and users. The Project Leader is responsible for ensuring that project tasks and deliverables are completed on time and reviewed by the appropriate members of the project team.

4.2 Risk Management and Lessons Learned Status Reports will be conducted every 3 weeks with each project member in the CSCI680 class facilitating the meeting while also providing a powerpoint document. Risks and other issues associated with the project will be addressed at that time. Every team member has the responsibility to document and address issues/problems that may impact the success of this project. All risks will be communicated to the team and users. All issues will be tracked and a Lessons Learned document will be produced toward the end of the project life cycle.

4.3 Monitoring and Controlling Mechanisms Status Reports will be conducted every three weeks. Peer reviews will be conducted at the discretion of the Professor or Project Leader.


Page 17

Appendix A Requirements http://cba.winthrop.edu/css/documentation/css_srs.pdf


Page 18

Appendix B Project Plan http://cba.winthrop.edu/css/documentation/css.mpp


Page 19

Appendix C Acronyms, Definitions, and References

C.1 Acronyms

UAT User Acceptance Testing CSS Course Scheduling System SDP Software Development Plan SRS Software Requirements Specification

MPP Microsoft Project Plan STP Software Test Plan

course scheduling system software development plancba.winthrop.edu/css/documentation/css_sdp.pdf ·...

Documents