Abstract

This is the documentation for a course project in COMP305 Software Engineering, Spring 2017. The project is based upon this template and this description, and follows the development of an information technology system for a small business, Showtime Sound & Lighting.

Introduction

Purpose

The purpose of this report is to document the current status of the information technology systems at Showtime Sound & Lighting and to lay out a plan of action to replace these systems with a new, custom-built system.

Background

Showtime Sound & Lighting has, to date, been using a system intended for a single user. At that small a scale, all of the information of the company can be said to exist in the mind of that single user, and whatever system they design for themselves is the best case. Unfortunately, such systems generally do not scale well for multiple employees, and with the current larger roster of employees, and future plans to further grow the company, developing a system that will function well for a larger number of employees is of critical importance.

Scope

The system to be designed is for use by the employees of Showtime Sound & Lighting. All interaction with the system by customers will be mediated by employees of the company, thus reducing the complication of outward-facing functionalities.

Structure

The report begins with this introductory section, covering the purpose, background information, and scope of the project. From there, it goes to define the standards and specifications used for the documentation of the project, and the environment in which the software was developed. From there, it goes to an in-depth system specification, laying out the way the system will be designed. Next is the program specification, similar to the system specification but focusing on what the programmer(s) will need to construct and deliver the programs in the system. Then come the implementation details, covering the budget, staffing, and time needed to develp the system. Finally comes the conclusion, providing a high-level summary of the report.

Standards and Specifications

Documentation

The documentation for this project follows the Unified Modeling Language structure, and will follow the various object-oriented design techniques described within that system.

For a detailed explanation of any of the content used herein, see Systems Analysis & Design: An Object-Oriented Approach with UML by Dennis, Wixom, and Tegarden.

Technical Environment

The software will be developed on and for the Microsoft Windows computing environment, specifically making use of the Windows Forms software platform. Any computer capable of running Microsoft Windows 7 or later will be capable of running the client-side software. Also necessary will be a single computer to function as the central server, hosting the database and document storage systems.

System Specifications

System Requirements

  • The system must be able to match customer requests and available equipment.
  • The system must be able to produce reports.
  • The system will enable an employee to login before using
  • the system.
  • The system will enable employees to generate bid proposals.
  • The system will enable employees to generate invoices.
  • The system will enable executives to generate reports to support decision making.
  • The system will enable an office manager to maintain customers.
  • The system will enable an office manager to maintain employees.
  • The system will enable an office manager to view employee schedules.
  • The system will enable an office manager to maintain contractors.
  • The system will enable an office manager to view current equipment being rented.
  • The system will enable an office manager to view a history of equipment rentals.
  • The system will enable a field technician to maintain consultations.
  • The system will enable a field technician to maintain installations.
  • The system will enable a field technician to evaluate the contractor’s performance.
  • The system will enable a field technician to note equipment problems.
  • The system will enable a customer to request a consultation.
  • The system will enable a customer to rent equipment.
  • The system will enable a customer to buy equipment.

Feasibility Analysis

Technical

Developing the system within the Microsoft Windows software environment allows the employees to continue using the equipment they already have without the steep learning curve required by a new system. This also allows the company to continue using equipment they already have without requiring large-scale purchases.

Economic

SSL, as a small company, has a capital budget of $15,000 for system development. Without development of the new system, however, an estimated loss of 5-10% of customers due to inefficiencies can cause a serious decrease in revenue.

Organizational

Since SSL currently only has 4 employees, training all of them to use a new system - especially one well-designed around the needs of the company - would not require a significant time investment. Switching to the new system now, prior to the planned increase in the staffing of the company, also allows the use of the new system to replace the use of the old system in new employee training, and thus reduces the burden on all employees.

Use Cases

