Course - DT249/1Course - DT249/1

Subject - Information Systems in Organisations

BUILDING INFORMATION SYSTEMS

Semester 1, Week 8

1

2

Model Content TitleModel Content Title

From the course document, this week’s lecture refers to:

Building Information Systems

Managing information systems operation

3

Textbooks?Textbooks?The Laudon and Laudon book,

‘Management Information Systems’ (Seventh Edition) – Chapters 10 and 11 match this lecture the closest – though I have gone off at a tangent of my own.

Where/When Does the ‘Build’ Where/When Does the ‘Build’ Begin?Begin?The building of an Information System

could be viewed as occurring throughout the life cycle, but the main ‘build’ – the one that has the appearance of a project – is in the latter part of the Design Phase and throughout the Implementation Phase.

Building assumes that most, if not all, of the design issues have been agreed upon between the client and the vendor.

4

5

System Build – Where It Fits System Build – Where It Fits InIn

Systems Investigation

Systems Analysis

Systems Design

Systems Implementation

Review & Maintenance

Feasibility Study

Project Selection

The ‘build’

Implementation is building upon the Design to further develop the selected solution

6

From Design to From Design to ImplementationImplementationThe next 16 or so slides look at

the typical features of Design and Implementation phases to see how the building of an information system spreads itself as an ‘extended process’.

7

Systems DesignSystems DesignThe Systems Design Phase:

◦Details how the system will meet information requirements as determined by the procedure of Systems Analysis

◦May involve the user interface and output design for usability

◦Deals with configuration and architecture issues related to the system for scalability, reusability, and performance (measurement)

8

Systems Design (2)Systems Design (2)The Systems Design Phase usually

has many items of documentation.Typical and important documents

are the Specifications for the system solution.

The Design Phase should reflect clearly the clients’ business priorities and information needs.

9

Between Design and Between Design and ImplementationImplementationProgramming and Testing

◦Programming: The process of translating System Specifications into program code.There are many different programming languages. More than one may be needed for coding the complete system specification. The coding stage breaks down into:

the logic of linear processes, logical decisions, repetition, and ‘calls’ to other programs.

10

Between Design and Between Design and Implementation (2)Implementation (2)

(With regard to coding)

Integration of code is needed and may be required at:

module, application, system, intra-system and inter-system levels

via ‘middleware’ and calls to programs/modules.

11

Between Design and Between Design and Implementation (3)Implementation (3)Programming and Testing

◦Testing:Checks whether the system of programs/modules produces the desired results under known conditions.Is a serious part of the development of a system and good ‘test cases’ are required.

Testing includes ‘unit’ testing (testing individual modules), system testing (testing all programs together), acceptance testing (demonstrating all programs for client agreement).

There is often a document showing a ‘test plan’.

12

Between Design and Between Design and Implementation (4)Implementation (4)System Conversion:

The process of changing from the old system to the new system.

Four possible installation choices:1. Firm-wide rollout versus ‘single location

installation’ rollout (Example; all Currys stores Vs. one Currys at a time)

2. Entire application installation versus ‘phased’ installation (Ex; all software loaded Vs. one application at a time)

3. ‘Direct’ installation vs. ‘parallel’ installation (Running without old system Vs. using new and old together until the ‘new’ is trusted)

4. Insource versus Outsource (Internal IT expertise Vs. ‘hired in’ IT expertise)

13

Between Design and Between Design and Implementation (5)Implementation (5)System Conversion:

Four possible strategies for conversion:◦ Direct cutover (As in 1, 2 and 3 of previous

slide)◦ Parallel (As in 1, 2 and 3 of previous slide)◦ Pilot study (As in 1 and 2 of previous slide)◦ Phased approach (As in 1 and 2 of previous

slide)◦ Documentation-driven (where no previous

systems exist, relying on documentation to ‘test and compare’)

14Source: Valacich et al., 2001

Four installation choices:1. Firm-wide rollout vs.

“single location installation” rollout

2. Entire application installation vs. “phased installation”

3. “Direct installation” vs. “parallel installation”

4. Insource vs. Outsource (usually transitional)

15

Between Design and Between Design and Implementation (6)Implementation (6)Production and Maintenance:

