AnchorEEcaseStudy by wuxiangyu

VIEWS: 0 PAGES: 9

									                   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)
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
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       <<JSP>>



SearchSale       <<Servlet/Struts/Action+Form>>




      Access                            <<Façade/SessionEJB>>

getSale(id) : Sale
getSale(date, custID, prodId) : Sale



cpanel         <<JSP>>



 Alternate flow:


searchsale       <<JSP>>




searchsale                    <<JSP>>
+ “There is no sale…”        <<error message>>

								
To top