System Analysis and Design

Published on May 2016 | Categories: Types, Books - Non-fiction | Downloads: 76 | Comments: 0 | Views: 605
of x
Download PDF   Embed   Report

Computer System

Comments

Content

CS-1st Year

Systems Analysis and Design
G.K.A. Dias

University of Colombo School of Computing

1

References
Ref : 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

2

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???

3

Information Systems
Applications
Earlier applications

Airline Reservations

Keeping records of transactions

Keeping records of Stock

4

Information Systems
Introduction
Computers are now becoming part of virtually every activity in an organization

Production

HRM - Training

Telephone Integration

5

Information System
An arrangement of

People

Interface

Data

Information Technology

Network

Process

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

Information System
Information Technology
A combination of Computer Technology Telecommunication

Hardware & Software
Computer Technology

Data, image, voice

Telecommunication Technology

7

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

8

Information Systems
System stakeholders
can be classified into five groups

System User

System Owner

System Builders

System Designer

System Analysts

9

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
10

Information Systems
• Stakeholders cont..
• 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
11

System Owner

Information Systems
• Stakeholders cont..
technical specialists Translates system users’ business requirements and constraints into technical solutions. Design the system (data-bases, inputs, outputs, screens, network, software) to meet the users requirements
12

System Designer

Information Systems
• Stakeholders cont..
Design the computer files, databases, inputs, outputs, screens, networks, and programs that will meet the system users requirements.
System Designer

13

Information Systems
• Stakeholders cont..
Construct, test and deliver the Information System based on the design specifications generated by the system designer.
System Builders

14

Information Systems
• Stakeholders cont..

People who understand both business and computing.

Systems Analysts
15

Information Systems
• Stakeholders cont..
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.
16

Systems Analysts

Information Systems
• Stakeholders cont..
What does a systems analyst do? - 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
17

Systems Analysts

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

18

Information Systems
Legacy systems cont…
• 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.

19

Information Systems
Legacy systems cont…
Support old business requirements
Old technology Old standard Euro?
Converted to satisfy

Support new business requirements
Euro New standard

Y2K? Old system

new environments

Y2K free New technology New system New functionality

20

Information Systems
Legacy 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
21

Information Systems
Legacy 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 1978 Age? -74, 0, 74
22

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

1

Transaction Process Systems (TPS) • Capture and process data about business transactions

Airline Reservations

Bank deposit and withdrawal
2

Management Information System (MIS)
• Designed for management oriented reporting • Based on transaction processing and operations of the organization

Production scheduling

Inventory reporting
3

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 work With DSS

4

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.
5

Expert Systems
• An expert system is a programmed decision making information system. I am a human • Capture and reproduce the knowledge and expertise of a decision maker • Simulates the “thinking” of the expert.
6

Communications and Collaboration Systems
• Enables more effective communications between
– – – – Workers Partners Customers Suppliers

• Enhance their ability to collaborate
7

Office Automation Systems
• Supports the wide range of business office activities • Provides improved work flow between workers.
h sc p i ng l du e

or W

rou kg

-M E
g tin pu m

il a

ac f

ile im s
rou kg

co p

ni t ro lec E

oc cd

nt me u

or W

8

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 am doing all processing I have all system data

Databases

Provide interfaces

1

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.

Distributed to multiple locations -- Components of an information system -- Processing workload required to support the components

2

Distributed Systems
1. 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. Sales
Client Computers : Any combination of personal Computers or Workstations, “sometimes connected”

Accounts

Design

Construction
3

Distributed Systems
Client Server Systems cont.. Clients may be thin or flat
Almost all PCs Acts only as a terminal
e.g. Windows terminal

4

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

5

Distributed Systems
3. 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

6

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

7

Processing Types
2. Online Processing
The data about a single transaction is processed immediately.

ATM-Real time processing
8

CS-1st Year

Systems Analysis and Design
G.K.A. Dias

University of Colombo School of Computing

1

System Development Life Cycle (SDLC)
Problem Definition System Analysis

Maintenance

System Testing System Implementation

System Design

2

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
3

Why we need a life cycle in systems development? • 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 technology infrastructure • to avoid failures like unclear objectives, cost overruns, and • to maintain cheaply and enhance cost effectively
4

Sequential or Waterfall development approach
• An approach to system analysis and design • Completes each phase one after another and only once.
Problem Definition Requirement Analysis System Design System Development System Testing Maintenance 1

Problem Definition
Project goals Project bound Provides a broad statement of user requirements in users terms, or what the users expect the system to do 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. Specify the resources to be made available for the project (resource limits).

Project limits

2

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
3

System Analysis
how 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

4

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

Analysts

Design
5

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
6

System Implementation
Individual system components are built and tested Data and tools are used to build the system User interfaces are developed and tried by users Database is initialized with data