◦Production is the stage after the new system is installed and the conversion is complete. Basically, it is the system in use.

◦Maintenance is a series of tasks following changes in hardware, software, documentation or procedures to correct errors in the system(s).

Maintenance can be seen as starting the process over again, but on a different scale.

16

Information Systems Information Systems SolutionsSolutionsEvaluating and choosing Information

Systems solutions has the processes of:◦Feasibility issues examined◦Costs and benefits examined◦Advantages and disadvantages

identified◦Business value of systems identified◦Change management planned (More on

this later)

17

Information Systems Information Systems Solutions (2)Solutions (2)Developing an Information Systems

solution looks a lot like this:

18

Information Systems Information Systems Solutions (3)Solutions (3)Implementing the solution has the

processes of:◦Systems design◦Completing implementation

Hardware selection and acquisition Software development and programming Testing Training and documentation Conversion Production and maintenance

◦Managing the change

19

From Management to From Management to ProgrammingProgrammingLet us examine some of the

issues related to the ‘sub-phases’ of Programming and Testing.

The next part of the lecture tries to keep to the themes of Design and Implementation Phases as well as Project Management.

Coding PracticesCoding PracticesA good software program:

◦works according to specification and is verifiable

◦ is well commented◦is written in an appropriate language◦has a simple design◦is modular, with independence◦uses only sequence, selection and

iteration◦is independent of specific hardware

constraints◦ is efficient

20

21

Coding Practices (2)Coding Practices (2)Good commenting (accompanying

instructions) examples:4 - 5 lines per module

(subroutine/section)1 line per 4 - 5 lines of code.Assembler (low level) programs should

have almost one comment per line.4GLs do not need much commenting.Comments should be brief and to the

point.Data and module names should also

be brief and to the point.

22

Coding Practices (3)Coding Practices (3)Pitfalls in code commenting:

◦Redundant commenting,◦Obsolete comments,◦ Incorrect comments,◦Vague comments,◦Correct, but incomplete comments,◦ Incomprehensible comments.

23

Design OptionsDesign OptionsWhen designing software programs

there are two main options: ◦Top-Down Design and Bottom-Up.

Top-Down is probably the most popular and begins with a general view, moving to more detailed views that become comparable to code modules.

Bottom-Up begins with finer-detailed program design options and tries to fit them to broader solutions.

24

Top-Down DesignTop-Down DesignTop-Down Design practice includes:

◦Formal and rigorous specification of input, processing and output of each software module.

◦When the software module is properly specified, disregard the internal workings.

◦Keep away from trivialities.◦Each level of design should be

expressible on a single page of flowchart.◦Pay as much attention to data design as

to process/algorithm design.

25

Top-Down Design (2)Top-Down Design (2)Moduler Project example

26

Top-Down Structure Top-Down Structure DiagramsDiagrams

C on ten ts :1 .2 .3 .4 .5 .6 .7 .8 .9 .1 0 .1 1 .1 2 .

5 6

2

7 8

3

1 1 1 2

9 1 0

4

1M A IN

HIPO stands for Hierarchical Input Process Output

HIPO Diagrams

27

Top-Down Structure Top-Down Structure Diagrams (2)Diagrams (2)For each module do an Input-Process-Output

(IPO) chart

Input Processing Output

Top-Down CodingTop-Down CodingAs a level is specified, the coding is done for

that level, before subordinate levels are specified.

Design flaws discovered early on.‘Dummy’ modules must be inserted, to allow for

the running of the program. Some modules will take precedence over others;

a processing module cannot run without the input module being written and the results cannot be seen without the output module.

Arrange modules in the program in an organised fashion, i.e. either horizontally or vertically.

28

The Advantages of The Advantages of ModularityModularityWhen writing code as modules there are

advantages.

Code is:◦Easier to write and debug.

◦Easier to maintain and change.

◦Easier for a manager to control (e.g. as regards delegating programming tasks to programmers of varying abilities).

29

The Disadvantages of The Disadvantages of ModularityModularityCoding modules has disadvantages:

◦A lot of programmers do not understand it.

◦ It requires a great deal of extra work.◦ It may require more processing time on