Login to system
Actors: Employees, system
Employees have their own unique username and password with which they can access the system.
Generate bid proposal
Actors: Employee, Customer
Employees are able to generate proposals for work, allowing SSL to submit a bid to the customer.
Generate invoice
Actors: Employee, Customer
Employees generate invoices to be sent to customers, billing them for whatever order(s) the customer has not yet paid for.
Track hours worked
Actors: Employee, Contract/Temporary Worker
Employees track the hours they have worked, as well as tracking the hours that contract/temporary workers have worked, ensuring they are paid the correct amount. Overtime may be tracked, as well.
Generate report
Actors: Executive
Executives are able to generate reports on all aspects of the business in order to support high-level decision making.
Maintain customers
Actors: Office manager (manager), customer
Managers add, update and delete customers from the database.
Maintain employee
Actors: Manager, employee
Managers add, update and delete employees from the database.
Maintain contractors
Actors: Manager, contractors
Managers add, update and delete contractors from the database.
View employee schedule(s)
Actors: Manager, Employee
Managers can view employee schedules in order to ensure an employee is available to work on a scheduled contract.
View Contract/Temporary Worker list
Actors: Manager, Contract/Temporary Worker
Managers can view a list of all contract/temporary workers that SSL has in order to schedule them for a contract.
View rented equipment
Actors: Manager, Equipment
Managers can view a list of rented equipment in order to ensure the necessary equipment is available for a contract.
View equipment rental history
Actors: Manager, Customer, Equipment
Managers can view a history of equipment rentals in order to project future use and make recommendations for or purchases of new equipment.
Maintain consultations
Actors: Technician, customer
Technicians add, update, and delete consultations from the database.
Maintain installations
Actors: Technician, customer
Technicians add, update, and delete installations from the database.
Note equipment problems
Actors: Technician
Technicians write down any equipment problems they may encounter during a consultation or installation.
Request consultation
Actors: Customer, technician
Customers can request a technician to survey the current equipment.
Request instillation
Actors: Customer, technician
Customers can request a technician to install rented equipment or bought equipment.
Rent equipment
Actors: Customers
Customers can borrow equipment from SSL for an allotted time.
Buy equipment
Actors: Customers, technicians
Customers can buy equipment from SSL with help from a technician if it's cheaper than renting equipment.

Use Case Model

Click to view full-size.

Use Case Scenarios

Click on the title of a use case scenario to view it.

Summary
Executives are able to hire and fire employees, and need to be able to manage employee records to do so.
Pre-Conditions
The executive needs to manage an employee's records. The executive must be logged in to the system.
Special Requirements
None
Post-Conditions
The employee's records have been updated.

Flow of Events

Basic Flow

The use case begins when the executive requests that the system allow them to manage an employee's records.

  1. The system presents the executive with a list of all of the employees.
  2. The executive selects an employee to edit, or has the system create a new, blank employee record.
  3. The executive edits the information, or fills in new information, and tells the system to save the changed record.

Alternate Flow(s)

Removing an employee
While editing the employee's information (step 3, above) the system provides an option to delete the employee record.
Summary
Executives are able to generate reports on all aspects of the business in order to support high-level decision making.
Pre-Conditions
The executive needs a report. The executive is signed in to the system.
Special Requirements
None
Post-Conditions
A report has been generated.

Flow of Events

Basic Flow

The flow begins when the executive requests that the system generate a report.

  1. The system requests information on which report to generate.
  2. The executive provides the information about which report to generate, and the system generates the report.
  3. If the executive desires, the report can be printed or saved as a PDF.

Alternate Flow(s)

None.

Summary
Technicians can use the system to track problems with equipment in order to make timely repairs or maintenance.
Pre-Conditions
A technician is available to work with the equipment. The technician is logged in to the system.
Special Requirements
All equipment problems should be logged upon the problem being discovered.
Post-Conditions
Equipment problems have been logged or, if previously logged, the damaged equipment is being repaired or replaced.

Flow of Events

Basic Flow

The flow begins when a technician finishes a contract and returns with the equipment, or when the technician is going to repair any equipment that has been logged as damaged.

  1. The technician requests the list of equipment problems.
  2. If logging a new problem, the technician requests a new, blank equipment problem form. If repairing an already-logged problem, the technician requests an existing equipment problem form.
  3. The technician makes changes to the form as necessary, and saves the result.
  4. If the equipment has been fully repaired, the problem is removed from the list.

Alternate Flow(s)

Equipment damaged beyond repair
The equipment is removed from the list of available equipment, and the technician notifies management so that a replacement, if necessary, may be ordered.
Summary
In order to maintain high working standards, technicians evaluate the quality of work of the contract/temporary workers.
Pre-Conditions
A job has been completed. A contract/temporary worker was employed for the job. A technician accompanied them. The technician is logged in to the system.
Special Requirements
None
Post-Conditions
The performance log for the contract/temporary worker has been updated.

Flow of Events

Basic Flow

The flow begins at the end of a job, when a technician accesses the system to log the performance of the contract/temporary worker(s) that was/were on the job.

  1. The technician requests a new contract/temporary worker review form.
  2. The system provides the form, and the technician fills the form.
  3. The technician completes the form, and the system saves it.