Analysts

System
7

System testing
Test and evaluate results, and the system ready to be delivered to the user/client.

8

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

9

Problems with waterfall cycle
It has a rigid design Inflexible It has a top-down procedure One phase must be completed before the next phase starts No phase can be repeated Time consuming

10

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.
11

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.

12

Modified Waterfall Model
Problem Definition Requirement Analysis System Design Implementation System Testing Maintenance

13

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.
14

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
15

Iterative development approach
Complete problem definition Some System Analysis

Iteration # 1
Some System Design Some System Implementation

Iteration # 2
More System Analysis More System Design More System Implementation

Iteration # 3
Still more System Analysis Still more System Design Still more System Implementation 16

Repeat until no additional iterations needed

Underlying Principles for System Development methodology
• P1: Get the system users involved
– A communication between system users, analysts, designers, and builders • Minimizes miscommunication and misunderstanding • Help to win acceptance of new ideas and technological change

Involved

System Development
1

• 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.
2

• 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
3

• 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.

4

P5: Establish standards. # Documentation # Quality

# Automated tools

#Information Technology

5

• 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
6

An organization’s chosen methodology For system development

• 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.

7

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

IS

cost

# 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
8

P8:Don’t be afraid to cancel or revise scope.
# Cancel the project if it is no longer feasible # If project scope is to be increased, reevaluate and adjust the cost and schedule # If the project budget and schedule are frozen and not sufficient to cover all project objectives, reduce the scope.
Cancel

9

P9:Divide and conquer.
# divide a system into subsystem and components --- Easily to conquer the problem --- Easy to build a large problem

10

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
11

Major components of system development
• Methodology • Modeling Methods or Techniques • Tools
Major Components

1

Methodology
• A set of
– Activities – Methods – Best practices – Deliverables – Automated tools

• Used by stakeholders to
– Develop – Continuously improve
Information systems and Software
2

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

e.g. SSADM, RUP

3

Methodology

Modeling Methods or Techniques Class Diagram, Use Case Diagrams etc.
Eg .Rational Unified Process

Tools Rational Rose, Rational Suit

4

Methodology
• Uses tools and modeling methods

Tools

Most Effective Way of Building Methods 5

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.

6

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.

7

Life Cycle vs. Methodology
•A system development life cycle divides the life of an information system into two major stages, LIFE CYCLE STAGE • Systems development
(consists of system analysis, system design, system implementation and testing phases)
A System Development Process
using System Development Methodology Conversion

LIFE CYCLE STAGE

Lifetime of a System

System Operation and Maintenance
using Information Technology

and • Systems operation and
support (maintenance)
8
Obsolescence

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

9

Modeling Methods
A 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
10

Tools
• Software systems • Assists analysts and designer to build information systems • They will not replace Systems Analysts.

e.g. Easy Case, Rational Rose

11

Tools
General 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.

12

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
1

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

2

Scope Definition
This 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
3

Scope Definition
Scope 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.
4

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)
5

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)
6

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.

7

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?

8

Finding Problems to Solve
• 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.
Conclusion (Root cause of the child’s symptoms) : AN EAR INFECTION

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

9

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.
10

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

1

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.
2

Feasibility Checkpoints
• Systems Analysis – Scope Definition Checkpoint • Systems Analysis – Problem Analysis Checkpoint • Systems Design – Decision Analysis Checkpoint

3

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?

4

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

5

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
6

Decision Analysis Checkpoint
Range 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 computerbased system

After defining these options, each option should be analyzed.
7

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

8

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?

9

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.
10

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?

11

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.

12

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 13

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
14

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?
1

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 computerbased solutions have been defined • Recur throughout the lifetime of the system
2

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

3

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
4

Is the proposed system cost effective
• Cost effectiveness techniques
– Payback Analysis – Return on Investment Analysis – Net present value Analysis

5

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)

6

Return-on-Investment (ROI) Analysis
• A technique that compares the lifetime profitability of alternative solutions Lifetime benefits - Lifetime costs Lifetime costs

7

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

8

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
1

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

2

Candidate Systems Matrix
• Example
Candidate 1 Name Candidate 2 Name Candidate 3 Name

Stakeholders Knowledge Processes Communications Template
3

Candidate Systems Matrix
• Example
Candidate 1 Name Candidate 2 Name Candidate 3 Name

Stakeholders

Identify how the Knowledge system will interact Processes with people, and other Communications systems Template
4

Candidate Systems Matrix
• Example
Candidate 1 Name Candidate 2 Name Candidate 3 Name

Stakeholders

Identify how data stores Knowledge be implemented, inputs will be captured, Processes outputs will be generated Communications Template
5

Candidate Systems Matrix
• Example
Candidate 1 Name Candidate 2 Name Candidate 3 Name

