Modern Systems Analysis & Design

The Systems Development Environment

Complex organisational process in which information systems are developed and maintained Result of systems analysis & design is usually development of application/systems software Systems development methodologies - systematic approach..science Systems development techniques - art of applying methodologies Primary responsibility of systems analyst and related teams

Systems
Group of related parts that function as a Unit
collection of people, machines & methods to accomplish specific objectives

In Computer parlance..
Collection of hardware, software, data

Beginning in 1950s. Emphasis was on..

Processes Automating single function e.g. purchasing or payroll Considered more as an art and less as science

Software Systems
System Software
Performs basic functions to establish and maintain operating environment (Co-ordinates & controls the running of the computer) Works with the computer and not with the end-user Operating systems like DOS, UNIX, OS-400 etc. which perform functions like memory management, secondary storage management Device management drivers like printer drivers, mouse drivers, modem s/w etc. Utilities and editors like file compression, defragmentation etc. Language compilers like BASIC, C, COBOL, FORTRAN Software packages like xBase,

Business Application Software

Uses the environment provided by Systems Software to perform functions directly needed by endusers Generic programs such as Word processors, electronic spreadsheets, e-mail etc. Programs to support specific business functions like TBA, Financial Accounting packages etc.

Structure of systems
Data. Data.

Hardware

Hardware

O.S. Systems S/W Application S/W Application S/W

How it is

How it should be

Business Application Software

Phases in Business Application Software Systems Development Life Cycle (SDLC)
Feasibility Study Systems Requirements Specifications Systems Design Programming / Construction Testing Entering history / master data User Training Implementation / commissioning Live working Post implementation support / modifications

Implementation / Commissioning

Towards next maturity level

Feasibility Study

Feasibility Study
To set priority of Areas / departments to computerise vis-vis business focus.. TBA vs. Fixed Assets Accounting To finalise overall direction of the Computerisation..
Centralised vs. decentralised, Web-enabled or non-web-enabled

Make or Buy Decision

Make.. In house or Outsourcing Buy..off the shelf with customisation

To gather information about various aspects of computerisation e.g. hardware, software, information about about vendors etc. To finalise Terms-of-reference / time and cost estimates A Feasibility Study Report is the outcome of this phase

Make or Buy
Make..In-House
A team of Project Leader, systems analysts, programmers etc. will be required (may be difficult) Resulting software would cover most of the user needs with proper integration within the modules.(Advantage) Complete control and ownership of the resulting software. (Advantage) Less technically and professionally competent software than developed by outsourced vendor whose main business is software development. (Disadvantage) Integration with other bought out systems may be difficult e.g. TBAs linkage with voice-mail recognition s/w Due to high employee turn over in IT field, difficulty in retaining IT staff. This could pose problems for maintaining software and developing new modules. (Disadvantage) The time frame required to form such team and developing software may be more. (Disadvantage) Due to rapid technological advancement in computer field, the IT staff will have to undergo continuous training in new areas and technologies.

Make or Buy
Make..Outsourcing
Expert team having state-of-the-art knowledge would be involved in the development (Advantage) Deliverables by outsourced vendor must be clearly specified. Rigorous acceptance testing is necessary.(May be difficult) If more than one vendor, then integration amongst vendors is a key factor.(May be difficult) Likelihood of vendor/s misusing the source code elsewhere (Disadvantage) .. IPR issues are to be looked into and involves lot of legal documentation. For replication of the software fresh licensing issues & cost may not be involved (Advantage) Senior management involvement will be more

Make or Buy
Buy.. Off the shelf
No plug-and-play.. Customisation is necessary. Some product deficiencies, if any, will have to be accepted.(Disadvantage) Market research and comparative analysis of different vendors and their products will have to carried out. Vendors specifications need to be brought down to a common scalable platform. (May be difficult). Vendors capability of providing continuous support must be ensured. Software escrow agreement must be entered into and all the legal documents need to be reviewed by legal counsel. Total dependability on the vendor (Disadvantage) Senior management involvement will be more

Systems Requirement Specifications (SRS)

Systems Requirement Specifications - SRS

