Systems Analysis and Desgin Notes

System Analysis and design by Balirwa Moses 2010

1

Systems Analysis and Design

Instructor: Balirwa Moses

Email: [email protected]


2

Introduction

•The Systems Development Process (Overview)•Project Selection and sources of Projects


3

Course Overview Business and government rely heavily on information systems to support their missions and goals. In fact it is almost impossible to conduct substantial business these days without 'computers''. Many people use the word "computers" as a surrogate for the information system on which they are relying.

This is an introductory resource for systems analysis, design, and implementation of information systems. Systems analysis, design, and implementation are, in the broadest sense, the processes used by professionals to develop or maintain information systems.


4

Objective

• To give an understanding of the methodologies and the applicability of the steps involved in analysing, designing, testing and implementing a computer / information system.

Why?• Projects do not succeed by chance• Successful IT projects follow systematic “analysis

and design” process


5

Introduction

• Earlier applications that used computers were business applications, such as keeping records of transactions, Airline reservations etc.

• Computers are now becoming part of virtually every activity in an organization.


6

What Information Systems Can Do

PORT OF ROTTERDAM

• Largest commercial port

• 30,000 ocean going vessels & 150,000 river boats per year

• 300 million tons of cargo per year

• $35 billion in revenue per year

• Fierce competition from other ports

• Develop plan 2010 - $23 billion to be spent on developing IS


7

• Port business is very dependent on quick information exchange between the companies involved

• Large oil companies, freight forwarders, custom brokers need to get there IS connected with that of the port for fast exchange of cargo manifests, import permits etc.

• All such documents in digital form

• Similar methods adopted by Port of Singapore

• Processing time reduced from 2-4 days to 15 minutes


8

• Keeping a ship in dock for an extra day costs its owners dearly, amounting to millions of dollars

• Singapore port has cut down it’s processing staff by 75%

• Volume of shipment has doubled• Economies of EDI benefits both customers & the

port• Container handling companies can prepare the

appropriate freight just in time for truck arrival• The times that trucks spend in the port has been

cut down to 15 to 20 minutes from a previous 1-2 hours


9

• Even a small company now stops at the port 50-55 times a day

• Vessel Traffic Management System – provides traffic controllers with a complete overview of traffic in the port 24 hrs. a day

• Maintains historic data too for seagoing ships

• Helps managers to control current operations as well as plan for the future

• Gets help from Rotterdam’s Erasmus University

• Will create many job opportunities in the IT sector


10

Definition

• SA & D covers the entire systems development process from planning all the way through implementation, maintenance, and evolution.

• It is a process that includes all activities performed to produce an automated IS.


11

Justification of SA & D

What an organization needs to do in order to computerize.


12

What is a System?

• A System is set of interrelated components, working together for a common purpose.

• A generic systems model consists of six components – inputs, outputs, controls, feedback, and boundary.

• Using predetermined controls, a system accepts inputs at its boundary, processes them into outputs, and provides a feedback mechanism for taking any necessary corrective action.


13

Cont…

• The internal control subsystem either directly implements change to the IS or notifies the end-user that the system is not functioning properly.

• Controls ensure that input data is valid before its processed, that file and database data are protected against unauthorised access and update, that recovery procedures are available for a system catastrophe, that output information is disseminated to proper end-users, and that other relevant conditions are met.


14

System Boundary• A boundary (scope) is the perimeter or border of

the system – elements, features, options, that will be included in the system.

SystemProcessing

Boundary

Inputs Controls

Feedback Outputs

Systems Model with six components


15

Components of an Automated Information System

• An IS is an arrangement of interdependent human and machine components that interact to support the operational, managerial, and decision-making information needs of the business’s end-users.

• An IS is made up of:-• Hardware• Software• People• Data• procedures


16

An Automated Information System

Data People

Procedures

Hardware

Software


17

Characteristics of an Information System

• Data – are either (I) input via some data entry device, (II) already in the system and stored on a storage device, or (III) displayed or printed on an output medium.

• Function (process, method) – is a transformation or action taken by the IS. Functions carry out and enforce business policies, rules, and procedures.

• Behaviour – is the observable effects of a request.


18

Basic Characteristics of an IS

• Data: input, stored, or output• Function: business activity performed• Behaviour: the observable effects of a request

Data Functions

Behaviour


19

Systems Development Process(Overview)

• SA & D takes a much broader perspective and focuses on:

• Systems Planning – performing planning and initial feasibility activities to determine which IS projects take priority over others.

• Systems Analysis – understanding and documenting the requirements of a specific problem domain. A problem domain refers to the business problem or function being planned, analysed, designed, and ultimately implemented as an automated IS.


20

Cont…

• Systems design – designing an appropriate solution for the problem domain based on the documented requirements from SA.

• Systems Implementation – constructing, testing and installing the information system and having the users use the IS.

• Systems Evolution – maintaining and enhancing an IS so that it continues to meet the needs of the business.


21

What does a Systems Analyst Do?

• A systems analyst studies the problems and needs of an organisation to determine how people, methods, and computer technology can best accomplish improvements for the business.

Duties of a Systems Analyst• Look at how information is used, handled and

manipulated in an organization.


22

Cont…

• Identifying inefficiencies in the current system that the organization is using e.g. delays, high operating costs, huge clerical effort.

• Analyze the results of the investigation that will lead to designing the system.

• Design and specification of a new system which overcomes the inefficiencies and meets organization objectives.

• Oversees the process of testing during the testing of the system.


23

• Qualifications of SA– Very wide and deep understanding of the

concepts of IT.– Ongoing interest in updating one’s knowledge

in IT.• Qualities of a SA

– Working knowledge of IS Techniques and Technology

– Computer Programming Knowledge– Problem-solving skills (creativity)– Interpersonal Relations skills (confidence,

persistent, patience)– Interpersonal communication skills


24

Systems Analyst

Vendors

Steering Committee

Users

Managers

Database Administrators

Programmers& Technical

Staff

Stakeholders of an Information System


25

Cont…

• NB. These teams will be created and disbanded as projects are started and completed or cancelled.

What is the analyst’s role in the systems project?• The analyst may be viewed as a facilitator. The

analyst acts as the interface among many different types of people and facilitates the development of computer applications through these people.

• The analyst may well be the only individual who sees the big picture of the system.


26

Steering Committee

Role of the Steering Committee• This committee is formulated in the organization

to oversee the Systems Study and thereafter.• Steering Committee is usually composed of cross

functional, senior managers within a business:– Personnel from IT department– Vice presidents / directors– Accounts department– Administration


27

Cont…

– Data processing department– SA team (if it’s from outside)– Senior Information Systems Manager

Functions of the Steering Committee:• The main role of this group is to conduct high-

level reviews and evaluations of proposed IS development projects and make recommendations for prioritization and resources for the projects.


28

Cont…

• Study, determine and maintain an IT policy for the organization.

• Get views and requirements of the user dept to be represented as they try to look for solutions for the entire organization.

• Initiating IT systems development projects.• Interviewing and appointment of IT personnel.• Selecting suppliers and negotiating supply

contracts with them and include penalty clauses.


29

Cont…

• Vendors are those businesses which support the IS development effort, such as consultants, hardware, software companies, training companies, telecommunication companies, documentation companies, and so on.


30

Stakeholder

Information Technology staff

AnalysisDesign

&Implementation

ProblemDefinitionSkills (2)

Requirements(1)

ContinuedInvolvement (5)

RequirementSpecification (3)

Problem Solution Skills (4)

InformationSystem (6)

General model of Systems Analysis, Design & Implementation


31

Where do Systems Projects Originate?

• New or changed IS development projects come from problems, opportunities, and directives and are always subject to one or more constraints. Most maintenance of existing IS projects come from users discovering real problems with existing IS.

• Problems – may either be current, suspected, or anticipated. Problems are undesirable situations that prevent the business from fully achieving its purpose, goals, and objectives.


