EMTM600 Enterprise Software Development, Third Term ...



EMTM600 Enterprise Software Development, Third Term, Spring 2009

Instructor: Val Tannen, val@cis.upenn.edu, 215-898-2665

Case Study based on “Anchor Machinery”

We give here some information about a project called “Anchor Machinery CRM”. The project was based on another case study used by Greg Vesonder in EMTM 601. Thus, you should first read the accompanying document entitled “Anchor Machinery Case Study”.

Based on that description, we began by identifying actors and use cases for our project:

Actors

CallAtt: call center attendant (many)

ChatWeb: chat website; accessible through the company’s website (one)

ChatAtt: chat website attendant (many)

Super: chat website supervisor (one)

ChatCust: customer connecting to chat website (many)

TechAtt: factory-based employee with customer service

duties; specializing in repairs (many)

SalesDB: database where sales information was recorded;

was designed and implemented prior to the development of

our application. (one)

SalesDB Schema (E-R Diagram)

[pic]

Use Cases

1. Customer call to Call Center

a. CallAtt checks in SalesDB for current service contract

UserStory: CallAtt brings up new call form, then obtains from customer over the phone either the sale ID or the customer ID + product ID + sale date. CallAtt enters this data in the form, submits. If system answers no such sale, requests data again, re-enters, re-submits. After three such tries, give up, and no record is made of the call. If sale is found, system may find that service duration has expired. If so, no record is made of the call. If there is a current service contract, the system remembers the data and displays a control panel for other functions.

b. CallAtt accesses product service and repair history

UserStory: Starting from control panel, CallAtt selects service history. Gets back a list of past service transactions. For each, system displays the date when the transaction opened, a complaint code and status (closed/active). ChatAtt can select a transaction and request details, which are displayed on a separate page.

c. CallAtt enters complaint code and obtains answer guidelines

UserStory: At any time during the phone conversation, CallAtt can and should initiate a service transaction recording, from the control panel. A form in a separate page is generated, date and time are automatically entered, as well as sale identification information. A complaint code can be selected from a pull-down menu. This results in the display of answer guidelines in a separate page. CallAtt may also enter the complaint narrative at the same time as the complaint code, or wait till the end of the call.

d. CallAtt records call summary; add to product service history

UserStory: At the end of the call, CallAtt a enters a complaint narrative in the service transaction recording (if not entered earlier), a resolution code (problem solved, customer hang up on me, etc) is selected from a pull-down menu. Additional remarks (eg., “customer is a pain in the neck”) can be entered as free text. When CallAtt submits the form, the current time is also added to the record.

2. Management of multiple ChatCust requests and multiple ChatAtt s at chat website

a. ChatCust login; obtain and check information

UserStory: ChatCust visits company web site and requests chat session. It is prompted for either sale ID or for customer ID + product ID + sale date and enters info. System checks for current service contract, as in 1a. If a current service contract is found, ChatCust is put in queue waiting for next available ChatAtt. The identification information is remembered.

b. Manage ChatCust waiting queue

UserStory: ChatCust waits in queue for next available ChatAtt. Receives updates on remaining wait time periodically. System also maintains list of active ChatAtts with availability status. ChattAtt can be involved in multiple chat sessions simultaneously (how many is one of the system parameters) so availability is determined by comparing the number of active chat sessions with the maximum number. System selects available ChatAtt who then receives alert on screen to join a chat session. Active chat connection initiated and added to list. System goes to next ChatCust in queue.

c. Manage list of active chat connections for Super

UserStory: Super is presented with a list of active chat connections. For each connection, the list displays the id and name of the ChatAtt, the id and name of the ChatCust, the id, name, model, and year-of-manufacture of the product that is the subject of the complaint, the time the customer logged in, the time the chat session started, and the complaint code (when it becomes available). Super can request to inspect the interaction in any chat of the chat sessions and the complaint narrative (when it becomes available). Super is also presented with the size of the ChatCust waiting queue as well as statistics: average waiting time per ChatCust in a specified period of time (today, yesterday, this week), average chat session duration and others.