Stakeholders Knowledge Processes Communications

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

Candidate Systems Matrix
• Example
Candidate 1 Name Candidate 2 Name Candidate 3 Name

Stakeholders Knowledge Processes Communications

Identify how processes and data will be distributed. Template
7

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

8

Feasibility Analysis Matrix
Weighting Candidate1 Candidate2 Candidate3

Description Operational Feasibility Cultural Feasibility Technical Feasibility Economic Feasibility Schedule Feasibility Legal Feasibility Weighted Score
9

The System Proposal
A report / presentation of a recommended solution Usually a formal written report or oral presentation Intended for system owners and users

Formal written report

System owners And End Users Oral presentation
1

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.

2

Secondary elements for a written report
Letter of transmittal Title page Tables of contents List of Figures, illustrations, and tables Abstract or executive summary (primary elements are presented in this portion of the report) Appendixes
3

Formal Presentation
• A special meeting • Used to sell new ideas and gain approval for new systems • Can be also used for Sell 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 4

Requirements Analysis
Identifying Requirements
Correct systems can only be built if you know exactly
what the system must do Systems Analyst

what the user needs

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.
1

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
2

Requirements Analysis
Example: Ambiguous Requirement Statement Identify the mode of transportation to transfer a single individual from home to place of work

Management Interpretation

IT Interpretation

User Interpretation

3

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

4

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

5

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

6

Requirements Discovery…
• The process and techniques used by systems analysts to
– Identify – Analyze – Understand
System Requirements

Works with Systems Analyst
Systems Owner Works with 7

Systems User

Requirements Discovery…
System Requirements Specify what the information system must do, or what property / quality the system must have

8

Requirements Discovery…
System Requirements

Functional Requirements Specify what the information system must do

Non functional Requirements Specify a property / quality the system must have e.g. user friendliness, Security etc. Refer page 209 Ref1 table 6-1
9

Requirements Discovery…
System requirements can be gathered by
– using discussions with users, about their requirements – building systems that satisfy these requirements

10

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.
11

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

• Provide direction for the modeling techniques

12

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.
13

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

14

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

15

Fact Finding Techniques
Fact-Finding
A formal process Uses techniques to collect / gather information about System requirements Problems Preferences Also known as Information gathering Used across the entire development cycle Extremely critical in the requirement analysis phase
1

Fact Finding Techniques…

Research and site visits Sampling of Existing documents

Observations of the work environment

Prototyping Joint requirements planning
2

Interviews Questionnaires

Fact Finding Ethics
• Come across sensitive data
e.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
3

Fact Finding Techniques…
Sampling of existing Documentation
– When you are studying an existing system, you can get a good idea by studying existing Documentation Forms Files

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
4

Fact Finding Techniques…
Research and Site Visits
Thoroughly, research the problem domain. Identify the material that are relevant and reliable
Internet Computer trade Journals World Wide Web Intranets Reference books

Good sources of information 5

Fact Finding Techniques…
Observations of the work environment Systems Analyst participates in or watches a person perform activities to learn about the system Often used when
validity of data collected through other methods is in question or the complexity of certain aspects of the system prevents a clear explanation by the end users.
6

Fact Finding Techniques…
Observations of the work environment… Advantages
Data gathered by observation can be highly reliable Relatively inexpensive Allows systems analyst to do work measurements Systems analyst is able to see exactly what is being done

7

Fact Finding Techniques…
Observations of the work environment… Disadvantages
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
I don’t like being watched

8

Fact Finding Techniques…
Questionnaires
Special purpose documents Allow the analysts to collect information and opinions from a large audience.

Advantages :
Most questionnaires can be answered quickly Allow individuals to maintain anonymity Relatively inexpensive way of gathering data. Responses can be tabulated and analyzed quickly etc.

1

Fact Finding Techniques…
Questionnaires…
Disadvantages:
The number of respondents is often low Mostly suited for closed questions No 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.

2

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
3

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

4

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.

5

tio n Mo tiv a

Fact Finding Techniques…
Advantages
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
6

Interviews…

Fact Finding Techniques…
Interviews…
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.
7

Fact Finding Techniques…
Interviews…
Types of Interviews Unstructured 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 interviews
interviewer has a specific set of questions to ask of the interviewee 8

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

9

Fact Finding Techniques…
Interviews…
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.
1

Fact Finding Techniques…
Interviews…
How to conduct an Interview? Prepare for the Interview
Prepare an interview guide - checklist of specific questions interviewer will ask the interviewee Avoid 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 ? 2

Fact Finding Techniques…
Interviews…
How to conduct an Interview? Prepare for the Interview
Interview question guidelines : Use clear and concise language Don’t include your opinion as part of a question Avoid long or complex questions Avoid threatening questions verify before you leave The purpose of the interview is to investigate, not to evaluate or criticize
3