32

Cont…

• An Opportunity – is a chance to improve the business even in the absence of specific problems. This means that the business is hoping to create a system that will help it with increasing its revenue, profit, or services, or decreasing its costs.

• A Directive – is a new requirement that is imposed by management, government, or some external influence. I.e. are mandates that come from either an internal or external source of the business.

• Constraints are limitations and compromises that come with the soon to be developed IS.


33

Systems Development Life Cycle• The Systems development life cycle (SDLC) is

the process by which an IS comes to life and maintains its usefulness to a business as it moves from inception to replacement.

Phases include:• Systems planning – planning for the new system.• Feasibility study (optional) – determines whether

or not significant resources should be committed to the other phases of the life cycle.

• Systems study and Analysis – requirements determination.


34

Cont…

• Conceptual (logical)– define the inputs, files, processing, and outputs for the new system.

• Physical design – outputs, inputs, files, methods, and procedures, internal controls, (these can be done by prototyping).

• Construction, and testing, or purchase, testing, and integration.

• Implementation – Conversion from current system to new or changed system; Training.

• Evolution for enhancements and maintenance – continuous systems support.


35

Principles to guide Systems Development• The system is for the end-user. Get the end-user

involved through out the systems development.• Establish phases and tasks to better manage systems

development projects.• Systems development tasks aren't strictly sequential.

They can overlap. Also, you may need to backtrack / revisit to correct mistakes.

• Systems are capital investments. They should be economically justified as such.

• Establish checkpoints to re-evaluate feasibility, and don’t be afraid to cancel infeasible projects despite sunk costs.

• Documentation should be the natural, working by-product of systems development. Don’t post document phases or tasks.


36

Feasibility Analysis and Requirements Determination

•Feasibility Types – Technical, Operational and Economic, and others

•Requirements Determination Sub activities

•Fact gathering techniques


37

How to Survey Feasibility of the project and study the current System

Purpose and objectives of the Survey and Study: • To understand the current system and its problems

and to determine if solving the problems would be beneficial.

• NB: The Survey phase is a preliminary investigation of the system, whereas the study phase is a much more detailed investigation.


38

Feasibility Study

• Feasibility study:• Is the measure of how beneficial the development

or enhancement of an IS would be to the business. • A preliminary investigation is done at this stage.

Purpose of the feasibility study:• Define the problem – it provides a broad statement

of user requirements in users terms, or what the users expect the system to do (project goals)


39

Cont…

– This phase also sets project bounds, or scope of the system which defines what part of the system can be changed by the project and what parts are to remain unchanged. Document flow diagrams & a context diagram may help at this stage.

– Identify the users of the system.– Specify the resources to be made available for

the project (resource limits).


40

Cont…

– Propose general Hardware/systems software options in broad terms (client-server configuration), which is necessary to size the project.

– Perform a value assessment, such as the cost-benefit analysis, based on the project size.

– Assess the project risks.– Recommend whether to proceed with the

project or abandon the project


41

Cont…– project goals, project bounds and resource

limits are some times called a project’s terms of reference and set by the management of the organization.

a) Feasibility Types• Operational feasibility – is the measure of how

well a particular IS will work in a given environment. I.e. will the solution fulfil the end-users’ requirements? Will the organizational change result in an acceptable quality of working life for those affected by the system?


42

• Technical feasibility – is the measure of the practicality of a specific technical IS solution and the availability of technical resources. I.e. Do we have the technology & skills needed to develop & operate the system?

• Economic feasibility – is the measure of the cost-effectiveness of an IS solution. I.e. Will the system result in competitive advantage to the enterprise?

• Legal – Will the proposed system conform to laws & regulations?

• Ethical – Will the proposed system conform to the norms of ethics?


43

b) Other aspects of feasibility study:• What volumes of data will be handled, what

numbers of users in various categories will be supported and with what levels of service, what file & database capacities the system will need to maintain, and other quantitative estimates of this type.

• What interface will be provided for the users to interact with the system, based on the skills & computer proficiency of the intended users.

• What control measures will be undertaken in the system.


44

Requirements Determination• It addresses the gathering and documenting of the

true and real requirements for the IS being developed.

• A Problem Domain – refers to the business problem, area, or function being investigated and analysed.

• The purpose of the investigation and analysis is to determine the need to purchase, make, or revise an IS to enhance the business activity of the problem domain.

• Requirements is the wants and /or needs of the user within a problem domain.


45

Frameworks for understanding and doing Requirements Determination

1. Requirements Determination Sub activities - Requirements determination is the general data-gathering activity done during analysis. It has 4 sub activities: -

• Requirements anticipation – the SA hypothesizes that particular requirements are relevant based on his or her previous experience with other similar systems and knowledge about the problem domain.

• Requirements Elicitation – the SA uses this activity to gather the essential requirements from the stakeholders employing a variety of techniques, such as interviews, questionnaires.


46

Cont…• Requirements Assurance – the SA uses this activity of

requirements assurance to validate and verify the requirements with the user as being the real and essential requirements.

• Requirements Specification – this is the activity that the SA uses to explicitly catalo and document the requirements either during or after the elicitation and assurance activities. This is a doc that outlines all the requirements that the proposed system must address. It forms a contract btn the system analyst and the customer the specification document further provides a basis for system testing and validation. It also helps in system in trouble shooting.


47

Cont…2. The PIECES Framework - Focuses on the

actual work of doing requirements determination. The model is used to classify identified requirements into one of six subject areas:- Performance, Information, Economy, Control, Efficiency, and Services.

• Performance questions address how the system needs to perform for the user. Issues of throughput and response time are considered.

• The Information category provides the basis for the information or data model that the system needs to maintain. Issues dealing with input data, output data, and stored data are considered.


48

Cont…• Economy addresses project development and

operational cost information along with any objectives that may relate to economy or savings associated with the system.

• The Control category is closely associated with system security issues as well as the editing required on the incoming data. Any issues related to controlling the use of the system, its outputs and inputs, or required controls over the data can be included in this category.

• Efficiency is a measure of method correctness. I.e. are things being done right?

• Services are functional requirements of the system.


49

Cont…

3. Object-oriented Requirements Determination Modelling Activities – emphasizes objects, patterns, responsibilities, and scenarios.

• An object is a person, place, or thing, such as student, faculty, sales clerk, city hall, ATM machine.

• A pattern is a template of objects with stereotypical responsibilities and interactions; the template may be applied again and again, by analogy. Pattern instances are building blocks used to assemble effective object models.

• Responsibility is associated with objects and has three aspects to it: “What I know,” “who I know,” and “what I do.”


50

• What the object knows about itself – the things that an object knows about itself are called attributes. An attribute is a characteristic associated with a person, place, or thing object. Each characteristic has a state or value.

• Who the object knows – a problem domain has many objects within it. Who the objects knows identifies relationships between objects.

• What the object does – this translates into a list of services for each object. A service is some functionality that an object is responsible for performing.

• A scenario is a time-ordered sequence of object interactions to fulfil a specific responsibility. A scenario would be developed for each of the preceding services.


51

Cont…

• Coad’s object-oriented requirements determination modelling approach would involve the following four major activities:-

• Identify purpose and features of the IS.• Identify objects and patterns.• Establish object responsibilities: “What I know,”

“who I know,” and “what I do.”• Work out the system’s dynamics using scenarios.


52

Methods Used to gather an IS Requirements

Information Gathering Techniques

Asking the users

Deriving from an

Existing System

Deriving from the Analysis of

the Business Area

Experimentingwith the system

underdevelopment

InterviewingQuestionnairesGroup Decision Making Process Data analysis

Document analysisObservationParticipation

Business SystemsPlanningCritical success FactorsDecision analysis

ThrowawayprototypingEvolutionaryprototyping


53

Information Gathering Techniques

1. Asking the usersa) Interviews - Is a planned meeting during which

you obtain information from users of the existing system.