To set Terms-of-reference (TOR) for Software Development (objective scope and deliverables) Existing operations along with users additional requirements with running description and system flow diagrams
Interview / meetings with users at various levels along with / observation of users at work Document / register / report forms collection and analysis Existing Work flow analysis BPR requirements Volume of data, frequency of transactions, entry points are decided Analysis of authorities / roles / responsibilities of users at various levels Analysis of locations of computers

Many-a-times Feasibility is merged into this phase and therefore SRS must be carried out irrespective of Make or Buy decision. A Systems Requirements Specifications Report is the outcome of this phase

Systems Design

Systems Design
Organisation of data (temp files, report files) / programs(Source code, executables, DLLs) on computer is designed Business rules / requirements of validation of data are specified and designed as per the analysis done Various types of charts are prepared such as Systems Flow Chart (Function wise), Work flow Charts (Actor wise), Data Flow Diagrams, Decision tables(Business Rules) etc. Design of Database.. E.g. Single / Multiple database, Tables (Normalisation), relations between tables, Primary / Foreign keys User interfaces (Screens / Views) / report formats etc are designed Controls start getting built-up..Authority / security requirements are specified / designed Users involvement in this phase is minimal but necessary Plan to convert legacy system to new system

Types of Systems
Operational Information Systems - OIS
e.g. stand-alone and small systems where individual functions or their integration is established

Transactions Processing Systems - TPS

High-volume..similar to OIS but focus is on capturing data for entire transaction

Management Information Systems - MIS

Usually built on OIS and/or TPS.. Helps enabling management reporting / decision taking

Decision Support Systems - DSS

involves semi-structured problems, requires iterative development, may not be well-structured

Expert Systems - ES
for providing expert advise based on pre-captured knowledgebase

CASE TOOLS
Computer Aided Software Engineering tools Refers to the use of s/w packages to aid in the development of all phases of Information Systems I.e. SDLC Aids designers / programmers to prepare business models and various flow diagrams Aids in designing and providing relationships amongst data entities Changes introduced in one CASE diagram will automatically update all relevant diagrams Helps in documentation Use of CASE tools by developers shall give primary comfort to IS auditors in respect of standard and consistent methodology followed Some of the CASE TOOLs : Rational Rose, Systems Architect, Visual UML etc.

Client-Server Computing
All client access points should be identified Application code and data may not be located on a single machine Mixed platforms (h/w, s/w, networking) may lead to compatibility problems and confusion Security issues need to be considered for multiple process layers in hardware, operating systems, telecommunication systems, database systems etc.

Version control and program change control may become complex Testing of system is a complex process

Web-enabled Software - Some issues

More stringent user identification and authentication is required Use of fire-walls in case of internet applications Data encryption needs to be built-in to avoid data exposure to unauthorized users (hackers) Telecommunication band-width problems leading to slower system response Mixed platforms lead to compatibility problems Due to browser based user interfaces, server side processing is done for allowing access through any browser Form Fill - submit methodology needs to be adopted to avoid sluggish response Performance profile of site needs to be built-up in respect of following
Pages visited most often and average visit length Most typical traffic pattern with peak traffic occurrence

Programming / Construction

Programming / Construction
The Systems Design is converted into Source Programs (Source Code - human readable form). Source Code is then compiled into Executable Code (Machine readable form) Executable code resides on secondary storage and loaded into memory when executed Executable cannot be modified. If source code is unavailable, modification to software is not possible. Programming documentation needs to be done

Two Methodologies
Procedural Programming - past trend e.g. COBOL, BASIC, Foxpro - 3 GL Object Oriented Programming(OOPs) - current trend Visual versions of BASIC, Foxpro, SQL, C++, JAVA etc. - 4 GL

Procedural Programming vs. OOPs

Procedural Programming
Addition Program Accept A (variable 1), B (variable 2) from user C (variable 3) = A + B Display C as answer Features Each task needs to programmed Less re-usablility Usually one executable

OOPs
Addition Object Call Accept object Call summation object Call display object Features Re-usability of objects Modular(not procedure wise) development Unrestricted data types Inheritance, encapsulation, polymorphism

be

Few Validation checks

Sequence check
Control number follows sequentially and any out-of-sequence number is either rejected or reported as an exception

Limit Check
Data should not exceed a pre-determined number or range

Validity check
Checking data validity in accordance with pre-determined criteria..e.g. Male / Female check for Sex code

Logical relationship check

Checks logical relationship between two data entities.. E.g. relation between joining date and retirement date

