Systems implementation & evaluation

  1. What is systems implementation?
  2. What are the tools for physical systems design?
  3. What are the issues to consider before an information system is operational?
  4. What are the key indicators of a quality system?
  5. What are the techniques for systems evaluation?

 

Systems implementation is the process of:

  1. defining how the information system should be built (i.e., physical system design),
  2. ensuring that the information system is operational and used,
  3. ensuring that the information system meets quality standard (i.e., quality assurance).

 

Systems design

Conceptual design what the system should do

Logical design what the system should look to the user

Physical design how the system should be built

 

Physical system design using structured design approach:

To produce a system that is easy to read, code, and maintain

1.      Factoring: decomposition

2.      Span of control: 9 subordinate modules

3.      Reasonable size: 50-100 LOC

4.      Coupling: minimize inter-module dependency

5.      Cohesion: single module functionality

6.      Shared use: multiple calls to lower level modules from different bosses

 

Structured design tools

        Organization of programs and program modules (structure chart)

        Processing logic specification in each module (pseudocode)

 

Structure chart to show graphically

  1. how the various program parts/modules of an information system are physically organized hierarchically
  2. how the modules communicate with each other through data couple (data exchange) and flag (control/message)
  3. how the modules are related to each other in terms of sequence, selection, and repetition

 

Symbols

Components

Symbol

Module

Rectangle

Data couple

Clear circle with out arrow

Control flag

Filled circle with out arrow

Conditional processing/selection

Diamond

Repetition

A curved line intersecting the connection to the modules

Predefined module

Rectangle with a vertical bar on each side

 


Converting DFDs to structure charts

1.      Locate the central transform/transaction center

2.      Find a coordinating module for the top of the chart

3.      Identify the primary input and output data flows

4.      Draw a top-level chart (consists of two hierarchical level)

5.      Refine the chart until the data origin, system function, and output dispositions are defined

 

Cap and gown ordering system example

Step

Example

Center

Process #3: Validate Order

Root module

Process Order

Primary inputs

Student ID, cap size, gown size

Primary outputs

Receipt, Order detail, Inventory update

Top-level

Get student, Get order, Process invalid order, Process valid order

Refinement

Get student, Get order, Process valid order

 


Pseudocode

To provide programmers with a text description of the contents of each module

 

Cap and gown ordering system example

MODULE: Process_Order()

Set EOF = no, VALID = 0

Get_Student

DO WHILE EOF = no

IF VALID = 0

Get_Order

ENDIF

IF VALID = 0

Process_Valid_Order

ELSE Process_Invalid_Order(VALID)

ENDIF

Get_Student

ENDDO

 

MODULE: Get_Student()

SET EOF = no, VALID = 0, TYPE="student"

READ student_ID

IF student_ID = null

THEN EOF = yes

ELSE Verify_Data(TYPE)

ENDIF

RETURN student_ID, EOF, VALID

 

MODULE: Get_Order()

SET TYPE = "order"

READ cap_size, gown_size

Verify_Data(TYPE)

RETURN cap_size, gown_size, VALID

 

MODULE: Process_Invalid_Order(valid)

IF VALID = 1

error = "Student not found"

ELSE IF VALID = 2

error = "Student is not graduating in spring"

ELSE IF VALID = 3

error = "Cap size out of stock"

ELSE IF VALID = 4

error = "Gown size out of stock"

ENDIF

ENDIF

ENDIF

ENDIF

DISPLAY error


MODULE: Verify_Data (type)

IF TYPE = "student"

THEN OPEN Student_File

FIND Student_Record USING student_ID

IF Student_Record NOT_FOUND

THEN VALID = 1

ELSE IF Student.graduate_date <> "Spring 1999"

THEN VALID = 2

ENDIF

ENDIF

ELSE IF TYPE = "order"

THEN OPEN Inventory_File

GET Inventory.cap_on_hand USING cap_size

GET Inventory.gown_on_hand USING gown_size

IF Inventory.cap_on_hand = 0

THEN VALID = 3

ELSE IF Inventory.gown_on_hand = 0

THEN VALID = 4

ENDIF

ENDIF

ENDIF

ENDIF

RETURN VALID

 

MODULE: Process_Valid_Order(student_ID, cap_size, gown_size)

Update_Inventory(cap_size, gown_size)

Generate_Receipt(student_ID, cap_size, gown_size)

Record_order(student_ID, cap_size, gown_size)

 

MODULE: Update_Inventory(cap_size, gown_size)

OPEN Inventory_file

GET Inventory.cap_on_hand USING cap_size

REDUCE Inventory.cap_on_hand BY 1

FIND Inventory.gown_on_hand USING gown_size

REDUCE Inventory.gown_on_hand BY 1

CLOSE Inventory_File

 

MODULE: Record_Order(student_ID, cap_size, gown_size)

OPEN Order_File

Order.student_ID = student_ID

Order.cap_size = cap_size

Order.gown_size = gown_size

WRITE Order_Record

PRINT Order_Record AS Receipt_Report

CLOSE Order_File


Implementation issues

1.      Testing

2.      Conversion

3.      Documentation

4.      Training

 

7 types of tests

Test

Description

Characteristic

Inspection

Manually examine code for errors

Detect 60 to 90 percent of defects

Walkthrough

(Figure 20.1)

Manually review code to find errors by examining what the code does

Should be done when the pieces of work are small

Desk checking

Manually work through the code, executing each instruction using test cases

The reviewer acts as a computer

Syntax checking

Uncover syntax errors by a compiler

The only automated testing technique that is static

Unit/module testing

Discover any error that may exist in a module's code

Each module is tested alone

Integration testing

Discover any error that may exist by combining modules

Top-down gradual testing

System testing

Discover any error that may exist by integrating programs into systems