• Advantages of interviews– An opportunity to gather information from

respondents who are knowledgeable about the system under study.


54

Cont…

– Best source of qualitative information I.e. opinions of people, policies, and subjective description of activities and problems.

– Useful for respondents who do not communicate properly in writing or are lazy to complete questionnaires.

– Allow SA to discover areas of misunderstanding unrealistic expectations and indications of resistance to the proposed system.


55

Cont…

• Disadvantages– Subjective and sometimes irrelevant.– Communication problems– Misunderstandings can rise from different user

values, or technical jargons by the SA.• Guidelines to interviewing

– The interviewer should acquaint him/herself with the work of the person he/she is going to interview.


56

Cont…

– Prepare before hand.– Make an appointment, and the interview takes

place away from the interviewee’s place of work to avoid interruptions.

– The interviewer should do little talking, let the interviewee do more talking, and make sure the discussion stays on truck.

– Be able to separate his/her opinion from facts and fictions from facts.

– Interview one person at a time.


57

Cont…

– Avoid the temptation to try and cover too much ground.

– End with a brief statement of what has been discussed. I.e. give a summary to the interviewee to cross-check with what been discussed, and if there are any misconceptions, corrections are made.


58

Cont…

b) Questionnaires – is a document containing a number of standard questions that you ask of a large number of people.

• Advantages– Can be filled by a large number of

respondents.– Can get reliable information.– Allow collection of data and can be filled in

at leisure.


59

Cont…

– Use of standardized formats yield more and reliable data.

– It also ensures anonymity of respondents which can lead to more honest responses.

• Disadvantages– Misinterpretation of the question.– Does not lead to further/deep probing.– They don’t allow analysts the opportunity of

observing and sensing reactions.


60

• Guidelines to Questionnaire design– Should begin with a preamble – Bear in mind the level of intellect and the level

of interests of the respondents– Keep questions short, unambiguous and

unbiased, and where possible have multi-answers.

– If possible avoid too much branching.– If the survey is extensive, you may consider use

of automated means of reading responses.– Pretest the questionnaire before using it for the

purpose of checking whether all the questions will be easily understood.


61

c) Group Decision-making process/Formal Sessions

– Workshops and Brainstorming sessions are increasingly being used to draw out new ideas for systems.

– Get people who are familiar with the issues together to spontaneously explore ways of improving a system.

– Delphi technique, group members may be scattered around the world. A questionnaire may be circulated.


62

Cont…

Important factors:

No criticism

“Anything goes”

The more the better

Build on the ideas of others


63

Cont…

2. Deriving from an existing system

Possibilities here are:

• The system that will be replaced by the proposed system

• A system similar to the proposed one that has been installed elsewhere & is accessible to the analyst

• A proprietary package, whose functionality may be analyzed.


64

Cont…

a) Data analysis: The requirements for the proposed system are derived from the data contained in inputs (orders, invoices, time cards etc.) or data contained in the outputs (reports, worksheets) of the existing system

b) Sampling of existing Documentation – when you are studying an existing system, you can get a good idea by studying existing: documentation, forms, and files


65

Cont…

– First document that analyst should seek out is the organizational chart

– Be sure that they are relevant and up-to-date

– Document analysis usually accompanies the “asking” methods, as documents are difficult to be interpreted independently.


66

c) Observational Studies

– Systems Analyst participates in or watches a person perform activities to learn about the system.

– often used when validity of data collected through other methods is in question or when the complexity of certain aspects of the system prevents a clear explanation by the end users.

– People usually feel uncomfortable when being watched.


67

Cont…

• Advantages of Observations– Permits correction of any misconceptions or

erroneous impressions made before.– Permits verification of statements made in

interviews as well as determine if procedures operate as specified in the system documentation.

– You become better acquainted with the operating personnel who will be implementing the new or changed system.


68

d) Measuring – It is important in systems investigation, analysis and design in terms of:-

– Magnitude of the exercises– Processes– Quantity of work– Time taken to accomplish work (time frame

works)– Rates of doing work– Intervals• These help to determine the systems

requirements, e.g. s/w, h/w e.t.c…


69

3. Deriving the requirements from the analysis of the business areaUsing Business Systems Planning (BSP)

Define Business Processes

Define Business

Data

Define IS Architecture

Analyze Current System support

InterviewExecutives

Define findings& conclusions

DetermineArchitecture

priorities

Review informationresource management

Develop recommendations

Reportresults


70

b) Critical Success Factors methodology“Those few critical areas where things must go right for the business to flourish”

Obtain CSF of

Manager B

Obtain CSF of Manager C

Combine individual CSFs

into Organizational CSFs

Derive Informational requirements

to support CSFs

Use CSFs to redesign the organization

and use informational requirements to plan IS

Obtain CSF of

Manager A


71

c) Establish informational needs of an individual manager by decision analysis

• Identify the key decisions that a manager makes

• Define the process by which the manager makes these decisions

• Define the information needed for the decision process

• Establish what components of this information will be delivered by the information system and what data will be needed to do so.


72

Cont…

4. Prototyping

– A method used to test or illustrate an idea and build a system in an explorative way.

– Used to discover user requirements

– Allows analyst to quickly create mock forms and tables to simulate the implemented system.


73

Identify basicUser requirements

Rapidly developprototype

Enable users to work with the prototype

Obtain user feedback

Modify the prototype

“Evolutionary Development” – complete document the final version, field it as the operational system

ThrowawayPerform furtherSystem devtWith lifeCycle, discardprototype


74

Advantages of a Prototype– Valuable for the design of the end user

interface of an IS. Users’ needs and behavior are not entirely predictable and are strongly dependent on the context of the situation. So it enables users to react immediately to the parts of the system they will be dealing with.

– It is more likely to produce a system that will fulfill user requirements, especially when it is used for decision-support applications.


75

Cont…

– It promises to eliminate excess development costs and design flows that occur when requirements are not fully captured the first time round.

– User satisfaction and morale are usually heightened because users can be presented with an actual working system, preliminary though it may be in a very short period of time.


76

Cont…

• Disadvantages– Prototyped systems still need to be fully

documented and tested, but often these steps are shortened.

– The final step to convert the prototype into a polished production system may not be carried out. I.e. if it works reasonably, management does not / may not see the need for reprogramming and redesigning.


77

Systems Analysis – Tools and techniques:

•Users Requirement Document

•Decision Tables, Decision Trees, Structured English

•Process Modeling with Data flow diagrams (DFDs).

•Data Modelling with Entity Relationship Diagrams (ERDs).


78

Requirements Analysis

• This process is usually characterized by the following activities:

• What outputs the system will produce, what inputs will be needed, what processing steps will be necessary to transform inputs into outputs, and what data stores (files or databases) will have to be maintained by the system.


79

Types of Requirements

• User Requirements – Statements in natural language plus diagrams of

the services the system provides and its operational constraints. Written for customers.

• System Requirements – A structured document setting out detailed

descriptions of the system services. Written as a contract between client and contractor.


80

User Requirement Document

• User Requirement Document (URD) – What the system should do (user requirement analysis).– Systems Analysts have to work out between

themselves on what the system should do. They are guided by the URD. The URD has 4 categories of information:


81

• Functional Requirements – these describe the desired functionality of the new system I.e. what is expected of the system in behavior terms e.g. outputs and inputs of the system.

Examples of Functional Requirements:• The user shall be able to search either all of the

initial set of databases or select a subset from it.• The system shall provide appropriate viewers for

the user to read documents in the document store.• The system shall be designed in a way that makes

it easy to update and easy to use.


82

• Non-Functional Requirements – these have the effect of limiting the choice so that if there many possible designs can be eliminated and don’t have to be assessed. They’re sometimes referred to as constraints. Usually concerned with the h/w, s/w, time and money constraints. Examples of NFR:

• The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.

• The product shall use the company colors. • Only direct managers can see the personnel

records of their staff.


83