Table look-ups
Input data is checked against master data already stored..e.g. Account number entered gives details of account holder from master data

Testing

Testing
Unit testing ( testing)
Individual function / object / program is tested Normally carried out by programmers / QC

Integration testing
Linkages between all related programs is tested for interfaces and overall functioning Normally carried out by senior programmers / QC

System testing ( testing)

Completed modules are tested for interfaces and overall functioning Normally carried out by Project Leaders / QC

Regression testing
Any changes in coding needs to be tested again in isolation as well as with all linkages

Acceptance testing
Done by users, QC, IS auditors

Approaches to Testing
Black-box testing
Internal logic of programs is not examined.. Product is examined and not the process

White-box testing
Internal logic of programs is examined.. Process is examined and not the product

Top-down testing
Top-level modules are tested first and then explored further into lower level modules / programs

Bottom-up testing
Lower level modules / programs are tested first and graduated to higher level modules / programs

The objective of testing is to make the system fail

Debugging .. removing the errors Bebugging .. planting the errors to gauge system response

SDLC Methodologies
Water-fall model (Linear Sequential Model)
Analysis >> Design >> Coding >> Testing

Spiral Model
Analysis >> Design >> Coding >> Testing >> Review >>

Prototyping Model
Uses 4GL programming languages which enable faster development

Controlled trial & error method Emphasis is on screens and reports acceptable to users Users are misled into believing that the complete system is ready (processing, transaction volumes, security & controls, back-up & recovery etc will have to be built later) Likelihood of resulting system not having proper controls Seldom documented / approved because of the fast development Significant cost & time saving is possible

SDLC Methodologies
Rapid Application Development Model (RAD)
Strategically important systems are developed faster Well-defined methodology Reduction in development cost / time while maintaining quality Small well-trained development teams are used Integrated RAD tools(e.g. VB, Magic) are required Central repository of objects / functions is developed Rigid limits on development time frames are set

SDLC Methodologies
Joint Application Development Model (JAD)
Introduced by IBM in late 70s users , managers and analsysts/programmers, scribe, IS staff work together usually requires a sponsor JAD session leader is required disadvantages similar to those of group meetings

Participatory Development (PD)

alternative approach to SDLC users involvement is more

Improper SDLC - Risks

System may not meet end-users needs May exceed financial budget May exceed budgeted project time May result into inefficient product Promote poor or mismanagement of project Incompatibility with existing systems Missed business opportunities Reduced credibility of IS department Demotivation of staff

Modern Systems Analysis & Design

Feasibility Study
To set priority of Areas / departments to computerise vis-vis business focus.. TBA vs. Fixed Assets Accounting To finalise overall direction of the Computerisation..
Centralised vs. decentralised, Web-enabled or non-web-enabled

Make or Buy Decision

Make.. In house or Outsourcing Buy..off the shelf with customisation

To gather information about various aspects of computerisation e.g. hardware, software, information about about vendors etc. To finalise Terms-of-reference / time and cost estimates A Feasibility Study Report is the outcome of this phase

Systems Requirement Specifications - SRS

To set Terms-of-reference (TOR) for Software Development Existing operations along with users additional requirements with running description and system flow diagrams
Interview / meetings with users at various levels along with / observation of users at work Document / register / report forms collection and analysis Existing Work flow analysis BPR requirements Volume of data, frequency of transactions, entry points are decided Analysis of authorities / roles / responsibilities of users at various levels Analysis of locations of computers

Many-a-times Feasibility is merged into this phase and therefore SRS must be carried out irrespective of Make or Buy decision. A Systems Requirements Specifications Report is the outcome of this phase

Project Identification and Selection

SDLC
SRS Analysis

Project Initiation and Planning

Logical Design Physical Design Implementation

Maintenance

Commercial Systems
Accounting Systems
Creating & processing documents Book keeping / filing / register updating Posting in subsidiary and general ledger Reconciliation of ledger with all sub-ledgers Preparation of trial balance Preparing financial statements such as P & L account, balance sheet, income statement, cash-flow statement Analysis of authorities / roles / responsibilities of users at various levels Analysis of locations of computers

Operational Systems
Production / Project planning / Scheduling etc. 3 Ms Inventory / raw material / WIP / finished goods .. JITs etc. Purchase systems