Fact Finding Techniques…
Interviews…
How to conduct an Interview? Conduct the Interview The actual interview consist of three phases:
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.
4

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.
5

Fact Finding Techniques…
Prototyping…
Analyst will develop a model following an initial analysis

A repeat visit may then validate the model with the user

Agreement is reached on the model

Further detailed data may be gathered to elaborate the model
6

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 user Analyst does not get too far ahead using wrong assumptions

7

Fact Finding Techniques…
Prototyping…
Advantages
Allow 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.

8

Fact Finding Techniques…
Prototyping…
Disadvantages
Developer 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

9

Fact Finding Techniques…
Joint Requirement Planning (JRP)
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

10

Fact Finding Techniques…
Joint Requirement Planning (JRP)
JRP Participants Sponsor
Serve 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

11

Fact Finding Techniques…
Joint Requirement Planning (JRP)…
JRP Participants… Users and Managers
Number 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
12

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
13

Fact Finding Techniques…
Document Flow Diagrams
– Used to identify physical movement of documents.

Purch. Dept.

Purc
…. …..

Order has e

Supplier

14

Fact Finding Techniques…
Document Flow Diagrams…
– shows
• where the document comes from, • where it goes to , and • what it is called.

Purch. Dept.

Purc
…. …..

Order has e

Supplier

15

Fact Finding Techniques…
Document Flow Diagrams…
Used to examine the flow of documents within the existing system.
Invoice Order Purch. Dept.
no t De liv e ry e

Supplier Example: Purchasing System

y er liv De

no

Stores

te

16

Fact Finding Techniques…
Document Flow Diagrams…
Example: Purchasing System
Order

Supplier
Invoice
De liv er y

Purch. Dept.
y e ot n

no

te

Stores
D

r ve i el

System boundary 17

Fact Finding Techniques…
Document Flow Diagrams…
Maintenance Example: Purchasing System
Order

Supplier
Invoice
De liv er y

Purch. Dept.
y e ot n

no

te

Stores
D

r ve i el

System boundary 18

Fact Finding Techniques…
Document Flow Diagrams…
Advantages / Usefulness
Used to identify the documents in the system Identify 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

19

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.
20

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.

21

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.

22

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)
23

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)

24

Modeling Methods
How to simplify, present / document a complex problem? The answer is just Simple, use MODELS

Model :
A pictorial representation of reality.
SA R OO L EF L MP

N LA P

1

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.

2

Process Modeling
Models

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

Physical Models
Other names: ~ Implementation Model ~ Technical model

3

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 nontechnical / less technical languages.
4

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
5

Process Modeling
Program Structure Charts Logic Flow Charts Decision 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.
6

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
7

Elements in a DFD (Gane and Sarson Symbols)
Purchasing System
A Process Invoice A Data Flow Supplier An External Agent

Orders
A Data Store
8

Elements in a DFD (Gane and Sarson Symbols)
Process name
A Processes or Work to be done
Represented by a rounded rectangle

- 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
9

Elements in a DFD (Gane and Sarson Symbols)
Represented by a square External Agent An External Agent

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.
10

Elements in a DFD (Gane and Sarson Symbols)
Represented by a square External Agent An External Agent

External Agents Provide the net inputs into the system and receive net outputs from the system being defined. External external to the system being analyzed or designed.
11

Elements in a DFD (Gane and Sarson Symbols)
Data store
A Data Store
Represented by the open-end box

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.

12

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 include Persons: Customer, Employee Places: Building, Room, Campus Objects: Book, Machine, Product Events: Invoice, Order, Registration, Renewal Concepts: Course, Fund, Stock
13

Elements in a DFD (Gane and Sarson Symbols)
Represented by an arrow 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
14

The Context Data Flow Diagrams
• A diagram that shows the system as a “black box” and its main interfaces with its environment. External • Used to document the Agent scope of the system • Also known as environmental model.
External Agent External Agent

Process

External Agent
15

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
16

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

17

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
18

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

19

Task 2
• Identify major data flows to and from the System

20

Task 3
• Convert each source or recipient into external agents

Supplier

21

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

Supplier

Order Invoice Delivery note

Purchasing System

22

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

23

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.
24

Context Diagram
Account Holder

C he que /Wi th Slip drawa l

With d A ck now rawal ledg eme nt

Bank Payment System

25

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

26

Process Decomposition
Is an act of breaking a system into its component subsystems, processes, and sub processes.
0 UCSC System

n positio Decom m Diagra
2 Registration sub System 2.1 Process

1 Payroll sub system 1.1 Process 1.2 Process

1.1.1
Sub Process

1.1.1.1 1.1.1.2

1.1.2
Sub Process