• Design Objectives – these are attributes of s/w that would enable comparison. Once the designer appreciates the relative importance that the user attaches to a certain property then that would be the most outstanding design objective e.g. should be user friendly, maintainable, easy to develop.

• Design Decisions – these are premature statements usually requested by experienced users e.g. how the behavior is to be achieved rather than what behavior is required. – Such statements should be withdrawn or interpreted

as non-functional requirements.


84

URD Diagram

URD

Analysis

SOR

D

RA DONFRFR


85

Example of A Decision Tree for a Discount Authorization process

Condition 1 Condition 2 Action

Pay within 10 days

Size of order over 10.000/=

Take 3% discount from invoice total

Pay within 10 days

5000 – 10000/= Take 2% discount from invoice total

Pay within 10 days

< 5000/= Pay full invoice amount


86

Example - Discount Authorization Process

Discount Authorization

Process

Pay within10 days

Pay after 10 days

Over 10.000 --- 3%Discount

5.000 – 10.000 --- 2%Discount

<5.000 --- pay full amount

----- No discount, payInvoice amount


87

Cont…

– Decision Tables – It is a tabular description of a selection structure. I.e. It is a graphic method for describing the logic of decisions. It provides a means of documenting procedures in which several complex decisions have to be made.


88

Decision Table diagram

Condition Statement

Condition Entries

Action Entries

Action Statement

1 2

3 4


89

Cont… Decision Tables

– Condition Statement – identify relevant items– Condition Entry – identify which value if any

apply a particular condition.– Action Statement – will list all the steps that

can be taken when a certain condition occurs.– Action Entry – identifies what specific actions

in the set to take when selected conditions or combinations of conditions are taken.


90

Example: Insurance Application Process

• Instructions to an insurance clerk reads as follows:

• Policy type 22 may be issued if the applicant has been issued with policy type 19 and is a married male or has been issued with policy type 19 and is married and under 25years. Alternatively if the applicant has not been issued with policy type 19 and is married female, policy 22 may be issued. Then a policy may also be issued to a male under 25 years, or married person who is 25 years or over. All other applicants are refused.


91

Insurance Application Process

Rule Else

Condition Stub 1 2 3 4 5

Has policy type 19? Y Y N . .

Married? Y Y Y . Y

Male? Y . N Y .

Under 25? . Y . Y N

Action Stub

Issue policy type 22 X X X X X

Reject X


92

Cont…

• Advantages of Decision Tables– Is concise, unambiguous, clearly conveying the

logic involved, hence less danger of omitting a logical possibility.

– Enhanced communication with action separated from conditions.

– Easier to draw and they’re easily understood.– Produces an automatic compact program

documentation.


93

Cont…

– Its format is highly standardized.– Can be checked mathematically for

completeness and that all test combinations have been considered.

– Disadvantage – however, they don’t show the sequence of decisions.


94

• Structured English - It is based on structured logic, or instructions organized into nested and grouped procedures and simple English statements such as add, multiply, move e.t.c.. I.e. it describes logical processes precisely and concisely. I.e. it uses narrative statements to describe a procedure.

• Developing Structures which express problem solutions:

• Sequence Structures – Is a single step or action included in a process. I.e. the completion of one process step in sequence after another process step. It doesn’t depend on the existence of any conditions, so when encountered, it is always taken.


95

Cont…• Decision Structures – Occurs when two or more

actions can be taken. I.e. the completion of one or two process steps based on the results of a test or condition. One must assess the condition and then make a decision to take the stated actions. E.g. the If statement.

• Iteration Structures – the completion of a process step repeated until the results of a condition terminates this repetition. e.g. Loops

• Discussion Question– When should a Systems Analyst choose a particular

process description tool / technique to use? (Guidelines for choosing a technique to use).


96

Structured Analysis

• It deals more with the logic of the system – requires the analyst to define what the system should do. I.e. breaking down the system into manageable subsystems – method for defining systems inputs, processes, and outputs, and for partitioning systems into subsystems or modules that show a logical graphic model of information flow.

• Objective of Structured Analysis - Is to document all the end user requirements for the proposed IS and present these requirements in the systems requirement document.


97

• Structured Analysis accomplishes the following:-– Views the system from the top to down.– Specifies the interfaces that exist between

modules.– Rigorously specifies the processes or

transformations that occur within each module.

Components of Structured Analysis • Data Dictionary – description of all the

data used in the system.


98

Cont…

• Graphic Symbols – icons and conventions for identifying and describing the components of a system and relationship among these components.

• Procedure and Process description – formal statements using techniques and languages that enable systems analysts to describe important activities that make up a system.


99

Cont…

Rules – standards for describing and documenting the system correctly and completely.

Data Flow Diagrams – show how data moves and changes through an IS in a graphical top-down fashion. I.e. a graphic representation of a system’s components processes and the interfaces between them.


100

• Process Modeling with Data flow diagrams (DFDs)

• DFDs are useful for modelling the scope of a systems project in terms of its interfaces with other systems, the business as a whole, and the outside world.

• DFDs show how data flow to, from and within an IS and the processes that transform data. They also show where the data are stored.

Symbols for drawing DFDs


101

Cont…

• DFDs are constructed using 4 symbols:

– Data flows ( ) - these show the movement of data between processes, external entities, and data stores in a DFD.

– Processes ( ) – they portray the transformation of input data flows to output data flows in DFDs.


102

Cont…

– Data Store ( ) – are either manual or automated inventories of data. E.g. computer files or databases, file cabinets, card files, microfiche e.t.c…

– External Entity ( ) – are originators or receivers of information outside the scope of the IS portrayed in the data flowing.


103

Cont…• General rules for drawing DFDs

– Any data flow leaving a process must be based on data that is input to the process.

– All data flows are named and the name reflects the data flowing between the processes, sources, and data stores.

– All the data needed to perform the process should be input to that process.

– The process should be independent of any other in the system – each process has its own input and output.


104

GENERATE BILL

CUSTOMER

GENERATE BALANCE

GENERATE REPORT

MANAGER

PAYMENTFILE

CUSTOMERFILE

Data FlowData Flow DiagramDiagram


105

Order processing systemCustomer

WarehousePicking-labels

Order

Out-of-stock-notice

Order-rejection-notice

Invoice

Context diagram of an order processing system


106

• Context diagram - It is a simple DFD that depicts the system being studied as it relates to other systems, the business, and the outside world – the interfaces flowing to or from external entities.

• DFDs can be drawn in various levels of details using a technique known as levelling, ranging from depicting an entire system’s “big picture” to showing the detailed processing of a single transaction. The entire collection of DFDs is called a levelled set.


107

Document Flow Diagram• A diagramming technique which is used to

identify physical movement of documents.• It shows where the document comes from,

where it goes to , and what it is called.

• The source and destination of the document are usually shown using an elliptical shape.

• For each document or communication that occurs in the system, identify the source and the target. This will help in developing a context diagram during analysis.


108

Document Flow Diagram of a Purchasing System

Supplier PurchasingDept

Stores

Order

Invoice

Delivery notes


109

Data Modelling using Entity Relationship Diagrams

Customer OrderPlaces

Contains Product

One Many

Customer No.

Name

Address

Balance due

Order No

Order Date

Order Price

Shipping Cost

Product No.

Product Name

Price

Many

Many


110

Data Modelling using Entity Relationship Diagrams

• A data Entity is anything, real, or abstract about which we want to store data. Most entities correspond to persons, objects, events or locations in the business environment.

• A data Relationship is a natural association between entities. All relationships are further described by words or symbols that indicate the number of occurrences of one entity that can exist for a single occurrence of the related entity.


111

• In the definition phase, we look at requirements independently. I this phase, data modelling is performed. Entities, data elements and relationships are identified.

• Data models complement process models. • In the selection phase, the following are

addressed:• The new files and databases to be designed are

identified.• How much data should be automated?• Should it be central or distributed data storage?• How relationships between data entities be stored?