d. ChatCust logout; get satisfaction report, add to product service history

UserStory: When chat session terminates (disconnect by either ChatCust or ChatAtt) ChatCust is redirected to short customer satisfaction survey. This survey data is added to the service transaction record.

3. ChatCust and ChatAtt have a chat session

a. ChatAtt accesses product service and repair history

UserStory: same as 1b. We assume that once the chat session begins the ChatAtt has the same control panel as the CallAtt.

b. ChatAtt enters complaint code and obtains answer guidelines

UserStory: Same as 1c and in addition ChatAtt can cut and paste between the chat window and the guidelines.

c. ChatAtt records chat summary; add to product service history

UserStory: Similar to 1d, with some additional twists. The ChatAtt should be able to cut and paste text between the chat window and the complaint narrative window in the form that records the service transaction (alternatively, we may automatically save the entire chat script; this may make sense if we have only moderate confidence in our chat attendants and we have good supervisors).

4. Repair-related interaction between a customer and (possibly several) TechAtt (s).

a. Repair initiation by direct customer call to a TechAtt

UserStory: Same as 1a + 1c, except that instead of a service transaction, a repair transaction is initiated and the current call is made its first repair event.

b. TechAtt accesses product service and repair history

UserStory: Same as 1b.

c. Repair initiation by previous support call or support chat.

UserStory: We don’t have this one yet. I am dearly tempted to forget about it

d. Spare part ordered by TechAtt, and shipped to customer.

UserStory: TechAtt brings up the shipment form. Input all the necessary information including part# and shipping address. If necessary collect payment information from the customer and submits. (Assuming that the responsibility of checking part availability is with shipping department.)

The order is recorded as a separate repair event, part of the current repair transaction.

e. Broken machine received from customer, TechAtt initiates repair.

UserStory: The receipt is recorded as a separate repair event, part of the current repair transaction.

f. Machine is fixed, TechAtt shipps it back to customer.

UserStory: TechAtt brings up the shipment form. Input all the necessary information including shipping address. If necessary collect payment information from the customer and submits. The shipment is recorded as a separate repair event, part of the current repair transaction.

g. Follow-up phone call;

i. Initiated by customer

ii. Initiated by TechAtt, possibly a manager to check on customer satisfaction

UserStory: Here we need first a list of currently active repair transaction. Then a choice is made to call. Recorded as an additional repair event.

h. TechAtt summarizes one step of interaction;

UserStory: When an interaction is initiated either by the TechAtt or customer, TechAtt brings up the form to enter the details of interaction. TechAtt fills in the summary of the interaction relating to the customer’s problem. TechAtt then submits the form to update the system.

i. Repair is classified as finished; add to product service history

UserStory: Like 4 h but for the last event in the repair transaction

The next step in architecting the projects was to identify the business objects (the principal entities that participate in the business logic of the application). They form what is usually called a “domain model”, described here in UML:

Domain Model

[pic]

[pic]

An important advantage of using a framework such as Java EE is that the architectural design of the project will follow established patterns. The focus of the developer is in providing detailed design and coding. Moreover, the documentation of the detailed design will be closely guided by the established patterns, by the user requirements, and by the description of the business objects (the domain model). We illustrate with a simple example:

Example of Java EE Documentation

A) We repeat the DB specification as OO classes, eg.:

Sale

- id

- date

- custId

- prodId

- etc.

B) To document the implementation of the logic, we follow a use-case-centric approach:

User Story 1a: CallAtt checks in SalesDB for current service contract

Main flow:

searchsale

SearchSale

Access

getSale(id) : Sale

getSale(date, custID, prodId) : Sale

cpanel

Alternate flow:

searchsale

searchsale

+ “There is no sale…”

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download