410
1 CS-1 st Year Systems Analysis and Design G.K.A. Dias University of Colombo School of Computing

System Analysis and Design

Embed Size (px)

DESCRIPTION

Computer System

Citation preview

Page 1: System Analysis and Design

1

CS-1st Year

Systems Analysis and Design

G.K.A. Dias

University of Colombo School of Computing

Page 2: System Analysis and Design

2

ReferencesRef : System Analysis and DESIGN

METHODS

By Jeffrey L Whitten & Lonnie D Bentley ISBN 0-07-063417-3 (7th Edition)

Recommended Links

http://www.mhhe.com/whitten

Page 3: System Analysis and Design

3

Introduction to Information System Environment

• What is an information system?• Types of Information Systems and

processing types• System development life cycle ???• Major components of the development

process???

Page 4: System Analysis and Design

4

Applications

Earlier applications

Keeping records of transactions

Airline Reservations Keeping records of Stock

Information Systems

Page 5: System Analysis and Design

5

Information Systems

IntroductionComputers are now becoming part of virtually every activity in an organization

HRM - Training Telephone IntegrationProduction

Page 6: System Analysis and Design

6

Information SystemAn arrangement of

• To support and Improve day to day operations• problem solving and decision making needs of

management and users

Interface InformationTechnology

People ProcessData Network

Page 8: System Analysis and Design

8

Information Systems

The Players - System Stakeholders

• any person who has an interest in an existing or proposed information system.

•Can be classified into five broader categories

• may include both –technical and non-technical workers–Internal and External workers

Page 9: System Analysis and Design

9

System stakeholders

can be classified into five groups

Information Systems

System OwnerSystem User System Builders

System AnalystsSystem Designer

Page 10: System Analysis and Design

10

Information Systems• Stakeholders cont.. a “customer” who will use or

is affected by an information system on a regular basis –capturing, validating, entering, responding to, storing, and exchanging data and information.

System Users or Clients

Page 11: System Analysis and Design

11

Information Systems

• Stakeholders cont..

System Owner

• An information system’s sponsor and advocate

• Owns the system

• Set the vision and priorities

• Determine the policies

• Responsible for funding the project of

•Developing•Operating•Maintaining

Page 12: System Analysis and Design

12

Information Systems

• Stakeholders cont..

System Designer

technical specialiststechnical specialists

Translates system usersTranslates system users’’business requirements and business requirements and constraints into technical constraints into technical solutions.solutions.

Design the system (dataDesign the system (data--bases, bases, inputs, outputs, screens, network, inputs, outputs, screens, network, software) to meet the users software) to meet the users requirementsrequirements

Page 13: System Analysis and Design

13

Information Systems

• Stakeholders cont..

System Designer

Design the computer Design the computer files, databases, inputs, files, databases, inputs, outputs, screens, outputs, screens, networks, and programs networks, and programs that will meet the system that will meet the system users requirements.users requirements.

Page 14: System Analysis and Design

14

Information Systems

• Stakeholders cont..

System Builders

Construct, test and deliver the Information System based on the design specifications generated by the system designer.

Page 15: System Analysis and Design

15

Information Systems

• Stakeholders cont..

Systems Analysts

People who understand both business and computing.

Page 16: System Analysis and Design

16

Information Systems

• Stakeholders cont..

Systems Analysts

Studies the problems and needs of an organization

Determine how people, data, processes, and information technology can best accomplish improvements for the business

Bridge the communication gap that exists between non technical and technical people involved with building systems.

Page 17: System Analysis and Design

17

Information Systems

• Stakeholders cont..

Systems Analysts

- Identify the problem- Analyze and understand the problem

- Identify the requirements- Identify the solution- Identify alternative solutions- Design and implement the best solution

- Evaluate the result

What does a systems analystdo?

Page 18: System Analysis and Design

18

Information Systems

Legacy systems• an existing computer system or

application program• continues to be used because the user

does not want to replace or redesign it• an "antiquated" systems. • Ref : http://en.wikipedia.org/wiki/Legacy_system

Page 19: System Analysis and Design

19

Legacy systems cont…

Information Systems

• potentially problematic

– often run on obsolete (and usually slow) hardware

– spare parts for such computers become increasingly difficult to obtain

– hard to maintain, improve, and expand because there is a general lack of understanding of the system

– The designers of the system may have left the organization, leaving no one left to explain how it works

– Integration with newer systems may also be difficult because new software may use completely different technologies.

Page 20: System Analysis and Design

20

Legacy systems cont…

Converted to satisfy new environments

Old technology

New technology

Support old business requirements

Support new business requirements

Old standard

New standard

New functionality

Old system

Y2K?

Euro?

New system

Y2K free

Euro

Information Systems

Page 21: System Analysis and Design

21

Information SystemsLegacy systems cont…

• Many complex legacy systems yet to be upgraded to new technologies because of– Cost,– Skills and– People required

• Force to change – to reflect new or changing business requirements. – Year 2000 problem (Y2K)– Euro conversion

Page 22: System Analysis and Design

22

Information SystemsLegacy systems cont.

Y2K problem

– Many computers and applications stored date with only 2 digits.(e.g. 99 =1999)

– Problems : when the millennium changed(e.g. 03=2003)

Born in 1978Age? -74, 0, 74

Page 23: System Analysis and Design

1

Types of Information Systems

• Transaction Process Systems (TPS)• Management Information Systems (MIS)• Decision Support Systems (DSS)• Executive Information Systems (EIS)• Expert Systems• Communications and collaboration

Systems• Office Automation Systems

Page 24: System Analysis and Design

2

Transaction Process Systems (TPS)

• Capture and process data about business transactions

Bank deposit and withdrawal

Airline Reservations

Page 25: System Analysis and Design

3

Management Information System (MIS)

• Designed for management oriented reporting• Based on transaction processing and

operations of the organization

Inventory reportingProduction scheduling

Page 26: System Analysis and Design

4

Decision Support System (DSS)

• Helps to identify decision making opportunities• Provides information to help make decisions • Provides its user with decision-oriented

information whenever decision making situation arises.

Executes at workWith DSS

Page 27: System Analysis and Design

5

Executive Information Systems

• Designed for top-level managers.

• Supports the planning and assessment needs of executive managers.

• Integrates data from all over the organization into “at-a-glance” graphical indicators and controls.

Page 28: System Analysis and Design

6

Expert Systems

• An expert system is a programmed decision making information system.

• Capture and reproduce the knowledge and expertise of a decision maker

• Simulates the “thinking” of the expert.

I am a I am a humanhuman

Page 29: System Analysis and Design

7

Communications and Collaboration Systems

• Enables more effective communications between – Workers– Partners– Customers– Suppliers

• Enhance their ability to collaborate

Page 30: System Analysis and Design

8

Office Automation Systems• Supports the wide range of business office

activities• Provides improved work flow between workers.

facsimileE-Mail

Electronic document

Work group computing Work group scheduling

Page 31: System Analysis and Design

1

Information technology Features

Centralized Systems

- All the components are hosted by a central, multi user system- User interact with the host computer via terminals- Virtually all of the actual processing and work is done on the host computer.

I have all system data

I am doing all processing

Provide interfaces

Databases

Page 32: System Analysis and Design

2

Information technology features

Distributed Systems

- Components are distributed across multiple locations and computer networks

- Processing work load required to support these components are distributed across multiple computers on the net work.

Distributedto multiple locations

-- Components of an information system -- Processing workload required to

support the components

Page 33: System Analysis and Design

3

Distributed Systems1. Client Server Systems

The presentation, presentation logic, application logic, data manipulation and data layers are distributed between client PC’s and one or more servers.

AccountsSales

Design

Construction

Client Computers :

Any combination of personal Computers or Workstations, “sometimes connected”

Page 34: System Analysis and Design

4

Distributed Systems

Client Server Systems cont..

Clients may be thin or flat

Acts only as a terminal

Almost all PCs

e.g. Windows terminal

Page 35: System Analysis and Design

5

Distributed Systems

2. File server Architecture

– A LAN (Local area network) based solution– A server computer hosts only the data layer– All other layers are implemented on the client

PC.– Practical only for small database applications

shared by relatively few users

Page 36: System Analysis and Design

6

Distributed Systems3. Network Computing Systems• Presentation and presentation logic layers are implemented in a client

side web browser • The presentation logic layer then connects to the application logic

layer that run on an application server,• Subsequently connects to the database server/s

Page 37: System Analysis and Design

7

Processing Types 1. Batch Processing

•Data about many transactions is collected as a single file which is then processed

•The data entered is collected into files called batches.

•Each file is processed as a batch of many transactions.

Super market-Batch processing

Page 38: System Analysis and Design

8

Processing Types2. Online Processing

ATM-Real time processing

The data about a single transaction is processed immediately.

Page 39: System Analysis and Design

1

CS-1st Year

Systems Analysis and Design

G.K.A. Dias

University of Colombo School of Computing

Page 40: System Analysis and Design

2

System Development Life Cycle (SDLC)

Problem Definition

System AnalysisMaintenance

System Testing System Design

System Implementation

Page 41: System Analysis and Design

3

System Development Life Cycle (SDLC) • A systematic approach to software development• Composed of several phases,

– Problem Definition - identifies and defines a need for the new system

– System Analysis - analyzes the information needs of the end users

– System Design - creates a blueprint for the design with the necessary specifications for the hardware, software, people and data resources

– System Implementation- creates and programs the final system

– System testing - evaluates the system's actual functionality in relation to expected or intended functionality.

– Maintenance – keeping the system up to date with the changes in the organization and ensuring it meets the goals of the organization

Page 42: System Analysis and Design

4

Why we need a life cycle in systems development?

• to avoid failures like unclear objectives, cost overruns, and

• to maintain cheaply and enhance cost effectively

• to ease the process of building a system

• to build high quality systems that meets customer expectations, within time and cost estimates

• to work effectively and efficiently in the current and planned information technologyinfrastructure

Page 43: System Analysis and Design

1

Sequential or Waterfall development approach

Problem Definition

Requirement Analysis

System Design

System Development

System Testing

Maintenance

• An approach to system analysis and design

• Completes each phase one after another and only once.

Page 44: System Analysis and Design

2

Problem Definition Provides a broad statement of user requirements in users terms, or what the users expect the system to do

Project goals

project bounds are set during this phase. Defines what part of the system can be changed by the project and what parts are to remain same.

Project bound

Specify the resources to be made available for the project (resource limits).

Projectlimits

Page 45: System Analysis and Design

3

System Analysis

• The study of a business problem domain to recommend improvements

• Specify the business requirements and priorities for the solution

• Business area is studied and analyzed to gain more information

• Produces a statement of the system users’business requirements, expectations and priorities for a solution to the business problem

Page 46: System Analysis and Design

4

System Analysishow the current

system works and what it does

Producing a detailed model of what the new system will do and how it will work.

Producing a high-level description of the system

Page 47: System Analysis and Design

5

System Design• The specification or construction of a technical, computer

based solution for the business requirements identified in a system analysis

• Initially explore alternative technical solutions• Develops the technical blueprints and specifications

DesignAnalysts

Page 48: System Analysis and Design

6

System Design

• Things to be done:• Select equipment• Specify new programs or

changes to existing programs

• Specify new database or changes to existing database

• produce detailed procedures

Design

Page 49: System Analysis and Design

7

System ImplementationIndividual system components are built and testedData and tools are used to build the systemUser interfaces are developed and tried by users Database is initialized with data

SystemAnalysts

Page 51: System Analysis and Design

9

Maintenance

Eliminate errors in the system during its working life.

Fixing any bugs and problem found by users

Tune the system to any variations in its working environment

Page 52: System Analysis and Design

10

Problems with waterfall cycle

It has a rigid design InflexibleIt has a top-down procedureOne phase must be completed before the next phase startsNo phase can be repeatedTime consuming

Page 53: System Analysis and Design

11

Criticisms fall into the following categories:

Real projects rarely follow the sequential flow that the model proposes.

At the beginning of most projects there is often a great deal of uncertainty about requirements and goals, and it is therefore difficult for customers to identify these criteria on a detailed level. The model does not accommodate this natural uncertainty very well.

Page 54: System Analysis and Design

12

Criticisms fall into the following categories: cont…

Assumptions made in the early phases no longer hold

Some of the early work is incomplete

Something was overlooked or not completely understood.

Page 55: System Analysis and Design

13

Modified Waterfall ModelProblem Definition

Requirement Analysis

System Design

Implementation

System Testing

Maintenance

Page 56: System Analysis and Design

14

Modified Waterfall Model• Allow some of the stages to overlap, such as the

requirements stage and the design stage

• Make it possible to integrate feedback from one phase to another

• Incorporate prototyping.

• Verification and validation are added.– Verification checks that the system is correct (building the

system right). – Validation checks that the system meets the users desires

(building the right system).

• Progress is more difficult to track.

Page 57: System Analysis and Design

15

Iterative development approach• An approach to systems analysis and design

• Completes the entire information system in successive iterations

• Each iteration does some – Analysis– design – Construction

• Allows versions of usable information to be delivered in regular and shorter time frames

Page 58: System Analysis and Design

16

Iterative development approachComplete problem definition

Some System Analysis

SomeSystemDesign

Some System

Implementation

MoreSystem Analysis

MoreSystemDesign

More System

Implementation

Still moreSystem Analysis

Still moreSystemDesign

Still more System

Implementation

Repeat until no additional iterations needed

Iteration # 1

Iteration # 2

Iteration # 3

Page 60: System Analysis and Design

2

• P2: Use a problem-solving approach.

# Study and understand the problem and its context

# Define the requirement of a suitable solution.