112

Systems Design

•Architectural design process

•Output design, input design, User interface design, file & database design, program specification design

•Prototyping


113

• Systems Design – details how a system will meet the information requirements as determined by systems analysis.

• Note that the primary input to design is the requirements specification document, which is the output from analysis. This document is critical to the success of the system because it represents the users’ requirements for the system.

Systems Design


114

Cont…• Much of the contents of this document get

transformed into design equivalents as the systems analysts begin to customize the proposed IS for the specific h/w and s/w platforms to be used for its creation and ultimate operation in some production environment within an organization.

• These specifications should be detailed enough to become inputs to the programming stage that follows the design. The design process is usually broken down into two parts.


115

Cont…

• Logical design – produces the general specification of the resources that will make up the system - lays out the components of the IS and their relationship to each other as they would appear to users.

• Physical design – produces a complete, detailed specification of the named program components and of the databases to be maintained by the system - the process of translating the abstract logical model into the specific technical design for the new system.


116

Cont…

– This activity addresses all of the environment, platform, and human-computer interface specifics for the proposed information system. Issues to be discussed and decided here include all aspects of the five components of an information system such as: hardware, software, data, people, procedures.


117

Objectives of Systems Design

• Specify logical design elements – detailed design specifications that describe the features of an IS: I/P,O/P, files, databases, and procedures.

• Support business activities – results of using the system help business performance. Design fits the way the firm conducts its business.


118

Cont…

• Meet user requirements – in terms of:- performing appropriate procedures correctly; presenting proper form of information; providing accurate results; using appropriate methods of interaction; providing overall reliability.

• Easy to use – favorable human engineering; ergonomic design that is physically comfortable and contributes to user effectiveness and efficiency.


119

Cont…

• Provide software specifications – specific components and functions with adequate detail to construct application software.

• Confirm to design standards – design and specification of the design in accordance with prescribed rules and practices of the organization.


120

Architectural Design

- The design process of identifying subsystems of a large system and establishing a frame work for sub-system control and communication.

- It involves identifying major system components and their communications.

• A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems.

• A module is a system component that provides services to other components but would not normally be considered as a separate system


121

Architectural design process

• System structuring– The system is decomposed into several principal

sub-systems and communications between these sub-systems are identified

• Control modelling– A model of the control relationships between the

different parts of the system is established

• Modular decomposition– The identified sub-systems are decomposed into

modules


122

What features must be designed – Logical Design

• Design specifications describe the features of a system. These are the elements of the system and their appearance to the users. These include:– Data Flows – the movement of data into,

around, and out of the system are specified.– Data Stores – temporary or permanent

collections of data are specified


123

Cont…

– Processes – activities to accept, manipulate, and deliver data and information, may be manual or computer-based are specified.

– Procedures – methods and routines for using the IS to achieve the intended results are specified.

– Roles – the responsibilities of all persons involved with the new system, including end-users, computer operators, and support personnel are specified.


124

Cont…

– Controls – standards and guidelines for determining whether activities are occurring in the anticipated or accepted manner I.e. under control. It also specifies actions to take when problems or unexpected circumstances are detected. May include the reporting of exceptions or procedures for correcting problems.


125

Physical design

• When physical design is completed, the following aspects of the system will have to be specified:

• System outputs – report layouts, document designs, screen designs

• System inputs – data inputs & their validation procedures

• User-system interface – exact protocols of user-system interaction (menu trees, icons for graphic interfaces etc.)

• Platforms – H/W & S/W platform (s)• Acquisition method – the way each component of

the application will be acquired


126

• Modular design of the programs that will be developed for the application, interfaces between the modules, and the specification of the logic of the individual modules. The algorithms to be implemented in each module will be selected.

• Detailed test plan – the plan for various levels of testing to be conducted during the later stages of development & a test suite containing the sets of tests for these levels.

• Database – logical & physical designs. Needed capacities of files & databases have been estimated.

• Controls – application-specific controls, as well as the necessary general controls.


127

Cont…

• Documentation – a full set of documentation to be delivered with the system is specified. The documentation will include the user manual, systems & operation documentation, maintenance documentation. The requirement specification & the system design documentation will also be included in the documentation package.

• Conversion plan – the plan for converting the present way of doing things to the new system


128

Techniques & Tools used in design

• Structured design - The principal product of logical design are structure charts of the programs that need to be coded & tested. They are of 2 kinds:-

• Modular structure

• Hierarchical design


129

COMPUTE-SALES-TOTAL

OUTPUT-TOTAL

READ-SALES-TRANSACTION

ADD-TO-TOTAL

Sales

Transaction Sales

TransactionSales Total

Sales Total

A

CB

Modular Design

Hierarchical Design


130

PROCESS A

PROCESS B

SEQUENCESEQUENCE

PROCESS CPROCESS D

R

TRUE

SELECTIONSELECTION

PROCESS E

S

TRUE

ITERATIONITERATION

Program Program FlowFlowchartchart


131

LOAD & VALIDATE

COMPARE & UPDATE

VALID TRANS-

ACTIONS

PAYROLL SYSTEM

TIME CARDS

HUMAN RESOURCES

DATA

PAYROLL MASTER

UPDATED PAYROLL

MASTER

DIRECT DEPOSITS

GENERAL LEDGER

PAYROLL REPORTS &

CHECKS

PAYROLL MASTER

System Flowchart


132

DOCUMENT

DATABASE

ON-LINE DISPLAY TELECOMMUNICATIONS LINK

INPUT/OUTPUT PROCESS MAGNETIC TAPE

PUNCHED CARD MANUAL OPERATION ON-LINE STORAGE

ON-LINE INPUT

System System FlowchartFlowchart SymbolsSymbols


133

BEGIN OREND

DIRECTION

PROCESS

DECISION

INPUT OROUTPUT

SUBROUTINE

MANUALOPERATION

CONNECTOR

Program Flowchart Symbols


134

Cont…• After the logical design stage, the processing steps

to be carried out by individual modules are specified in physical design.

• Prototyping – 4GLs, AG

• Joint application development (JAD) – participative development

• Rapid application development (RAD)

• Object oriented design (OOD)


135

USER INTERFACE DESIGN

• User interacts with the computer system through a combination of means – User Interface

• User Interface is the yardstick by which the system is judged by the user

• Difficult to use Interface will cause errors, the system may be discarded, meaning of information may be misunderstood, may corrupt data, may cause system failure

• Text based interfaces were used in the early days

• Replaced by Graphical User Interfaces (GUI)


136

Cont…

• Windows – Several windows on the screen enable the user to work with several programs, either simultaneously (multitasking) or on one

• Icons – little pictures which may represent files or processes

• Menus – Commands selected from a menu rather than typed in a command language

• Pointing – Pointing devices such as a mouse to point at a selection from a menu or point at an icon & then click to issue the command


137

Cont…• Graphics – Graphical elements mixed with text in

the same display

• User Interface design must take into consideration the capabilities of the user

• Prototyping may be helpful• Short-term memory of humans is limited, do not

overload with information• Consistency in the Interface helps to reduce errors,

comparable operations should be activated in the same manner


138

Cont…• Use terms & concepts familiar to the user

• Recoverability – Confirmation of destructive actions, Undo facility

• Help facilities – Structured help facility at different levels, Context sensitive help

User-System Interaction is two ways:

• Information from the user to be given to the Computer system

• Information from the Computer system to be presented to the user


139

• Direct manipulation ( as in word processing, screen editors, form-based interfaces)

Interface Models• Desktop metaphor

Screen is used as a Desktop

System entities are represented as icons

In addition the use of a controlpanel with buttons, switches, menus,indicators, displays, sliders


140

Cont…

• Menu Systems

May type the name of the commandPoint with a mouseMay use cursor moving keysOn touch-sensitive screens use the finger

or penDo not need to remember commands


141

Typing effort is minimalUser errors of a certain type can be avoidedMost frequent operations at the top of a menuMost destructive operations at the bottom

