Upload
Search
CTTS Case Study
Nicholai Stevens
Apr. 16, 2015 • 8 likes • 16,519 views
CTTS Case Study
2 of 40
Follow
Download Now
Login
Signup
More Related Content
What's hot (20)
It101 lec7
Functional requireme…
Sales and inventory …
Базові технології е…
Canteen managemen…
Met
Ganbaata… • 11.8K views
Anil Kumar • 23.3K views
Fuckboy123 • 3.7K views
Oleg Nazare… • 470 views
rimshailyas1 • 2.5K views
her
Client Technology Tra…
Simulation Report
Enterprise workspace…
Energy Strategy Grou…
Information från Läke…
Alta
Brendan M… • 1.1K views
Lim1990 • 14.2K views
SAP Portal • 2.2K views
Eugenio Bac… • 946 views
Läkemedel… • 4.6K views
Patr
Viewers also liked (13)
Similar to CTTS Case Study (20)
TY CS Black book Con…
merged_document_3
Hms project report
Hospital E-Token Man…
4aa4 5484enw
Min
Dinesh Jog… • 2.3K views
Nikhil D'souza • 151 views
Simranjitk…
ANISUR RA… • 3.4K views
Gregory Jor… • 328 views
Min
• 1.7K views
Related Books
Free with a 30 day trial from Scribd
View All
Ebook
Ebook
Ebook
Ebook
Ebook
Ebook
The MaintenanceExcellence…
Kris
Bagadia
Program
Software Testing
Interview…
Vibrant
Publishers
Questions
You'll
/5
Most Likely0 Be
Asked
Stress Free
Maintenance…
Ron
Mueller
Solutions
Metrics-based IT
service…
Dimitry
Isaychenko
management
Network
Operating Syste…
Gerardus
Blokdyk
A Complete
Guide
0/5
- 2020 Edition
Business Visibility
with Enterprise…
Anupama
ResourceSakhare
Planning 0 / 5
3/5
0/5
0/5
Related Audiobooks
Free with a 30 day trial from Scribd
View All
Audiobook
Audiobook
Audiobook
Audiobook
Audiobook
Audiobook
The Lean Product
Playbook: How …
Dan
Olsen with
Innovate
4.5 / 5
Minimum Viable
Products and
Operations
Management F…
Mary
Ann Anderson
Dummies
Project
Management Al…
Stanely
Portny P…
in-OneE.For
Dummies 5 / 5
Software
Engineering…
Introbooks
Team
Fundamentals
Key Performance
Indicators:…
David
Parmenter
Developing,
3.5 / 5
Implementing,
and Using
Building
Microservices:…
Sam
NewmanFineDesigning
3/5
Grained Systems
4.5 / 5
4/5
CTTS Case Study
1. TYPE OF SERVICE REQUESTED: Information Strategy Planning Existing Application Enhancement Business Process Analysis and Redesign Existing Application Maintenance (problem fix) New Application
Development Not Sure Other (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 SOLUTION We 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 Charles Title Web Programmer Title President/analyst Office
DHQ Office DHQ Phone 850-234-6789 Ext- 0001 Phone 850-234-6789 Ext- 0006
2. PROBLEM STATEMENT MATRIX Brief Statements of Problem, Opportunity, or Directive Urgency Visibility Annual Benefits Priority or Rank Proposed Solution 1. Current system for clients submitting service
requests inefficient. ASAP High In 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 Medium 4,000 minimum 2 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 - Constant Low 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
3. PROBLEMS, OPPORTUNITIES, OBJECTIVES AND CONSTRAINTS MATRIX Project: 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 systemfor 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 Configuration 1.1. Enter
New/Existing and Update 1.1.1. Hardware 1.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.
4. 2. Manage Service Requests 2.1. Enter New Service Request 2.1.1. Client 2.1.2. Technicians 2.1.3. Receptionist 2.2. View Service Request Status/History 2.2.1. Client (Only their own) 2.2.2. Technicians 2.2.3.
Receptionist 2.2.4. Management 2.3 Update/Close Service Requests 2.3.1. Technicians 2.3.2. System Auto after 10 Days 3. Generate Statistics and Reports 3.1. TBD 4. System Log-ins 4.1. Client Log-in 4.2. User Logins 4.2.1. Technician 4.2.2. Receptionist 4.2.3. Management Non-Functional Requirements 1. Operational Requirements 1.1. The system will operate in the Windows environment 1.2. The system should
automatically back up at the end of each business day 1.3. The system should be accessible by multiple users simultaneously 1.4. The service request function should be accessible through a web page application
1.4.1. New Request Entry 1.4.1.1. Can be performed by clients, technicians, and receptionist 1.4.2. Existing Request Status/History 1.5. Client configuration changes should be saved before exiting 1.6. Inventory
Scanners should connect wirelessly 1.7. The system should be searchable 2. Performance requirements 2.1. Inventory Scanners should recognize items within 2 seconds 2.2. System Search results should display
within 10 seconds 2.3. System Statistics and Reports should generate within 30 seconds 2.4. Client configuration updates should be reflected in the system within 5 seconds 2.5. New service requests should be
placed in queue within 5 seconds
5. 3. Security Requirements 3.1. Client configuration information should not be on the internet 3.2. Clients should only have access to their own service requests 3.3. System Access 3.3.1. Log-in 3.3.1.1. Each
client and user will have a unique username and password 3.3.1.2. Passwords should be changed every 90 days 3.3.2. Time-out 3.3.2.1. Clients/users will be logged out after 30 minutes of inactivity 3.3.3.
Technician only functions 3.3.3.1. Add/Update client configuration information 3.3.3.2. Update/close/cancel service requests 4. Cultural and Political Requirements 4.1. No special cultural and political
requirements are anticipated
6. Context Diagram Manager Receptionist Technician Client ServiceRequest Inquiry Statistics/Reports Request Statistics/Reports ServiceRequest Status/History Enter Service Request UpdateClient
Hardware/software Configuration ServiceRequest inquiry ServiceRequest Status/History Submit Service Request Submit Service Request Enter Service Request ServiceRequest inquiry ServiceRequest
Status/History Enter Service Request ServiceRequest inquiry ServiceRequest Status/History Enter New Inventory
7. Decomposition Diagram CTTS Service Request Subsystem Clients Subsystem Inventory Subsystem Client Configurations Add New Client Manual Auto Enter Request Resolve Request Enter Work Record
View Request Check-in Inventory Pg 2
8.
Update Standard Type Installed Components Equipment Software Configuratio n View Add/ Update Add New Equipment Update Configuratio n Add New Component Component Client Configurations
Event
Diagrams Client Technician Reception Process New Service Request Service request Confirmation of Accepted Request New Service Request Service Requests
9. Client Technician Management Display Unresolved Requests/ History View ServiceHistory Display Service Record Request for ServiceRecord Technician Manually Resolve Service Request Problem is Solved
Confirmation of Resloution UpdateService Record Technician Process Work Record Entry Enter Work Record Create/Update Work Record Time (Resolution Clock) Auto Resolve Service Request Counter Reaches
Zero UpdateWork Record Service Requests Return Requested Record Service Requests Service Requests Set Resolution Clock to 48 Hours ClientE-Mail Inquiry Inquiry Response Service Requests
10. Technician Process New Component Installation Install New Component Confirm Installation Add New Component In Database Technician Process Request for Software Configuration View Client
Configuration Display Requested Information Request for Configuration Info Technician Process New Equipment Installation Install New Equipment Confirm Installation Add New Equipment In Database
Reception/ Bookkeeping Process Incoming Inventory Check-In Inventory Add to/Update Inventory Database Client Components Client Equipment Client Configuration Return Requested Record Inventory
11. Technician Process Configuration Update Enter Configuration Info Confirmation of Update Update Configuration In Database Any Employee Enter/Edit Equipment Type(s) Add/Change Equipment Type
Update Equipment in Database Technician Process Request for Component Information View Components Display Requested Information Request for Component Information Client Configuration Client
Components Return Requested Record Standard Equipment Any Employee Enter/Edit Component Type(s) Add/Change Component Type Update Component in Database Standard Components
12. Reception/ Bookkeeping Process New Customer Add New Client Add Client to Database Clients Confirm Information Manager Process Request for Statistics/ Reports View Statistics/Reports Display
Requested Information Request for Statistics/Reports CTTS Return Requested Reports
13. System Diagram View Service Requests Submit Service Request Resolve Service Requests Perform Services Service Requests Manager Technician Reception Client(s) View Service Requests Add New
Request Display Requests Request Add Request Technician Time Update Record Do Work Complete Work Reach Zero Update Record E-Mail Inquiry E-mail Response Open Request
14.
Technician View Information Technician Add/ Update Client Components Client Configurations Client Equipment Request Display Request Request Request Return Return Return Select Add Update
Standard Components Standard Equipment Confirm Confirmation Reception Check-In Inventory Clients Inventory Check-In Add Client New Contract Add
New Inventory Update Add
15. Primitive Diagram Technician Process New Component Installation Enter Component Confirm Installation Add/Update Component Client Components Validate Client Client ID Select/ Validate Equipment
Select Component Clients Client Equipment Standard Components Client Display Equipment Component Valid Equipment Check/Edit Date/ Quantity Equipment Selection Scan Component Enter Installation
Details Invalid Client Invalid Equipment Error Message Enter Component Information Event
16. Entity/Definition Matrix ENTITY BUSINESS DEFINITION Client 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.
17. Context Data Model Work Record Service Request Software Configuration Equipment Client Component Enters Has Owns Owns Contains Key Based Data Model Work Record Service Request Software
Configuration Client Equipment Client Client Component Standard EquipmentStandard Components Enters Has Owns Owns WorkNumPK BarcodeFKPK ClientIDPK ReqNumPK EquipNumFKPK Configuration IDPK
Contains ClientIDFK ClientIDFK ReqNumFK EquipNumPKBarcodePK ClientIDFKPK ClientIDFKPK Contains Contains
18. Fully Attributed Data Model (in 3NF) Work Record Service Request Software Configuration Client Equipment Client Client Component Standard EquipmentStandard Components Enters Has Owns Owns
WorkNumPK BarcodeFKPK ClientIDPK ReqNumPK EquipNumFKPK ConfigurationIDPK Contains ClientIDFK ClientIDFK ReqNumFK EquipNumPKBarcodePK ClientIDFKPK ClientIDFKPK Contains Contains
ClientName ContactFirstName ContactLastName Email State ReportDate ReportedBy Address City Zip Equipment InfoValues InfoName FinishTime StartTime ResolutionDate WorkDate WorkDescription
TechInitials Vendor ModelNum DatePurchased Description EquipType EquipName InServiceDate ComponentType DateRemoved DateInstalled Quantity
19. Use-Case Glossary Use-Case ID Use Case Name Use-Case Description Participating Actors and Roles CTTS-001 Enter 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-002 View 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 Record This use-case describes the event of a technician entering a work record pertaining to an
active service request. Technician CTTS-004 Manually Resolve Service Request This use-case describes the event of a technician completing a service request and marking it “Resolved.” Technician CTTS-005
Automatically 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-006 Enter Component Information This use-case describes the event of a technician entering new, or updating existing client component information. Technician CTTS-007 Enter New Equip This
use-case describes the event of a technician entering new, or updating existing client equipment information. Technician CTTS-008 View 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 Inventory This use-case describes the event of the Receptionist/bookkeeper entering new
inventory items as they arrive in orders. Receptionist/bookkeeper CTTS-010 Enter Configuration Information This use-case describes the event of a technician entering new, or updating existing client
configuration information. Technician CTTS-011 View Installed Components This use-case describes the event of a technician retrieving existing client component information from the database. Technician
CTTS-012 Enter/Edit Equip Type This use-case describes the event of an employee entering new, or editing existing standard equipment information. Any Employee CTTS-013 Enter/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 Client This use-case describes the event of the
Receptionist/bookkeeper adding a new client to the CTTS. Receptionist/bookkeeper
20. Use-Case Model Diagram Enter New Client Enter/Edit Component Type Enter/Edit Equip Type Enter New Equipment View Component Info Enter Component Info View Configuration Info Enter Configuration
info Enter Service Request Enter Work Record View Unresolved Request(s) AutoManual Resolve Request Check In Inventory Client Employee Technician Manager Recept/Book Time * I highlighted the generalization
relationships in yellow to help avoid confusion.
21. Fully-documented Use Case Narrative CTTS Author (s): Nicholai Stevens___ Date: _02/21/2014__ Version: ___1.0______ USE CASE NAME: View Unresolved Requests/History USE CASE TYPE USE CASE ID: CTTS002 Business Requirements: PRIORITY: High System Analysis: SOURCE: Management, Business Requirement PRIMARY BUSINESS ACTOR Client PRIMARY 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 systemdisplays
a list of all requests relevant to the userbased 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
systemdisplays 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 systemwill display the appropriate message. Alt Step 5a: If the useris a technician, he/she will have the option to add a new WorkRecord to the request.If this is selected the systemwill
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 ofthe request to “resolved.” This
will initiate use case CTTS-004. Once a request has been marked resolved, the systemreturns to Step 2. CONCLUSION: This use case successfully ends when the usercloses the “View Unresolved Requests”
screen,and returns to their home page. POST-CONDITION: None BUSINESS RULES None IMPLEMENTATION 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
22. Activity Diagram Request to View Unresolved Requests Retrieve Relevant Requests Display Message Display List No Unresolved Requests 1 or More Unresolved Request Return to List Tech/Manager: Resolve
Request Techs: Add New Work Order Select Request to View Details Retrieve Details Display Details ш Add Work Record Activity Update Record Update List Exit Unresolved Request Page
23. System Sequence Diagram User :System :Service Requests :Work Records View Unresolved Requests Retrieve Appropiate Records Return List/Message Select Record for Details Retrieve Details Return Detail
Add Work Record Relay New Work Record UpdateService Request Return Detail Reslove Request UpdateRequest status Return Updated List/Message Exit Display List/Message Display Detail Display Detail Display
List/Message
24.
Class Diagram EQUIPMENT EquipName LANIP USER UserName UserPassword TECHNICIAN RECEPTION/BOOK CONFIGURATION InformationName InformationValue MANAGER EMPLOYEE +Add/Edit
COMPONENT +Add/Edit ComponentType INVENTORY Barcode DatePurchased SERVICE
REQUEST RequestNum ProblemDescription WORK RECORD FinishTime CLIENT ClientAddress ClientName ContactFirstName ContactLastName DateInstalled DateRemoved ClientEmail InServiceDate
InventoryDescription ModelNum Phone Quantity ReportDate ReportedBy ResolutionDate StartTime Vendor WorkDescription WorkDate Performed On Submits +ShowDetail +ShowDetail Add New +Add/Edit
+Add/Edit +Add/Edit +Verify Enters Checks In +Add/Edit +Add/Edit Manages Reviews 1 1 0..1 1..* 0..* 1 0..* 1 0..1 0..1 1 1..* 1..* 1..* 1..* 1..* 1 1..*
25. Candidate Matrix Characteristics Candidate 1: Desk.com Plus Plan Candidate 2: Kayako Case Candidate 3: Custom Build Portion of System Computerized Brief description of that portion of the systemthat
would be computerized in this candidate. This package would be purchased and customized to fulfill the requirements of thecustomer service request management portion of thesystem. Same as Candidate 1.
This option requires an extension application to be built from scratch to fulfill therequirements 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 customin-house build,
thesystemcan 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 softwareto be purchased, built, accessed, or some combination of these techniques. Package Solution Same as Candidate 1. CustomSolution
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 Implications A 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
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. Client info, Request history stored by service provider Same as Candidate 1. Or, if downloaded information will be stored in relational SQL server DBMS. 2TB capacity. Same as Candidate 2.
26. Feasibility Matrix Feasibility Criteria Wt. Candidate 1 Candidate 2 Candidate 3 Operational Feasibility An assessment of how well the solution meets theidentified systemrequirements 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 systemcontingent on internet connection. Score: 90
Solution fully supports required functionality Score: 100 Solution fully supports required functionality Score: 100 Cultural/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 No foreseeable problems Score: 100 Technical Feasibility An assessment of the practicality of the solution and
theavailability 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 thefuture. 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 Custombuild can be implemented and maintained without issues but this will take away from other responsibilities. Score: 80 Economic Feasibility An assessment of the cost- effectiveness of a project or
solution. Cost to develop: Payback period (discounted): Net present value: Detailedcalculations: 30% ~ $4153 <1 year $15,612 See Attached Documents Score:85 ~ $4153 <1 year $15,612 See Attached Documents
Score:85 ~$3740 <1 year $20,115 See Attached Documents Score:95 Schedule 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: 85 Legal Feasibility An assessment of how well the solution can be implemented within existing legal and contractual obligations. 10% No foreseeable problems Score: 100 No
foreseeable problems Score: 100 No foreseeable problems Score: 100 Ranking: 100 % 92.5 93 93
27. Estimated Costs Desk.com Kayako Case Custom Build Development Costs: Personnel: Personnel: Personnel: 1 Programmer($30/hour) 1 Programmer($30/hour) 1 Programmer($30/hour) -Customize: 16hours Customize: 16hours -CustomBuild: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
*(firstmonthfree trial) *(firstmonthfree trial) Total: $2233 Total: $2233 Total: $170 Total Development Costs: $4153 $4153 $3740 Annual Operating Costs: Personnel: Personnel: Personnel: 1 Technician:12 hours @
$30/hour 1 Technician:12 hours @ $30/hour 1 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
28. Net Present Value Desk.com Cash Flow Description Year 0 Year 1 Year 2 Year 3 Total Development Cost: ($4,153) Operation & Maintenance Cost: $2,796 $3,000 $3,200 Discount Factor for 10% 1.000 .909 .826
.751 P.V. ofAnnual 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,000 Discount Factor for 10% 1.000 .909 .826 .751 P.V. ofAnnual Benefits: $0 $9,090
$9,086 $9,012 T.P.V. of lifetime benefits: $27,188 NPV of this alternative: $15,612 Kayako Case Cash Flow Description Year 0 Year 1 Year 2 Year 3 Total Development Cost: ($4,153) Operation & Maintenance Cost:
$2,796 $3,000 $3,200 Discount Factor for 10% 1.000 .909 .826 .751 P.V. ofAnnual 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,000 Discount
Factor for 10% 1.000 .909 .826 .751 P.V. ofAnnual Benefits: $0 $9,090 $9,086 $9,012 T.P.V. of lifetime benefits: $27,188 NPV of this alternative: $15,612 Custom Build Cash Flow Description Year 0 Year 1 Year 2 Year 3
Total Development Cost: ($3,740) Operation & Maintenance Cost: $1,200 $1,350 $1,500 Discount Factor for 10% 1.000 .909 .826 .751 P.V. ofAnnual Costs: ($3,740) ($1,091) ($1,115) ($1,127) T.P.V. of lifetime costs:
($7,073) Benefits Derived: $0 $10,000 $11,000 $12,000 Discount Factor for 10% 1.000 .909 .826 .751 P.V. ofAnnual Benefits: $0 $9,090 $9,086 $9,012 T.P.V. of lifetime benefits: $27,188 NPV of this alternative: $20,115
29. Clients Destin: Coastline Consulting Windows Server 2012 SQL/Server Database Server Windows Server 2012 With IIS SQL/Server Web Server 8 Windows 7 Pro Clients Any Client with a Browser Windows 7
Pro And IEor Firefox 100 MB/sec TCP/IP Ethernet Or Wifi Access Internet Explorer or Firefox Browser Middleware 100 MB/sec TCP/IP Ethernet Internet Explorer or Firefox Network Architecture Physical DFD
30. SQL Update: ClientComp AddNew Technician D VB .Net: Enter Component SQL Server: tblStandardComp VB + SQL: Select Client Client ID VB + SQL: Select Equipment VB + SQL: AddNew or Remove D SQL
Server: tblClients D SQL Server: tblClientEquip D SQL Server: tblClientComp SQL Read: ClientName SQL Read: ClientEquip SQL Read: ClientComp Display Selected Equipment Components VB + SQL Remove
Component Remove Equipment Selection Manage Components VB .Net: Confirm Removal Manage Client Components Event SQL Update: ClientName Display Selected Client Equipment SQL Update: ClientEquip
SQL Update: ClientComp VB .Net: Pop-up Removal Confirmation VB + SQL AddNew Component VB .Net Select Add New VB .Net Details Textboxes System Date VB .Net: Retrieve Date SQL Read: StandardComp SQL
Insert: ClientComp VB .Net Typeor Scan Barcode VB .Net: ErrorMessage VB .Net: Retrieve Date VB .Net: Return Date VB .Net: Clients ComboBox VB .Net: Equipment ComboBox
31. Design Use Case Narrative CTTS Author (s): Nicholai Stevens Date: _04/08/2014__ Version: __1.1_________ USE CASE NAME: View Unresolved Requests/History USE CASE TYPE USE CASE ID: CTTS-SDUC002
Business Requirements: PRIORITY: High System Analysis: SOURCE: Business Requirement Analysis Use Case CTTS-002 System Design: PRIMARY BUSINESS ACTOR Client PRIMARY 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 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 systemand window W002Service 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 Response OF EVENTS: Step 1: The user clicks the [Unresolved Requests]button. Step 2: The systemdisplays 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 systemdisplays window W007Request Detail. This will showthe 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 systemwill display window W002- Service Requests. ALTERNATE COURSES: Alt Step 2: If no unresolved requests are available for
that user the systemwill 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 systemreturns to the Service
Requests window. Alt Step 5a: If the useris a technician, he/she can add a new WorkRecord to the request.If the [Add Work Order] button is clicked the systemwill launch use case CTTS-003 (Add work Order). Upon
completion the systemreturns to Step 4. Alt Step 5b: If the service request has been completed a technician or management can change the status ofthe request to “resolved.” If the [Resolve] button is clicked the
systemwill update the status ofthe request. Once a request has been marked resolved, the systemreturns to Step 2.
32. CONCLUSION: This use case successfully ends when the usercloses 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 systemis 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 loop User
<<interface>> :Service Request <<interface>> :Unresolved Requests <<interface>> :Request Details :Request History Query :ServiceRequest <<controller>> :View Requests Click "Unresolved Requests"
getRequests(unresolved) retrieveRecords Unresolved Requests Select specific record getRequestHistory(requestNum) Servicerequest details Exit [OK] retrieveRecord Exit [OK] x x x x
33. Design Class Diagram: View Unresolved Requests/History
34. State Machine Diagram Service Request Lifecycle Unresolved Worked On Resolved Resolution Pending Work Record Entered Auto Email To Client (48hrs) Manual Resolution Request Closed No Response
(24hrs) Client Responds Request Submitted
35. 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 Detaildisplay 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. Method: WhiteBox,Control structure (branch, condition) 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. Method: White-Box,Control structure (branch, condition) 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
36. 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- Userexits unresolved requests list page. Post condition- N/A Business 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. Test 2:
Method: Black-Box 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- Userexits unresolved requests list page. Post condition- N/A Business 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 reviewother 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. Test 3: Method: Black-Box
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- Userexits unresolved requests list page. Post condition- N/A Business 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; howeverthe manager should
have an option to reviewother 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.
37. *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 smalldetails 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.
38. 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
39. 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
40. 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.
About
Support
Terms
Privacy
Copyright
Cookie Preferences
Do not sell or share my personal information
English
00:20
© 2023 SlideShare from Scribd

03:49