Top-down gradual testing

 

Testing process (Figure 20.27)

  1. Program testing with test data
  2. Link testing with test data
  3. Full systems testing with test data (alpha test)
  4. Full systems testing with live data (beta test)

 

Testing guidelines

         Test different aspects of the system, e.g., response time, response to boundary data, response to no input, response to heavy volumes of input

         Test anything that could go wrong or be wrong about a system

         Test the most frequently used parts of the system at a minimum

         The people who create the test cases should not be the same people as those who coded and tested the system

         Use debugging tools, e.g., symbolic debugger

 


Conversion strategies (Figure 21.12)

Strategy

Pros and cons

Direct/abrupt/

cold-turkey

         risky

         least expensive

Parallel

         less risky

         expensive

         confusing to users

Gradual/Phased/staged

         more manageable

         requires careful version control

Modular/Pilot/single location

         middle-of-road approach

         limits potential damage and cost

 

Types of documentation

System documentation maintenance programmers

Records detail information about a system's design specifications, functionality (external), and internal workings (internal), e.g., DFDs, ERDs, Structured English, Structure Chart, Pseudocode.

 

User documentation end-users

Records information about an application system, how it works, and how to use it, e.g., user manual, procedure manual

 

Documentation standard

  1. Compatible
  2. Comprehensible
  3. Informative
  4. Adequate
  5. Structured
  6. Maintainable

 

Training guidelines (Figure 21.11)

  1. Consider who will be the trainer and trainee
  2. Establish measurable objectives
  3. Use appropriate training methods
  4. Select suitable training site
  5. Use understandable training materials

 

Training topics

1.      Use of the system

2.      Computer concepts

3.      IS concepts

4.      Organizational concepts

5.      System management

6.      System installation

 


Training methods

1.      Local experts: 51%

2.      Computer-aided instruction: 17%

3.      On-line help: 10%

4.      Course: 10%

5.      Tutorial: 7%

6.      External sources: 5%

 

Why implementation fails

1.      Conventional wisdom: management support and user involvement

2.      Factor model: Ginzberg's 4 factors, Lucas's 6 factors

 

Ginzberg's 4 factor model

1.      Project commitment: how well understood?

2.      Change commitment: how willing to change?

3.      Extent of project planning and definition: how well planned?

4.      User expectations: how realistic?

 

The Lewin/Schein change model

1.      Unfreezing

        Establish a felt need

        Create a safe atmosphere

2.      Moving

        Provide necessary information

        Assimilate knowledge and develop skills

3.      Refreezing

        Integrate the new behavior into ongoing behavior

        Diffuse the change throughout the system

 

5 areas of expectations

Goals: the reasons for developing the system

Importance: the importance of the problem being addressed

Patterns of use: the way the system will be used

Impacts: system impacts on the organization

Evaluation criteria

discuss these expectations from time to time involving end users, mangers, and system developers

Source: Ginzberg, M.J., "Early Diagnosis of MIS Implementation Failure: Promising Results and Unanswered Questions," Management Science, vol.27, no.4, April, 1981, pp.459-478

 

Lucas's 6 factors model

1.      User's personal stake: how important?

2.      System characteristics: how easy to use?

3.      User demographics: how computer literate?

4.      Organization support: how committed?

5.      Performance: how much can be done?

6.      Satisfaction: how much is used?

 

Escalation traps

Factor

Description

Project

         Setbacks are temporary

         Money spent as investments toward a large pay-off

         Expenditures are irretrievable

Managers

         Reward for perseverance

         See only what confirms their preferences

         Self justification or protection

Social pressure

         Do not want to admit error or expose mistakes

         Associate persistence with strong leadership

Organization

         Administrative inertia

         Political resistance

         Company identity

 

Prevent over-commitment

Means

Description

Recognize over-commitment

         Concrete definition of failure

         Prevent personal attachment to projects

         Open to other's concerns about the project

         Put the company before the project

         Consider withdrawal alternatives

         Step back and look at the project from an outsider's perspective

Change the organization

         Replace project managers

         Separate initial from subsequent decisions

         Lessen the risk of failure

         Reward honest recognition of problems

Experimentation attitude

         Avoid institutionalize projects

         Subject all ventures to regular reconsideration

 

Source: Staw, B.M., and Ross, J, "Knowing When to Pull the Plug," Harvard Business Review, March-April, 1987, pp.68-74

 


 

Quality assurance to ensure that the system actually developed meets current and projected needs of the users and the organization

Total quality management approach to quality assurance:

  • To build systems correctly from the start
  • To detect and fix errors as soon as possible

 

Indicators of a quality system

  1. Structured: top-down in design; modular in programming
  2. Documented
  3. Tested
  4. Maintained, and
  5. Audited

 

Structured system = structured analysis + structured design + structured programming

Structured analysis: input-process-output

Structured design: modular

Structured programming: sequence-selection-repetition

 

Main causes of changes

  1. New business/strategic development
  2. New technology
  3. Organizational changes
  4. Original specification is inadequate
  5. Government/legal changes
  6. External factors, e.g., suppliers, customers
  7. New policies, e.g., security, financial cutbacks
  8. Original specification is not property implemented
  9. Personnel changes

Source: Fitzgerald, G., Philippides, A., and Probert, S., "Information Systems Development, Maintenance, and Enhancement: Findings from a UK study," International Journal of Information Management, vol.19, 1999, pp.319-328.

 

Systems evaluation

  • provide feedback for system improvement
  • measure the success of a developed system

 

Evaluation technique

IS utility approach (Figure 21.14)

An IS can be evaluated as successful if it possesses all six utilities:

  • Possession (who)
  • Form (what)
  • Place (where)
  • Time (when)
  • How (actualization)
  • Why (goal)