2.2 Process

27

Context Diagram
Wit Ack hdr now awa ledg l eme nt

Account Holder

Ch eq u e /W ithd Slip raw

al

Bank Payment System

28

Top Level DFD – Step 1
Withdr Acknow awal ledgem ent Verify Account A/C Holder Balance

Cheq

ue/W ithdr aw al Slip

Debit Withdrawal

29

Top Level DFD – Step 2
Withdrawal Acknowledgement Account Holder Cheque/Withdrawal Slip Verify A/C Balance Debit Withdrawal

30

Top Level DFD – Step 3

• Identify the Data Stores Account Master

31

Top Level DFD – Step 4
• Identify the other data flows.
Get current balance

Verify Current Balance A/C Balance

Account Master

32

Top Level DFD – Step 4
• Identify the other data flows. Transfer the verified details
Verify A/C Balance

Verified details

Debit Withdrawal

33

Top Level DFD – Step 4
• Identify the other data flows. update new balance

Account Master

New Balance

Debit Withdrawal

34

Top Level Diagram
1 Verify A/C Balance Cheque/Withdrawal Slip Account Holder
Ve ri

fie dD eta ils

Account Master

2 ew ce N an Debit al B Withdrawal

Withd r Ackn awal owle dgem e
35

Account Holder

nt

nt rre ce Cu lan Ba

Illegal Data Flows
Illegal data flows Corrected data flows
A process is needed to Exchange data Flows between External agents

E1

E2

E1

E2

E1

D1

E1

A process is needed to Update / use A data store

D1

36

Illegal Data Flows
Illegal data flows Corrected data flows D1
A process is needed to present data From a data store A process is needed to move data From one Store to another

D1

E1

E1

D1

D2

D1

D2

37

Another Common error

Process 1

No data flow should ever go unnamed

38

CASE STUDY Library System

1

Library System
Library supports
– Lending – Cataloging – Registration of Members and Books – Reservation – Inquiries – Correspondence

All activities are done manually
2

Library System
To Analyze and Design a Library System
– What are the Documents in the system?

– Study the physical movements of documents

3

Library System
• Documents in the system
– – – – – – Application form Student Id Membership card Reminders Borrowing slips etc. Reservation ready notice

4

Library System
• Identify the physical movements of documents.
– Document Flow Diagram
• Modeling method or technique used to illustrate movements of documents.

Student

on Membership applicati Librarian
…. …..

5

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?

6

Document Flow Diagrams for the Library System
Student Member

Library

r de in m p Re S l i e e in fin F e ttl Se New member details

Stude n

Admin.

System boundary
7

Stud ent r

egist form ration

Member

. Ca Mem slip rd+

t car d

m Me

d car ber

Data Flow Diagrams (DFDs)
• DFDs handle transformation from physical document to logical data • Advances in technology mean that electronic means are increasingly supplementing the paper based documents.

8

Context Diagram
Member
Me m.

Me mb

sli p

R

er c

ard

Library System

Admin.

New er b em ls m ai Det
9

Fi Sl ne ip

Member

Ca

rd+

e er d ttl in Se ine f em

Top Level Diagram
Member
Me m
M em .C

Member
e in f

be rc ar d

ar d+ sl ip

Lending Returning Member y rar Registration Lib em yst S
10

Admin.

r membe New Details

Fi ne

Sl ip

R

in em

er d

e ttl Se

Top Level Diagram
Member

Me

Member

m.

Ca

e ttl Se

rd

+s lip
R em

Member Registration

d er car Memb

fin e

ne Fi

ip Sl

Lending

d in er

Returning
New member Details
Admin.

11

Data Stores

Mem. Registration

Borrowing Details

Book Details

12

Top Level Diagram
Settle fine
Member

Fine Slip Reminder
Me m. C +sl ard ip
Borrowing details

Returning

return details

Book details

Member Registration

ber Mem card

Lending
Boo k

Borrowing Details
deta ils

New member details member details

Mem. Registration
Admin.

Book Details

New member Details

13

Documenting Elements in DFD
• Element name is not enough. • More important for processes
You need to convert these into programs
Debit Withdrawal
A(int w){ a=a-w; }

14

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
15

The Functional Decomposition Diagram
Context diagram
The System

Decomposition diagram
Function1

The System

Function2

Function n

Event1

Event2

Event3

Event4

Event5

Event n-1 n-

Event n

16

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
17

Event Diagram
The System

Decomposition diagram

Function1

Function2

Function n

Event1

Event2

Event3

Event4

Event5

Event n-1 n-

Event n

Event1

Event5

Eventn

Event diagrams 18

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
19

Process Descriptions
• Structured English • Decision Table • Decision Tree

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

20

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.

21

