project specification documentepics.ecn.purdue.edu/.../lcc/lccdetaildesigndoc2.docx · web...

EPICS – Fall 2010

Design Review Document

Lafayette Crisis CenterProject Partner ContactMike Silanskis

[email protected]

Project Team MembersZach Cassiday

Evan KahrigLara Schmidt

mailto:[email protected]


PROJECT SUMMARY FOR SCHEDULING SYSTEM

PROJECT FOR LCCCommunity Need:

The Lafayette Crisis Center (LCC) is a non-profit human service organization that fills a major need in Tippecanoe County and White County by providing round-the-clock crisis intervention, suicide prevention, and information and referral. Services are confidential, free and available by phone or in person 24 hours a day, 365 days a year (organization description from: http://epics.ecn.purdue.edu/lcc/). The members of the community have the ability to call the LCC at any time and reach a volunteer. Creating a volunteer schedule with all of the volunteer’s schedule preferences is time consuming work. With the use of our scheduling system, the volunteer’s schedule preferences are entered and a schedule will be automatically generated. The project partner will benefit from this project as the time spent making a schedule will greatly decrease. He will also be able to easily identify the shifts that do not have any volunteers. The scheduling system will also allow easy rearrangement of the schedule in case a conflict arises. This will make having a volunteer for every shift easier. The community will benefit from this as there will always be somebody to speak to at the LCC.

Project Goals:The goal of this project is to use a combination of Visual Basic and Python to generate

a schedule based on user input of each volunteer’s schedule. The Visual Basic and Python program will simulate, as close as possible, the manual way of creating the schedule. The result of the project will be a scheduling system that will be stored on the project partner’s Windows computer for their use. It will show the volunteers scheduled for each shift and the shifts with no volunteers will be left blank. It will incorporate “special requests”, which will account for specific days that a volunteer cannot work for. There will also be a check to see if the volunteers have worked fewer than 39 shifts, a request by Mike Silanskis, the person at the Lafayette Crisis Center who will operate our program. Also, as there are changes that occur after the schedule has been generated, the project will allow manual override.

Background Research:

2

http://epics.ecn.purdue.edu/lcc/


To create the scheduling system, our team reviewed our respective skills in programming in Visual Basic. There were different skills levels in using Visual Basic before the project started but all of the team members were familiar with programming languages. We were able to study some material, such as books and internet tutorials, to learn the skills necessary to do this project.

We also spoke to Mike Focosi of the Purdue Physics Department. Mr. Focosi is a Web Content Specialist who created a similar program to schedule physics teaching assistants. He uses PHP and AJAX for his scheduling system. Our team was able to observe the well designed user interface he created and the algorithm he used to schedule the different teaching assistants.

Our team also spoke with Nelson Uhan, a Purdue assistant professor of Industrial Engineering. Professor Uhan is experienced in scheduling. He suggested that our team use a linear programming method to develop the optimal schedule of volunteers. Our algorithm may not fully satisfy the requirements of the method but it is possible to optimize it with more knowledge of the linear programming method.

Systems Overview:As of now, our system has a graphical user interface that resembles the volunteer form

that Mike Silanskis uses to collect data from the volunteers. He will now be able to input each volunteer’s data into the graphical user interface. The data is then analyzed and then stored in a formatted file. After all the data is entered, the formatted file can be loaded back into the GUI for modifications to the schedule. The python program uses the data of shift preferences and volunteer information and creates a schedule. Finally, the program generates a calendar file based on the schedule and opens a program to view the calendar.

Design Used:Our team is using Visual Basic to program the graphical user interface portion of the

scheduling system. The reason we chose to use Visual Basic is it will allow us in the future to implement it online as an ASP application if Mike Silanskis would like the system online. This will allow individual volunteers to enter their schedule preferences, rather than Mike Silanskis. The actual scheduling algorithm is in a python script. The python script allows us to easily extract data from the formatted file and manipulate the data to create an optimal schedule. By splitting the project into two parts, the project has progressed further than if it was one part.

Current Status:As of now, our project in Visual Studio has a completed graphical user interface

(GUI). The user can input all the data of the volunteer’s schedule and submit the data. The

3


data is then written to a formatted file which maintains the information and preferences of each volunteer. The program is created to allow the formatted files to be saved in the current directory to allow access to previous schedule information. The formatted files can be loaded into the graphical user interface so Mike Silanskis can modify each volunteer’s preferences or information as needed. The python script creates a schedule based on preferences and the number of workers that would like to volunteer for each shift. It also analyzes data to see if a volunteer has worked the required number of training shifts or not, and it tries to make sure that it spaces out shifts for each volunteer. After the schedule has been created, the script generates a calendar file and opens a calendar reader, and imports the calendar file for viewing. The current version has been finished and delivered to our project partner for review, use, and feedback.

4


PROJECT SPECIFICATION DOCUMENT

Table of Content

1. User and Beneficiary Analysis...............................................................................................52. Customer/User Requirements................................................................................................5

a. Functional performance..................................................................................................5b. Human factors................................................................................................................6c. Reliability.......................................................................................................................6d. Cost................................................................................................................................6e. Service and maintenance................................................................................................7f. Ease-of-use......................................................................................................................7

3. Design Considerations...........................................................................................................7a. Familiarity......................................................................................................................7b.Programming Language..................................................................................................7c. Accessing Past Data........................................................................................................8

4. Evaluation Criteria.................................................................................................................85. Design Targets........................................................................................................................86. Discussion and Conclusion.................................................................................................8,9

5


1. User and Beneficiary Analysis Who will use the product and who will benefit from it? What are the users’ backgrounds, capabilities, etc.? How will they benefit from the project?

The project partner for this project is Lafayette Crisis Center (LCC). The LCC is a

non-profit human service organization that fills a major need in Tippecanoe County and

White County by providing round-the-clock crisis intervention, suicide prevention, and

information and referral. Services are confidential, free and available by phone or in

person 24 hours a day, 365 days a year (organization description from:

http://epics.ecn.purdue.edu/lcc/). Mike Silanskis at the Lafayette Crisis Center will use

our project, the scheduling system, to coordinate the volunteers’ shifts. He is computer

literate and will be able to operate our scheduling system on his Windows computer.

The project partner will benefit from this project as the time spent making a schedule

will greatly decrease. He will also be able to easily identify the shifts that do not have

any volunteers. The scheduling system will also allow easy rearrangement of the

schedule in case a conflict arises. This will make having a volunteer for every shift

easier. The community will benefit from this as there will always be somebody to speak

to at the LCC.

2. Customer/User Requirements

What are some of the following customer/user requirements should we consider in our project?

a. Functional performance

What do the customers/users need it to do?

The user is looking for a more efficient way of creating a schedule of all the volunteers’ shifts. Mike Silanskis would like to input the volunteers individual schedule preferences and have a computer generate a schedule. There would have to be a manual override option to give Mike Silanskis more flexibility. The scheduling system would

6

http://epics.ecn.purdue.edu/lcc/


simulate the manual way of creating the schedule as close as possible.b. Human factors

What are some of the usability issues? How do users interactive with the product/system?

The user will be able to run the system on his Windows operating system. The user will input the individual volunteers’ schedule preferences into a graphical user interface. The graphical user interface will then call the Python script containing the scheduling algorithm. An aesthetically pleasing text based interface will then be displayed containing the schedule.

c. Reliability

What is availability or the ability to perform the functions under stated conditions for a specified period of time?

How robust will the product/system be? How well will the product/system continue to operate under changing conditions?

There are many specifications that Mike Silanskis wants to be incorporated into the

scheduling system. It will show the volunteers scheduled for each shift and the shifts with no

volunteers will be left blank. It will incorporate “special requests”, which will account for

specific days that a volunteer cannot work for. There will also be a check to see if the

volunteers have worked fewer than 39 shifts. Also, as there are changes that occur after the

schedule has been generated, manual override must be implemented in the system.

Therefore, numerous tests must be conducted to see if the algorithm correctly analyzes all

these situations. Our program can also be easily adapted to changing specifications. In the

future, Mike Silanskis may prefer that the system is online so the individual volunteers can

enter their schedule preferences. Our team decided to use Visual Basic to program one part

of the scheduling system so that it will allow us in the future to implement it online as an

ASP application. Our team also decided to divide the project into two parts: the graphical

user interface for entering the volunteers’ information and a Python program that contains the

scheduling algorithm. By dividing the project into multiple parts, the project has progressed

much further and it is easier to modify the project with smaller parts.

7


d. Cost

As of now, our team has everything that is needed for this project. We are using Visual Basic to allow input of the volunteers’ preferences and a Python script that contains the scheduling algorithm. They are both on the Windows computers we are using.

e. Service and maintenance

Who will be responsible to service or support the product/system? How often is service and maintenance required?

If the system is having problems or Mike Silanskis desired an additional specification in the scheduling system, a person who is knowledgeable in programming would be needed to service the system. There is no regular service or maintenance required for this machine.f. Ease-of-use

How intuitive will the product/system be to the users? What prior knowledge should the users should have?

The project will be very easy for users to adapt to, as they need to just enter the data into the graphical user interface. Once the data is submitted, the program will take care of the rest of the work. The user should be computer literate.

3. Design Considerations

What are some of the following design considerations applied to the project?

a. Familiarity

Our system has a graphical user interface, as can be seen in Figure 1, Figure 2, and Figure 3, that resembles the volunteer form that Mike Silanskis uses to collect data from the volunteers.

8


Figure 1 Blank Graphical User Interface for a Volunteer

Figure 2 Sample Graphical User Interface Form for a Volunteer

9


Figure 3 Sample Calendar Output Using Mozilla Sunbird

b. Programming Language

Our team is using Visual Basic to program one part of the scheduling system. The reason we chose to use Visual Basic is it will allow us in the future to implement it online as an ASP application if Mike Silanskis would like the system online. This will allow individual volunteers to enter their schedule preferences, rather than Mike Silanskis. The actual scheduling algorithm is in a python script. The python script allows us to easily extract data from the formatted file and manipulate the data to create an optimal schedule. Our team is very comfortable using Python. The outline for the system is illustrated in Figure 4 below.

10


11


Figure 4 System Outline of the Visual Basic and Python Components

12


c. Accessing Past DataThe user can input all the data of the volunteer’s schedule and submit the data. The data

is then written to a formatted file which maintains the information and preferences of each volunteer. The formatted file can then be re-loaded into the graphical user interface and modifications to the schedule can be made. Therefore, Mike Silanskis has the control over the schedule that he desires.

4. Evaluation Criteria

What quantifiable and measurable criteria that can be used to evaluate preliminary designs and pre-existing (benchmark) products?

We can evaluate our scheduling system based on how well our system generates a schedule as compared to a manual way of generating the schedule. There are multiple ways of generating the manual schedule but our team would like the schedule that allows the volunteers’ to have their highest shift preferences. Our team would also like the volunteers to be spread out across the calendar and fill as many shifts as possible.

5. Design Targets

What are the design targets for each of the measurable criteria?

The results of the project will be a scheduling system that will be stored on the

project partner’s Windows computer for their use. It will show the volunteers scheduled

for each shift and the shifts with no volunteers will be left blank. It will incorporate

“special requests”, which will account for specific days that a volunteer cannot work for.

It will also incorporate a “special request” to assign a specific volunteer to work a

specific shift anytime during the month. There will also be a check to see if the

volunteers have worked fewer than 39 shifts, a request by Mike Silanskis. Also, as there

13


are changes that occur after the schedule has been generated, Mike Silanskis will be able

to manually rearrange or reassign individual shifts using the output program, Sunbird.

6. Discussion and Conclusion

What are overall technical issues, usability, and effectiveness of the solution that we have discussed?

Are there alternative possible solutions? What are they? How do they compare with the solutions we proposed?

The goal of this project is to use a combination of Visual Basic and Python to generate a schedule based on user input of each volunteer’s schedule. The Visual Basic and Python program will simulate, as close as possible, the manual way of creating the schedule. The result of the project will be a scheduling system that will be stored on the project partner’s Windows computer for their use. It will show the volunteers scheduled for each shift and the shifts with no volunteers will be left blank. It will incorporate “special requests”, which will account for specific days that a volunteer cannot work for. There will also be a check to see if the volunteers have worked fewer than 39 shifts, a request by Mike Silanskis, the person at the Lafayette Crisis Center who will operate our program. Also, as there are changes that occur after the schedule has been generated, the project will allow manual override. The reason we chose to use Visual Basic to allow the volunteers’ input information is that it will allow us in the future to implement it online as an ASP application if Mike Silanskis would like the system online. This will allow individual volunteers to enter their schedule preferences, rather than Mike Silanskis. The actual scheduling algorithm is in a python script. The python script allows us to easily extract data from the formatted file and manipulate the data to create an optimal schedule. The project partner will benefit from this project as the time spent making a schedule will greatly decrease. He will also be able to easily identify the shifts that do not have any volunteers. The scheduling system will also allow easy rearrangement of the schedule in case a conflict arises. This will make having a volunteer for every shift easier. The community will benefit from this as there will always be somebody to speak to at the LCC.

14


Alternative Solutions: There are different programming languages that can be used to write this scheduling system program but Visual Basic will allow us to adapt to further requests in the future easily compared to other programming languages. Python is also very easy to manipulate and can easily read the data from the formatted file using regular expressions.

CONCEPTUAL/DETAIL DESIGN REPORT

SummaryThe project partner is looking for a more efficient computer scheduling system. Mike

Silanskis, the user of the scheduling system, is computer literate. The LCC obtains schedules

with a preference for each shift from all of the volunteers by the 15th of each month. The

preferences are ranked in a scale with 0 being “not available” to 3 which is “highly

preferred”. There are 5 shifts a day, 7 days a week. Each shift is 4 hours long with the

exception of the first, morning shift. There are many schedules which makes creating a

schedule difficult. A scheduling system would make this much easier. Mike Silanskis would

like a system that allows him to input the volunteers’ schedule preferences and the system

will generate a schedule with all of his specifications. The team is using a combination of

Visual Basic and Python to create the scheduling system. The scheduling system should

simulate as close as possible to Mike’s manual way of creating the schedule. We are also

creating it with Mike’s request to have manual override as conflicts arise after the schedule

has been created.

Systems Overview and Design Considerations

Design

The schedule can allow Mike Silanskis to see when there are no volunteers

available. This will help him have a volunteer at the LCC 24/7. The community will

benefit as there will always be somebody to help them at the LCC. The mission of this

project is to use Visual Basic and Python to generate a schedule based on user input of

each volunteer’s schedule. The Visual Basic and Python program will simulate, as close

as possible, the manual way of creating the schedule.

15


When designing and modifying the illustrations through this software, our team must consider the following:

Appeal of user interfaceo The interface must offer a time saving approach to scheduling as necessary

Ease of use and simplicity of user interfaceo It should be straightforward and easy to navigate

Level of user engagement/interactiono It should be simple to navigate with and fast as far as progression goes.

Aestheticso The appearance should be visually stimulating

Time/project completion restraintso must be capable of completing the scheduling in the database within an

appropriate time frame User comprehension level

o The purpose of the system should be understood by someone with little knowledge of computer applications so that it is not hard to use for anyone

DeliveryVersion 1.3 of the program was delivered to Mike Silanskis on 20 April, 2010. Version 1.5 of the program was delivered to Mike Silanskis on December 3, 2010.

Future GoalsThe future goals of this project are to make corrections to any problems Mike Silanskis

encounters during his use of the program and to implement improvements suggested by him. The team will also discuss with him the potential benefits of creating an online version of the application that may be even more useful to the LCC.

16

project specification documentepics.ecn.purdue.edu/.../lcc/lccdetaildesigndoc2.docx · web...

Documents