Commercial Systems
Human Resource Systems
Personnel Administration Payroll and associated processing Employee performance tracking

Marketing Systems
Customer Billing Accounts receivables Supply chain management Customer service management

Banking Systems Portfolio management systems / Shares accounting systems School / College / results processing systems Many more.

Types of Files
Five generally observed types..these are logical types and not physical
Transaction files Master Files
Master files..can also contain transaction data Reference or Parameter files

System files Summary files Temporary files

Reports
Printed Reports.. Can be on plain or pre-printed stationery Display Reports Queries processing leading to display or printed reports

Systems Analysis
Systems Analysis involves
Study of existing system Study the product and information(data) flows Formulate strategic requirements for the new system Evaluate the present system (mainly reassessment) ---------------------------------------------------------------------------------------------

Business Objectives
Find out, decompose and document..obtain from stakeholders

Organisation and Job Design

Organisation structure Bifurcation into roles / responsibilities / authorities

Project Management Study throughobservation, interviews, meetings, reading, presentation, collecting documents etc. Making use of computer based tools and techniques

Systems Analysis Techniques

Effective Interviewing

Plan your interview Do your homework .. Clients brochures, web-sites, balance sheet Observe necessary protocols Know your subject very well
Convey your subject/s that this is an unstructured interview Be very informal / casual and do not interrogate your subject too much You may not be specific about a topic Make notes of discussion points in brief Convey your subject/s that this is a structured interview Ask very specific questions Take detailed notes.. If required take a steno or record interview with permission After the interview, circulate minutes and take formal / informal approval

Unstructured interviews

Structured Interviews should follow unstructured interview

Systems Design
Organisation of data (temp files, report files) / programs(Source code, executables, DLLs) on computer is designed Business rules / requirements of validation of data are specified and designed as per the analysis done Various types of charts are prepared such as Systems Flow Chart (Function wise), Work flow Charts (Actor wise), Data Flow Diagrams, Decision tables(Business Rules) etc. Design of Database.. E.g. Single / Multiple database, Tables (Normalisation), relations between tables, Primary / Foreign keys User interfaces (Screens / Views) / report formats etc are designed Controls start getting built-up..Authority / security requirements are specified / designed Users involvement in this phase is minimal but necessary Plan to convert legacy system to new system

Data Flow Diagrams - DFDs

Process Modeling
Involves graphical representation of functions / processes Functions or processes .. Capture, manipulate, store and distribute data within or outside of the systems

DFD is a Structured Analysis Technique Out of Requirements Determination, Requirements Structuring and Alternative generation and selction.. DFD is for requirements structuring Context data flow diagram DFDs of current physical system DFDs of current logical system DFDs of proposed logical system DFDs of proposed physical system

Data Flow Diagrams - DFDs

Data Flow
Data in motion e.g. customer order form, Invoice, Paycheque

Data store is data at rest e.g. a file folder, computer file Process is work performed to transform, store or distribute data Source / Sink is origin and / or destination of the data
We do not consider..
Interactions between source & sinks What a source or sink does with the data How to control or redesign source or sink How to provide direct access to source and sinks

Process

Data Store

Source/Sink

Data Flow
DeMarco & Yourdon symbols Gane & Sarson symbols

Context Diagram
Kitchen Customer Customer Order 0 Food Order

Receipt Management Reports

Rules of DFD
A C D E F
Source Sink

Rules of DFD
G
A A A

H
A A

K L

B A C

Update Retrieval

J
A

DFD Improper way

Customer Payment Receipt Payment Data Payment Data 1.0 Record Payment

2.0 Make Bank Deposit

Accounting Department

Credit Data

D1

Customer Master

Deposit Data

Bank

DFD Proper way

Customer Payment Receipt 3.0 Update Customer Master Payment Data Payment Data 1.0 Record Payment

2.0 Make Bank Deposit

Credit Data

D1

Customer Master

Deposit Data

Bank

Level-0 diagram
Customer Customer Order Receipt 2.0
Update Goods Sold File

Kitchen 1.0
Receive and Transform Customer Food Order Inventory Data Formatted Goods Sold Data

Food Order 3.0

Update Inventory File

D1

Inventory File

4.0
D2Goods

Daily Inventory Depletion Quantity

Sold File

Produce Management Report

Restaurant Manager
Management Reports