Structured English
IF credit limit exceeded THEN IF Customer has bad payment history THEN refuse credit ELSE IF purchase above Rs.10000/= THEN refuse credit ELSE refer to manager ELSE allow credit

22

Decision Tree
A graph or model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility. Purchase Good payment above Rs Refuse credit History 10000/= Credit limit exceeded Purchase below Refer to Rs.10000/= Manager Credit limit not exceeded Bad payment history Refuse credit Allow credit
23

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

24

Decision Table
Y-TRUE N-NOT TRUE X-TAKE ACTION Credit limit exceeded
Y Y Y Y N N N N Y Y N N Y Y N N Y N Y N Y N Y N
X X X X X X X X

Co nd itio n Ac tio n

Good payment history Purchase above Rs.10000/= Allow Credit Refuse Refer Manager

25

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.
1

Data Modeling…
Entity Relationship Diagrams
Shows 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

2

Data Modeling…
Entity Relationship Diagrams… 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.
3

Data Modeling…
Entity Relationship Diagrams… 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.

4

Data Modeling…
Entity Relationship Diagrams…
Symbol: Consider Martin notations.
EMPLOYEE DEPARTMENT

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

Data Modeling…
Entity Relationship Diagrams… Attribute:
is a descriptive property or characteristics of an entity. Sometimes called as element, property, or field.

6

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

EMPLOYEE
NIC_NO Name Address Age …. …. ….

This person can be identified using his ID number.
7

Data Modeling…
Entity Relationship Diagrams…
Compound Attribute is one that actually consist of other attributes. Synonyms- composite attribute, concatenated attribute
Example : Student name Address
Last Name First Name Middle Name Street Address Postal Code Country City

8

Data Modeling…
Entity Relationship Diagrams…
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.
9

Data Modeling…
Entity Relationship Diagrams…
Relationships Natural business association that exists between one or more entities E.g.. A Current Student is enrolled in one or more curricula
STUDENT
is enrolled in

CURRICULA

10

Data Modeling…
Entity Relationship Diagrams…
Cardinality
Defines the minimum and maximum number of occurrences of one entity that may be related to a single occurrences of the other entity.

Exactly one or

11

Data Modeling…
Entity Relationship Diagrams…
Cardinality
Zero or one I might be married or not…

Zero, one or more

I may have one, some friends or none…
12

Data Modeling…
Entity Relationship Diagrams…
Cardinality…
One or more I have to work at least in one, or more projects.

More than one I am working on many projects.
13

Data Modeling…
Entity Relationship Diagrams…
Degree
Number of entities that participate in the relationship

Degree =1 Recursive Relationship – Relationship that exists
between different instances of the same entity.
Supervise EMPLOYEE
14

Data Modeling…
Entity Relationship Diagrams…
Degree… Degree =2 Binary Relationship - When two different entities
participates in a relationship

EMPLOYEE

Works

DEPARTMENT

15

Data Modeling…
Entity Relationship Diagrams…
Degree… Degree =3 Ternary or 3-ary Relationship When more than two different entities participates in a relationship.
PROJECT
requires

EMPLOYEE
Is given

ASSIGNMENT

offers

LOCATION 16

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
17

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.

18

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
19

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
20

System Concepts for Object Modeling…
• Attributes
– The data that represents characteristics of interest about an object e.g. Object : Customer Attributes : Customer no, first name, last name, home address, work address, contact no,…etc.

21

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.
22

System Concepts for Object Modeling…
• Object instance
e.g. A “CUSTOMER” Object Instance
001:Customer

OR

Object name is underlined and centered

001:Customer customerNo =001 lastName = Perera firstName = Ann homePhoneNo = 0112123456 city = Colombo

23

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 : Door behavior : open, shut, lock or unlock

24

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
25

System Concepts for Object Modeling…
Encapsulation
When an object carries out its operations, those operations are hidden.
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. The TV hides its operations from the person watching it.
26

System Concepts for Object Modeling…
• 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 Class name

Book
-ISBN -title -copyrightDate -edition +open() +close()

Behaviors

27

System Concepts for Object Modeling…
An Object instance e.g.
0-07-231539-3 : Book ISBN = 0-07-231539-3 title = Systems Analysis copyrightDate = 2001 edition = 5th 0-09-341234-5 : Book ISBN = 0-09-341234-5 title = Programming in C++ copyrightDate = 2006 edition = 7th

28

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

29

System Concepts for Object Modeling…
• Inheritance
e.g. Cont…
Person Class Student Class Student A Student B Teacher Class Teacher A Teacher B

30

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.
31

System Concepts for Object Modeling…
Specialization

Generalization
Person firstName lastName birthdate gender walk jump talk sleep Inheritable Attributes And behavior

Student GPA Classification enroll displayGPA Teacher rank lecture

+