Command-line Interfaces

Allow faster interaction

Command language has to be learnt

Command language programs can be written

Cause more errors

Interface cannot use pointing devices, interaction is through the keyboard only


142

Out put design

• Characteristics of good output – there are several characteristics that make information a candidate to be considered both highly quality and usable:– Accessibility – This characteristic refers to how easy

it is to use the information when a person gets it.

– Timeliness – This characteristic refers to the amount of elapsed time it takes to obtain specific information that is needed


143

Cont…

– Relevancy – this characteristic refers to whether the information as presented is free from trivial or superfluous details or lacking in sufficient details.

– Accuracy – This characteristic addresses the issue of error-free information.

– Usability – This characteristic refers primarily to the presentation style of the information, I.e. its format. E.g. text, numbers, graphics, graphs e.t.c…


144

Cont…

• Output types– Internal, External, and Turnarounds Outputs –

Internal outputs are intended to be used by people or other information systems within a business.

– External outputs are intended to be used by people or other information systems outside the business.

– Turnaround outputs this type of output is generally external and people oriented and has the dual purpose of serving as output to the user and input to the information system from the user.


145

Cont…

– Static and Dynamic outputs – Static outputs are those that can be

predetermined and planned for. – Dynamic Outputs are those that cannot be

easily predetermined or planned for during information systems development.

• Output devices and media• Plotters are most often used to draw maps,

architectural drawings, and blueprints, graphs, and pictures.


146

Cont…

– Computer output on Microfilm or microfiche are devices that, as their name implies, produce microfilm or microfiche output.


147

Interface Evaluation

• Usability of the Interface• Meets the user requirements• Learn ability - How long it takes a new user to

become productive with the system?• Speed of Operation – How well does the system

response match the user’s work practice?• Robustness – How tolerant is the system of user

error?• Recoverability – How good is the system at

recovering from user errors?• Adaptability – How close is the system tied to a

single model of work?


148

Cont…

Methods of Evaluation

• Questionnaires, Observation of users at work, Inclusion of SW in the code to collect information about most-used facilities and most common errors.

• Specific questions must be asked from users for evaluation (e.g. Error messages)


149

Files and Database Designs

• Files for data storage Files are generally used to store sequences or lists of data in a format that has been optimized for some particular type(s) of transaction, and require routines specifically written for those formats and transactions.

• Generally these are organized sequentially, adding new data records to the end of the file. They are often arranged in a linked-list format for ease of manipulation.


150

File types by their area of application

• Master files: are files used to record key business information which is maintained over a long period of time. Typical examples include order information, customer and account information, etc.

• Lookup files: are files containing static values, generally used for validation. Common examples are postal codes, province, state, and city names, etc.


151

Cont…

• Transaction files: are files which hold information used to update the master files. For instance, we might have a transaction file which records all the orders placed today and is used to periodically update the master file. Thus the "current" state of the system is maintained in memory, but in the event of a discrepancy or system failure we can check the master file against the day's transactions to determine where the failure occurred and how to correct it.


152

Cont…

• Audit files: audit files are used to record key information immediately before and after a transaction is applied. For instance, we could take a snapshot of an account immediately before applying a withdrawal transaction, and another immediately afterwards. Again, in the event of an error or system failure during the transaction the combination of master file, transaction file, and audit file allow us to pinpoint exactly what went wrong and how to correct it.


153

Cont…

• History files: many such systems collect vast amounts of data over time, and much of that data is rarely required. As such, it is common to create an archive of old data - data moved into a more compact and/or cheaper storage mechanism so that the overall system is more efficient but the data is still recoverable if necessary.


154

File Access and Organisation

• File Access: refers to the method of reading or writing records within a file.

• File Organisation: refers to the method of storing records within a file.

• Two methods for accessing records in a file: sequentially and directly

• Four ways of storing data in files: serial, sequential,direct, and indexed.


155

Methods for accessing records in a file

• Sequential access: is access by physical record location or position within a file (i.e. Starting at record one and sequentially reading or writing every record to the end of the file).

• Direct access: is access by physical address (i.e. ability to go directly to certain records within files without having to sequentially scan from the first record in the file).


156

Methods of File Organisation

• Sequential file organisation: a method of storing data records in which the records must be retrieved in the same physical sequence in which they are stored (e.g. batch processing applications such as a payroll).

• Direct/ Random file organisation: a method of storing data records in a file so that they can be accessed in any sequence without regard to their actual physical order on the storage media.


157

Cont…

• Serial file organisation: is the storing of records in a file in chronological order (e.g. Recording of a bank’s ATM transactions as they occur).

• Indexed file organisation: uses and maintains a sorted index in key order, which stores the record location of the actual data file record as part of the index.


158

Cont…

• Databases for data storage Databases are used to store logical data groupings and their relationships, and require a database management system (DBMS) to maintain and access the data. Databases come in a vast range of sizes and complexity, from small scale systems such as Microsoft Access to full-fledged business or enterprise DBMSs such as Oracle.


159

General categories of database systems

• Legacy databases: are databases using older, outdated technologies. They are frequently encountered in large organizations where the cost of replacing the database is prohibitive.

• Relational databases: are the most common/popular current form of database, primarily because they are much easier systems to perform development and maintenance on. These databases are composed of a set of tables, composed of a fixed number of rows (records) and columns (fields within each record).


160

Cont…

• Each table has a primary key (uniquely identifying each record in the table) and which may have one or more foreign keys. These foreign keys define the relationship to another table, and would be the primary key of the other table. • Some of the most common RDBMSs include

Access, Oracle, DB2, and Microsoft SQL Server.


161

Cont…

• Object databases: are databases which try to encapsulate logical data entities and their associated processes as separate objects. This makes it easier to alter portions of the database, since changes within one object do not impact other objects. Object-oriented data base management systems (OODBMSs) are primarily used in supporting multimedia applications, but they are also becoming more common in large scale electronic commerce systems.


162

Software Construction and Testing

•General software design principles

•Construction strategies

•Testing principles

•Testing strategies

•The Generic software testing methodology


163

General software design principles

• The software must conform to the requirements specification document created during the analysis portion of the project and any modifications added later during design – with time the original specification requirement document becomes obsolete, hence changes may not be reflected.

• The software must be reliable over time while processing a potentially limitless combination and types of data, as well as user keystrokes and pointing device (mouse clicks).


164

Cont…

• The software must be maintainable and evolutionary over time – upgradeable to accommodate changes.

• The software must be easy to use (user friendly).• The software should be easy to test and

implement using the test plans.• The software should use computer resources

efficiently – minimize computer resources e.g. memory, processing power.

• The software should work correctly – should avoid errors.


165

Software Construction Strategies

• Top-Down software construction – follows the functional decomposition approach to problem solving. It starts with the design overview or high-level view (control or management oriented e.g. menus & calling modules) of the system and then creation of the program code for it. Next the details of the system are written for the program code, layer by layer, until the bottommost modules are programmed (operational or worker oriented e.g. modules which calculate results, update databases, print lines on a report).


166

Cont…

• Bottom-up software construction – starts with writing the program code for the lowest-level details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fit the requirements for the system. Next is the construction of the code for the modules or modules that calls these bottommost modules.


167

Cont…• Middle-out software construction – starts

somewhere in the “middle” of the system that seems convenient, and proceeds both upward to higher levels and downward to the lower levels as appropriate (e.g. coding a low-level module that opens a file, or calculates sales tax (bottommost modules)).

• The Hybrid combination of top-down, bottom-up, and middle-out software construction may be suitable for certain environments or projects.


168

Software Testing Principles

• It should conform to at least three principles:• First principle is that Software testing begins

with plans for the tests and ends with the user accepting the tested software. Software test plans should be developed at the same time the requirements specification document is being developed and can be refined and updated during design as well. The plans for the user acceptance test should conform to the user requirements as documented in the requirements specification document.


