Upload
buck-williams
View
214
Download
0
Tags:
Embed Size (px)
Citation preview
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