the computer.◦ It may require more main memory.◦ It may cause problems in real-time and

on-line systems.◦Modules normally working together

should be on the same page.

30

31

Testing LevelsTesting Levels1. Module (unit/program) Testing.

2. Subsystem Testing (Groups of modules but not the whole system).

3. Integration Testing (The whole system).

Testing MethodsTesting MethodsBlack Box Testing - (Functional Testing)

◦Top-Down testing

◦Knowing the specific functions a system is required to perform, tests are developed to demonstrate that each function is working correctly.

32

Testing Methods (2)Testing Methods (2)White Box Testing - (Structure Testing)

◦Bottom-Up testing

◦Knowing the internal workings of the system, tests are developed to ensure that each program is working according to it’s specification.

33

Black BoxBlack BoxUse dummy modules to represent the lower echelons…

Main

A B C

A, B and C may be blocks or modules of code – or whole programs.

34

Black and White Box: Black and White Box: DifferenceDifferenceWhat is the difference between black- and white-box testing? Black-box (procedural) test:

Written without knowledge of how the class under test is implemented.◦ focuses on input/output of each component or call

White-box (structural) test:

Written with knowledge of the implementation of the code under test.

◦ focuses on internal states of objects and code◦ focuses on trying to cover all code paths/statements◦ requires internal knowledge of the component to craft

input example: knowing that the internal data structure

for a spreadsheet uses 256 rows/columns, test with 255 or 257

35

36

Black Box (2)Black Box (2)The system is considered as a black box whose behaviour is determined by examining inputs and related outputs.

Tests are designed to demonstrate that◦system functions are operational◦ input is correctly accepted◦output is correctly produced◦the integrity of the system files/databases

are maintainedTest cases are derived from the requirements documentation.

Black Box (3)Black Box (3)Black box tests attempt to find software

errors such as:◦incorrect or missing functions◦ interface errors◦errors in data structures or external file

or database access◦performance errors◦ initialisation and termination errors

37

Black Box (4)Black Box (4)The benefits of Top-Down testing:

◦System testing ought to be eliminated◦Major interfaces are tested first◦Prototyping is enabled◦A usable subset is available before the

deadline◦Testing is evenly distributed ◦Quicker results◦ It creates a ‘natural test harness’

38

X, Y and Z may be

blocks or modules of code – or

whole programs.

39

White Box TestingWhite Box Testing

X Y Z

X Y Z

A

40

White Box Testing (2)White Box Testing (2)Using White Box Testing the software

engineer can design test cases that check:Path - Guarantee that all independent

program paths within a module have been exercised at least once

Condition - Exercise all logical decisions on their true and false sides

Loop - Execute all loops at their boundaries

Data Structures - Exercise internal data structures to ensure their validity

White Box Testing (3)White Box Testing (3)Bottom-Up Testing might be needed:

◦for testing a module for insertion into a Top-Down structure.

◦To rigorously test a module where the program environment cannot.

IE The module cannot be tested as part of the whole software system.

◦To allow for an imperfect Top-Down implementation (EG where the design is flawed or inefficient).

41

Desk CheckingDesk CheckingWhen a programmer checks the program

logic by looking at it as a print-out. General errors found include:◦Failure to follow specification

◦Commenting errors

◦Quality (standards) errors

◦ ‘Fitting-in’ (being able to run on the hardware)

◦Logic errors (sequence, selection, iteration logic errors)

42

43

Structured WalkthroughStructured WalkthroughThis is a presentation of a program to a

group, which may include other programmers on the project, the project leader or manager and maybe a user.

All are issued with a listing of the program specification, coding, test data and results a day or two before the meeting.

44

Structured Walkthrough Structured Walkthrough (2)(2)The purpose of the walkthrough is to

provide a non-aggressive evaluation of the program, in regards to its 'goodness' as described earlier.

The programmer receives advice on where a program contains errors.

It is the programmer's responsibility to correct any errors uncovered and to hold another walk-through. The idea of the walkthrough is that responsibility for the 'goodness' of the program is shared.

45

Evaluating Test ResultsEvaluating Test ResultsTest results can be :-

◦output files◦ reports◦screens◦updated data on a database

To check them they must be printed, browsable or compared with expected results. Differences should be printed or otherwise recorded.