169

Cont…

• By doing so, the development loop is completed, and the software is certified to be in compliance with the requirements specification document. User acceptance test plans include more than just the software; they include the other four IS components-hardware, procedures, people, and data.

• The second software testing principle is that testing’s intent is to cause and discover errors – testing should be done with as little pride of ownership as possible.


170

Cont…

• The third software testing principle is that rules of reasonableness should prevail – testing should follow commonly accepted testing techniques designed to provide a certain threshold of statistical confidence in the tests (e.g. rather than testing every record in a large database for a certain sequential processing situation, one commonly accepted testing technique is to test the first record, a few records in the middle of the database, and the last record I.e. test the huge actual database).


171

Software testing strategies

• Top-down testing – follows the functional decomposition approach to problem solving. It starts at an overview or high-level view of the system to be tested, then works its way down into details of the system, layer by layer until reaching the bottommost programmed modules.

• Bottom-up – testing starts with details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fit the requirements for the system.


172

Cont…

• Middle-out testing – starts somewhere in the “middle” of the system that seems convenient, and tests both upward to higher levels and downward to lower levels as appropriate.

• Hybrid is a combination of the three above.• Regardless of which testing strategy is chosen,

software testers view portions of the system, subsystem, programs and modules as either a white box or a black box as they test.


173

• White box is the portion of the system that we are testing from an inside perspective. I.e. there is the ability to actually look at the code statements within the white box portion being tested and make changes to them should they not work correctly.

• Black box is the portion of the system that we are testing from an outside perspective. I.e. the tester doesn’t have the ability to look at the code statements and change them. (Usually done when programmers need to integrate that part of the system with the part of the system they are creating and testing). Usually done on software wrote by someone else.


174

Cont…

• Alpha testing is testing done in-house by testers such as programmers, software engineers and internal users. I.e. a first cut at the acceptance tests is done in-house by in-house staff.

• Beta testing usually involves a select group of customers to perform tests on the software as they would use it in their normal environment. In exchange, the customers get an advance copy of the soon to be released software, which usually has new features in it.


175

A Generic Software Testing Methodology

Software Testing Methodology Showing Feedback/fallback loop

User Acceptance Testing

System Testing

Function TestingIntegration Testing

Unit Testing


176

A Generic Software Testing Methodology

• The above generic testing methodology can be utilized regardless of whether the resulting software is to be used in house or is to be available for public sale at computer stores. Note the feedback or fall back arrows in the diagram. Whenever testing discovers errors at any level of the methodology, the programming staff will need to make coding changes followed by a trip back through the layers to ensure defect-free code in all test levels.


177

• As testing takes place, keep in mind that code changes made by programmers in one module or section of a program may fix the identified bug but may cause an error in some other seemingly unrelated section of the program when it is tested again.

• Large systems are built of sub-systems which are built out of modules which are composed of procedures & functions.

• The testing process should be carried out in stages:

• Unit/ Module testing – individual components are tested. I.e. Individual program modules are tested by their developers.


178

Cont…

• Integration Testing – is the combining of several units or modules for the purpose of testing them as a whole.

• As software is being constructed and simultaneously being tested for integration with other software modules by the programmer, a technique known as stub testing is often used. Stub testing is a test performed on individual modules as they are being integrated in a top-down, bottom-up, or middle-out manner.


179

LEVEL 1

Level 2 stubs

Level 3 stubs

LEVEL 2LEVEL 2 LEVEL 2 LEVEL 2

LEVEL 1

TOP-DOWN TESTING

Testing sequence


180

• Function testing – is the combining of one or more integration tested groups of modules that collectively perform a user identified function, as documented in the requirements specification document.

• System testing – combines all of the user-defined functions together to form the subsystem or system.

• Acceptance testing – is similar to system testing. However the user is the one who usually does the testing. These tests are most often conducted with well-defined test data, as well as the actual, real data.


181

• The diagram below represents a framework for the methodology and how it interrelates with the other activities and deliverables of IS development.

Systems Design

Systems Design

Program Design

Module Design

User SpecificationSystems Analysis

System Specification

Software Specification

Program Specification

Module Specification

Acceptance Testing

System Testing

Function Testing

Integration Testing

Unit Testing

Programming

Framework for Information Systems Testing


182

• System Development and Implementation– Individual system components are built and

tested – User interfaces are developed and tried by users– Database is initialized with dataAt the end of this phase :

• Users are provided with a working system (programs and database)

• System documentation describing the programs is also completed.

• All users are trained and can use the new system.


183

Systems Implementation; Evaluation & Review

•Installation – conversion strategies; Activate; Institutionalization

•Implementation Critical success factors

•Evaluation and review


184

• Implementation - is the conversion of data to the new system’s files, final training of the end users, and transition from the old system to the new system.

• Marks the end of development for now, and begins the user’s realization of the new or changed information system.

• Implementation is a critical time for users because the user must switch from the old to the new system, and the user must take responsibility for the successful utilization of the new system.


185

Cont…

• The IS development team must anticipate, even expect, problems during implementation. Hopefully, the problems can be turned into opportunities.

• Implementing a system consists of 3 phases : Install, Activate, Institutionalization.

• Install – Is putting the new IS in place. I.e. physically install all of the five components:– h/w, s/w, people, procedures, data, of an IS. People are trained or prepared as part of the install phase.


186

Install Phase

• A very significant part of the install phase has to do with conversion. Conversion is the switching from one thing to another. I.e. a new IS is replacing an obsolete manual or automated IS. NB. Conversion affects each of the components of an IS.

• There are three Conversion strategies of :-


187

Old System

New SystemParallel Operation

Old System

New SystemDirect Conversion

Old System New SystemPhased Conversion

Conversion with a pilot Version

Old System New System


188

Conversion

• Cutover/Abrupt/Direct Conversion – is one in which the user uses the old system up to a specific point in time after which the user starts using the new system.

• Advantages - – No duplication of effort for users.– No transition costs with the old system.– Learning advantage for groups converted later,

if Cutover is done by groups. The costs of running parallel systems.


189

Cont…

• Disadvantages of Cutover Conversion -– High risk I.e. It may disrupt operations if it

fails.– Cannot compare results.– Sense of user insecurity I.e. no period of

adjustment could lead to resistance to change.


190

Cont…

• Parallel Conversion – is one that allows the user to continue use the old system and the new system simultaneously for a period of time, eventually discarding the old system.

• Advantages – – Low risk I.e. it guarantees continuing incase the

new system fails.– Sense of user security – Ability to compare results with old system.


191

Cont…

• Disadvantages of Parallel Conversion – – Duplication of effort for users– Transition costs I.e. Expensive– Additional processing strain on the computer.


192

Cont…

• Pilot Conversion – is one in which the new system is implemented in one part of the organization such as a single department, and eventually extended to other departments.

• Advantages – – Incase of failure, the rest of the organization is

not affected.


193

Cont…

– Based on feed-back, changes are made and the system is installed in the rest of the organization by one of the other methods.

– It provides experience and live tests for implementation.

– Gives an opportunity to the implementers to display the advantages of the new system.


194

Cont…

• Disadvantages of Pilot – – May give the impression that the new system is

un-reliable and not error-free, depending on the effectiveness of the implementers.

– May give the impression that the old system is un-reliable and not error-free because staff may loose confidence in the old system.


195

Cont…

• What do Software Engineers base their conversion strategy decision on?– The design of the information system.– User needs and preferences.– Risk factors.

(Give your understanding of what we mean by each of the above.)


196

Activate Phase

• The second phase of Implementation, the Activate phase, deals with getting the user to use the new or changed IS.

• Once the IS has been installed and the conversion performed, the implementation moves naturally into the activate phase as the predetermined users begin exercising and using the new system.


197

Cont…

• During this critical phase the development team may continue training the users on an as-needed basis.

• The team should also anticipate and expect problems and be prepared to correct them.