Alternate Flow(s)

Technician cancels
The system reminds the technician of the company policy, that all contract/temporary workers should have their performance logged after all jobs, but the system will allow the technician to exit without logging the performance review.
Bad review
If the review of the worker is bad, their work is flagged for management to review and potentially remove them from the list of contract/temporary workers so as to avoid future low-quality work.
Summary
Employees are able to generate proposals for work, allowing SSL to submit a bid to the customer.
Pre-Conditions
A customer has requested a proposal for work. An employee has received the request.
Special Requirements
None
Post-Conditions
A proposal for work has been generated and sent to the requesting customer.

Flow of Events

Basic Flow

The flow begins when a customer requests a proposal for work.

  1. The receiving employee opens a new proposal.
  2. The employee fills out the proposal using the information given to them by the customer.
  3. When the proposal has been filled out, it is sent to the customer for review.

Alternate Flow(s)

Customer cancels
The order is marked as cancelled and removed from the system.
Insufficient information
The employee contacts the customer and asks for the necessary information.
Summary
Employees are able to generate orders, through which the system tracks purchases, rentals, and other transactions with customers.
Pre-Conditions
A proposal has been generated and accepted by the customer.
Special Requirements
For complex orders, a manager may be required - varies with company policy.
Post-Conditions
An order has been generated detailing the work to be done or the transaction to be completed.

Flow of Events

Basic Flow

The flow begins when a customer accepts a proposal.

  1. The employee selects the accepted proposal from a list of accepted proposals.
  2. The system uses the information in the accepted proposal to generate an order.
  3. If any changes to the order need to be made, the employee makes the changes.
  4. The employee or employees, depending upon the order, fulfill the order.

Alternate Flow(s)

Order cancelled
If the customer cancels the order, it is marked as cancelled within the system. If it is necessary to generate an invoice for the time already billed on the order, that process is done.
Summary
Employees generate invoices to be sent to customers, billing them for whatever order(s) the customer has not yet paid for.
Pre-Conditions
A customer has work that has not yet been paid for.
Special Requirements
None
Post-Conditions
An invoice has been sent to the customer for the unpaid work.

Flow of Events

Basic Flow

The flow begins when work for a customer on an order has been completed.

  1. The employee marks the order as completed but unpaid.
  2. The employee requests that the system generate an invoice for the unpaid order.
  3. The system sends the invoice to the customer.
  4. The customer pays the invoice, and the order is marked as completed and paid.

Alternate Flow(s)

Unpaid order
If the order is to be unpaid, a manager may override the system and skip the invoice-generation process.
Incorrect bill
If the bill is incorrect, a manager may override the system-generated invoice and replace the billed amount with a different amount.
Summary
Employees track the hours they have worked, as well as tracking the hours that contract/temporary workers have worked, ensuring they are paid the correct amount. Overtime may be tracked, as well.
Pre-Conditions
The employee is loged in to the system.
Special Requirements
None
Post-Conditions
The worked hours have been logged.

Flow of Events

Basic Flow

The flow begins when an employee or contract/temporary worker has logged hours.

  1. If logging their own hours, the employee selects themself from the list of employees and contract/temporary workers.
  2. If logging hours worked by a contract/temporary worker, the employee selects the contract/temporary from the list.
  3. The employee enters the start and end time worked and saves the result.

Alternate Flow(s)

Wrong User
If the employee attempts to log hours worked for someone they do not have permission to - another employee, for instance, that is not a contract/temporary worker - the system will not permit them to do so.
Impossible Time
If the employee attempts to log times that aren't possible - ending before it starts, for example - the system highlights the error and requests a correction.
Summary
Managers can view employee schedules in order to ensure an employee is available to work on a scheduled contract.
Pre-Conditions
The manager is signed in to the system.
Special Requirements
Should only be used to check for contracts.
Post-Conditions
The manager is aware of employee schedules, and may have scheduled an employee or employees to work on a contract.

Flow of Events

Basic Flow

The flow begins when an employee needs to view schedules.

  1. The employee selects which schedules they want to see - their own for employees, or everyone's, for managers.
  2. The system presents the requested information.

Alternate Flow(s)

Insufficient Permissions
If someone without managerial access rights attempts to run the flow, the system will present them with their own schedule, but nobody else's. If someone who is not an employee attempts to run the flow, the system will refuse to show them any information.
Summary
Managers can view a list of rented equipment in order to ensure the necessary equipment is available for a contract.
Pre-Conditions
A manager is logged in to the system.
Special Requirements
None
Post-Conditions
The manager is aware of which equipment is rented and to whom.

