Team-Awesome

csus logo

Project Proposal: Faculty Information Cards

For California State University Sacramento, Computer Science Department

Version 2.0 March 10, 2017
Team Members: Aitken, Connor Binjola, Devesh Duan, Cindy
Hairabedian, Bryce Newaz, Shah Wadsworth, Robert

Reason for this document (To who? And Why?) This document provides the responce to the project proposal given by our instructor Professor Dale Fletter.

This document also includes the ‘Vision and Scope’, and the ‘Estimated cost and effort’ of the project.

Table of Contents

1. Business Requirements

1.1 Background / Current System

1.2 Business Opportunity

1.3 Business Objectives

1.4 Success Metrics

1.5 Vision Statement

1.6 Business Risks

1.7 Business Assumptions and Dependencies

2. Scope and Limitations

2.1 Major Features

2.2 Scope of Initial Release

2.3 Scope of Subsequent Release

2.4 Limitations and Exclusions

3. Business Context

3. 1 Stakeholder Profiles

3.2 Project Priorities

3.3 Deployment Considerations

4. Estimate of Cost and Effort

4.1 Team Resumes

4.2 Product Backlog

4.3 Total Work Hours

1. Business Requirements

1.1 Background / Current System

The Computer Science (CS) department must post faculty information cards each semester outside the office where they sit. The information cards are printed for each semester to include information for the faculty member, the courses he/she teaches, and office information including location, phone number and times that the faculty member can be found there.

**Current System: **

Persistent information block contained in the upper portion of the faculty card is consistent across semester, ex: Fall 2016.

The Middle portion of Course, Section, Days, Time, and Room information is manually transferred and entered into Enrollment Document by Clerk, currently Alysa.

The Bottom portion of the Faculty card information including Office Hours, Office, and Phone is currently entered in manually by the Clerk. The information is provided by email from each instructor to the Clerk, currently Alysa.

1.2 Business Opportunity

A new software system should be designed and implemented that will ease the administrative burden required to produce the printed Faculty Information Cards. The system needs to be usable by staff without requiring a high degree of technical skills. The software should be generalized so that it may be easily migrated or scaled to other departments, campuses or schools.

The software is intended for internal department. Optionally, other departments may utilize the system but will be required to have their own administrator and clerk. Any administrator would be able to set up their own clerk, create another department and grant authority to the admin or reset another admin’s password.

The new system can streamline some of the administrative overhead by allowing faculty to access the system and enter their own office hours as well as automate the ETL process when downloading the schedule data from Space Management.

1.3 Business Objectives

The objective is to create a tool that retrieves information about a faculty member from a database system and uses that information to generate faculty information cards.

1.4 Success Metrics

Acceptance criteria 1: The system should include the automation of the necessary information being printed into all the cards using information provided by the user

Acceptance criteria 2: The system should also be capable of printing a single card upon request.

Acceptance criteria 3: The information about a faculty member should only be changeable by the office administrator.

Acceptance criteria 4: The entry of faculty office hours and the viewing of all information is allowed for the clerk.

Bonus acceptance criteria

1.5 Vision Statement

To create a user-friendly automated software that helps CS faculty administration generate accurate faculty information cards.

Desired End-State: A sleek software tool that helps the CSUS faculty administration create information cards.

1.6 Business Risks

No business risks have been identified for the implementation of this system. If the system is adopted, having a single admin is a potential single point of failure. The system should consist of a global administrator(s), application administrator(s), and user(s) for a more robust management framework.

1.7 Business Assumptions and Dependencies

2. Scope and Limitations

2.1 Major Features

Elevator Pitch: A partially automated ‘Faculty Office Hour’ card system for the Department of Computer Science California State University Sacramento.

Capable of housing all pertaining information relating to the Faculty Card per each faculty member, updating or creation of new faculty/class information, and the actul printing of the faculty card after such information has been verified by all parties.

Parties & Users include : CS Department, Instructors, ABA(Administration & Business Affairs), and Admins to the system.

2.2 Scope of Initial Release

Users

Initial Release

The initial release will consist of a large subset of desired features. These features are provided in terms of User Story epics that convey the scope of work to be considered “Done.”

2.3 Scope of Subsequent Release

Deliverables to be deferred in initial release

2.4 Limitations and Exclusions

The option to create multiple academic is not planned for this release but will be an additional feature in future releases.

3. Business Context

3. 1 Stakeholder Profiles

Office Administrator (Reyna) - Downloads class schedule data from Space Management (ABA) and transfers to local database (ETL). Receives office hour information by email and enters this information into the database.

Clerk (Alysia) - Pulls data from local database and uses Microsoft Word mail merge to prepare the Faculty Information Cards for printing.

Computer Science Department Faculty - Notifies Veronica Pruitt by email of office hours.

Students - Relies on faculty information cards to get meet with faculty for help outside of class.

IT Staff - There may or may not be IT staff required to install faculty information card software, setup/maintain database and maintain respective servers.

3.2 Project Priorities

3.3 Deployment Considerations

The Oracle database 12.12 is required to be installed on the database server, and apple browser and windows explore need to be upgraded to the newest version on the web server. Application server have to be ready one day before promote all the program objects from test environment to production. One additional backup printer has to be ready for print the faculty information cards.

4. Estimate of Cost and Effort

4.1 Team Resumes

Bryce Hairabedian

Shah Newaz

Connor Aitken

Robert Wadsworth

Devesh Binjola

Cindy Duan

4.2 Product Backlog

Our Product Backlog below is organized according to priority set by Product Owner.

Priority Sprint Feature / Story / Item ————– ———— ———————————————————————————————————————— 1 1 Get/pull class schedule data from Space Management (ABA) populate database automatically for the Office administrator. 2 2 Create web interface for Instructors to be able to upload Office Hours, Office Room, Email. 3 2 Present class schedule data on a web interface for the Office Administrator (Reyna.) 4 3 Create view for individual faculty member to edit/add/remove information during current semester. 5 3 Automated print feature upon change to any faculty member information.

4.3 Total Work Hours

The estimated total hours worked is per person per week basis. Six total team members expected to contribute at roughly six hours per week. And a strict deliverable date of May 15th currently leaves ten weeks remaining. Resulting in 360 estimated hours to be worked by Team Awesome.