# Identify candidate solutions that fulfill the requirements and select the best solution.

# Design and/or implement the solution.

# Observe and evaluate the solution’s impact, and refine the solution accordingly.

Page 61: System Analysis and Design

3

• P3: Establish phases and activities.

• All methodologies prescribe phases and activities• The number and scope of phases and activities may

vary.• The Phases are

# Scope definition # Problem analysis# Requirement analysis#Logical design# Decision analysis# Physical Design# Construction &Testing # Installation & Delivery

Page 62: System Analysis and Design

4

• P4 : Document through out Development

– An ongoing activity of recording facts and specifications for a system for current and future reference

– Documentation enhances communications and acceptance

– Stimulates user involvement and reassures management about progress

– Reveals strengths and weaknesses of the system to multiple stakeholders.

Page 64: System Analysis and Design

6

• P6 :Manage the process and Projects

Process Management

– Ensures that an organizations chosen process or management is used consistently on and across all projects

– An ongoing activity• Documents• Teaches• Oversees the use of • Improves

– Concerned with • Phases• Activities• Deliverables• Quality Standards

An organization’s chosen methodology

For system development

Page 65: System Analysis and Design

7

• P6 :Manage the process and Projects Cont….

Project Management

– Process of• Scoping• Planning• Staffing• Organizing• Directing• Controlling a project

– ensures that an information system is developed • at minimum cost, • within a specified time frame and • with acceptable quality.

Page 66: System Analysis and Design

8

P7:Justify systems as Capital Investments.

# Cost-effectiveness

– Obtained by striking a balance between the lifetime cost of Developing, Maintaining, Operating an information system and the benefits derived from that system

– measured by cost-benefit analysis– Performed throughout the system development

IScost

# Risk management

• The process of identifying, evaluating, and controlling, what might go wrong in a project before it becomes a threat

• Driven by risk analysis or assessment

Page 68: System Analysis and Design

10

P9:Divide and conquer.

# divide a system into subsystem and components

--- Easily to conquer the problem --- Easy to build a large problem

Page 69: System Analysis and Design

11

P10: Design systems for growth and change.# the business, their need and priorities change over time

# thus, information system that supports a business must also change over time

# good methodologies should embrace the reality of change

# the systems should be designed to accommodate both growth and changing requirements

#the systems should be designed to scale up and adapt to the business

Page 70: System Analysis and Design

1

Major components of system development

• Methodology • Modeling Methods or Techniques• Tools

Major Components

Page 71: System Analysis and Design

2

Methodology• A set of

– Activities– Methods– Best practices– Deliverables– Automated tools

• Used by stakeholders to– Develop– Continuously improve

Information systems and

Software

Page 72: System Analysis and Design

3

Methodology

• Provides the framework • Has a predefined set of steps• Ensures that systems are built in the most

effective way

e.g. SSADM, RUP

Page 73: System Analysis and Design

4

Methodology

Modeling Methods or Techniques

Class Diagram, Use Case Diagrams etc.

Tools

Rational Rose,Rational Suit

Eg .Rational Unified Process

Page 74: System Analysis and Design

5

Methodology

• Uses tools and modeling methods

Tools

Methods

Most Effective Way of Building

Page 75: System Analysis and Design

6

Methodology

Supported by Modeling Methods or Techniques

• Techniques used to implement the Methodology.• Provides the descriptions of the business system

requirements from various view points.

Page 76: System Analysis and Design

7

Life Cycle vs. Methodology

• The system development methodology consists of several well-defined steps.

• When following a design methodology, a designer can select appropriate modeling method related to each step.

Page 77: System Analysis and Design

8

Life Cycle vs. Methodology

System Development

LIFE CYCLE STAGE

A System Development

Process

using

Methodology

•A system development life cycle divides the life of an information system into two major stages,

• Systems development(consists of system analysis, system design, system implementation and testing phases)

and • Systems operation and support (maintenance)

using

Conversion

Obsolescence

Lifetimeof a

System

LIFE CYCLE STAGE

System Operationand

Maintenance

Information Technology

Page 78: System Analysis and Design

9

Life Cycle vs. Methodology

• A system development methodology is a very formal and precise system development process that defines – a set of activities, – methods, – best practices, – deliverables, – and automated tools

Page 79: System Analysis and Design

10

Modeling MethodsA set of techniques used to implement a Methodology

• Data Flow Diagrams -– A process model– Depict the flow of data through a system and the work

performed by the system

• Entity Relationship Diagrams –– A data model– Depict data in terms of entities and relationships

described by the data– Consists of several notations

• Structure Charts etc.Different Views of the System

Page 80: System Analysis and Design

11

• Software systems • Assists analysts and designer to build

information systems• They will not replace Systems Analysts.

e.g. Easy Case, Rational Rose

Tools

Page 81: System Analysis and Design

12

ToolsGeneral Aim :

Decrease the human effort required to develop the software.

Increase the quality of software

Tools will support methodologies but will not replace system analysts.

Page 82: System Analysis and Design

1

Information Systems Development

System owners & system users initiate most Information Systems Development projects

An undesirable situation or problem/s in the organisation which hinders their progress or achieving the desired goals may be one reason to develop a new system

It could also be that a new opportunity has been identified which would bring more benefits to the organisation

Page 83: System Analysis and Design

2

Information Systems Development……

A new requirement that may be imposed on the organisation by directives issued by Government/Management/some other External Influence

Page 84: System Analysis and Design

3

ScopeDefinitionThis is the first stage/phase of an Information

Systems Development project

The purpose of the scope definition is twofold.

1. Is this problem/opportunity/directive worth looking at?

2. If the above is worthwhile doing then identifying the size and boundaries of the project, the project vision, any constraints, the participants, budget & the schedule

Page 85: System Analysis and Design

4

ScopeDefinitionScope definition should include:

1. The scope of the project which may later change during the development life cycle(Scope is the boundaries of a project – the areas of a business that a project may or may not address)

Project scope can be easily defined using:

What type of data: e.g. For a sales Information System – customer data, product data etc.

Page 86: System Analysis and Design

5

What are the business processes in the system(customer management, order entry, order fulfillment) etc.

What are the System interface with users, locations & other systems (e.g. Customers, Sales reps, Regional sales offices, Accounts receivable etc.)

Perceived problems (as perceived mostly by system users)

Opportunities (which would bring more benefits to the organization)

Page 87: System Analysis and Design

6

Directives that triggered the project(Government regulations or mergers)

2. Project worthiness (Is this project worth doing? Feasibility studies)

3. Schedule & budget

4. Constraints – budget limits, deadlines, availability of human resources etc.

5. Communication of the project plan or project proposal (Communication skills of presenters are very important)

Page 88: System Analysis and Design

7

At this stage it is not necessary to spend a lot of time preparing this document and modeling or prototyping may not be required.

Refer to the Sample Problem Statement

Fig. 5 – 8 in Ref 1 p171.

Page 89: System Analysis and Design

8

Finding Problems to Solve• Requirements solve problems

– E.g. A mother takes her young daughter to the doctor because the child is ill. The first thing the doctor tries to do is, identify the problem.

• The child has – an earache, – a fever, – a runny nose.

Are these the problems?

Page 90: System Analysis and Design

9

• E.g. Cont…• The mother has been giving the child pain medicine to

ease the pain,• But still the child is not well. • The mother is treating

– the symptoms and – NOT the real problem.

• However, the doctor, – analyze the symptoms further– examine the child – Make the conclusion

Finding Problems to Solve

Conclusion (Root cause of the child’s

symptoms) :AN EAR

INFECTION

Page 91: System Analysis and Design

10

Finding Problems to Solve• E.g. Cont…

– Problem is identified and analyzed, – Recommend a cure (solution)

• An antibiotic can be prescribed • Determine constrains on the medicine that can prescribe.

– How old is the child? – How much does she weigh? – Is the child allergic to any medications? – Can she swallow pills?

• Once the constraints are known, a prescription can be generated.

• Systems analysts use the same problem-solving process as a doctor uses, but instead of diagnosing medical problems they diagnose system problems.

Page 92: System Analysis and Design

1

Feasibility Study • Feasibility

– The measure of how beneficial / practical an information system will be to an organization

– Should be measured through out the life-cycle

• Feasibility Analysis– The process by which the feasibility is measured– An ongoing evaluation of feasibility at various

checkpoints in the life cycle

Page 93: System Analysis and Design

2

Feasibility Checkpoints in the Software Development Life Cycle

• Feasibility of a project can be changed during the system development.

• For reevaluate feasibility, there are different checkpoints in the development.

• A project may be canceled, revised or continued at any checkpoint, despite whatever resources have been spent.

Page 94: System Analysis and Design

3

Feasibility Checkpoints

• Systems Analysis – Scope Definition Checkpoint

• Systems Analysis – Problem Analysis Checkpoint

• Systems Design – Decision Analysis Checkpoint

Page 95: System Analysis and Design

4

Scope Definition Checkpoint• Measure of the urgency of the problem. • Find the first-cut estimate of development

costs.• Answer the question,

– Do the problems warrant the cost of a detailed study & analysis of the current system?

Page 96: System Analysis and Design

5

Problem Analysis Checkpoint

• Occurs after a more detailed study and problem analysis of the current system

• Can make a better estimate of the development cost and benefits

Minimum Value of solving a problem = cost of problem

Page 97: System Analysis and Design

6

Decision Analysis Checkpoint• Represent major feasibility analysis activities

• Charts one of many possible implementations as the target

• Alternate solutions are defined in terms of,• Input/Output methods• Data storage methods• Hardware requirements• Software requirements• Processing methods• People implications

Page 98: System Analysis and Design

7

Decision Analysis CheckpointRange of options – Evaluated by the analyst

• Leave current system alone• Re-engineer the manual process• Enhance existing computer processes• Purchase packaged software• Design and construct a new computer-

based system

After defining these options, each option should be analyzed.

Page 99: System Analysis and Design

8

Tests for Feasibility

• Operational Feasibility• Cultural / Political Feasibility• Technical Feasibility• Schedule Feasibility • Economic Feasibility• Legal Feasibility

Page 100: System Analysis and Design

9

Operational feasibility. •A measure of how well a solution meets the identified system requirements to solve the problem.

•Take advantage of the opportunities identified during the scope definition and problem analysis phases.

– Will the solution fulfill the users’ requirements? To what degree?

– How will the solution change the users’ work environment?

– How do users feel about such a solution?

Page 101: System Analysis and Design

10

Cultural (or Political) Feasibility

• A measure of how well the solution will be accepted in a given organizational climate

• Deals with how the end users feel about the proposed system.

• Evaluates whether a system will work in a given organizational climate.

Page 102: System Analysis and Design

11

Technical feasibility.• A measure of the

– Practicality of a technical solution– Availability of technical recourses and expertise

• Addresses three major issues – Is the proposed technology or solution practical?– Do we currently possess the necessary technology

(Hardware/Personnel) ?– Do we possess the necessary technical expertise?

Page 103: System Analysis and Design

12

Schedule feasibility• A measure of how reasonable a project time table is.

– Can the solution be designed and implemented within an acceptable time period?

– how much time is available to build the new system?

– when it can be built ?

• Mandatory / Desirable deadlines.

Page 104: System Analysis and Design

13

Economic feasibility. • a measure of the cost-effectiveness of a project

– Is the solution cost-effective?– Whether the solution will pay for itself?– How profitable the solution is?

• Once the specific requirements and solutions have been identified

– Weight the costs and benefits of each alternative (Cost benefit Analysis)

e.g. Personnel cost, Computer cost, Training, Software, Tangible and Intangible benefits

Page 105: System Analysis and Design

14

Legal Feasibility

• A measure of how well a solution can be implemented within existing legal and contractual obligations.

• understand potential legal and contractual ramifications of the system

* copyright law* non-disclosure clauses and non-compete clauses* code ownership (if developed with outside

assistance) -- be VERY specific* labor laws* foreign trade, and labor regulations* Financial & Accounting standards* governmental constraints, and pending legislation

Page 106: System Analysis and Design

1

Cost Benefit Analysis• Determines the cost effectiveness of a project or

solution

• The purpose of a cost/benefit analysis is to answer questions such as:

- Is the project justified (because benefits outweigh costs)?

- Can the project be done, within given cost constraints?- What is the minimal cost to attain a certain system?- What is the preferred alternative, among candidate

solutions?

Page 107: System Analysis and Design

2

How much will the system cost?• Two types of costs, costs associated with

