CTTS Case Study

TYPE OF SERVICE REQUESTED:Information Strategy Planning Existing Application EnhancementBusiness Process Analysis and Redesign Existing Application Maintenance (problem fix)New Application Development Not SureOther (please specify ___________________________________________________________________

BRIEF STATEMENT OF PROBLEM, OPPORTUNITY, OR DIRECTIVE (attach additional documentation as necessary)

Coastline Systems Consulting’s web programmer has identified their client technology tracking system and service requests and records as being in need of process redesign and a new integrated application. The current system in place to keep track of and update clients’ hardware and software configurations is not centralized and ineffective. This has led to inefficient use of technician resources in the form of technicians frequently not having the proper information or equipment at client sites. The current system for clients to submit service requests is inefficient and does not provide an effective way for technicians to record actions taken in response to those requests.

BRIEF STATEMENT OF EXPECTED SOLUTIONWe propose a system for storing and updating client hardware and software configurations. The system should be secure yet accessible by technicians at any time and from any location. We envision a system where clients can directly submit service requests, technicians can document work done, and all parties can view the history and status of those requests. We envision a system capable of generating reports and statistics enabling management to continue to improve these areas.

ACTION (ISS Office Use Only)

Feasibility assessment approved Assigned to Nicholai Stevens _

Feasibility assessment waived Approved Budget $ _____________ Start Date ASAP Deadline 6 Months

Request delayed Backlogged until date: ______________

Request rejected Reason: ________________________________________________Authorized Signatures:_____________________________________ _________________________________________________

Project Executive Sponsor

Coastline Systems Consulting

Phone: 850-234-6789 Fax: 850-987-5432

DATE OF REQUEST SERVICE REQUESTED FOR DEPARTMENT(S)

01/17/2012 Client Services

SUBMITTED BY (key user contact) EXECUTIVE SPONSOR (funding authority)

Name Anna Kelly Name Peter CharlesTitle Web Programmer Title President/analystOffice DHQ Office DHQPhone 850-234-6789 Ext- 0001 Phone 850-234-6789 Ext- 0006

PROBLEM STATEMENT MATRIX

Brief Statements of Problem, Opportunity, or Directive

Urgency VisibilityAnnual Benefits

Priority or Rank

Proposed Solution

1. Current system for clients submitting service requests inefficient.

ASAP HighIn the

thousands.1

Process Analysis and Redesign/ New Web

Application Development

2. Current system for recording and tracking services performed is inefficient.

ASAP High 3,000 – 5,000 1 New Development

3. There is no centralized system for tracking client systems configurations. (hardware and software)

ASAP

Low

(approved users only)

4,000 minimum

1 New Development

4. Technician time is wasted because of a lack of proper information before initiating service call.

6 Months Medium4,000

minimum2

After system is developed technicians

will properly document services.

5. Secure system access must be available to technicians from their homes or in the field, but management does NOT want system exposed to the internet.

6 Months Low Unknown 1 VPN or data replication

6. Systems and processes always have room for improvement.

6 Months -

ConstantLow Unknown 2

Generation of reports and statistics

7. Management would like an easy way for techs to track installation of new hardware components.

6 Months High Unknown 3 Barcode Scanners

8. Warranty information about current and future hardware components needs to be stored available to clients and technicians.

6 Months High Unknown 3

After system is developed technicians

will properly document hardware installations.

PROJECT: Client Technology Tracking System

PROJECT MANAGER: Dr. Alex Lazo

CREATED BY: Nicholai Stevens LAST UPDATED BY: Nicholai Stevens

DATE CREATED: 01/15/2014 DATE LAST UPDATED: 01/18/2014

PROBLEMS, OPPORTUNITIES, OBJECTIVES AND CONSTRAINTS MATRIXProject: Client Technology Tracking System Project Manager: Dr. Alex Lazo

Created by: Nicholai Stevens Last Updated by: Nicholai Stevens

Date Created: 1/25/2014 Date Last Updated: 1/26/2014

CAUSE AND EFFECT ANALYSIS SYSTEM IMPROVEMENT OBJECTIVES

Problem or Opportunity Causes and Effects System Objective System Constraint

1. Current system for clients submitting service requests inefficient.

2. System for tracking services performed is ineffective.

3. System for tracking client hardware and software configurations is ineffective.

4. Systems and processes can be observed and measured to indicate areas where improvements can be made.

5. System should be expandable to allow for company growth.

1. Clients have to call in their service requests

2. Technicians enter changes by hand, and sometimes updates are not entered at all.

3. Technicians enter changes by hand, and sometimes updates are not entered at all.

4. Technicians are sometimes unprepared for service calls.

5. Services performed may be unnecessary

1. Reduce time receptionist spends entering new service requests by 80%

2. Increase services performed tracking accuracy to 95%.

3. Increase tracking of client systems configurations accuracy to 98%.

4. Increase technician efficiency by 30%

5. Produce accurate real time information about services and procedures.

6. Allow technicians to access client information remotely.

1. Services request/tracking web application must work in all major web browsers.

2. Out of office entries may not be reflected in central system immediately.

3. System must be secure.

4. System should not be on the internet.

5. System must be compatible with existing hardware and software components.

System Requirements

Functional Requirements

1. Manage Client Configuration1.1. Enter New/Existing and Update

1.1.1. Hardware1.1.1.1. Computers

1.1.1.2. Printers/Scanners/Copiers 1.1.1.3. Servers 1.1.1.4. Etc.

1.1.2. Software/Systems

1.1.2.1 Operating Systems 1.1.2.2. Usernames/Passwords 1.1.2.3. IP/Web/E-mail Addresses 1.1.2.4. Etc.

2. Manage Service Requests 2.1. Enter New Service Request

2.1.1. Client2.1.2. Technicians2.1.3. Receptionist

2.2. View Service Request Status/History2.2.1. Client (Only their own)2.2.2. Technicians2.2.3. Receptionist2.2.4. Management

2.3 Update/Close Service Requests2.3.1. Technicians2.3.2. System Auto after 10 Days

3. Generate Statistics and Reports3.1. TBD

4. System Log-ins4.1. Client Log-in4.2. User Log-ins

4.2.1. Technician4.2.2. Receptionist4.2.3. Management

Non-Functional Requirements

1. Operational Requirements1.1. The system will operate in the Windows environment1.2. The system should automatically back up at the end of each business day1.3. The system should be accessible by multiple users simultaneously1.4. The service request function should be accessible through a web page application

1.4.1. New Request Entry1.4.1.1. Can be performed by clients, technicians, and receptionist

1.4.2. Existing Request Status/History1.5. Client configuration changes should be saved before exiting1.6. Inventory Scanners should connect wirelessly1.7. The system should be searchable

2. Performance requirements2.1. Inventory Scanners should recognize items within 2 seconds2.2. System Search results should display within 10 seconds2.3. System Statistics and Reports should generate within 30 seconds2.4. Client configuration updates should be reflected in the system within 5 seconds2.5. New service requests should be placed in queue within 5 seconds

3. Security Requirements

3.1. Client configuration information should not be on the internet3.2. Clients should only have access to their own service requests3.3. System Access

3.3.1. Log-in3.3.1.1. Each client and user will have a unique username and password3.3.1.2. Passwords should be changed every 90 days

3.3.2. Time-out3.3.2.1. Clients/users will be logged out after 30 minutes of inactivity

3.3.3. Technician only functions3.3.3.1. Add/Update client configuration information3.3.3.2. Update/close/cancel service requests

4. Cultural and Political Requirements4.1. No special cultural and political requirements are anticipated

Context Diagram

Decomposition Diagram

Event Diagrams

System Diagram

Primitive Diagram

Entity/Definition Matrix

ENTITY BUSINESS DEFINITIONClient A customer who has a contract for services.

Component Any Hardware item in inventory that can be installed in a system. i.e. DVD drives, NICs, etc.

Configuration Information about a client’s system such as usernames/passwords, IP addresses, etc.

Equipment Any device such as a printer, PC, router, hub, etc. that the company ensures is operational and handles warranty issues for.

Service Request A request placed in the system by a client/technician, or receptionist to address a malfunction or improper performance of some part of a system.

Work Record An individual record of services performed by a technician on a service request.

Context Data Model

Key Based Data Model

Fully Attributed Data Model (in 3NF)

Use-Case Glossary

Use-CaseID

Use Case Name Use-Case Description Participating Actors and Roles

CTTS-001Enter Service

Request

This use-case describes the event of a client, technician, manager, or receptionist entering a service request in the online application.

Client Technician Management Receptionist/bookkeeper

CTTS-002View Unresolved Requests/History

This use-case describes the event of a user viewing unresolved service requests and their history. A client has access to only their service requests, technicians can view unresolved requests they are part of, and management will review unresolved requests open for more than 72 hours.

Client Technician Receptionist/bookkeeper

CTTS-003 Enter Work RecordThis use-case describes the event of a technician entering a work record pertaining to an active service request.

Technician

CTTS-004Manually Resolve Service Request

This use-case describes the event of a technician completing a service request and marking it “Resolved.”

Technician

CTTS-005Automatically

Resolve Service Request

This use-case describes the event of a service request being considered resolved after a certain amount of time has elapsed between the initial request and follow up email.

Time

CTTS-006Enter Component

Information

This use-case describes the event of a technician entering new, or updating existing client component information.

Technician

CTTS-007 Enter New EquipThis use-case describes the event of a technician entering new, or updating existing client equipment information.

Technician

CTTS-008View Software

Configuration Info

This use-case describes the event of a technician retrieving existing client configuration information from the database.

Technician

CTTS-009 Check In InventoryThis use-case describes the event of the Receptionist/bookkeeper entering new inventory items as they arrive in orders.

Receptionist/bookkeeper

CTTS-010Enter Configuration

Information

This use-case describes the event of a technician entering new, or updating existing client configuration information.

Technician

CTTS-011View Installed Components

This use-case describes the event of a technician retrieving existing client component information from the database.

Technician

CTTS-012Enter/Edit Equip

Type

This use-case describes the event of an employee entering new, or editing existing standard equipment information.

Any Employee

CTTS-013Enter/Edit

Component Type

This use-case describes the event of an employee entering new, or editing existing standard component information.

Any Employee

CTTS-014 Enter New ClientThis use-case describes the event of the Receptionist/bookkeeper adding a new client to the CTTS.

Receptionist/bookkeeper

Use-Case Model Diagram

* I highlighted the generalization relationships in yellow to help avoid confusion.

Fully-documented Use Case Narrative

CTTSAuthor (s): Nicholai Stevens___ Date: _02/21/2014__

Version:___1.0______USE CASE NAME: View Unresolved Requests/History USE CASE TYPEUSE CASE ID: CTTS-002 Business Requirements:PRIORITY: High System Analysis: SOURCE: Management, Business RequirementPRIMARY BUSINESS ACTOR ClientPRIMARY SYSTEM ACTOR Technician, Management, Client

OTHER PARTICIPATING ACTORS:

Technician, Management, Client

OTHER INTERESTED STAKEHOLDERS:

N/A

DESCRIPTION: This use-case describes the event of a user viewing unresolved service requests and their history. A client has access to only their service requests, technicians can view unresolved requests they are part of, and management will review unresolved requests open for more than 72 hours.

PRE-CONDITION: In order to execute this this use case the user must be logged in and verified.TRIGGER: This use case is initiated when a user selects the “View Unresolved Requests” option from their

home screen in the online requests system.TYPICAL COURSE OF EVENTS:

Actor Action System Response

Step 1: A user selects the “View Unresolved Requests” option from their home screen in the online requests system.

Step 2: The system displays a list of all requests relevant to the user based on their log-in information that have not been marked resolved.

Step 3: The user selects the unresolved request they wish to see additional details about.

Step 4: The system displays the detail concerning the unresolved request including the original request information and any work records pertaining to the request.

Step 5: The user may now review the information and return to the previous screen which initiates Step 2.

Step 6: When finished the user may close the unresolved requests list and return to their home page.

ALTERNATE COURSES: Alt Step 2: If no unresolved requests are available for that user the system will display the appropriate message.

Alt Step 5a: If the user is a technician, he/she will have the option to add a new WorkRecord to the request. If this is selected the system will launch use case CTTS-003. Upon completion the system returns to Step 4.Alt Step 5b: If the service request has been completed a technician or management can change the status of the request to “resolved.” This will initiate use case CTTS-004. Once a request has been marked resolved, the system returns to Step 2.

CONCLUSION: This use case successfully ends when the user closes the “View Unresolved Requests” screen, and returns to their home page.

POST-CONDITION: NoneBUSINESS RULES NoneIMPLEMENTATION CONTRAINTS AND SPECIFICATIONS

This function will be carried out through a web based application. The information will be stored in a database that will be updated and queried through the web application.

ASSUMPTIONS: None

OPEN ISSUES: None

Activity Diagram

System Sequence Diagram

Class Diagram

Candidate MatrixCharacteristics Candidate 1:

Desk.com Plus PlanCandidate 2:Kayako Case

Candidate 3:Custom Build

Portion of System Computerized

Brief description of that portion of the system that would be computerized in this candidate.

This package would be purchased and customized to fulfill the requirements of the customer service request management portion of the system.

Same as Candidate 1. This option requires an extension application to be built from scratch to fulfill the requirements of the customer service request management portion of the system.

Benefits

Brief description of the business benefits that would be realized for this candidate.

Because this solution is purchased the time frame for implementation is very short. It also comes with support services and is cloud based which reduces processing load.

Same as candidate 1.

Alternatively, this solution can be purchased and downloaded to be run directly from in-house equipment for additional control

Because this is a custom in-house build, the system can be designed around current business practices and no unnecessary functionality will be included.

Servers and Workstations

A description of the servers and workstations needed to support this candidate.

Windows 7 class servers and workstations

Same as Candidate 1. Same as Candidate 1.

Software Tools Needed

Software tools needed to design and build the candidate (e. g., database management system, emulators, operating systems, languages, etc.). Not generally applicable if applications software packages are to be purchased.

N/A Package Solution Same as Candidate 1. Microsoft FrontPage, Visual C++, Web browser of choice

Application Software

A description of the software to be purchased, built, accessed, or some combination of these techniques.

Package Solution Same as Candidate 1. Custom Solution

Method of Data Processing

Generally some combination of: on-line, batch, deferred batch, remote batch, and real-time.

Online Online, Client/Server Same as Candidate 2

Output Devices and Implications

A description of output devices that would be used, special output requirements, (e.g. network, preprinted forms, etc.), and output considerations (e.g., timing constraints).

Various inkjet/laser printers Same as Candidate 1. Same as Candidate 1.

Input Devices and ImplicationsA description of Input methods to be used, input devices (e.g., keyboard, mouse, etc.), special input requirements, (e.g. new or revised forms from which data would be input), and input considerations (e.g., timing of actual inputs).

Keyboard and Mouse, Mobile devices with app

Same as Candidate 1. Keyboard and Mouse

Storage Devices and Implications

Client info, Request history stored by service provider

Same as Candidate 1. Same as Candidate 2.

Brief description of what data would be stored, what data would be accessed from existing stores, what storage media would be used, how much storage capacity would be needed, and how data would be organized.

Or, if downloaded information will be stored in relational SQL server DBMS. 2TB capacity.

Feasibility Matrix

Feasibility Criteria Wt. Candidate 1 Candidate 2 Candidate 3Operational Feasibility

An assessment of how well the solution meets the identified system requirements to solve the problems and take advantage of the opportunities envisioned for the system.

15%Solution fully supports required functionality, but is cloud based making access to the system contingent on internet connection.

Score: 90

Solution fully supports required functionality

Score: 100

Solution fully supports required functionality

Score: 100Cultural/Political Feasibility

An assessment of how well the solution will be accepted in a given organizational climate.

15%No foreseeable problems

Score: 100

No foreseeable problems

Score: 100


Score: 100Technical Feasibility

An assessment of the practicality of the solution and the availability of technical resources and expertise to implement and maintain it.

20% Packaged solution is web based and maintained by provider. Only resources required from staff are initial set up/customization and minor changes in the future.

Score: 95

Same as Candidate 1.

If program is run on in house server one year of support is provided and then maintenance responsibility will shift to staff.

Score: 90

Custom build can be implemented and maintained without issues but this will take away from other responsibilities.

Score: 80Economic Feasibility

An assessment of the cost-effectiveness of a project or solution.

Cost to develop:

Payback period (discounted):

Net present value:

Detailed calculations:

30%

~ $4153

<1 year

$15,612

See Attached Documents

Score:85

~ $4153

<1 year

$15,612


Score:85

~$3740

<1 year

$20,115


Score:95Schedule Feasibility

An assessment of how long the solution will take to design and implement.

10%Less Than 2 months

Score: 95

Less Than 2 months

Score: 95

4-6 Months

Score: 85Legal Feasibility

An assessment of how well the solution can be implemented within existing legal and contractual obligations.

10% No foreseeable problems

Score: 100


Score: 100


Score: 100Ranking: 100

%92.5 93 93

Estimated Costs

Desk.com Kayako Case Custom BuildDevelopment Costs:

Personnel: Personnel: Personnel:1 Programmer ($30/hour) 1 Programmer ($30/hour) 1 Programmer ($30/hour)

-Customize: 16 hours -Customize: 16 hours -Custom Build: 80 hours

-Data Entry: 24 hours -Data Entry: 24 hours -Data Entry: 24 hours

Total: 50 Hours = $1500 Total: 50 Hours = $1500 Total: 105 Hours = $3150

Training: Training: Training:2 Hours each 2 Hours each 2 Hours each

5 Technicians ($30/Hour) 5 Technicians ($30/Hour) 5 Technicians ($30/Hour)

1 Receptionist ($15/hour) 1 Receptionist ($15/hour) 1 Receptionist ($15/hour)1 Analyst/Pres. ($45/hour) 1 Analyst/Pres. ($45/hour) 1 Analyst/Pres. ($45/hour)

Total: $420 Total: $420 Total: $420

Hard/Software: Hard/Software: Hard/Software:7 -Licenses: @ $348/each 7 -Licenses: @ $348/each -FrontPage: $170

*(first month free trial) *(first month free trial)Total: $2233 Total: $2233

Total: $170

Total Development Costs: $4153 $4153 $3740

Annual Operating Costs:

Personnel: Personnel: Personnel:1 Technician: 12 hours @

$30/hour1 Technician: 12 hours @

$30/hour1 Technician: 40 hours @

$30/hour

Total: $360 Total: $360 Total: $1200

Expenses: Expenses: Expenses:7 -Licenses: @ $348/each 7 -Licenses: @ $ 348/each N/A

Total: $2436 Total: $2436

Total Projected Annual Costs: $2796 $2796 $1200

Net Present ValueDesk.com

Cash Flow Description Year 0 Year 1 Year 2 Year 3 TotalDevelopment Cost: ($4,153)

Operation & Maintenance Cost:

$2,796 $3,000 $3,200

Discount Factor for 10% 1.000 .909 .826 .751P.V. of Annual Costs: ($4,153) ($2,542) ($2,478) ($2,403)

T.P.V. of lifetime costs: ($11,576)

Benefits Derived: $0 $10,000 $11,000 $12,000Discount Factor for 10% 1.000 .909 .826 .751P.V. of Annual Benefits: $0 $9,090 $9,086 $9,012

T.P.V. of lifetime benefits:

$27,188

NPV of this alternative: $15,612

Kayako CaseCash Flow Description Year 0 Year 1 Year 2 Year 3 Total

Development Cost: ($4,153)Operation &

Maintenance Cost:$2,796 $3,000 $3,200





$27,188


Custom BuildCash Flow Description Year 0 Year 1 Year 2 Year 3 Total

Development Cost: ($3,740)Operation &

Maintenance Cost:$1,200 $1,350 $1,500





$27,188


Design Use Case Narrative

CTTSAuthor (s): Nicholai Stevens Date: _04/08/2014__

Version: __1.1_________USE CASE NAME: View Unresolved Requests/History USE CASE TYPEUSE CASE ID: CTTS-SDUC002 Business Requirements: PRIORITY: High System Analysis: SOURCE: Business Requirement

Analysis Use Case CTTS-002System Design:

PRIMARY BUSINESS ACTOR ClientPRIMARY SYSTEM ACTOR Technician, Management, ClientOTHER PARTICIPATING ACTORS:

Technician, Management, Client

OTHER INTERESTED STAKEHOLDERS:

N/A

DESCRIPTION: This use-case describes the event of a user viewing unresolved service requests and their associated history through the web application. A client has access to only their service requests, technicians can view unresolved requests they are part of, and management will review all unresolved requests and specifically request to view requests open for more than 72 hours.

PRE-CONDITION: In order to execute this this use case the user must be logged into the system and window W002- Service Requests, is displayed.

TRIGGER: This use case is initiated when a user clicks the [Unresolved Requests] button from the Service Requests window in the online requests system.

TYPICAL COURSE Actor Action System ResponseOF EVENTS: Step 1: The user clicks the [Unresolved

Requests] button.Step 2: The system displays window W004 - Unresolved Requests, a list showing all records relevant to the user based on their log-in credentials that have not been marked resolved. All records will be displayed on one page.

If the list is longer than can be displayed in the window a scroll bar will automatically appear.

Step 3: The user scrolls through the available items using the scroll bar if necessary, and then selects the unresolved request they wish to examine more closely by clicking on it.

Step 4: The system displays window W007- Request Detail. This will show the original request information and any work records associated with the request selected by the user.

Step 5: When the user is finished reviewing the request they can click the [OK] button in the window or the [Back] button in their browser to return to the Unresolved Requests window.

Step 6: System returns to step 2.

Step 7: When the user is finished reviewing the unresolved requests they can exit the Unresolved Requests window by clicking the [OK] button.

Step 8: The system will display window W002- Service Requests.

ALTERNATE COURSES: Alt Step 2: If no unresolved requests are available for that user the system will display the pop-up window W-001- No Results Found, which indicates that no records match their request. The user then clicks the [OK] button and the system returns to the Service Requests window.

Alt Step 5a: If the user is a technician, he/she can add a new WorkRecord to the request. If the [Add Work Order] button is clicked the system will launch use case CTTS-003 (Add work Order). Upon completion the system returns to Step 4.

Alt Step 5b: If the service request has been completed a technician or management can change the status of the request to “resolved.” If the [Resolve] button is clicked the system will update the status of the request. Once a request has been marked resolved, the system returns to Step 2.

CONCLUSION: This use case successfully ends when the user closes window W004 - Unresolved Requests, and returns window W002- Service Requests.

POST-CONDITION: If work records were added or request status was changed, all copies of the record(s) will be updated and Window W002- Service Requests, is displayed.

BUSINESS RULES The manager will have an additional [Delayed Requests] button that retrieves all service requests that are more than three days old and are unresolved.

Clients will only have access to their own service request records. Only technicians can enter work orders A technician, management user, or the client can manually change a service request

status to “Resolved” An automatic resolution system is also being designed that will be integrated as well.

IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS

Use case must be available to clients and technicians 24/7. Updates should occur immediately. Frequency – It is estimated that the use case will be executed no more than 500 times a

day. It should support up to 30 concurrent users.ASSUMPTIONS: The connection will be secure to ensure confidentiality.OPEN ISSUES: None

Sequence Diagram

View Unresolved Requests/History

Design Class Diagram:View Unresolved Requests/History

State Machine Diagram

Service Request Lifecycle

Testing

Before the testing begins, sample data should be input for multiple clients. Sample data should include multiple service requests in varying states (resolved/unresolved) with varying numbers of related work records. Some should be more and some should be less than 72 hours old.

Unit Tests

Test 1: Unresolved Requests list display test.

Description: This test will ensure that only the appropriate service request records are displayed when a user selects the option to view unresolved requests from the web page home. This test should be performed for each class of user; technician, client, and management.

Method: White-Box, Control structure (branch, condition)

Test 2: Request Detail display test.

Description: This test will ensure that when the “view” link next to an unresolved service request is clicked, the appropriate details concerning the original request and any related work records are retrieved displayed.

Method: White-Box, Control structure (condition, data flow)

Test 3: Request Resolution initiation test.

Description: This test will verify the functionality of the UI link “resolve” in the request_detail page. This test will also cover the verification of user status when attempting to resolve a request.


Test 4: Manager Review of delayed requests test.

Description: This test will verify that only service requests which have not been resolved and are more than 72 hours old are displayed when a manager user selects the option to view unresolved requests from the web page home.

Method: White-Box, Condition

Test 5: No unresolved requests test.

Description: This test will verify the appropriate message display when there are no unresolved requests to display.


Test 6: Unauthorized request resolution command test.

Description: This test will ensure that either an error message is displayed if the user is not authorized to resolve a request, or that the “resolve” link is not available to users who are not authorized.

Method: White-Box, Condition

Program Tests

*Each of these tests will be performed through the ASP.NET web application written for this system.

Test 1: Method: Black-Box

Precondition- User logged-in and verified as a client. Client has one or more unresolved requests.Trigger- User selects the option to view unresolved requests from the web page home.Conclusion- User exits unresolved requests list page.Post condition- N/ABusiness Rules- N/A

In this test the user will select the option to view unresolved requests from the web page home. The system will then display the Unresolved Request list along with a “view” hyperlink for each. This list should be specific to the client. The user will then select an unresolved request to review further. The system should display all details concerning the request and any associated work records. Because the user has been verified as a client they have the option to change the status of the unresolved request to “resolved”. When the user selects the “resolve” link the Use case for manually resolving service requests is initiated.


Precondition- User logged-in and verified as a Technician. Technician has one or more related unresolved requests.Trigger- User selects the option to view unresolved requests from the web page home.Conclusion- User exits unresolved requests list page.Post condition- N/ABusiness Rules- N/A

In this test the user will select the option to view unresolved requests from the web page home. The system will then display the Unresolved Request list along with a “view” hyperlink for each. This list should be specific to the technician; however they should have an option to review other requests if necessary. The user will then select an unresolved request to review further. The system should display all details concerning the request and any associated work records. Because the user has been verified as a technician they have the option to change the status of the unresolved request to “resolved”. When the user selects the “resolve” link the Use case for manually resolving service requests is initiated.


Precondition- User logged-in and verified as a Manager. There are one or more unresolved requests that have been active for more than 72 hours.Trigger- User selects the option to view unresolved requests from the web page home.Conclusion- User exits unresolved requests list page.Post condition- N/ABusiness Rules- N/A

In this test the user will select the option to view unresolved requests from the web page home. The system will then display the Unresolved Request list along with a “view” hyperlink for each. This list should contain only those unresolved requests that are more than 72 hours old; however the manager should have an option to review other

requests if necessary. The user will then select an unresolved request to review further. The system should display all details concerning the request and any associated work records. Because the user has been verified as a manager they have the option to change the status of the unresolved request to “resolved”. When the user selects the “resolve” link the Use case for manually resolving service requests is initiated.

*Each of these tests should be repeated with the precondition changed such that no unresolved requests meet the criteria for being displayed. This should confirm the proper functionality of the appropriate messages.

* During these tests, the functionality of UI features such as scroll bars, button, and etc. should be confirmed as well.

Staff Assignments

Testing: Anna Kelly will be responsible for the majority of the unit and program testing and documentation. Her role as the developer of this system makes her uniquely qualified to adequately test the functionality of the system. She may recruit Dane Wagner (Web Server Administrator) to assist in the testing of the system’s ability to perform under stress.

Test Review: Because small details can be missed when working closely with a system it is important to have someone other than those who performed the tests review them. Peter Charles (president) is just as familiar with the expected performance of the system and should be responsible for reviewing the test results.

Sign off: As the president of the company, Peter Charles is ultimately responsible for the final sign off.

Conversion Plan

Section I: Conversion Strategy

A. Overview of conversion strategies

Abrupt cut-over. In this method the old system is shut down and the new system is made operational on a predetermined date. There are pros and cons to this approach. Financially, this approach is great because there are no transition costs. Operationally however, there is the risk that a major issue was missed in testing and the system, or parts of it, may fail.

Parallel conversion. In a parallel conversion the old system and the new one operate simultaneously for a period of time. The pros and cons to this method are the inverse of the abrupt cut over. Since the old system is still operational, if an unforeseen issue with the new system arises, business operations can still be performed. However, there is the additional cost of having two systems running at once. This approach may not be possible if the network cannot support both systems simultaneously. Once the conversion begins the old system can be terminated all at once or a little at a time once the functionality of the new system has been confirmed.

Location conversion. This method is used when there are multiple geographical locations implementing the new system. Generally one location, often called the beta test site, implements the new system before the others. This can be done with either the abrupt or parallel method. Once the entire system is operational and approved the remaining sites can make an abrupt cut over. With this method the risk involved in the abrupt cut over for the subsequent locations is greatly reduced because most of the issues will have been discovered at the beta site.

Staged conversion. This method utilizes multiple versions of the new system. As each version of the system is developed it is implemented. Any of the three previously discussed methods can be used to execute this implementation.

B. Recommended conversion strategy for CTTS

I recommend the abrupt cut-over conversion strategy for implementing the CTTS. The current systems they have in place are not very organized and very inefficient so maintaining them any longer than necessary is not recommended. If there is a problem with the new system, going back to hand written methods temporarily will not be difficult.

Section II: User Documentation

A: Sources for documentation

When creating a user manual much of the documentation created throughout the process can be used as reference. Documents/diagrams such as; use cases narratives, activity diagrams, sequence diagrams, state machine diagrams, etc.

B: Outline of a Proposed User manual

Introduction:- Overview of new system- Overview of new equipment

Getting Started:- Adding/removing users (Coastline staff only)- Logging in- Setting/changing password

Internal Operations: (Coastline staff only)- Inventory

- Input- Equipment/components

- Add/update- Client Configurations

- Enter/update

Service Requests:- Add new- Reviewing

- All- Unresolved

- Responding- Add Work Order (Coastline staff only)

- Resolution-Manual- Auto

Appendixes

- Glossary- Diagrams- References

C: Recommended Format for Manual (Hard copy vs. Online)

For the manuals I recommend having a comprehensive version online with one hard copy kept at the central office. I also recommend and a one page (front and back) pamphlet to be provided to all users with quick reference instructions for commonly used features.

D: Staff responsibilities

Anna Kelly will be responsible for developing the training materials for this system. Kathy Grey (receptionist) will assist in editing the materials and Peter Charles will give the final approval before printing.

Section III: User Training

A: Review of training alternatives

One-on-One training. In this method an instructor goes over the system with each user individually. This method is the most time consuming and expensive, but very effective.

Hands-on classroom style instructor-led training. In this approach up to 30 users can be walked through the training while they perform the tasks on their computers. This method saves time and money, and also gives the users some practice.

Seminar style group demonstration. In this method an instructor demonstrates how things are done while the users watch and take notes.

Computer Based Training. In CBT users can learn at their own pace, via an interactive lesson. Book-based self-paced training. In this approach users are given manuals and can complete workbook

lessons. B: Recommended training plan for CTTS

Because the number of staff at Coastline is less than 10, a one day Hands-on classroom style instructor-led training session is the best choice. Each staff member has participated in the development of the new system at some level, so there should be an overall sense of familiarity. This is also a group of technically trained professionals so their existing knowledge should make the training relatively easy.

For introducing the clients to the new system I recommend the computer based training. Creating an instructional video that can be accessed online is the best way to distribute the information to their growing client base. This also provides a resource that can be accessed before contacting customer service or outside of business hours.

C: Staff responsibilities

Anna Kelly will organize and lead the user training. Kathy Grey will be responsible for printing and distributing training materials. And. Peter Charles will provide the venue and refreshments for the training session.

Approaches to Technical Support

Technical support is an ongoing set of routine activities intended to provide users additional assistance

concerning issues with the day-to-day use of specific applications. In order to provide adequate support several tasks

should be performed. These tasks result in information that can be used to deliver effective technical support and a

more user friendly, bug free system. Some of these tasks include:

Observing the use of the system Conducting user satisfaction surveys and meetings Changing business procedures Providing additional training when required Logging enhancement ideas and requests

Technical Support recommendations for CTTS

For the CTTS system implemented at Coastline Consulting I think all of these activities should be used to

some degree. Observing the use of the system will provide insight into things like high volume times and who is using

the system. User satisfaction surveys should be sent out soon after the system is implemented. These can be used to

identify any additional changes that can be made to improve the system. Because this system will require new

business procedures for most of the activities performed by each employee, it is likely that more efficient ways to use

the system will be discovered over time. Additional training will need to be provided to new employees and clients as

the business continues to grow. Lastly all enhancement requests and ideas should be logged in the repository. By

keeping records of all these things there will be an excellent resource for requirements analysis in future iterations of

the system.

Coastline does have the option of outsourcing the tech support responsibilities, however since they are a small

company I think it should handled internally. That being said I do think that they should hire a new employee to

oversee the new system or to take over Anna Kelly’s role as a web developer so she can act as the system

administrator.

CTTS Case Study

Documents

Transcript of CTTS Case Study