firstName lastName birthdate gender walk jump talk sleep

32

System Concepts for Object Modeling…
• Generalization / Specialization
Person

Vehicle

Student

Teacher

Bus

Car

Truck

* Specialized classes inherits from the parent class
33

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.

34

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 bidirectional (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 Damith Gihan is a friend of Damith
35



System Concepts for Object Modeling…
• Object / Class Association
e.g.
A CUSTOMER PLACES zero or more ORDERS An ORDER IS PLACED BY one and only one CUSTOMER

Customer

Places

0..*

Order

Represent the relationship between the classes

36

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..1 Zero or more -> 0..* or * 1 or more -> 1..* Specific range -> 7..9 Refer Figure 10-5 pg 377 Ref1 for more details
37

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 members A computer – a computer contains a case, CPU, motherboard, power supply …etc.
38

System Concepts for Object Modeling…
• Aggregation some more examples…
Glider Plane
0..* 0..*

Engine

UML notation

Team
Whole object

0..*

12..18

Player
Part Objects
39

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.
40

System Concepts for Object Modeling…
• Composition
– Drawn with a filled diamond.

School

1

1..* Department

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
41

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 behavior But the way it has been carried Out differs from one another 42

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

Analysis

Design

Systems Design…
Systems analysis - emphasize on the business problem Systems design - emphasize on the technical or implementation concerns of the system.
Task1 Task2

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

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).
Process A1 Process A Process A2 Process A3 Process A4 Process A11 Process A12 Process A13

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

Modern Structured 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…
Structure Chart • The software model derived from structured design • It is derived by studying the flow of data through the program.

Modern Structured Design…
Structure Chart
1.2 Calculate Sales Total
Sales Total

s ction le Sa nsa a Tr Sales Transaction

Sa To les ta l

1.2.1 Get Sales Transaction

1.2.2 Adds to Total

1.2.3 Output Total

Modern Structured Design…
Structure Chart
• 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

• Execution Sequence
By 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
Decisions are modeled by a diamond symbol.
Payment
Or

Cash

Cheque

@ Payment pays either cash or Cheque

Modern Structured Design…
Structure Chart
Repetition occurs when some modules are called repetitively by the calling module. Repetition is modeled by a looping arrow

Modern Structured Design…
Structure Chart is a technique used in Modern Structured Design The objective of structured design is to produce a good design.

Information Engineering (IE)
• Model driven and data centered, but PROCESSsensitive 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.

Prototyping
Prototyping: The prototyping approach is an iterative process involving a close working relationship between the designer and the users.

Prototyping…
Key Benefits:
Prototyping encourages and requires active enduser 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.

Prototyping…
Key Benefits:
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.

Prototyping…
Disadvantages:
Prototyping encourages ill-advised shortcuts through the life cycle.

Joint Application Development (JAD) JAD emphasize
participative development among system owners, users, designers, and builders.

JAD

Joint Application Development (JAD)… JAD sessions for systems design, systems designer - role of facilitator for possibly several full-day workshops intended to address different design issues and deliverables.

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.

Rapid Application Development (RAD)…
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.

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

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

Application Architecture and Modeling
Application Architecture
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

Physical Data Flow Diagrams (PDFD)
Process

• 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) Action verb + Noun or Object Phrase Implementation

Physical Data Flow Diagrams (PDFD)…
Physical Process 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 Data Flow Diagrams (PDFD)…
Characteristics of Physical DFDs
# 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.

Physical Data Flow Diagrams (PDFD)…
Physical Data Flows
• 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 Flow Diagrams (PDFD)…
Physical Data Flows… Physical Data Flow Representation
Implementation method: Data flow name Refer Figure 13-2 pg 482 Ref1 to learn how to apply one of these naming conventions in physical DFDs

OR
Data flow name (Implementation method)

eg.

PRINTOUT: Salary Equity Report

Physical Data Flow Diagrams (PDFD)…
Physical External Agents • 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 Data Flow Diagrams (PDFD)…
Physical Data Stores
• 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 Flow Diagrams (PDFD)…
Physical Data Stores Representation of physical data stores
Implementation Method : ID Data Store Name (opt) OR Data Store Name ID (opt) (Implementation Method)

Physical Data Flow Diagrams (PDFD)…
Physical Data Stores
Logical Data store

Purchase Orders

Implementation : A table in a database Physical Data store MS Access: Purchase Orders

Design the System Database
• 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…
• 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 Interface
– 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…
– 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

Package Design Specifications
– 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

Update the Project Plan
• 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.

Information Technology Architecture
• 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)

Centralized Systems
• 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
I am doing all processing I have all system data

Databases

Provide interfaces

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. • More complicated and more difficult to implement than centralized systems

Distributed Systems…
• 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… • 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…
Architecture Layers
• • 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