If differences exist, a storage dump may be produced. This is difficult to use, stops the test run and generally signifies serious trouble.

46

UtilitiesUtilitiesThe utility exercises of code testing (which

may, themselves, be programs… system software programs) include:◦Traces◦Core dumps◦Snapshots◦Desk checking◦Test data loader◦Test data generator◦Transaction capture facility◦

47

Other Testing MethodsOther Testing MethodsStatic program analysis (Isolating

programs and inspecting them line by line)

Dynamic program analyser (This may be a testing program ‘run over’ the module under test)

Mathematical proofs (Using comparative formulae)

48

Other Testing Methods (2)Other Testing Methods (2)Seeded bugs (Placing bugs (which are

erroneous instructions or data) into a program to see how many are detected. Example; placing 10, 6 found – indicates a 40% detection failure rate)

Cleanroom approach (Where the code is tested as it is written so that no errors ‘creep in’)

49

Testing PrinciplesTesting PrinciplesAll tests should be traceable to client

requirements. (A ‘quality quotient’ should be met).

Tests should be planned long before testing begins.

80% of all errors uncovered during testing will likely be traceable to 20% of all program modules.

50

Testing Principles (2)Testing Principles (2)Testing should begin “in the small”

and progress toward testing “in the large”.

Exhaustive testing is not possible.

To be most effective, testing should be conducted by an independent third party.

51

Characteristics of Testable Characteristics of Testable SoftwareSoftwareOperabilityObservabilityControllabilityDecomposabilitySimplicityStabilityUnderstandability

Managing the ChangeManaging the ChangeNew information systems have a

powerful impact on an organisation – behaviourally and organisationally.◦They change how information is used

and this often leads to new distributions of authority and power.

◦Sometimes internal organisational change fosters resistance and opposition from people.

Change management is required for successful system building.

52

Managing the Change (2)Managing the Change (2)During the Implementation Phase of a

project:All organisational activities should be

working towards the adoption, management and integration of an innovation.

Who is the change agent?

53

Managing the Change (3)Managing the Change (3)The change agent takes responsibility for

the change caused by the new system.◦ It could be a manager from te organisation,

a project manager or a systems analyst.The systems analyst as change agent:

◦She or he redefines the configurations (of tasks), interactions, job activities and power relationships of individuals and groups.

◦They are a catalyst for the change process.◦Responsible for ensuring all parties accept

the changes caused by the new system.

54

Managing the Change (4)Managing the Change (4)Management can give support and

commitment to the new system changes. This would provide:

a positive perception by both users and technical staff

assurances about sufficient funding and resources

enforcement of required organizational changes (possibly)

55

Process Review for Process Review for ImplementationImplementationThere may be process reviews carried

out by the change agent or group, such as:◦Managing technical complexity –

Usage of internal integration tools to ensure the operation of an implementation team.

◦Formal planning and control tools – Structuring and sequencing tasks, monitoring progress towards the fulfillment of goals.

56

Process Review for Process Review for Implementation (2)Implementation (2)The process review group will:

Allow for the human factor – including the interaction of people and technology in the work environment.

Apply sociotechnical design – producing an information system that blends technical efficiency with sensitivity to organisational and human needs.

57

The Role of End Users (Process The Role of End Users (Process Review)Review)With high levels of user involvement the system is more likely to conform to requirements.Users are more likely to accept system.

User-designer communication gap –Users and information systems specialists have: Different backgrounds, interests, and prioritiesDifferent loyalties, priorities, vocabulariesDifferent concerns regarding a new system

58

Organisational and Systems Organisational and Systems ScopeScopeCore processes of an organisation may

be critical to the organisation. Core systems may support core processes and/or functions.

Implementation tactics – cooptation(?)◦This tactic or strategy is about bringing

all people affected by change (end users) into the design phase as well as the implementation phase.

59

Organisational and Systems Organisational and Systems Scope (2)Scope (2)

60

Managing Change Managing Change (in Project Management)(in Project Management)

• Managers focus on solving problems and meeting challenges.

• Project planning is an enterprise-wide focus…

61

62

What Next?What Next?

Next week:

System Projects and Project Planning