• The team should also monitor the user’s usage of the IS, taking note of what the users like and dislike, patterns of user usage, shortcut opportunities to improve the IS effectiveness, e.t.c.


198

Cont…

• In short, the development team needs to pay serious attention to the IS and its use by the users during this phase and be prepared to maintain, fix, and enhance it as the need and opportunity to do so become available.

• Maintenance and Review – changes in h/w, s/w, documentation or procedures to a production system to correct errors, meet new requirements, or improve processing efficiency.


199

Cont…

• Evaluation – this is to determine whether the IS operates as expected, and if the costs and benefits are as anticipated. I.e. identify the strengths and weaknesses of the IS.

• Why Maintenance is important?– Necessary to eliminate errors in the system during

its working life (corrective maintenance)– Enhancing & modifying the system to respond to

changing user environment & organizational needs, improving system efficiency, & enhancing documentation (perfective maintenance)


200

Cont…

– Changing the application to adapt it to a new H/W or S/W environment (adaptive maintenance)

– Information system planners must always plan for resource availability to carry out these maintenance functions.

• Institutionalization phase – means that the new or changed IS becomes the new status quo within the business.


201

Cont…

• Status quo doesn't guarantee 100% use by the users, but it does imply that the new IS is now the standard for the business and that a certain percent of user critical mass has adopted and is using the new IS.

• What are some of the reasons that lead to resistance of a new Information System by the users? Discuss in class.


202

Implementation Critical Success Factors

• From an Organizational change perspective, successful IS implementation depends on the following critical success factors:

• User Commitment – the user must be the champion or advocate for the new IS. I.e. the user should take ownership and responsibility for the new system.

• Organizational trust – management and staff within the business, both IS types and user types, must have a high degree of trust in one another.


203

• Open communication between IS management and staff and user management and staff – communication problems and breakdowns can cause significant harm to an IS development project and the IS implementation.

• Financial commitment from user management – lack of or limited funding for the new system can cause significant problems during the development process and during the system's implementation.

• Common view of the IS development and implementation strategy between management and staff.


204

Project Management

•The project management causes of failed projects

•The basic functions of the project manager

•Project management tools and techniques


205

What is Project Management

The purpose of this module is to introduce you to project management.

Why? • Project Management is applied during Systems

Analysis, Systems Design and Systems Implementation. Information Systems development is almost always done under the auspices of a project.


206

Definition of Project Management

Definition: Information Systems Project Management is a process of directing the development of an acceptable Information Systems at a minimum cost within a specified time frame.

NB: The acceptability, deadline and budget criteria must all be for a project to be considered completely successful. The role of Project Management is to recognize such factors to eliminate or minimize their negative effects.


207

Sources of Systems Development Projects

Systems Development Projects come from one of three sources: -

A directive or mandate from some person, such as a president, vice president, or senior Manager, or an organization such as a labor Union or Uganda Revenue Authority.

An opportunity to exploit. The opportunity usually results in increased revenues and/ or profits reduced costs, or increased or improved services.

A problem to solve. Something usually isn’t working correctly and needs fixing.


208

Systems Development Failures

• Use of undisciplined development methodologies or approaches.

• Inadequate or not understood or appreciated Systems Development tools.

• Project Scope was not clearly defined in the beginning.

• Use of no or poor estimating techniques.• Schedule delays.


209

Cont…

• Beliefs in the mythical person- month syndrome. E.g. a Manager with this mindset thinks that if two developers can do or finish up a project in six weeks, then simply adding a third developer to the project will allow it to be completed in 4 weeks. The reality is much different than this.


210

What constitutes a Systems Development project failure

• The organization completely abandons the project at some point prior to its implementation.

• The organization must rework a significant amount of the project, so much so that they deem it a failure but do go ahead and initiate the network.

• The delivered Information Systems is okay, but the project was way over time and budget, therefore, it is defined a failure.

• The delivered Information Systems doesn’t meet the user requirement or expectations, therefore; it is deemed a failure.


211

Functions of the Project Manager

• Planning Project tasks and staffing the project team – a good manager always has a plan. The manager estimates resource requirements and formulates a plan to deliver the target system. Each task required to complete the project must be planned. Some of the planning issues include: How much time will be required? How many people will be needed? How much will the task cost? What tasks must be completed before other tasks are started? Can some of the tasks overlap?


212

• Organizing and scheduling the project effort – members of the project team should understand their own individual roles and responsibilities as well as their reporting relationship to the project manager. The project schedule should be developed with an understanding of task time requirements, personnel assignments, and interties dependencies.

• Directing and controlling the project – once the project has begun the project manager becomes the project leader. As a leader the project manager directs the team’s activities and evaluates progress. The manager must frequently report progress to superiors. The manager’s job is to monitor tasks, schedules, and costs in order to control those elements.


213

Project Management Tools and Techniques

PERT Network and Gantt chart

There are 2 commonly used Project Management tools:

• Programmed Evaluation and Review Techniques (PERT) charts which are most useful for project planning and modification.

• Gantt charts which are for project scheduling and progress reporting.


214

Cont’ of Tools

A PERT network is • A graphical representation of project tasks laid out

in the form of a critical path network

A Gantt chart shows• Project tasks and their deviations in a bar chart

format in the planning and estimating of a project prior to its inception.


215

• Steps to Create a PERT Chart• Determine the duration time for each task• Assign a task identification letter to each task• Draw the PERT network, number each node.• Label each task with its task identification letter.• Connect each node from start to finish• And put each task’s duration on the network• Determine the need for any dummy tasks• Determine the earliest completion time for each

task node• Verify the PERT network for correctness.


216

PERT ChartPERT Network Strengths• Determine task dependencies• PERT network is continuously useful to project

managers prior to and during a project.• PERT network is straightforward in its concept

and is supported by soft war.• PERT network can be a valuable tool for project

managers, but the tool is only as good as the data that are input to it. Its strengths include:


217

Cont…• The PERT network’s graphical representation of

the project’s critical path and task slack time allows the project manager to focus more attention on the critical aspects of the project-time, costs, and people.

• The project management software that creates the PERT network usually provides excellent project tracking documentation.

• The use of the PERT network is applicable in a wide variety of projects.


218

• Weaknesses of the PERT network:• In order for the PERT network to be useful,

project tasks have to be clearly defined as well as their relationships to each other.

• The PERT network does not deal very well with task overlap. PERT assumes that following tasks after their preceding tasks end.

• The PERT network is only good as the time estimates that are entered by the project manager.

• By design, the project manager will normally focus more attention on the critical path tasks than other tasks, which could be problematic for near-critical path tasks if overlooked.


219

The Gantt chart

The Gantt chart is based on a two-dimensional graph scale.

Each of the significant project tasks is listed along the vertical axis of the graph, and the estimated elapsed calendar time to complete the entire project is listed along the horizontal axis.

An appropriate calendar time interval, such as days, weeks, or months is selected for the horizontal axis.


220

The Gantt chart is at its best for visually showing each of the project’s task status at any moment in time simply by drawing a vertical bar from top to bottom on the chart at the calendar time you are interested in.

Once drawn, a visual inspection of the shading within each of the bars on the chart gives you an indication of project task status for each task.

It is also useful for showing any overlapping or parallel tasks. It does not clearly show task dependence, even though it does show task start and stop times, and you can clearly see that tasks start after others have already begun or are already finished.

Gantt chart strengths & weaknesses

Gantt Chart Strengths

Being able to see overlapping or parallel tasks.

Being able to see the status of each project task at any point in time.

Gantt Chart Weaknesses

Not being able to definitely tell from the Gantt chart whether the entire project is on time, behind time, or ahead of schedule.

Not showing task dependencies.


221

Dfgasdfawdwtyhtrftgsw


222

Characteristics of good information

• Accurate

• Concise

• Complete

• Understandable

• Relevant

• Authoritative

• Timely

• Ease of use


223

Documents

Systems Analysis and Desgin Notes