• •

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

Distributed Systems…
DATA LAYER DATA MANIPULATION LAYER FILE SERVER SOLUTION APPLICATION LOGIC LAYER PRESENTATION LOGIC LAYER PRESENTATION LAYER

Stored on the File Server Executed on the Client Executed on the Client Executed on the Client Displayed on the Client

Distributed Systems… 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…
File server Architecture… 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

Distributed Systems…
DISTRIBUTED DISTRIBUTED PRESENTATION DATA (2 TIER) (2 TIER) DISTRIBUTED DATA & APPLICATION (2 TIER)

CLIENT / SERVER SOLUTION

DATA LAYER DATA MANIPULATION LAYER APPLICATION LOGIC LAYER PRESENTATION LOGIC LAYER PRESENTATION LAYER

Stored on the Database Server Executed on the Database Server Executed on the Server Executed on the Client Displayed on the Client

Stored on the Database Server Executed on the Database Server Executed on the Client Executed on the Client Displayed on the Client

Stored on the Database Server Executed on the Database Server Executed on the Application Server Executed on the Client Displayed on the Client

Distributed Systems…
Client Server Architecture
The 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…
Client/Server Architecture…
Sales Accounts

Design

Construction

Distributed Systems…
Client/Server Architecture…
• Clients may be thin or flat
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…
Client/Server Architecture…
• •
– –

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.

Distributed Systems…
Client/Server Architecture…
– 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

– –

Distributed Systems…
Client/Server Architecture…
• 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.

Distributed Systems…
Client/Server Architecture…
• 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

Distributed Systems…
DATA LAYER DATA MANIPULATION LAYER NETWORK COMPUTING SOLUTION APPLICATION LOGIC LAYER PRESENTATION LOGIC LAYER PRESENTATION LAYER

Stored on the Database Server Executed on the Database Server Executed on the Application Server Distributed from the Web Server Displayed on the Client

Distributed Systems…
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

Data Architectures • 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

Distributed Relational Database
• 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 Management System (RDBMS)
• 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 systems e.g. Oracle, SQL Server, Sybase

Distributed Relational Database Management System (RDBMS) • 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.

Data Architectures
• 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

Interface Architectures
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…
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… Remote batch • Combines the best aspects of batch and online inputs and outputs. Refer pg 497 Ref1 for more information

Interface Architectures…
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…
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… Electronic Data interchange (EDI) • The standardized electronic flow of business transactions or data between businesses Refer pg 499 Ref1 for more information

Interface Architectures… 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…
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

Process Architectures
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

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.

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

Project Management... • 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.

Project Manager

Project Management...
It is the process of
Scoping Staffing Directing Organizing Planning

Controlling

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

Project Management...
Necessary to ensure that the project
Delivered on time Resulting Information System Delivered within Budget

Acceptable to the customer Customer

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

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

Project Management...
Causes of failed projects
Failure 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

Project Management...
Causes of failed projects…
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.

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

Project Management...
Project Manager Competencies…
Influence Competencies Self-Management Competencies

Problem-Solving Competencies

Business Achievement Competencies

People Management Competencies

Refer Table 4-1 pg 123 Ref1 for more details

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)

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

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.

Project Management...
Project Management Tools and Techniques • PERT chart • Gantt chart

Project Management...
Project Management Tools and Techniques…
A PERT chart is a graphical network model that depicts a project’s tasks and the relationships between those tasks.
Eg.

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.

Project Management...
Project Management Tools and Techniques… 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...
Project Management Tools and Techniques…
e.g. Gantt Chart

For more details : Ref1 p122 - 131

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

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.

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

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

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

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

Automated tools and technology
• There are three classes of automated tools for developers.
– Computer-aided systems modeling – Application development environment – Project and process managers

Computer-Assisted Systems Engineering (CASE)
It is filling Automatically

• 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 the application of information technology to system development activities, technique and methodologies. Case tools are programs that automate or support phases of a system development life cycle.

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

Computer-Assisted Systems Engineering (CASE)
• CASE Facilities
To 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

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

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 mockups of system components such as inputs and outputs

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.

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.

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

Computer-Assisted Systems Engineering (CASE)
• 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)
• 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 chart Reverse 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

Computer-Assisted Systems Engineering (CASE)
• Systems designed to automate the stages of Systems Development. • Capable of bringing clear benefits to Systems Development.

Computer-Assisted Systems Engineering (CASE)
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) General Characteristics…
– Cheaper than building using traditional methods – Verifiable – Maintainable – Graphically Oriented
♥Easy to understand a graphical illustration

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

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.

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

Benefits of using CASE tools in Systems Development
Most Important Elements in the Development Process are

Skills and Capabilities of the Systems Analysts.

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

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

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

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.

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

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

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.

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close