– Developing the system• Can be estimated from the outset of a project• Should be refined at the end of each phase• One time costs (will not recur after the project has

been completed – Operating a system

• Can be estimated only after specific computer-based solutions have been defined

• Recur throughout the lifetime of the system

Page 108: System Analysis and Design

3

How much will the system cost?

• System development Cost Categories– Personnel costs– Computer Usage– Training– Supply, duplication, and equipment costs– Cost of any new computer equipment and software

Page 109: System Analysis and Design

4

What benefits will the system provide?

• Benefits – increase profit– Decrease costs– Can be classified as

• Tangible benefits – a benefit that can be easily quantified.

• Intangible benefits – a benefit that is believed to be difficult or impossible to quantify

Page 110: System Analysis and Design

5

Is the proposed system cost effective

• Cost effectiveness techniques

– Payback Analysis– Return on Investment Analysis– Net present value Analysis

Page 111: System Analysis and Design

6

Payback Analysis• A technique for determining if and when an investment

will pay for itself• How long will it take (usually, in years) to pay back the

project, and accrued costs:– Total costs (initial + incremental) - Yearly return (or savings)

Page 112: System Analysis and Design

7

Return-on-Investment (ROI) Analysis

• A technique that compares the lifetime profitability of alternative solutions

Lifetime benefits - Lifetime costsLifetime costs

Page 113: System Analysis and Design

8

Net Present value Analysis

• Compares the annual discounted costs and benefits of alternative solutions

• Spreadsheets such as Excel, Lotus 1-2-3 can be used to calculate all these values

Page 114: System Analysis and Design

1

Feasibility Analysis of Candidate systems

• During the decision analysis phase of system analysis, – Identifies candidate system solutions – Analyses the solution for feasibility

• Can use two alternatives to compare and contrast candidate system solutions – Candidate System Matrix– Feasibility Analysis Matrix

Use A Matrix Format

Page 115: System Analysis and Design

2

Candidate Systems Matrix• Used to document similarities and

differences between candidate systems

– Compare candidate systems– Offers no analysis– Columns represent candidate solutions– Rows represent characteristics that

differentiate the candidates

Page 116: System Analysis and Design

3

Candidate Systems Matrix

• Example

Candidate 1 Name

Candidate 2 Name

Candidate 3 Name

StakeholdersKnowledgeProcessesCommunications

TemplateTemplate

Page 117: System Analysis and Design

4

Candidate Systems Matrix• Example

Candidate 1 Name

Candidate 2 Name

Candidate 3 Name

StakeholdersKnowledgeProcessesCommunications

Identify how the Identify how the system will interact system will interact with people, and other with people, and other systemssystems

TemplateTemplate

Page 118: System Analysis and Design

5

Candidate Systems Matrix• Example

Candidate 1 Name

Candidate 2 Name

Candidate 3 Name

StakeholdersKnowledgeProcessesCommunications

Identify how data stores Identify how data stores be implemented, be implemented, inputs will be captured, inputs will be captured, outputs will be generatedoutputs will be generated

TemplateTemplate

Page 119: System Analysis and Design

6

Candidate 1 Name

Candidate 2 Name

Candidate 3 Name

StakeholdersKnowledgeProcessesCommunications

Identify How (manual) Identify How (manual) business process will business process will be modified, how be modified, how computer processes computer processes will be implementedwill be implemented

Candidate Systems Matrix• Example

TemplateTemplate

Page 120: System Analysis and Design

7

Candidate Systems Matrix• Example

Candidate 1 Name

Candidate 2 Name

Candidate 3 Name

StakeholdersKnowledgeProcessesCommunications

Identify how Identify how processes and data processes and data will be distributed.will be distributed.

TemplateTemplate

Page 121: System Analysis and Design

8

Feasibility Analysis Matrix

• Used to rank candidate systems– Columns represent candidate response– Rows correspond to the feasibility criteria– Cell contain the feasibility assessment notes

for each candidate

Page 122: System Analysis and Design

9

Feasibility Analysis MatrixWeighting Candidate1 Candidate2 Candidate3

Description

Operational Feasibility

Cultural Feasibility

Legal Feasibility

Technical Feasibility

Economic Feasibility

Schedule Feasibility

Weighted Score

Page 124: System Analysis and Design

2

Written Report• The most abused method used by analysts• Consists of

– Primary Elements • Actual information• E.g. introduction, conclusion

– Secondary Elements• Package the report• Reader can easily identify the report and its primary elements• Add a professional polish.

Page 125: System Analysis and Design

3

Secondary elements for a written report

Letter of transmittalTitle pageTables of contentsList of Figures, illustrations, and tablesAbstract or executive summary

(primary elements are presented in this portion of the report)Appendixes

Page 126: System Analysis and Design

4

Formal Presentation• A special meeting

• Used to sell new ideas and gain approval for new systems

• Can be also used forSell a new system, sell new ideas, sell change, head off criticisms, address concerns, verify conclusion, clarify facts and report progress.

Problems at the end of Chapter 11 in Ref. 1

Page 127: System Analysis and Design

1

Requirements AnalysisIdentifying Requirements

Correct systems can only be built if you know exactly what the

user needswhat the system must do

Therefore most important factor in building correct systems is to first clearly define what the system must do

For that we should have a better communication between system users and the analyst.

Systems Analyst

Page 128: System Analysis and Design

2

Requirements Analysis

Importance of Communication

- Analyst must ensure that no ambiguities arise, during the discussions between various people involved in the analysis phase

- Different jargon used by different people may cause problems

- Reduce misunderstandings between the end-users and developers

Page 129: System Analysis and Design

3

Requirements AnalysisExample:

Ambiguous Requirement Statement

Identify the mode of transportation to transfer a single individual from home to place of work

ManagementInterpretation IT Interpretation User Interpretation

Page 130: System Analysis and Design

4

Disadvantages of not identifying user requirements correctly

• The system will exceed time schedules and cost schedules

• The user may not be satisfied with the system requirements. Therefore, they may not use the system

• The cost of maintenance may be excessively high• The system may be unreliable and prone to errors• The reputation of the IT staff on the team will be

tarnished

Page 131: System Analysis and Design

5

Process of Requirements Discovery

• Consists of– Problem discovery and analysis (already

discussed in Chapter 3)– Requirements discovery (the process and

techniques used by systems analysts to identify or extract system problems and requirements from the user community )

– Documenting and analyzing requirements– Requirements management

Page 132: System Analysis and Design

6

Requirements Discovery

• Can start to define requirements after understanding the problem

• Must use effective methods for gathering information (Fact Finding)

• After completing the process of fact finding use various tools to document the requirements

Page 133: System Analysis and Design

7

Requirements Discovery…

• The process and techniques used by systems analysts to– Identify– Analyze– Understand

SystemRequirements

Systems Analyst

Systems UserSystems Owner

Works with

Works with

Page 134: System Analysis and Design

8

Requirements Discovery…

System Requirements

Specify what the information system must do, or what property / quality the system must have

Page 135: System Analysis and Design

9

Requirements Discovery…

System Requirements

Functional Requirements

Specify what the information system must do

Non functional RequirementsSpecify a property / quality the system must have

e.g. user friendliness, Security etc. Refer page 209 Ref1 table 6-1

Page 136: System Analysis and Design

10

Requirements Discovery…

System requirements can be gathered by– using discussions with users, about their

requirements– building systems that satisfy these requirements

Page 137: System Analysis and Design

11

Requirements Discovery…System requirements should meet the following criteria

– Consistent: not conflicting / ambiguous– Complete: describe all possible system inputs and

responses– Feasible: satisfied based on the available resources

and constraints – Required: truly needed and fulfill the purpose of the

system– Accurate: stated correctly– Traceable: directly map to the functions and

features of the system– Verifiable: defined so that they can be demonstrated

during testing.

Page 138: System Analysis and Design

12

Documenting and Analyzing Requirements

• Assemble or document the gathered information / draft requirements in an– Organized– Understandable– Meaningful way.

• Provide direction for the modeling techniques

Page 139: System Analysis and Design

13

Documenting and Analyzing Requirements…

• Documenting the draft requirements– Use various tools to draft the initial findings

• Use cases: describe the system functions from the external users’ perspective

• Decision tables: document an organization’s complex business policies and decision making rules

• Requirement tables: document each specific requirement.

Page 140: System Analysis and Design

14

Documenting and Analyzing Requirements…

• Analyzing Requirements– Fact finding activities produce requirements that

are in conflict with one another

– Requirements analysis activity• Discover and resolve the problems with the

requirements • Reach agreement on any modifications to satisfy

the stakeholders

Page 141: System Analysis and Design

15

Requirements Management

• Help to alleviate the many problems associated with changing requirements– Emerging new requirements– Changing existing requirements

• Encompasses – Policies– Procedures– Processes

Refer Page 215 Ref1

Page 142: System Analysis and Design

1

Fact Finding TechniquesFact-Finding

A formal processUses techniques to collect / gather information about

System requirementsProblemsPreferences

Also known as Information gatheringUsed across the entire development cycleExtremely critical in the requirement analysis phase

Page 143: System Analysis and Design

2

Fact Finding Techniques…

Sampling of Existing documents

Research and site visits Observations of

the work environment

QuestionnairesInterviews

Prototyping

Joint requirements planning

Page 144: System Analysis and Design

3

Fact Finding Ethics

• Come across sensitive datae.g. employee profile: salaries, performance history, medical history, career plans etc.

• Leaving sensitive documents in plain view on the desks or publicly discuss sensitive data could cause great harm to the organization

• Therefore, analysts must take great care to protect security and privacy of any facts

Page 145: System Analysis and Design

4

Fact Finding Techniques…

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

Should be analyzed to make sure that they are relevant and up-to-date

Sampling of existing Documentation– When you are studying an existing system, you can get

a good idea by studying existing

Documentation FilesForms

Page 146: System Analysis and Design

5

Fact Finding Techniques…

Research and Site Visits

Thoroughly, research the problem domain.Identify the material that are relevant and reliable

Intranets

Good sources of information

Computer tradeJournals

Reference booksInternet

World Wide Web

Page 147: System Analysis and Design

6

Observations of the work environmentSystems Analyst participates in or watches a person perform activities to learn about the system

Fact Finding Techniques…

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

Page 148: System Analysis and Design

7

Fact Finding Techniques…

Observations of the work environment…

Advantages

Relatively inexpensive

Data gathered by observation can be highly reliable

Allows systems analyst to do work measurements

Systems analyst is able to see exactly what is being done

Page 149: System Analysis and Design

8

Disadvantages

I don’t like being watched

Observations of the work environment…

Fact Finding Techniques…

People usually feel uncomfortable when being watched.

Work being observed may not involve the level of difficulty or volume normally experienced during that time

Some tasks may not always be performed in the manner in which they are observed by the system analyst. Etc…

Refer page 218 Ref1 – The Railroad Paradox

Page 150: System Analysis and Design

1

Questionnaires

Advantages :

Special purpose documents Allow the analysts to collect information and opinions from a large audience.

Relatively inexpensive way of gathering data.

Most questionnaires can be answered quicklyAllow individuals to maintain anonymity

Responses can be tabulated and analyzed

Fact Finding Techniques…

quickly etc.

Page 151: System Analysis and Design

2

Disadvantages:Questionnaires…

The number of respondents is often lowMostly suited for closed questionsNo guarantee that an individual will answer or

expand on all the questions

Good Questionnaires are difficult to prepare

No immediate opportunity to clarify a vague or incomplete answer to any question.

Fact Finding Techniques…

Page 152: System Analysis and Design

3

Fact Finding Techniques…

Questionnaires…

Types of Questionnaires

Free-format : A question is asked, and the respondent records the answer in the space provided after the question.

Fixed-format : contains questions that require specific responses from individuals

Page 153: System Analysis and Design

4

Fact Finding Techniques…

Questionnaires…There are 3 types of fixed-format questions

1. multiple-choice questions: Given several answers to select one. e.g. Yes, No type

2. rating questions: Given a statement and asked to use supplied responses to state an opinion.

3. ranking questions: Given several possible answers to be ranked in order of preference or experience

Refer Page 221-222 Ref1

Page 154: System Analysis and Design

5

Fact Finding Techniques…

Interviews– Most commonly used technique in analysis– Collects information from individuals face to face.– Must possess good human relations skills for

dealing effectively with different type of people

- Can be used to achieve any of the following goals:* find facts * get the end-user involved* verify facts * clarify facts* generate enthusiasm * identify requirements* solicit ideas and opinions.

Page 155: System Analysis and Design

6

Interviews…Advantages

Mot

ivat

ion

Fact Finding Techniques…

Gives the analyst an opportunity to motivate the interviewee to respond freely and openly to questions.Allow the analyst to look for more feedback from the interviewee.Permit the analyst to ask questions from each individual etc.New ideas may arise

Page 156: System Analysis and Design

7

Disadvantages

Very time consuming. Therefore costly approach

Success of interviews is highly dependent on the systems analyst’s human relations skill.

Interviews may be impractical due to the location of interviewees etc.

Interviews…

Fact Finding Techniques…

Page 157: System Analysis and Design

8

Types of InterviewsUnstructured interviews

conducted with only a general goal / subject in mind

contain only a few questions if any, specific ones

Interviewer counts on interviewee to provide a frame work and direct the conversation

Structured interviewsinterviewer has a specific set of questions to ask of

the interviewee

Interviews…

Fact Finding Techniques…

Page 158: System Analysis and Design

9

Fact Finding Techniques…

Interviews…

Types of Interview Questions

• Open-ended questions– Allows the interviewee to respond in any way

that seems appropriate

• Closed-ended questions – Restrict answers to either specific choices or

short, direct responses

Page 159: System Analysis and Design

1

Fact Finding Techniques…

How to conduct an Interview?Select Interviewees

Interview the end users of the information system you are studying.

A formal organizational chart will help you identify these individuals and their responsibilities.

Always make an appointment with the interviewee.

Higher the management level of the interviewees, less time should be spent.

Interviews…

Page 160: System Analysis and Design

2

Interviews…

Fact Finding Techniques…

Prepare for the InterviewPrepare an interview guide - checklist of specific questions interviewer will ask the intervieweeAvoid the type of questions such as:

Loaded questions e.g Do you need to include both of these columns for this report?

Leading questions e.g. You are not going to use this operator code, are you?

Biased questions e.g. How many codes do we need for food classification in the inventory file? I think 20 should cover it ?

How to conduct an Interview?

Page 161: System Analysis and Design

3

Fact Finding Techniques…

Interview question guidelines :Use clear and concise languageDon’t include your opinion as part of a questionAvoid long or complex questionsAvoid threatening questionsverify before you leave

The purpose of the interview is to investigate, not to evaluate or criticize

Prepare for the InterviewHow to conduct an Interview?

Interviews…

Page 162: System Analysis and Design

4

Fact Finding Techniques…

The actual interview consist of three phases:Conduct the Interview

How to conduct an Interview?Interviews…

Interview Opening : Intended to influence or motivate the interviewee to participate

Interview body : Obtain interviewee’s response to your list of questions

Interview conclusion : Express your appreciation. Important for maintaining good relationship and trust.

Page 163: System Analysis and Design

5

Fact Finding Techniques…

Prototyping

– Building a small working model of the users’requirements or a proposed design for an information system

– Usually a design technique

– Can also be used to perform fact-finding requirement analysis (discovery prototyping)

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

Page 164: System Analysis and Design

6

Fact Finding Techniques…

Prototyping…Analyst will

develop a model

following an initialanalysis

A repeat visit may thenvalidate

the model with the user

Agreement is reached

on the model

Further detailed

data may be gathered to elaborate the model

Page 165: System Analysis and Design

7

Fact Finding Techniques…

Prototyping…

This iterative approach serves a number of purposes:

there is always a record of information gathered to date ensures correctness of the information as you continually verify the results with the userAnalyst does not get too far ahead using wrong assumptions

Page 166: System Analysis and Design

8

Fact Finding Techniques…

Prototyping…

AdvantagesAllow users and developers to experiment with the

software and develop with an understanding

Helps to determine feasibility and usefulness of the system

Minimize the time spent for fact-finding and help define more stable requirements.

Page 167: System Analysis and Design

9

Fact Finding Techniques…

Prototyping…

DisadvantagesDeveloper may need to be trained in the

prototyping approach

Prototype can only simulate system functionality and are incomplete in nature.

May extend the development schedule

Increase the development costs

Page 168: System Analysis and Design

10

Highly structured group meeting are conducted to analyze problems and define requirements.

JRP is a subset of a more comprehensive joint application development or JAD technique

Joint Requirement Planning (JRP)

Fact Finding Techniques…

Page 169: System Analysis and Design

11

Joint Requirement Planning (JRP)

Fact Finding Techniques…

JRP ParticipantsSponsorServe as JRP champion. Single person in top

management who makes the final decision

Facilitator Single individual who plays the role of the leader or

facilitator. Someone who has excellent communication skills

Page 170: System Analysis and Design

12

Fact Finding Techniques…

Joint Requirement Planning (JRP)…

JRP Participants…Users and ManagersNumber of participants from the user and management.

Both users and managers are relied on to ensure that their critical success factors are being addressed

Scribes Those who are keeping responsible for keeping records

pertaining to everything discussed in the meeting. System analysts frequently play this role

Page 171: System Analysis and Design

13

Fact Finding Techniques…

Joint Requirement Planning (JRP)…

JRP Participants…IT Staff

IT personnel who primarily listen and take notes regarding issues and requirements. Usually consists of members of the project team.

Refer page 229-234 Ref1

Page 172: System Analysis and Design

14

Fact Finding Techniques…

Document Flow Diagrams– Used to identify physical movement of

documents.

Purchase Order

….…..

PurchPurch..Dept.Dept.

SupplierSupplier

Page 173: System Analysis and Design

15

Fact Finding Techniques…

Document Flow Diagrams…

– shows • where the document comes from, • where it goes to , and • what it is called.

Purchase Order

….…..

PurchPurch..Dept.Dept.

SupplierSupplier

Page 174: System Analysis and Design

16

Fact Finding Techniques…

Document Flow Diagrams…

Used to examine the flow of documents within the existing system.

Example:Purchasing Purchasing

SystemSystem

OrderInvoiceDelivery note

Delive

ry no

te

SupplierSupplier

PurchPurch..Dept.Dept.

StoresStores

Page 175: System Analysis and Design

17

Fact Finding Techniques…

System boundary

Order

InvoiceDelivery note

Delive

ry note

SupplierSupplier PurchPurch..Dept.Dept.

StoresStores

Document Flow Diagrams…

Example:Purchasing SystemPurchasing System

Page 176: System Analysis and Design

18

Fact Finding Techniques…

System boundary

Order

InvoiceDelivery note

Delive

ry note

SupplierSupplier PurchPurch..Dept.Dept.

StoresStores

Document Flow Diagrams…

Example:Purchasing SystemPurchasing System

MaintenanceMaintenance

Page 177: System Analysis and Design

19

Fact Finding Techniques…

Document Flow Diagrams…

Advantages / Usefulness

Used to identify the documents in the systemIdentify the flow of documents To understand the workflow of the existing system Used to define the system boundary Used to draw Data Flow Diagrams after further analyzing

Page 178: System Analysis and Design

20

Documentation

Documentation is both a communication tool and a management tool.

It is a communication tool :– because it contains a repository of all work done to date and

makes it available to all persons working on related parts of a large project.

– Such a repository can prevent unnecessary repetitions when someone leaves the project team.

– Proper documentation ensures that all the information developed about the system is always available to new people joining the project.

Page 179: System Analysis and Design

21

Documentation…

Documentation is also a management tool:

It supports management in two ways:

– gives access to the latest work to all project personnel and thus reduces the chance of work having to be repeated.

– is the only project deliverable, specially in the early project phases, and thus serves to determine project status and progress. Is also a part of the phase output.

Page 180: System Analysis and Design

22

Documentation…

• Requirement Definition Document

– A formal document that communicates the requirements of a proposed system to key stakeholders

– Serves as a contract for the systems project

– Final deliverable of the requirements analysis phase

– Also known as requirements statement, requirements specification, and functional specification.

Page 181: System Analysis and Design

23

Documentation…

• Requirement Definition Document

– Consists of • Functions and services the system should provide• Nonfunctional requirements (system’s features,

characteristics, and attributes)• Constraints• Information about other systems with which the system must

interface– No standard format for the document

Refer page 214 Ref1 Figure 6-2 (Sample Requirements Definition Outline)

Page 182: System Analysis and Design

24

Documentation…

• Requirement Definition Document

– Readers of the document

• System Owners and Users (to specify their requirements and any changes that may arise)

• Managers (to prepare project plans and estimates)

• Developers (to understand what is required and to develop tests to validate the system)

Page 183: System Analysis and Design

1

Modeling Methods

How to simplify, present / document a complex

problem?

The answer is just Simple, use MODELS

Model : A pictorial representation of reality.

SAMPLE FLOOR PLAN

Page 184: System Analysis and Design

2

Process Modeling

Introduction

– Technique for organizing and documenting the structure and flow of data through a system’s process and the logic, policies, and procedures to be implemented by a system’s process.

– Consists of various types of process models.

Page 185: System Analysis and Design

3

Models

Logical Models Physical Models

Process Modeling

Other names: ~Essential model~Conceptual model ~Business model

Other names: ~ Implementation Model~ Technical model

Page 186: System Analysis and Design

4

Logical Process Models• Show what a system is or does.• Implementation – independent

– depict the system independent of any technical dependence

• Illustrates the essence of the system• Used to Depict business and non technical

requirements• Used to document system’s Process focus from the

systems owners’ and users’ perspective• Encourage creativity• Reduce the risk of missing business requirements• Allows better communication with end-users in non-

technical / less technical languages.

Page 187: System Analysis and Design

5

Physical Process Models

• Show not only what a system is or does. But also how the system is physically and technically implemented.

• Implementation –dependent

• Reflect technology choices and the limitations of those technology choices

• Used to Depict technical designs

Page 188: System Analysis and Design

6

Program Structure ChartsLogic Flow ChartsDecision Tables, are some

examples for various types of process models found in early software engineering methods and programming.

Data Flow Diagram : Popular System Analysis Process Model.

Process Modeling

Page 189: System Analysis and Design

7

Data Flow Diagrams

• Shows the flow of data through the system and the processing performed by the system

• Other words : bubble chart, transformation graph, and process model

• Some analysts draw a decomposition diagram before DFD

• There exist several competing symbol sets for DFDs.– Gane and Sarson notation is widely popular

Page 190: System Analysis and Design

8

Elements in a DFD(Gane and Sarson Symbols)

SupplierSupplierPurchasingSystem

An External AgentA Process

OrdersOrders

A Data Store

Invoice

A Data Flow

Page 191: System Analysis and Design

9

Elements in a DFD(Gane and Sarson Symbols)

- A Process is work performed by a system In response to incoming data flows or conditions and it transforms incoming data flow into outgoing data flow.

A Synonym is transform

Process name

A Processes orWork to be done

Represented by a rounded rectangle

Page 192: System Analysis and Design

10

Elements in a DFD(Gane and Sarson Symbols)

Represented by a square

An external agent is an outside person (e.g. supplier, customer), organization unit (e.g. other dept), system (other business systems), or organization (e.g. Bank) that interact with the system. Also called an external entity.

External External AgentAgent

An External Agent

Page 193: System Analysis and Design

11

Elements in a DFD(Gane and Sarson Symbols)

Represented by a square

External AgentsProvide the net inputs

into the system and receive net outputs from the system being defined.

Externalexternal to the system

being analyzed or designed.

External External AgentAgent

An External Agent

Page 194: System Analysis and Design

12

Elements in a DFD(Gane and Sarson Symbols)

Data storeData store A Data Store is an “inventory” of data. That is, stored data intended for later use (data at rest). Also known as a file or database.

A Data Store

Represented by the open-end box

Page 195: System Analysis and Design

13

Elements in a DFD(Gane and Sarson Symbols)

A Data Store

• Data stores should describe “things” about which the business wants to store data.

• These includePersons: Customer, EmployeePlaces: Building, Room, CampusObjects: Book, Machine, ProductEvents: Invoice, Order, Registration, RenewalConcepts: Course, Fund, Stock

Page 196: System Analysis and Design

14

Elements in a DFD(Gane and Sarson Symbols)

Data flow name

A Data Flow

• Represent inputs or outputs, to or from the processes.• The arrow head indicates the direction of data flow. • Label the arrows with the name of the data that moves through it.• Data in motion

Represented by an arrow

Page 197: System Analysis and Design

15

The Context Data Flow Diagrams

• A diagram that shows the system as a “black box”and its main interfaces with its environment.

• Used to document the scope of the system

• Also known as environmental model.

ProcessProcess

External External AgentAgent

External External AgentAgent

External External AgentAgent

External External AgentAgent

Page 198: System Analysis and Design

16

The Context Data Flow Diagrams

• Used to clarify and agree the scope of the investigation

• Shows the interfaces between the system under investigation and the external agents with which it communicates

• Subject to constant change – Because the scope of any project is always

subject to change

Page 199: System Analysis and Design

17

The Context Data Flow Diagrams

• Can be drawn without considering the Document Flow Diagram

• Need to identify – the data flows and – the external agents needed for the context

diagram

Page 200: System Analysis and Design

18

The Context Data Flow Diagrams• Think the system as a container• Distinguish the inside from the outside• Ignore the inner workings of the container• Find out the net inputs to the system

– Business transactions a system must respond to

• For each net input determine its source (External Agents)• Find out the net outputs from the system

– Responses produced by the system

• For each net output find the destination (External Agents)• Identify any external data stores,

– Files or databases of other systems

Page 201: System Analysis and Design

19

Task 1

Identify all sources and recipients of data to/from the system.

Page 202: System Analysis and Design

20

Task 2

• Identify major data flows to and from the System

Page 203: System Analysis and Design

21

Task 3

• Convert each source or recipient into external agents

SupplierSupplier

Page 204: System Analysis and Design

22

Task 4

• Add the data flows between each external agent and the process representing the entire system.

PurchasingSystem

OrderSupplierSupplier

Invoice

Delivery note

Page 205: System Analysis and Design

23

Data Flow Diagrams

• Draw Context Diagram• Level 0 (Top Level) Data Flow Diagram• Level 1 Data Flow Diagram• Continue up to elementary functions

Page 206: System Analysis and Design

24

Bank Payment System

Consider a system in a bank whereby account holders get their withdrawals effected.

Whenever an account holder wants to withdraw some cash, he presents a cheque or withdrawal slip.

The account is checked for the appropriate balance.

If balance exists, the cash is paid and the account is updated.

Page 207: System Analysis and Design

25

Context Diagram

Withdrawal Acknowledgement

Cheque/Withdrawal Slip

BankBankPaymentPaymentSystemSystem

AccountAccountHolderHolder

Page 208: System Analysis and Design

26

Decomposition

• Is the act of breaking a system into its component subsystems , processes and sub processes.

• Top level function is then decomposed to its component functions

Page 209: System Analysis and Design

27

Is an act of breaking a system into its component subsystems, processes, and sub processes.

Process Decomposition

0UCSC System

1Payroll sub system

2Registration sub System

1.1Process

2.1Process

1.2Process

2.2Process

1.1.1Sub Process

1.1.2Sub Process

1.1.1.1

1.1.1.2

Decomposition

Diagram

Page 210: System Analysis and Design

28

Context Diagram

Withdrawal Acknowledgement

Cheque/Withdrawal Slip

BankBankPaymentPaymentSystemSystem

AccountAccountHolderHolder

Page 211: System Analysis and Design

29

Top Level DFD – Step 1

Withdrawal Acknowledgement

Cheque/Withdrawal Slip

VerifyA/C

Balance

Debit Withdrawal

AccountAccountHolderHolder

Page 212: System Analysis and Design

30

Top Level DFD – Step 2

Withdrawal Acknowledgement

VerifyA/C

Balance

Debit Withdrawal

AccountAccountHolderHolder

Cheque/Withdrawal Slip

Page 213: System Analysis and Design

31

Top Level DFD – Step 3

• Identify the Data Stores

Account MasterAccount Master

Page 214: System Analysis and Design

32

Top Level DFD – Step 4

• Identify the other data flows.Get current balance

Account MasterVerifyA/C

Balance

Current Balance

Page 215: System Analysis and Design

33

Top Level DFD – Step 4

• Identify the other data flows.Transfer the verified details

Debit Withdrawal

VerifyA/C

Balance

Verified details

Page 216: System Analysis and Design

34

Top Level DFD – Step 4

• Identify the other data flows.update new balance

Debit Withdrawal

Account Master New Balance

Page 217: System Analysis and Design

35

Cheque/Withdrawal Slip

Verified DetailsCurrent

BalanceNewBalance

Account MasterAccount Master

1VerifyA/C

Balance

2Debit

Withdrawal

With

draw

al

Ack

now

ledg

emen

t

AccountAccountHolderHolder

AccountAccountHolderHolder

Top Level Diagram

Page 218: System Analysis and Design

36

Illegal Data Flows

E1 E2

D1E1

E1

A process is A process is needed toneeded to

Exchange dataExchange dataFlows betweenFlows between

ExternalExternalagentsagents

E2

D1E1A process is A process is needed to needed to

Update / useUpdate / useA dataA datastorestore

Illegal data flowsIllegal data flows Corrected data flowsCorrected data flows

Page 219: System Analysis and Design

37

Illegal Data Flows

D2D1

D1 E1

A process is A process is needed toneeded to

present datapresent dataFrom a From a

data storedata store

D1 E1

Illegal data flowsIllegal data flows Corrected data flowsCorrected data flows

A process is A process is needed toneeded tomove datamove dataFrom one From one Store to Store to anotheranother

D2D1

Page 220: System Analysis and Design

38

Another Common error

Process 1

No data flow should ever go unnamed

Page 221: System Analysis and Design

1

CASE STUDYLibrary System

Page 222: System Analysis and Design

2

Library SystemLibrary supports

– Lending – Cataloging – Registration of Members

and Books– Reservation– Inquiries– Correspondence

All activities are done manually

Page 223: System Analysis and Design

3

Library SystemTo Analyze and Design a Library System

– What are the Documents in the system?

– Study the physical movements of documents

Page 224: System Analysis and Design

4

Library System

• Documents in the system

– Application form– Student Id– Membership card– Reminders– Borrowing slips etc.– Reservation ready notice

Page 225: System Analysis and Design

5

Library System

• Identify the physical movements of documents.– Document Flow Diagram

• Modeling method or technique used to illustrate movements of documents.

Membership application

….…..

StudentStudentLibrarianLibrarian

Page 226: System Analysis and Design

6

Converting Document Flow Diagrams to DFDs

• What process generates this document flow?• What process receives this document ?• Is the document stored by a process?• Where is the document stored?• Is the document created from stored data?

Page 227: System Analysis and Design

7

Document Flow Diagrams for the Library System

New memberdetails

System boundary

Mem

ber cardM

em. Card+slip Fine SlipReminder

Stud

ent r

egis

trat

ion

form

Stud

ent c

ard

MemberMember

Admin.Admin.LibraryLibrary

Settle fin

e

StudentStudent

MemberMember

Page 229: System Analysis and Design

9

LibrarySystem

New

member

Details

Member card

Mem. Card+slipRem

inder

Fine

Slip

Settle

fineMemberMember

MemberMember

Admin.Admin.

Context Diagram

Page 230: System Analysis and Design

10

New member

Details

Member cardMem. Card+slip

Reminder

Fine S

lip

Settle

fine

Lending Returning

MemberRegistration Library

System

MemberMember

MemberMember

Admin.Admin.

Top Level Diagram

Page 231: System Analysis and Design

11

Top Level Diagram

New member Details

Mem

ber card

Mem. Card+slipReminder

Fine SlipSettle fine

Lending

ReturningMember

Registration

MemberMember

Admin.Admin.

MemberMember

Page 232: System Analysis and Design

12

Mem. Registration

Borrowing Details

Data Stores

Book Details

Page 233: System Analysis and Design

13

Top Level Diagram

Mem

ber

card

Mem. Card+slip

ReminderFine Slip

Settle fine

Lending

Returning

MemberRegistration

Mem. Registration Book Details

Borrowing Details

MemberMember

Admin.Admin.

New member details

member details

Book details

Borrowing details

return details Book details

New member Details

Page 234: System Analysis and Design

14

Documenting Elements in DFD

• Element name is not enough.• More important for processes

You need to convert these into programs

A(int w){

a=a-w;

}

Debit Withdrawal

Page 235: System Analysis and Design

15

The Functional Decomposition Diagram

• Shows the top-down functional decomposition / the structure of the system

• Break the system into its component subsystems , processes and sub processes

• Top level function is then decomposed to its component functions

• Provides an outline for drawing the data flow diagrams

Page 236: System Analysis and Design

16

The Functional Decomposition Diagram

The SystemThe System

The SystemThe System

Function1Function1 Function2Function2 Function nFunction n

Event1Event1 Event2Event2 Event3Event3 Event4Event4 Event5Event5 Event nEvent n--11 Event nEvent n

Context Context diagramdiagram

Decomposition Decomposition diagramdiagram

Page 237: System Analysis and Design

17

Event Diagram

• A data flow diagram that depicts the context for a single event

• Shows the inputs, outputs, and data store interactions for the event.

• Users are not overwhelmed by the overall size of the system

• A powerful communication tool between users and technical professionals

Page 238: System Analysis and Design

18

The SystemThe System

Function1Function1 Function2Function2 Function nFunction n

Event1Event1 Event2Event2 Event3Event3 Event4Event4 Event5Event5 Event nEvent n--11 Event nEvent n

Event1Event1 Event5Event5 EventnEventn

Decomposition Decomposition diagramdiagram

Event diagramsEvent diagrams

Event Diagram

Page 239: System Analysis and Design

19

Event Diagram• For each event, illustrate the following

– The inputs and their sources• Sources are shown as external agents• The data structure for each input should be recorded in

the repository– The outputs and their destination

• Destinations are depicted as external agents• The data structure for each output should be recorded

in the repository– Any data stores from which records must be

read– Any data stores from which records must be

created, deleted, or updated

Page 240: System Analysis and Design

20

Process Descriptions

• Structured English• Decision Table• Decision Tree

Eg. A Process that has to determine whether a customer is to be given credit

Page 241: System Analysis and Design

21

Structured English

• A language and syntax, based on the relative strengths of structured programming and natural English, for specifying the underlying logic of elementary processes on process models.

Page 242: System Analysis and Design

22

Structured English

IFIF credit limit exceededTHENTHEN

IFIF Customer has bad payment historyTHENTHEN refuse creditELSEELSE

IFIF purchase above Rs.10000/=THENTHEN refuse creditELSEELSE refer to manager

ELSEELSE allow credit

Page 243: System Analysis and Design

23

Credit limit exceeded

Credit limit not exceeded Allow credit

Bad payment history

Refuse credit

Good payment History

Purchase below Rs.10000/=

Purchase above Rs10000/= Refuse credit

Refer to Manager

A graph or model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility.

Decision Tree

Page 244: System Analysis and Design

24

Decision Table

• A tabular form of representation that specifies a set of conditions and their corresponding actions

• Very useful for specifying complex policies and decision making rules

Page 245: System Analysis and Design

25

Cond

ition

Actio

nY-TRUE N-NOT TRUE X-TAKE ACTION

Decision Table

Credit limit exceeded Y Y Y Y N N N

Y N

Y

X

N

X

N

Y N

N

X X

XX

X

Refuse X

Refer Manager

Y

N

N

N

Y

Y

N

Good payment history Y

Purchase above Rs.10000/=

Y

Allow Credit

Page 246: System Analysis and Design

1

Data Modeling

• A technique for defining business requirements for a database

• Also known as database modeling• There are several notations• Actual model is called an ERD – Entity Relationship

Diagram

– Shows data in terms of the entities and relationships described by the data.

– There exist several notations for an ERD– Martin notation is widely used.

Page 247: System Analysis and Design

2

Data Modeling…

Entity Relationship DiagramsShows data in terms of the entities and relationships described by data.

Entities

An entity is something about which the business needs to store data.

Synonyms – entity type and entity class

Page 248: System Analysis and Design

3

Entity Relationship Diagrams…

Data Modeling…

Entity: is a class of

Persons(Customer,Employee)

Places(Building,Room)

Objects(Book,Product)

Events(Flight,Invoice)

Concepts(Account,Fund)

about which we need to capture and store data.

Page 249: System Analysis and Design

4

Entity Relationship Diagrams…

Data Modeling…

Entity Instance

An entity instance is a single occurrence of an entity. Every entity must have an identifier or key to uniquely identify each instance.

Page 250: System Analysis and Design

5

Entity Relationship Diagrams…

Data Modeling…

Symbol:Consider Martin notations.

DEPARTMENTEMPLOYEE

The named rounded rectangle represent the entity. –A line represent the relationship. –

Page 251: System Analysis and Design

6

Entity Relationship Diagrams…

Data Modeling…

Attribute:is a descriptive property or characteristics

of an entity. Sometimes called as element, property, or field.

Page 252: System Analysis and Design

7

Entity Relationship Diagrams…

Data Modeling…

A key is an attribute, or group of attributes that assumes a unique value for each entity instance. It is sometimes called an identifier.

EMPLOYEENIC_NOName

Address Age …. …. …. This person can be

identified using his ID number.

Page 253: System Analysis and Design

8

Entity Relationship Diagrams…

Data Modeling…

Compound Attribute is one that actually consist of other attributes.

Synonyms- composite attribute, concatenated attribute

Example : Street Address Postal Code

CountryCity

Student name Last NameLast Name

First NameFirst NameMiddle NameMiddle Name

Address

Page 254: System Analysis and Design

9

Entity Relationship Diagrams…

Data Modeling…

The values for each attribute are defined in terms of three properties:

1. Data type – What type of data can be stored in that attribute (Number, Date, Text etc).

2. Domain – What values an attribute can legitimately take on.

Refer to table 8-2 in pg 273 Ref1

3. Default – Is the value that will be recorded if not specified by the user.

Page 255: System Analysis and Design

10

Entity Relationship Diagrams…

Data Modeling…

Relationships

Natural business association that exists between one or more entities

E.g.. A Current Student is enrolled in one or more curricula

STUDENTSTUDENT CURRICULACURRICULAis enrolled inis enrolled in

Page 256: System Analysis and Design

11

Entity Relationship Diagrams…

Data Modeling…

CardinalityDefines the minimum and maximum number of occurrences of one entity that may be related to a single occurrences of the other entity.

or

Exactly one

Page 257: System Analysis and Design

12

Entity Relationship Diagrams…

Data Modeling…

Cardinality

I might be married or not…

Zero or one

I may have one, some friends or

none…

Zero, one or more

Page 259: System Analysis and Design

14

Entity Relationship Diagrams…

Data Modeling…

DegreeNumber of entities that participate in the relationship

Degree =1

Recursive Relationship – Relationship that exists between different instances of the same entity.

EMPLOYEESupervise

Page 260: System Analysis and Design

15

Entity Relationship Diagrams…

Data Modeling…

Degree…

Degree =2

Binary Relationship - When two different entities participates in a relationship

DEPARTMENTWorksEMPLOYEE

Page 261: System Analysis and Design

16

Degree =3

Ternary or 3-ary Relationship -

When more than two different entities participates in a relationship.

Degree… PROJECT EMPLOYEE

LOCATION

ASSIGNMENT

requiresrequires Is givenIs given

offersoffers

Entity Relationship Diagrams…

Data Modeling…

Page 262: System Analysis and Design

17

Synchronization of System Models

• Data and process models represent different views of the same system

• These views are interrelated

• Thus, modelers need to synchronize the different views to ensure consistency and the completeness of the total system specification.

Synchronization is the process of maintaining consistency between the different types of models

Page 263: System Analysis and Design

18

Object Modeling

• A technique for identifying objects within the systems environment and identifying the relationships between those objects.

• Object Modeling techniques prescribe the use of methodologies and diagramming notations that are completely different from the ones used for data modeling and process modeling.

Page 264: System Analysis and Design

19

Object Modeling Methods

• In the late 80s and early 90s– Booch Method – Grady Booch– Object Modeling Technique (OMT) – James Rumbaugh– Object-Oriented Software Engineering – Ivar Jacobson

• To avoid problems of having many different methods, In 1997,– Unified Modeling Language (UML) - Grady Booch,

James Rumbaugh, Ivar Jacobson

Page 265: System Analysis and Design

20

System Concepts for Object Modeling

• Objects– Something that is or is capable of being seen,

touched, or otherwise sensed and about which users store data and associate behavior

– Types of objects• Person – e.g. employee, customer, instructor, student • Place – e.g. warehouse, building, room, office• Thing – e.g. product, vehicle, computer, videotape• Event – e.g. an order, payment, invoice, application• Sensual – e.g. phone call, meeting

Page 266: System Analysis and Design

21

System Concepts for Object Modeling…

• Attributes– The data that represents characteristics of

interest about an objecte.g. Object : Customer

Attributes : Customer no, first name, last name, home address, work address, contact no,…etc.

Page 267: System Analysis and Design

22

System Concepts for Object Modeling…

• Object instance– Each specific person, place, thing, or event, as

well as the values for the attributes of that object.

– Sometimes referred to as an Object.– Drawn using a rectangle with the name of the

object instance– The name consists of the attribute that

uniquely identifies it, followed by a colon and then the name of the class in which the object has been categorized.

Page 268: System Analysis and Design

23

System Concepts for Object Modeling…

• Object instancee.g. A “CUSTOMER” Object Instance

001:Customer001:Customer

customerNocustomerNo =001=001lastNamelastName = = PereraPererafirstNamefirstName = Ann= AnnhomePhoneNohomePhoneNo = 0112123456= 0112123456city = Colombocity = Colombo

001:Customer001:CustomerOROR

Object name Object name is underlined is underlined and centeredand centered

Page 269: System Analysis and Design

24

System Concepts for Object Modeling…

• Behavior– The set of things that an object can do and that

correspond to functions that act on the object’s data or attributes.

– Also known as a method, operation or service

e.g. Object : Doorbehavior : open, shut, lock or unlock

Page 270: System Analysis and Design

25

System Concepts for Object Modeling…

• Encapsulation– Packaging of several items together into one unit

(both attributes and behavior of the object)

– The only way to access or change an object’s attribute is through that object’s specific behavior.

– Objects encapsulates what they do.• That is, they hide the inner workings of their operations

– from the outside world– and from other objects

Page 271: System Analysis and Design

26

System Concepts for Object Modeling…

EncapsulationWhen an object carries out its operations,

those operations are hidden.

The TV hides its operations

from the person

watching it.

E.g. When most people watch a television show, - they usually don’t know or care about the complex electronics that sit in back of the TV screen - or the operations that are happening.

Page 272: System Analysis and Design

27

System Concepts for Object Modeling…

Class name• Object class– A set of object instances

that share the same attributes and behaviors.

– Also referred to as a class.e.g. UML notation for the

object class ‘BOOK’

Attributes of the class

Book-ISBN

-title

-copyrightDate

-edition+open()

+close()

Behaviors

Page 273: System Analysis and Design

28

System Concepts for Object Modeling…

An Object instancee.g.

00--0909--341234341234--5 : Book5 : Book

ISBN = 0ISBN = 0--0909--341234341234--55title = Programming in C++title = Programming in C++copyrightDatecopyrightDate = 2006= 2006edition = 7thedition = 7th

00--0707--231539231539--3 : Book3 : Book

ISBN = 0ISBN = 0--0707--231539231539--33title = Systems Analysistitle = Systems AnalysiscopyrightDatecopyrightDate = 2001= 2001edition = 5thedition = 5th

Page 274: System Analysis and Design

29

System Concepts for Object Modeling…

• Inheritance– The concept wherein methods and/or attributes

defined in an object class can be inherited or reused by another object class.

e.g. some individuals in the room might be classified as STUDENTS and TEACHERS.

Thus, STUDENT and TEACHER object classes are members of the object class PERSON

Page 275: System Analysis and Design

30

System Concepts for Object Modeling…

Person ClassPerson Class

Student ClassStudent Class Teacher ClassTeacher Class

Student AStudent A Student BStudent B Teacher ATeacher A Teacher BTeacher B

• Inheritancee.g. Cont…

Page 276: System Analysis and Design

31

System Concepts for Object Modeling…

• Generalization / Specialization– A technique wherein the attributes and behaviors

that are common to several types of object classes are grouped / abstracted into their own class called a super type.

– The attributes and methods of the supertype object class are then inherited by those object classes (subtype)

– Sometimes abbreviated as gen/spec.

Page 277: System Analysis and Design

32

System Concepts for Object Modeling…

Specialization

Generalization StudentStudent

GPAGPAClassificationClassification

enrollenrolldisplayGPAdisplayGPA

firstNamefirstNamelastNamelastNamebirthdatebirthdategendergenderwalkwalkjumpjumptalktalksleepsleep

PersonPerson

firstNamefirstNamelastNamelastNamebirthdatebirthdategendergenderwalkwalkjumpjumptalktalksleepsleep

Inheritable Inheritable AttributesAttributes

And And behavior behavior

++TeacherTeacher

rankrank

lecturelecture

Page 278: System Analysis and Design

33

System Concepts for Object Modeling…

• Generalization / Specialization

StudentStudent

PersonPerson

TeacherTeacher

Vehicle

Bus Car Truck

* Specialized classes inherits from the parent class

Page 279: System Analysis and Design

34

System Concepts for Object Modeling…

• Object Class Relationships– A natural business association that exists

between one or more objects and classes

e.g. You interact with a text book by reading it,with a telephone by using it,

People interact with each other by communicating with them.

Page 280: System Analysis and Design

35

System Concepts for Object Modeling…

• Object / Class Association– When you turn on your TV, in object oriented

terms, you are in an association with your TV.

– An association is unidirectional (one way) or bi-directional (two way).

eg. is married to

– Some times an object might be associated with another in more than one way.

Gihan is a co-worker of DamithGihan is a friend of Damith

Page 281: System Analysis and Design

36

System Concepts for Object Modeling…

• Object / Class Associatione.g.

A CUSTOMER PLACES zero or more ORDERSAn ORDER IS PLACED BY one and only one CUSTOMER

CustomerCustomer OrderOrder0..*0..*PlacesPlaces

Represent the Represent the relationship relationship

between the classesbetween the classes

Page 282: System Analysis and Design

37

System Concepts for Object Modeling…

• Multiplicity– The minimum and maximum number of occurrences of

one object class for a single occurrence of the related object class.

e.g. Exactly one -> 1 or leave blank

Zero or 1 -> 0..1Zero or more -> 0..* or *1 or more -> 1..*Specific range -> 7..9

Refer Figure 10-5 pg 377 Ref1 for more details

Page 283: System Analysis and Design

38

System Concepts for Object Modeling…

• Aggregation– A relationship in which one larger “whole” class

contains one or more smaller “parts” classes. Conversely, a smaller “part” class is part of a “whole” larger class.

e.g. A club – a club is made up of several club membersA computer – a computer contains a case, CPU, motherboard, power supply …etc.

Page 284: System Analysis and Design

39

System Concepts for Object Modeling…

• Aggregationsome more examples…

0..* 0..*Glider Plane Engine

UML notation

Whole object Part ObjectsTeam Player0..* 12..18

Page 285: System Analysis and Design

40

System Concepts for Object Modeling…

• Composition– An aggregation relationship in which the

“whole” is responsible for the creation and destruction of its “parts”.

– If the “whole” were to die, the “part” would die with it.

– A stronger form of aggregation. • The relationship between club and club member

would not be composition, because members have a life out-side the club and can, belong to multiple clubs.

Page 286: System Analysis and Design

41

System Concepts for Object Modeling…

• Composition– Drawn with a filled diamond.

School Department1 1..*

Each “part” can belong to only one “whole”, therefore, multiplicity needs to be specified only one for the “part”

Components will live and die with the whole object

Page 287: System Analysis and Design

42

System Concepts for Object Modeling…

• Polymorphism– Literally meaning “many forms”, the concept that

different objects can respond to the same message in different ways.

e.g. Consider the WINDOW and DOOR objects

Behavior : Close“Slides downwards”

Behavior : Close“Swings shut”

Both have the common behaviorBut the way it has been carried

Out differs from one another

Page 288: System Analysis and Design

Systems Design

• Produces a design specification for the new system.• Also known as physical design.• Design inputs, outputs, files, databases and other

computer based components

DesignAnalysis

Page 289: System Analysis and Design

Systems analysis - emphasize on the business problem

Systems design - emphasize on the technical or implementation concerns of the system.

Task2

Task1

Systems Design…

Page 290: System Analysis and Design

– Modern structured design– Information engineering– Prototyping– JAD– RAD– Object-oriented design

Systems Design Approaches

Page 291: System Analysis and Design

Proc

ess A

Process A1

Process A2

Process A3

Process A4

Process A11

Process A12

Process A13

Modern Structured Design

-

• is a process-oriented technique for breaking up a large program into a hierarchy of modules

• result in a computer program that is easier to implement and maintain (change).

• synonyms are top-down program design and structured program Design.

Page 292: System Analysis and Design

-

• A system design technique that decomposes the system’s processes into manageable components / modules that have the following properties– Modules should be highly cohesive (each module

should accomplish one and only one function)– Modules should be loosely coupled (modules should

be minimally dependent on one another)– Modules should be adaptable (It should be easy to

incorporate changes)– Modules should be understandable

Modern Structured Design…

Page 293: System Analysis and Design

Structure Chart

• The software model derived from structured design

• It is derived by studying the flow of data through the program.

Modern Structured Design…

Page 294: System Analysis and Design

1.2.1Get Sales

Transaction

1.2Calculate

Sales Total

1.2.2Adds to

Total

1.2.3Output

Total

Sales

Transaction

SalesTransaction

SalesTotal

SalesTotal

Modern Structured Design…

Structure Chart

Page 295: System Analysis and Design

• Parameter Passing-The calling module passes a set of values to the called module and receives a set of values in return. These values are passed as parameter values

eg. A value of ‘sales transaction’ is passed from module Get Sales transaction to module Calculate Sales Total

Module Calculate Sales Total then passes the value of ‘sales transaction‘ to module Add to Total and get a value of ‘sales total’in return

The value of ‘sales total’ is then passed from module Calculate Sales Total to module output total

Modern Structured Design…

Structure Chart

Page 296: System Analysis and Design

• Execution SequenceBy convention, modules are executed from left to right in each level.Thus in the given example, module Get Sales Transaction is called before module Adds-To-Total. Module Output Total is the last module to be called.Certain conventions are also used to represent decisions and repetition.Decisions occur whenever a calling module has to decide to call only one of a number of modules.

Modern Structured Design…

Structure Chart

Page 297: System Analysis and Design

Decisions are modeled by a diamond symbol.

Payment

Cash Cheque

@ Payment pays either cash or Cheque

Or

Modern Structured Design…

Structure Chart

Page 298: System Analysis and Design

Repetition occurs when some modules are called repetitively by the calling module.

Repetition is modeled by a looping arrow

Modern Structured Design…

Structure Chart

Page 299: System Analysis and Design

Structure Chart is a technique used in ModernStructured Design

The objective of structured design is to produce a good design.

Modern Structured Design…

Page 300: System Analysis and Design

• Model driven and data centered, but PROCESS-sensitive technique for planning, analyzing, and designing information systems.

• Primary tool of information engineering is a data model diagram (ERD).

• Involves conducting a business area requirements analysis from which information system applications are carved out and prioritized.

Information Engineering (IE)

Page 301: System Analysis and Design

Prototyping:The prototyping approach is an iterative process

involving a close working relationship between the designer and the users.

Prototyping

Page 302: System Analysis and Design

Prototyping encourages and requires active end-user participation.Iteration and change are a natural consequence of systems development - that is end-users tend to change their minds. Prototyping endorses the philosophy that end-users will not know what they want until they see it.

Key Benefits:

Prototyping…

Page 303: System Analysis and Design

Prototypes are an active, model that end-users can see, touch, feel, and experience.An approved prototype is a working equivalent to a paper design specification, with one exception --errors can be detected much earlier.Prototyping can increase creativity because it allows for quicker user feedback, which can lead to better solutions.Prototyping accelerates several phases of the life cycle, possibly bypassing the programmer.

Key Benefits:

Prototyping…

Page 304: System Analysis and Design

Prototyping encourages ill-advised shortcuts through the life cycle.

Disadvantages:

Prototyping…

Page 305: System Analysis and Design

JAD emphasize participative developmentamong system owners, users,designers, and builders.

JAD

Joint Application Development (JAD)

Page 306: System Analysis and Design

JAD sessions for systems design,systems designer - role of facilitator

for possibly several full-day workshops intended to address different design issues and deliverables.

Joint Application Development (JAD)…

Page 307: System Analysis and Design

Rapid Application Development (RAD)

RAD is the merger of various structured techniques (especially the data-driven information engineering) with prototyping techniques and joint application development techniques to accelerate systems development.

Page 308: System Analysis and Design

RAD calls for the interactive use of structured and prototyping to define the users’ requirements and design the final system.

Using structured techniques, the developer first builds the preliminary data and process models of the business requirements.

Prototypes then help the analyst and users to verify those requirements and to formally refine the data and process models.

Rapid Application Development (RAD)…

Page 309: System Analysis and Design

Object Oriented Design (OOD)

• The newest design strategy

• Used to refine the object requirements definitions identified earlier during analysis and to define design-specific objects

– e.g. based on a design implementation decision, during OOD the designer may need to revise the data or process characteristics for an object that was defined during systems analysis

Page 310: System Analysis and Design

System Design Tasks

• Design the Application Architecture• Design the System Database (s)• Design the System Interface• Package Design Specifications• Update the Project Plan

Page 311: System Analysis and Design

An application architecture defines the technologies to be used by (and used to build) one, more, or all information systems in terms of its data, process, interface and how these components interact across a network.

It serves as an outline or blueprint for detailed design and implementation.

Primary tool : Physical data flow diagram

Application Architecture

Application Architecture and Modeling

Page 312: System Analysis and Design

• Model the technical and human decisions to be implemented as part of an information system.

• They communicate technical choices and other design decisions to those who will actually construct and implement the system.

ID (optional)

Implementation

Action verb +

Noun or Object Phrase

Process

Physical Data Flow Diagrams (PDFD)

Page 313: System Analysis and Design

A physical process is either a processor, such as a computer or person, or a technical implementation of specific work to be performed, such as a computer program or manual process.

Physical Process

Physical Data Flow Diagrams (PDFD)…

Page 314: System Analysis and Design

# Logical processes may be assigned to physical processors such as PCs, servers, mainframes, people, or devices in a network. A physical DFD would model that network structure.

# Each logical process must be implemented as one or more physical processes as some logical processes must be split into multiple physical processes.

Characteristics of Physical DFDs

Physical Data Flow Diagrams (PDFD)…

Page 315: System Analysis and Design

• Represents any of the following:– Planned implementation of an input to / output from

a physical process.– A database command or action (create, read,

update, or delete)– Import of data from or the export of data to another

information system across a network.– Flow of data between two modules within the same

program.

Physical Data Flows

Physical Data Flow Diagrams (PDFD)…

Page 316: System Analysis and Design

Implementation method:Data flow name

Data flow name(Implementation method)

Physical Data Flow Representation

ORRefer Figure 13-2 pg 482 Ref1 to learn how to apply one of these naming conventions in physical DFDs

Physical Data Flows…

PRINTOUT:Salary Equity Report

eg.

Physical Data Flow Diagrams (PDFD)…

Page 317: System Analysis and Design

• No change from logical DFD to Physical DFD.

– External agents were classified during systems analysis as outside the scope of the systems and therefore, not subject to change.

– Only a change in requirements can initiate a change in external agents

Physical External Agents

Physical Data Flow Diagrams (PDFD)…

Page 318: System Analysis and Design

• Represents the implementation of one of the following:– A database– A table in a database– A file (computer/non computerized)– A tape / Media backup of anything important– Temporary file needed by a program (e.g. Tax

Tables)

Physical Data Stores

Physical Data Flow Diagrams (PDFD)…

Page 319: System Analysis and Design

Representation of physical data stores

ID(opt)

Implementation Method : Data Store Name

ID(opt)

Data Store Name(Implementation Method)

OR

Physical Data Stores

Physical Data Flow Diagrams (PDFD)…

Page 320: System Analysis and Design

Purchase OrdersPurchase Orders

MS Access:MS Access:Purchase OrdersPurchase Orders

Logical Data store

Physical Data store

Implementation : A table in a database

Physical Data Stores

Physical Data Flow Diagrams (PDFD)…

Page 321: System Analysis and Design

• Databases are a shared resource.• A database should be adaptable to future

requirements and expansion.• Issues to be addressed during database design

include– how programs will access the data – Programming data structures and their impact on

performance and flexibility– Internal controls to ensure proper security and disaster

recovery technique, in case data is lost or destroyed. – Record size and storage volume requirement.

Design the System Database

Page 322: System Analysis and Design

• Purpose is to prepare technical design specification for the database.

• Participants– Systems analyst – participate in database modeling– System designers – complete the database design– Data administrator – recognize that the new system most

likely use s some portion of an existing database– System builders – build a prototype database for the

project• Inputs : The application architecture and

Distributed analysis decisions• Output / deliverable : Database schema

Design the System Database…

Page 323: System Analysis and Design

– Designer can work closely with system user to develop input, output and dialogue specifications.

– The precise format and layout of the outputs must be specified.

– Internal controllers must be specified to ensure that the outputs are not lost, misrouted, misused, or incomplete.

– the data capture methods for the inputs should be designed.

– Editing controllers must be designed to ensure the accuracy of input data.

Design the System Interface

Page 324: System Analysis and Design

– For dialogue design the designer must consider • Terminal familiarity• Possible errors and misunderstandings that the end

user may have or may encounter• The need for additional instructions or help at certain

points• The screen content and layout

– Participants• System users • System designers• System builders

Design the System Interface…

Page 325: System Analysis and Design

– Package all the specifications from the previous design tasks into a set of specifications.

– Guide the computer programmers activities.

– Inputs : database, input, and output specifications

Package Design Specifications

Page 326: System Analysis and Design

• Reevaluate project feasibility & update project plan

• Project manager facilitates the task

• Analysts and owners should consider the possibility that, based on the completed design work, the overall project schedule, cost estimates, and other estimates may need to be adjusted.

• The deliverable : updated project plan– Should include a detailed plan for the construction phase

that should follow.

Update the Project Plan

Page 327: System Analysis and Design

• System analysts must continuously read popular trade journals to stay abreast of the latest technologies and techniques that will keep their customers and their information systems competitive.

• The information system framework provides one suitable framework for understanding IT architecture.

• Today information systems are – no longer monolithic, mainframe computer based

systems.– Built on some combination of networks (Distributed)

Information Technology Architecture

Page 328: System Analysis and Design

• All the components are hosted by a central, multi user system

• User interact with the host computer via terminals• All of the actual processing and work is done on the host

computer

Centralized Systems

I have all system data

I am doing all processing

Provide interfaces

Databases

Page 329: System Analysis and Design

• Components are distributed across multiple locations and computer networks

• Processing work load required to support these components are distributed across multiple computers on the net work.

• More complicated and more difficult to implement than centralized systems

Distributed Systems

Page 330: System Analysis and Design

• Why use distributed systems?– Modern businesses are already distributed– Distributed computing moves information and

services closer to the customers– Consolidates the incredible power– More user friendly as they use the PC as the user

interface processor– PCs and network servers are much less expensive

than mainframes

Thus, there is a big trend towards distributed systems.

Distributed Systems…

Page 331: System Analysis and Design

• Disadvantages– Network data traffic can cause congestion

that actually slows performance.– Higher security risk due to more possible

access points for intruders and possible communication with insecure systems.

Many centralized, legacy systems are gradually being transformed into distributed information systems

Distributed Systems…

Page 332: System Analysis and Design

• Presentation layer – actual user interface which presents inputs and outputs to the user

• Presentation logic layer – any processing that must be done to generate the presentation. e.g. editing input data, formatting output data

• Application logic layer– all the logic and processing required to support the actual business application and rules. e.g. credit checking, calculations, data analysis

• Data manipulation layer – commands and logic required to store and retrieve data to and from the database

• Data layer – the actual stored data in the in a database

Architecture Layers

Distributed Systems…

Page 333: System Analysis and Design

• There are three types of distributed system architectures– File server architecture– Client server architecture– Internet based architecture

Distributed Systems…

Page 334: System Analysis and Design

Stored on the File Server

Executed on the Client

Executed on the Client

Executed on the Client

Displayed on the Client

PRESENTATIONLAYER

PRESENTATIONLOGIC LAYER

APPLICATIONLOGIC LAYER

DATA MANIPULATION

LAYER

DATA LAYER

FILE SERVER

SOLUTION

Distributed Systems…

Page 335: System Analysis and Design

File server Architecture– A LAN (Local area network) based solution

• LAN is a set of client computers connected over a relatively short distance to one or more servers

– A server computer hosts only the data layer– All other layers are implemented on the client

PC.– Practical only for small database applications

shared by relatively few users

Distributed Systems…

Page 336: System Analysis and Design

Disadvantages– Large amount of unnecessary data must be

moved between the client and the server– Reduce network and application performance– The client PC must be robust.– Data base integrity can be easily compromised

File server Architecture…

Distributed Systems…

Page 337: System Analysis and Design

Stored on the Database Server

Executed on the Database Server

Executed on the Server

Displayed on the Client

PRESENTATIONLAYER

PRESENTATIONLOGIC LAYER

APPLICATIONLOGIC LAYER

DATA MANIPULATION

LAYER

DATA LAYER

Executed on the Client

Stored on the Database Server

Executed on the Database Server

Executed on the Client

Displayed on the Client

Executed on the Client

Stored on the Database Server

Executed on the Database Server

Executed on the Application Server

Displayed on the Client

Executed on the Client

DISTRIBUTED PRESENTATION

(2 TIER)

DISTRIBUTED DATA

(2 TIER)

DISTRIBUTED DATA &

APPLICATION(2 TIER)

CLI

ENT

/ SER

VER

SO

LUTI

ON

Distributed Systems…

Page 338: System Analysis and Design

Client Server ArchitectureThe presentation, presentation logic, application

logic, data manipulation and data layers are distributed between client PC’s and one or more servers.

Client Computers :

Any combination of personal Computers or Workstations, “sometimes connected”

Distributed Systems…

Page 339: System Analysis and Design

AccountsSales

Design

Construction

Client/Server Architecture…

Distributed Systems…

Page 340: System Analysis and Design

• Clients may be thin or flat

Client/Server Architecture…

A personal that does not have to be very powerful (acts as a

terminal) e.g. Remote desktop

a personal computer, notebook computer, or

work station that is typically powerful

e.g. Almost all PCs

Distributed Systems…

Page 341: System Analysis and Design

• Server must be more powerful and capable than a server in the file server model

• Several types of servers may be used in a client/server solution.

– Database Server : A server that hosts one or more databases.

– Transaction Server : a server that hosts services which ensure that all database updates for a transaction succeed or fail as a whole.

Client/Server Architecture…

Distributed Systems…

Page 342: System Analysis and Design

– Application Server : A server that hosts application logic and services for an information system

– Messaging or Groupware Server : A server that hosts services for groupware.

– Web Server : A server that hosts internet or intranet web sites

Client/Server Architecture…

Distributed Systems…

Page 343: System Analysis and Design

• Client / Server – Distributed Presentation – A client/server system in which presentation and

presentation logic are shifted from the server to reside on the client

• Client / Server – Distributed Data– A client/server system in which the data and data

manipulation layers are placed on servers and other layers are placed on clients. Also called two-tiered client/server computing.

Client/Server Architecture…

Distributed Systems…

Page 344: System Analysis and Design

• Client / Server – Distributed Data and Application– client/server system in which the data and data

manipulation layers are placed on their own server (s). – Application logic is placed on its own server– Presentation logic and Presentation are placed on the

clients.– Also, called three-tiered, or n-tiered, client/server

computing

Client/Server Architecture…

Distributed Systems…

Page 345: System Analysis and Design

Stored on the Database Server

Executed on the Database Server

Distributed from the Web Server

Executed on the Application Server

Displayed on the Client

PRESENTATIONLAYER

PRESENTATIONLOGIC LAYER

APPLICATIONLOGIC LAYER

DATA MANIPULATION

LAYER

DATA LAYER

NETWORKCOMPUTING

SOLUTION

Distributed Systems…

Page 346: System Analysis and Design

Internet-based Architecture• Presentation and presentation logic

layers are implemented in a client side web browser

• The presentation logic layer then connects to the application logic layer that run on an application server,

• Subsequently connects to the database server/s

Distributed Systems…

Page 347: System Analysis and Design

• Client-server and network computing made it possible to distribute data without loss of control

• Control is accomplished through advances in distributed relational database technology

Data Architectures

Page 348: System Analysis and Design

• Stores data in a tabular form– Each file is implemented as a table– Each field is a column in the table– Each record is a row in the table– Related records between two tables (e.g. CUSTOMER

and ORDER) are implemented by internally duplicating columns in the two tables.

• Distributes or duplicates tables to multiple database servers located in important locations

Distributed Relational Database

Page 349: System Analysis and Design

• The software required to implement distributed relational databases

• Controls access to and maintenance of the stored data in the relational format

• Provides back-ups, recovery and security• Also called as client-server database

management systemse.g. Oracle, SQL Server, Sybase

Distributed Relational Database Management System (RDBMS)

Page 350: System Analysis and Design

• Supports two types of data

– Data partitioning : truly distributes rows and columns to specific database servers with little or no duplication between servers

– Data replication : duplicates some or all tables on more than one database server.

Distributed Relational Database Management System (RDBMS)

Page 351: System Analysis and Design

• For a given information system application the data architecture must specify the RDBMS technology and the degree to which data will be partitioned or replicated.

• One way to record these decisions is to record them in a physical data store

For more information Refer pg 495 Ref1

Data Architectures

Page 352: System Analysis and Design

Batch inputs or Outputs

• Transactions are accumulated into batches for periodic processing

• Batch inputs (e.g. time cards) are processed to update databases and produce appropriate outputs (e.g. paychecks, generation of invoices)

Refer pg 496 Ref1 for more information

Interface Architectures

Page 353: System Analysis and Design

Online inputs or Outputs

• Provide for a more conversational dialogue between the user and the computer applications.

• Provide immediate feedback in response to transactions, problems, and inquiries.

• Provide greater human interaction in decision

Refer pg 497 Ref1 for more information

Interface Architectures…

Page 354: System Analysis and Design

Remote batch

• Combines the best aspects of batch and online inputs and outputs.

Refer pg 497 Ref1 for more information

Interface Architectures…

Page 355: System Analysis and Design

Keyless Data Entry (and automatic identification)• Keying in data has always been a major source of

errors in computer inputs.

• In batch systems, keying errors can be eliminated through optical character reading (OCR) and optical mark reading (OMR) technology

• The real advance in keyless data entry are coming for online systems in the form of auto-identification systems. (e.g. bar-coding schemes)

Refer pg 498 Ref1 for more information

Interface Architectures…

Page 356: System Analysis and Design

Pen input

• A pen-based operating system become more widely available and used (e.g. Palm OS and Microsoft’s Windows Mobile)

• Uses this technology to for remote data collection

Refer pg 498-499 Ref1 for more information

Interface Architectures…

Page 357: System Analysis and Design

Electronic Data interchange (EDI)

• The standardized electronic flow of business transactions or data between businesses

Refer pg 499 Ref1 for more information

Interface Architectures…

Page 358: System Analysis and Design

Imaging and Document Interchange

• The actual images of the forms and data are transmitted and received.

• Useful in applications in which the form images or graphics are required

Refer pg 499 Ref1 for more information

Interface Architectures…

Page 359: System Analysis and Design

Middleware

• Utility software that enables communication between different processors in a system

• May be built into the respective operating system or added through purchased middleware products

Refer pg 500 Ref1 for more information

Interface Architectures…

Page 360: System Analysis and Design

The software development environment (SDE)• A language and tool kit for developing applications

• One way to classify SDEs is according to the type of client/server or network computing architectures they support– SDEs for Centralized Computing and Distributed

Presentation– SDEs for Two-Tier Client/Server– SDEs for Multi-tier Client/Server– SDEs for Internet and Intranet Client/Server

Refer pg 500-502 Ref1 for more information

Process Architectures

Page 361: System Analysis and Design

Project Management

Demand for Project managers in the Information system community is strong.

Information system project managers come from the ranks of experienced IS developers such as systems analysts

Systems Analysts should be aware of Project management processes, tools and techniques.

Page 362: System Analysis and Design

Project Management...

• Project– A sequence of unique, complex, and

connected activities that have one goal or purpose and that must be completed by a specific time, within budget, and according to specification

Page 363: System Analysis and Design

Project Management...

Project Manager

• Project manager– The person responsible for

supervising a systems project from initiation to conclusion.

– Should possess a wide range of technical, management, leadership and communication skills.

Page 364: System Analysis and Design

Project Management...

It is the process ofScoping Planning

Staffing

DirectingControllingOrganizing

the development of an acceptable system at a minimum cost within a specified time frame.

Page 365: System Analysis and Design

Project Management...

Necessary to ensure that the project

Resulting Information

SystemAcceptable to the customer

Delivered on time

Delivered within Budget

Customer

PM is a cross life cycle activity because it overlaps all phases of any systems development methodology.

Page 366: System Analysis and Design

Project Management...

• A project is successful if– The resulting Information system is acceptable to

the customer– The system is delivered “on time”– The system is delivered “within budget”– The system development process had a minimal

impact on ongoing business operations.• Not all projects meet the above criteria, thus,

not all projects are successful

Page 367: System Analysis and Design

Project Management...

Causes of failed projectsFailure to establish upper-management commitment to the project

Lack of organization’s commitment to the system development methodology

Taking shortcuts through or around the system development methodology

Premature commitment to a fixed budget and schedule

Poor estimating techniques

Premature commitment to a fixed budget and schedule

Poor estimating techniques

Page 368: System Analysis and Design

Project Management...

Over optimism

The mythical man-month

Inadequate people management skills

Failure to adapt to business change

Insufficient resources

Failure to “manage to the plan”

Major cause of project failure is that most project managers were not educated or trained to be project managers.

Causes of failed projects…

Page 369: System Analysis and Design

Project Management...

Project Manager Competencies

• Good project managers possess a core set of competencies.

• Some of these can be taught in courses, books and workshops

• Some come only with professional experience in the field

• basic premises of project management competencies:

• individuals cannot manage a process they have never used

•Managers must have an understanding of the business and culture that provides a context for the project

Page 370: System Analysis and Design

Business Achievement Competencies

Problem-Solving Competencies

People Management Competencies

Self-Management Competencies

Influence Competencies

Project Manager Competencies…

Project Management...

Refer Table 4-1 pg 123 Ref1 for more details

Page 371: System Analysis and Design

Project Management...Project management functions

– Scoping : scope defines the boundaries of the project. A project manager must scope project expectations and constraints in order to plan activities, estimate costs, and manage expectations.

– Planning : planning identifies the tasks required to complete the project.

– Estimating : each task that is required to complete the project must be estimated. (e.g. how much time will be required?, how much people will be needed? What skills will be needed? How much will it cost? Can some of the tasks overlap?...etc)

Page 372: System Analysis and Design

Project Management...Project management functions…

– Scheduling : given the project plan, all project activities should be scheduled.

– Organizing : should make sure that members of the project understand their own responsibilities as well as their reporting.

– Directing : once the project has begun the project manager should direct the team’s activities

Page 373: System Analysis and Design

Project Management...Project management functions…

– Controlling : need to monitor and report progress against goals, schedule, and costs and need to make appropriate adjustments when necessary.

– Closing : good project managers assess success and failures at the conclusion of the project. They learn from mistakes and plan for continuous improvement of the systems development process.

All these functions depend on ongoing interpersonal communication among the project manager. The team, and other managers.

Page 374: System Analysis and Design

Project Management...

Project Management Tools and Techniques

• PERT chart

• Gantt chart

Page 375: System Analysis and Design

Project Management...

A PERT chart is a graphical network model that depicts a project’s tasks and the relationships between those tasks.

Project Management Tools and Techniques…

Eg.

Page 376: System Analysis and Design

Project Management...

Project Management Tools and Techniques…

• PERT stands for Project Evaluation and Review Technique

• Developed to make clear the interdependence between project tasks before those tasks are scheduled.

• Boxes represent project tasks– Content of the boxes can be adjusted to show various

project attributes such as schedule and actual start and finished times.

• Arrow indicates that one task is dependent on the start or completion of another task.

Page 377: System Analysis and Design

Project Management...

Gantt Chart– The most commonly used project scheduling

and progress evaluation tool– a simple horizontal bar chart that depicts project

tasks against a calendar. – Each bar represents a named project task. – The tasks are listed vertically in the left-hand

column.

Project Management Tools and Techniques…

Page 378: System Analysis and Design

Project Management...

Project Management Tools and Techniques…e.g. Gantt Chart

For more details : Ref1 p122 - 131

Page 379: System Analysis and Design

Project Management...

Project Management Tools and Techniques…

Gantt Chart…Advantages – Clearly show overlapping tasks

• Tasks that can be performed at the same time– the bars can be shaded to clearly indicate

percentage completion and project progress– Shows which phases are ahead of and behind

schedule at a glance.– Simple– Easy to learn, read, prepare, and use

Page 380: System Analysis and Design

Project Management...

Project Management Tools and Techniques…

Gantt Vs. PERT– Gantt and PERT charts are not mutually

exclusive.– Gantt charts are more effective when seeking

to communicate schedule– PERT charts are more effective when you

want to study the relationships between tasks.

Page 381: System Analysis and Design

Project Management...

Project Management Tools and Techniques…

• Used to help project managers plan projects, develop schedules, develop budgets, monitor progress and costs, generate reports, and effective change.

• Automated project management tools :– Niku’s Project Manager– Artemis international solutions corporation’s 9000– Microsoft’s Project– Primavera’s Project Planner and Project Manager

Page 382: System Analysis and Design

Automated tools and technology

• In the not too distant past the principle tools of the systems analyst were paper, pencil, and flowchart template.

• Today entire suites of automated tools have been developed, marketed and installed to assist systems development teams

Page 383: System Analysis and Design

Automated tools and technology

• Benefits– Improved productivity – through automation of

tasks– Improved quality – because automated tools

check for completeness, consistency, and contradictions

– Better and more consistent documentation –because the tools make it easier to create and assemble consistent, high-quality documentation

Page 384: System Analysis and Design

Automated tools and technology

• Benefits– Reduced lifetime maintenance – because

of the aforementioned system quality improvements combined with better documentation

– Methodologies that really work – through rule enforcement and built-in expertise

Page 385: System Analysis and Design

Automated tools and technology

• There are three classes of automated tools for developers.– Computer-aided systems modeling– Application development

environment– Project and process managers

Page 386: System Analysis and Design

• The use of automated software tools that support the drawing and analysis of system models, detailed descriptions and associated specifications.

• Some CASE tools also provide prototyping and code generation capabilities.

Computer-Assisted Systems Engineering (CASE)

It is filling Automatically

Page 387: System Analysis and Design

Computer-Assisted Systems Engineering (CASE)

It is the application of information technology to system development activities, technique and methodologies. Case toolsare programs that automate or support phases of a system development life cycle.

Page 388: System Analysis and Design

Computer-Assisted Systems Engineering (CASE)

• CASE Repositories– A system developers’ database where

developers can store system models, detailed descriptions and specifications, and other products of system development.

– A collection of facilities, for creating system models and documentation

– Also known as data dictionary and encyclopedia

Page 389: System Analysis and Design

Computer-Assisted Systems Engineering (CASE)

• CASE FacilitiesTo use the repository, the CASE tools provide

some combination of facilities– Diagramming tools: used to draw the system

models required or recommended in most system development methodologies

Page 390: System Analysis and Design

Computer-Assisted Systems Engineering (CASE)

• CASE Facilities– Diagramming tools:

♥ Include capabilities– to produce ERDs, DFDs etc.– to store the details internally– to change and redraw,

Eliminates an activity that analysts find both tedious and undesirable.

♥ Perform online syntactic checks and semantic checks

Page 391: System Analysis and Design

Computer-Assisted Systems Engineering (CASE)

• CASE Facilities– Dictionary tools: used to record,

delete, edit, and output detailed documentation and specifications

– Design tools: used to develop mock-ups of system components such as inputs and outputs

Page 392: System Analysis and Design

Computer-Assisted Systems Engineering (CASE)

• CASE Facilities– Quality management tools: analyze system

models, descriptions and specifications, and designs for completeness, consistency, and conformance to accepted rules of the methodologies.

Page 393: System Analysis and Design

Computer-Assisted Systems Engineering (CASE)

• CASE Facilities– Documentation tools: used to assemble,

organize, and report on system models, descriptions and specifications, and prototypes that can be reviewed by system owners, users, designers and builders.

Page 394: System Analysis and Design

Computer-Assisted Systems Engineering (CASE)

• CASE Facilities– Design and code generator tools:

automatically generate database designs and application programs or significant portions of those programs

Page 395: System Analysis and Design

• CASE Facilities– Testing tools: simulate transactions and data

traffic, measure performance, and provide configuration management of test plans and test scripts.

Eg. Rational Team Test, Rational Purify, Rational Visual PureCoverage

Computer-Assisted Systems Engineering (CASE)

Page 396: System Analysis and Design

Computer-Assisted Systems Engineering (CASE)

• Forward and Reverse Engineering– Two distinct ways to develop system models.Forward Engineering: a CASE tool capability that

can generate initial software or database code directly from system models.

e.g. generate a program directly from a flow chartReverse Engineering: a CASE tool capability that

can automatically generate initial system models from software or database code

e.g. generate a flow chart from an existing program

Page 397: System Analysis and Design

Computer-Assisted Systems Engineering (CASE)

• Systems designed to automate the stages of Systems Development.

• Capable of bringing clear benefits to Systems Development.

Page 398: System Analysis and Design

General Characteristics– Break down complexity

♥Decompose requirements and design into manageable components

– Presentable to several audiences♥End users, ♥Contracting organization paying for the Software

development,♥Developers

Computer-Assisted Systems Engineering (CASE)

Page 399: System Analysis and Design

Computer-Assisted Systems Engineering (CASE)

General Characteristics…– Cheaper than building using

traditional methods– Verifiable– Maintainable– Graphically Oriented

♥Easy to understand a graphical illustration

Page 400: System Analysis and Design

Computer-Assisted Systems Engineering (CASE)

• Analyst/Designer Tool kit• Automate Plus• CASE 2000• Excelerator• Information Engineering

Workbench• TeamWork• Visible Analyst

• Deft• Easy CASE• Oracle *CASE• Designer 2000• OOTher• Rational Suit• Together

Page 401: System Analysis and Design

Benefits of using CASE tools in Systems Development

• CASE tools improve– Quality– Productivity– The amount of interaction between

developers and users

• However the Organizations must consider– Whether the features of CASE fit the methods they

use or– Whether they wish to modify their methods to

obtain CASE benefits.

Page 402: System Analysis and Design

Benefits of using CASE tools in Systems Development

• Better documentation (mostly because the tools make it easier to create and assemble consistent, high-quality documentation)

• Reduce lifetime maintenance (because of the aforementioned system quality improvements combined with better documentation)

• Reverse Engineering, Forward Engineering support

Page 403: System Analysis and Design

Benefits of using CASE tools in Systems Development

Most Important Elements in the Development Process

are

Skills and Capabilities of the Systems Analysts.

Page 404: System Analysis and Design

Application Development Environment (ADEs)

• An integrated software development tool• Provides all the facilities necessary to

develop new application software with maximum speed and quality.

• Also known as integrated development environment (IDE)

e.g. IBM’s Websphere, Oracle's Developer, Microsoft’s Visual Studio.NET …etc

Page 405: System Analysis and Design

Application Development Environment (ADEs)

• Provide a number of productivity and quality management facilities– Programming language or interpreters:

• help programmers quickly identify and solve programming problems

– Interface construction tools:• help programmers quickly build the user interfaces using

a component library– Middleware:

• helps programmers integrate the software being developed with various databases and computer networks

Page 406: System Analysis and Design

Application Development Environment (ADEs)

• Provide a number of productivity and quality management facilities (cont.)– Testing tools:

• used to build and execute test scripts that can consistently and thoroughly test software

– Version control tools:• help multiple programmer teams

manage multiple versions of a program

Page 407: System Analysis and Design

Application Development Environment (ADEs)

• Provide a number of productivity and quality management facilities (cont.)– Help authoring tools:

• used to write online help systems, user manuals, and online training.

– Repository links:• permit the ADE to integrate with CASE tool

products as well as other ADEs and development tools.

Page 408: System Analysis and Design

Process and Project Management Tools

• CASE tools and ADEs support analysis, design and construction of new information systems and software

• Process manager and project manager application tools are intended to support cross life-cycle activities.

• Project management tools – Microsoft’s project, Niku’s Open Workbench and Project Manager

Page 409: System Analysis and Design

Process and Project Management Tools

• Process manager application– An automated tool – Helps to document and manage a

methodology and routes, its deliverables, and quality management standards.

– Also known as methodware

Page 410: System Analysis and Design

Process and Project Management Tools

• Project manager application– An automated tool– Helps to

• plan system development activities, • estimate and assign resources, • schedule activities and resources, • monitor progress against schedule and budget, • control and modify schedule and resources, and • report project progress.