Flow of Events

Basic Flow

The flow begins when the manager wants to see which equipment is currently rented out.

  1. The manager requests a list of all rented-out equipment.
  2. The system generates a list of all equipment that is currently rented out and displays it to the manager.

Alternate Flow(s)

No equipment rented
If no equipment is currently rented out, the system will inform the user that this is the case.
Equipment sold
If equipment that was out on rental has instead been sold to the renter, the sale is entered as a separate order (using the 'generate order' flow) and the rental is marked as complete.
Summary
Managers can view a history of equipment rentals in order to project future use and make recommendations for or purchases of new equipment.
Pre-Conditions
The manager is signed in to the system.
Special Requirements
Assumes that equipment has, in the past, been rented out.
Post-Conditions
The manager knows about the rental history.

Flow of Events

Basic Flow

The flow begins when the manager wants to view a history of rentals.

  1. The manager selects the equipment or customer for which they want to view the rental history.
  2. If the manager selected a piece of equipment, the system displays a list of all the times that piece of equipment was rented, and to whom.
  3. If the manager selected a customer, the system displays a list of all the times that customer rented a piece of equipment, and which piece of equipment it was.

Alternate Flow(s)

No rentals
If no rentals have been logged in the system for the specified criteria, the system will inform the user of this.
Summary
Managers can view a list of all contract/temporary workers that SSL has in order to schedule them for a contract.
Pre-Conditions
The manager is signed in to the system.
Special Requirements
None
Post-Conditions
The manager has viewed or edited the list of contract/temporary workers

Flow of Events

Basic Flow

The flow begins when a manager wants to view the list of contract/temporary workers.

  1. The manager requests the list of all contract/temporary workers.
  2. The system displays a list of all contract/temporary workers.

Alternate Flow(s)

Edit worker
If the manager wants to edit information for one of the contract/temporary workers, the system enables them to do so. This process also allows them to delete a worker from the system.

Class Diagram

Click to view full-size.

File Specifications

The database used will be a central Microsoft Access database. A template file can be used to generate the database in Microsoft Access, and is available for download here.

Program Specifications

Upon accessing the system, users are asked to log in.

Upon logging in, the user is presented with all the functions they have access to; for example, the main menu for all employees, and the technicians-only menu for employees marked in the system as technicians.

When managing data, users are presented with either a detailed single-point-at-a-time view or with a table to manage large amounts of data at a time. Their ability to edit, add, or delete data is restricted based on their user type.

When editing data for which they have partial access, users are able to see all of the data, for context, but are only able to edit the data for which they have permission.

Implementation

Click on an image to view it full-size

Budget & Personnel Requirements

Five programmers, headed by Jane Ackerman and John Holmes. Each programmer should have knowledge of Access, C#, and other such skills. There should be no need for specialists. Since the budget for this program is minimal, $15,000 dollars, the staffing team should be small.

Backup & Recovery Strategies

The project should be backed up on the team's hard drive, and online. When programming, the programmers should back up their work on the central git repository. Recovering corrupted or overwritten information is much easier when using a cloud-based git repository like Github.

Schedule

Tom Smith wishes to expand his business to fifteen employees in the next five years. This project should be completed within a year, beginning on May 29th, 2017 and ending on May 25th, 2018. The planning phase is from May 29th to July 28th, 2017. Next, the analysis phase will take place from July 31st to November 24th, 2017. Then, the design phase will take place from November 25th, 2017 and end January 25th, 2018. Finally, the implementation will be from January 26th to May 25th, 2018. After its completion, the program should aid Mr. Smith's expansion throughout the next four years.

Recommendations and Conclusion

This report documented the current status of the information technology systems at Showtime Sound & Lighting and laid out a plan of action to replace those systems with a new, custom-built system. To date, SSL has been using a single-user system based upon a mix of paper forms and Microsoft Office documents. As the company has expanded, and plans to continue doing so, developing a system that will function better at a larger scale is very necessary to prevent major inefficiencies from costing the company customers and revenue.

This report contains design documents for a new system that SSL could use. The system is designed for the current and future needs of the company, and would allow for much easier scaling of their information technology systems to keep pace with the planned rate of growth for the company.

To SSL, we recommend they move forward with the development and, later, the use of the system designed within this document.