1
CS-1st Year
Systems Analysis and Design
G.K.A. Dias
University of Colombo School of Computing
2
ReferencesRef : System Analysis and DESIGN
METHODS
By Jeffrey L Whitten & Lonnie D Bentley ISBN 0-07-063417-3 (7th Edition)
Recommended Links
http://www.mhhe.com/whitten
3
Introduction to Information System Environment
• What is an information system?• Types of Information Systems and
processing types• System development life cycle ???• Major components of the development
process???
4
Applications
Earlier applications
Keeping records of transactions
Airline Reservations Keeping records of Stock
Information Systems
5
Information Systems
IntroductionComputers are now becoming part of virtually every activity in an organization
HRM - Training Telephone IntegrationProduction
6
Information SystemAn arrangement of
• To support and Improve day to day operations• problem solving and decision making needs of
management and users
Interface InformationTechnology
People ProcessData Network
7
Information SystemInformation Technology
A combination of
Computer Technology
Hardware & Software
Telecommunication
Data, image, voice
Computer Technology Telecommunication Technology
8
Information Systems
The Players - System Stakeholders
• any person who has an interest in an existing or proposed information system.
•Can be classified into five broader categories
• may include both –technical and non-technical workers–Internal and External workers
9
System stakeholders
can be classified into five groups
Information Systems
System OwnerSystem User System Builders
System AnalystsSystem Designer
10
Information Systems• Stakeholders cont.. a “customer” who will use or
is affected by an information system on a regular basis –capturing, validating, entering, responding to, storing, and exchanging data and information.
System Users or Clients
11
Information Systems
• Stakeholders cont..
System Owner
• An information system’s sponsor and advocate
• Owns the system
• Set the vision and priorities
• Determine the policies
• Responsible for funding the project of
•Developing•Operating•Maintaining
12
Information Systems
• Stakeholders cont..
System Designer
technical specialiststechnical specialists
Translates system usersTranslates system users’’business requirements and business requirements and constraints into technical constraints into technical solutions.solutions.
Design the system (dataDesign the system (data--bases, bases, inputs, outputs, screens, network, inputs, outputs, screens, network, software) to meet the users software) to meet the users requirementsrequirements
13
Information Systems
• Stakeholders cont..
System Designer
Design the computer Design the computer files, databases, inputs, files, databases, inputs, outputs, screens, outputs, screens, networks, and programs networks, and programs that will meet the system that will meet the system users requirements.users requirements.
14
Information Systems
• Stakeholders cont..
System Builders
Construct, test and deliver the Information System based on the design specifications generated by the system designer.
15
Information Systems
• Stakeholders cont..
Systems Analysts
People who understand both business and computing.
16
Information Systems
• Stakeholders cont..
Systems Analysts
Studies the problems and needs of an organization
Determine how people, data, processes, and information technology can best accomplish improvements for the business
Bridge the communication gap that exists between non technical and technical people involved with building systems.
17
Information Systems
• Stakeholders cont..
Systems Analysts
- Identify the problem- Analyze and understand the problem
- Identify the requirements- Identify the solution- Identify alternative solutions- Design and implement the best solution
- Evaluate the result
What does a systems analystdo?
18
Information Systems
Legacy systems• an existing computer system or
application program• continues to be used because the user
does not want to replace or redesign it• an "antiquated" systems. • Ref : http://en.wikipedia.org/wiki/Legacy_system
19
Legacy systems cont…
Information Systems
• potentially problematic
– often run on obsolete (and usually slow) hardware
– spare parts for such computers become increasingly difficult to obtain
– hard to maintain, improve, and expand because there is a general lack of understanding of the system
– The designers of the system may have left the organization, leaving no one left to explain how it works
– Integration with newer systems may also be difficult because new software may use completely different technologies.
20
Legacy systems cont…
Converted to satisfy new environments
Old technology
New technology
Support old business requirements
Support new business requirements
Old standard
New standard
New functionality
Old system
Y2K?
Euro?
New system
Y2K free
Euro
Information Systems
21
Information SystemsLegacy systems cont…
• Many complex legacy systems yet to be upgraded to new technologies because of– Cost,– Skills and– People required
• Force to change – to reflect new or changing business requirements. – Year 2000 problem (Y2K)– Euro conversion
22
Information SystemsLegacy systems cont.
Y2K problem
– Many computers and applications stored date with only 2 digits.(e.g. 99 =1999)
– Problems : when the millennium changed(e.g. 03=2003)
Born in 1978Age? -74, 0, 74
1
Types of Information Systems
• Transaction Process Systems (TPS)• Management Information Systems (MIS)• Decision Support Systems (DSS)• Executive Information Systems (EIS)• Expert Systems• Communications and collaboration
Systems• Office Automation Systems
2
Transaction Process Systems (TPS)
• Capture and process data about business transactions
Bank deposit and withdrawal
Airline Reservations
3
Management Information System (MIS)
• Designed for management oriented reporting• Based on transaction processing and
operations of the organization
Inventory reportingProduction scheduling
4
Decision Support System (DSS)
• Helps to identify decision making opportunities• Provides information to help make decisions • Provides its user with decision-oriented
information whenever decision making situation arises.
Executes at workWith DSS
5
Executive Information Systems
• Designed for top-level managers.
• Supports the planning and assessment needs of executive managers.
• Integrates data from all over the organization into “at-a-glance” graphical indicators and controls.
6
Expert Systems
• An expert system is a programmed decision making information system.
• Capture and reproduce the knowledge and expertise of a decision maker
• Simulates the “thinking” of the expert.
I am a I am a humanhuman
7
Communications and Collaboration Systems
• Enables more effective communications between – Workers– Partners– Customers– Suppliers
• Enhance their ability to collaborate
8
Office Automation Systems• Supports the wide range of business office
activities• Provides improved work flow between workers.
facsimileE-Mail
Electronic document
Work group computing Work group scheduling
1
Information technology Features
Centralized Systems
- All the components are hosted by a central, multi user system- User interact with the host computer via terminals- Virtually all of the actual processing and work is done on the host computer.
I have all system data
I am doing all processing
Provide interfaces
Databases
2
Information technology features
Distributed Systems
- Components are distributed across multiple locations and computer networks
- Processing work load required to support these components are distributed across multiple computers on the net work.
Distributedto multiple locations
-- Components of an information system -- Processing workload required to
support the components
3
Distributed Systems1. Client Server Systems
The presentation, presentation logic, application logic, data manipulation and data layers are distributed between client PC’s and one or more servers.
AccountsSales
Design
Construction
Client Computers :
Any combination of personal Computers or Workstations, “sometimes connected”
4
Distributed Systems
Client Server Systems cont..
Clients may be thin or flat
Acts only as a terminal
Almost all PCs
e.g. Windows terminal
5
Distributed Systems
2. File server Architecture
– A LAN (Local area network) based solution– A server computer hosts only the data layer– All other layers are implemented on the client
PC.– Practical only for small database applications
shared by relatively few users
6
Distributed Systems3. Network Computing Systems• Presentation and presentation logic layers are implemented in a client
side web browser • The presentation logic layer then connects to the application logic
layer that run on an application server,• Subsequently connects to the database server/s
7
Processing Types 1. Batch Processing
•Data about many transactions is collected as a single file which is then processed
•The data entered is collected into files called batches.
•Each file is processed as a batch of many transactions.
Super market-Batch processing
8
Processing Types2. Online Processing
ATM-Real time processing
The data about a single transaction is processed immediately.
1
CS-1st Year
Systems Analysis and Design
G.K.A. Dias
University of Colombo School of Computing
2
System Development Life Cycle (SDLC)
Problem Definition
System AnalysisMaintenance
System Testing System Design
System Implementation
3
System Development Life Cycle (SDLC) • A systematic approach to software development• Composed of several phases,
– Problem Definition - identifies and defines a need for the new system
– System Analysis - analyzes the information needs of the end users
– System Design - creates a blueprint for the design with the necessary specifications for the hardware, software, people and data resources
– System Implementation- creates and programs the final system
– System testing - evaluates the system's actual functionality in relation to expected or intended functionality.
– Maintenance – keeping the system up to date with the changes in the organization and ensuring it meets the goals of the organization
4
Why we need a life cycle in systems development?
• to avoid failures like unclear objectives, cost overruns, and
• to maintain cheaply and enhance cost effectively
• to ease the process of building a system
• to build high quality systems that meets customer expectations, within time and cost estimates
• to work effectively and efficiently in the current and planned information technologyinfrastructure
1
Sequential or Waterfall development approach
Problem Definition
Requirement Analysis
System Design
System Development
System Testing
Maintenance
• An approach to system analysis and design
• Completes each phase one after another and only once.
2
Problem Definition Provides a broad statement of user requirements in users terms, or what the users expect the system to do
Project goals
project bounds are set during this phase. Defines what part of the system can be changed by the project and what parts are to remain same.
Project bound
Specify the resources to be made available for the project (resource limits).
Projectlimits
3
System Analysis
• The study of a business problem domain to recommend improvements
• Specify the business requirements and priorities for the solution
• Business area is studied and analyzed to gain more information
• Produces a statement of the system users’business requirements, expectations and priorities for a solution to the business problem
4
System Analysishow the current
system works and what it does
Producing a detailed model of what the new system will do and how it will work.
Producing a high-level description of the system
5
System Design• The specification or construction of a technical, computer
based solution for the business requirements identified in a system analysis
• Initially explore alternative technical solutions• Develops the technical blueprints and specifications
DesignAnalysts
6
System Design
• Things to be done:• Select equipment• Specify new programs or
changes to existing programs
• Specify new database or changes to existing database
• produce detailed procedures
Design
7
System ImplementationIndividual system components are built and testedData and tools are used to build the systemUser interfaces are developed and tried by users Database is initialized with data
SystemAnalysts
8
System testingTest and evaluate results, and the system ready to be delivered to the user/client.
9
Maintenance
Eliminate errors in the system during its working life.
Fixing any bugs and problem found by users
Tune the system to any variations in its working environment
10
Problems with waterfall cycle
It has a rigid design InflexibleIt has a top-down procedureOne phase must be completed before the next phase startsNo phase can be repeatedTime consuming
11
Criticisms fall into the following categories:
Real projects rarely follow the sequential flow that the model proposes.
At the beginning of most projects there is often a great deal of uncertainty about requirements and goals, and it is therefore difficult for customers to identify these criteria on a detailed level. The model does not accommodate this natural uncertainty very well.
12
Criticisms fall into the following categories: cont…
Assumptions made in the early phases no longer hold
Some of the early work is incomplete
Something was overlooked or not completely understood.
13
Modified Waterfall ModelProblem Definition
Requirement Analysis
System Design
Implementation
System Testing
Maintenance
14
Modified Waterfall Model• Allow some of the stages to overlap, such as the
requirements stage and the design stage
• Make it possible to integrate feedback from one phase to another
• Incorporate prototyping.
• Verification and validation are added.– Verification checks that the system is correct (building the
system right). – Validation checks that the system meets the users desires
(building the right system).
• Progress is more difficult to track.
15
Iterative development approach• An approach to systems analysis and design
• Completes the entire information system in successive iterations
• Each iteration does some – Analysis– design – Construction
• Allows versions of usable information to be delivered in regular and shorter time frames
16
Iterative development approachComplete problem definition
Some System Analysis
SomeSystemDesign
Some System
Implementation
MoreSystem Analysis
MoreSystemDesign
More System
Implementation
Still moreSystem Analysis
Still moreSystemDesign
Still more System
Implementation
Repeat until no additional iterations needed
Iteration # 1
Iteration # 2
Iteration # 3
1
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
SystemDevelopmentInvolved
2
• P2: Use a problem-solving approach.
# Study and understand the problem and its context
# Define the requirement of a suitable solution.
# Identify candidate solutions that fulfill the requirements and select the best solution.
# Design and/or implement the solution.
# Observe and evaluate the solution’s impact, and refine the solution accordingly.
3
• P3: Establish phases and activities.
• All methodologies prescribe phases and activities• The number and scope of phases and activities may
vary.• The Phases are
# Scope definition # Problem analysis# Requirement analysis#Logical design# Decision analysis# Physical Design# Construction &Testing # Installation & Delivery
4
• P4 : Document through out Development
– An ongoing activity of recording facts and specifications for a system for current and future reference
– Documentation enhances communications and acceptance
– Stimulates user involvement and reassures management about progress
– Reveals strengths and weaknesses of the system to multiple stakeholders.
5
P5: Establish standards.
# Quality# Documentation
#Information Technology# Automated tools
6
• P6 :Manage the process and Projects
Process Management
– Ensures that an organizations chosen process or management is used consistently on and across all projects
– An ongoing activity• Documents• Teaches• Oversees the use of • Improves
– Concerned with • Phases• Activities• Deliverables• Quality Standards
An organization’s chosen methodology
For system development
7
• P6 :Manage the process and Projects Cont….
Project Management
– Process of• Scoping• Planning• Staffing• Organizing• Directing• Controlling a project
– ensures that an information system is developed • at minimum cost, • within a specified time frame and • with acceptable quality.
8
P7:Justify systems as Capital Investments.
# Cost-effectiveness
– Obtained by striking a balance between the lifetime cost of Developing, Maintaining, Operating an information system and the benefits derived from that system
– measured by cost-benefit analysis– Performed throughout the system development
IScost
# Risk management
• The process of identifying, evaluating, and controlling, what might go wrong in a project before it becomes a threat
• Driven by risk analysis or assessment
9
Cancel
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.
10
P9:Divide and conquer.
# divide a system into subsystem and components
--- Easily to conquer the problem --- Easy to build a large problem
11
P10: Design systems for growth and change.# the business, their need and priorities change over time
# thus, information system that supports a business must also change over time
# good methodologies should embrace the reality of change
# the systems should be designed to accommodate both growth and changing requirements
#the systems should be designed to scale up and adapt to the business
1
Major components of system development
• Methodology • Modeling Methods or Techniques• Tools
Major Components
2
Methodology• A set of
– Activities– Methods– Best practices– Deliverables– Automated tools
• Used by stakeholders to– Develop– Continuously improve
Information systems and
Software
3
Methodology
• Provides the framework • Has a predefined set of steps• Ensures that systems are built in the most
effective way
e.g. SSADM, RUP
4
Methodology
Modeling Methods or Techniques
Class Diagram, Use Case Diagrams etc.
Tools
Rational Rose,Rational Suit
Eg .Rational Unified Process
5
Methodology
• Uses tools and modeling methods
Tools
Methods
Most Effective Way of Building
6
Methodology
Supported by Modeling Methods or Techniques
• Techniques used to implement the Methodology.• Provides the descriptions of the business system
requirements from various view points.
7
Life Cycle vs. Methodology
• The system development methodology consists of several well-defined steps.
• When following a design methodology, a designer can select appropriate modeling method related to each step.
8
Life Cycle vs. Methodology
System Development
LIFE CYCLE STAGE
A System Development
Process
using
Methodology
•A system development life cycle divides the life of an information system into two major stages,
• Systems development(consists of system analysis, system design, system implementation and testing phases)
and • Systems operation and support (maintenance)
using
Conversion
Obsolescence
Lifetimeof a
System
LIFE CYCLE STAGE
System Operationand
Maintenance
Information Technology
9
Life Cycle vs. Methodology
• A system development methodology is a very formal and precise system development process that defines – a set of activities, – methods, – best practices, – deliverables, – and automated tools
10
Modeling MethodsA set of techniques used to implement a Methodology
• Data Flow Diagrams -– A process model– Depict the flow of data through a system and the work
performed by the system
• Entity Relationship Diagrams –– A data model– Depict data in terms of entities and relationships
described by the data– Consists of several notations
• Structure Charts etc.Different Views of the System
11
• Software systems • Assists analysts and designer to build
information systems• They will not replace Systems Analysts.
e.g. Easy Case, Rational Rose
Tools
12
ToolsGeneral Aim :
Decrease the human effort required to develop the software.
Increase the quality of software
Tools will support methodologies but will not replace system analysts.
1
Information Systems Development
System owners & system users initiate most Information Systems Development projects
An undesirable situation or problem/s in the organisation which hinders their progress or achieving the desired goals may be one reason to develop a new system
It could also be that a new opportunity has been identified which would bring more benefits to the organisation
2
Information Systems Development……
A new requirement that may be imposed on the organisation by directives issued by Government/Management/some other External Influence
3
ScopeDefinitionThis is the first stage/phase of an Information
Systems Development project
The purpose of the scope definition is twofold.
1. Is this problem/opportunity/directive worth looking at?
2. If the above is worthwhile doing then identifying the size and boundaries of the project, the project vision, any constraints, the participants, budget & the schedule
4
ScopeDefinitionScope definition should include:
1. The scope of the project which may later change during the development life cycle(Scope is the boundaries of a project – the areas of a business that a project may or may not address)
Project scope can be easily defined using:
What type of data: e.g. For a sales Information System – customer data, product data etc.
5
What are the business processes in the system(customer management, order entry, order fulfillment) etc.
What are the System interface with users, locations & other systems (e.g. Customers, Sales reps, Regional sales offices, Accounts receivable etc.)
Perceived problems (as perceived mostly by system users)
Opportunities (which would bring more benefits to the organization)
6
Directives that triggered the project(Government regulations or mergers)
2. Project worthiness (Is this project worth doing? Feasibility studies)
3. Schedule & budget
4. Constraints – budget limits, deadlines, availability of human resources etc.
5. Communication of the project plan or project proposal (Communication skills of presenters are very important)
7
At this stage it is not necessary to spend a lot of time preparing this document and modeling or prototyping may not be required.
Refer to the Sample Problem Statement
Fig. 5 – 8 in Ref 1 p171.
8
Finding Problems to Solve• Requirements solve problems
– E.g. A mother takes her young daughter to the doctor because the child is ill. The first thing the doctor tries to do is, identify the problem.
• The child has – an earache, – a fever, – a runny nose.
Are these the problems?
9
• E.g. Cont…• The mother has been giving the child pain medicine to
ease the pain,• But still the child is not well. • The mother is treating
– the symptoms and – NOT the real problem.
• However, the doctor, – analyze the symptoms further– examine the child – Make the conclusion
Finding Problems to Solve
Conclusion (Root cause of the child’s
symptoms) :AN EAR
INFECTION
10
Finding Problems to Solve• E.g. Cont…
– Problem is identified and analyzed, – Recommend a cure (solution)
• An antibiotic can be prescribed • Determine constrains on the medicine that can prescribe.
– How old is the child? – How much does she weigh? – Is the child allergic to any medications? – Can she swallow pills?
• Once the constraints are known, a prescription can be generated.
• Systems analysts use the same problem-solving process as a doctor uses, but instead of diagnosing medical problems they diagnose system problems.
1
Feasibility Study • Feasibility
– The measure of how beneficial / practical an information system will be to an organization
– Should be measured through out the life-cycle
• Feasibility Analysis– The process by which the feasibility is measured– An ongoing evaluation of feasibility at various
checkpoints in the life cycle
2
Feasibility Checkpoints in the Software Development Life Cycle
• Feasibility of a project can be changed during the system development.
• For reevaluate feasibility, there are different checkpoints in the development.
• A project may be canceled, revised or continued at any checkpoint, despite whatever resources have been spent.
3
Feasibility Checkpoints
• Systems Analysis – Scope Definition Checkpoint
• Systems Analysis – Problem Analysis Checkpoint
• Systems Design – Decision Analysis Checkpoint
4
Scope Definition Checkpoint• Measure of the urgency of the problem. • Find the first-cut estimate of development
costs.• Answer the question,
– Do the problems warrant the cost of a detailed study & analysis of the current system?
5
Problem Analysis Checkpoint
• Occurs after a more detailed study and problem analysis of the current system
• Can make a better estimate of the development cost and benefits
Minimum Value of solving a problem = cost of problem
6
Decision Analysis Checkpoint• Represent major feasibility analysis activities
• Charts one of many possible implementations as the target
• Alternate solutions are defined in terms of,• Input/Output methods• Data storage methods• Hardware requirements• Software requirements• Processing methods• People implications
7
Decision Analysis CheckpointRange of options – Evaluated by the analyst
• Leave current system alone• Re-engineer the manual process• Enhance existing computer processes• Purchase packaged software• Design and construct a new computer-
based system
After defining these options, each option should be analyzed.
8
Tests for Feasibility
• Operational Feasibility• Cultural / Political Feasibility• Technical Feasibility• Schedule Feasibility • Economic Feasibility• Legal Feasibility
9
Operational feasibility. •A measure of how well a solution meets the identified system requirements to solve the problem.
•Take advantage of the opportunities identified during the scope definition and problem analysis phases.
– Will the solution fulfill the users’ requirements? To what degree?
– How will the solution change the users’ work environment?
– How do users feel about such a solution?
10
Cultural (or Political) Feasibility
• A measure of how well the solution will be accepted in a given organizational climate
• Deals with how the end users feel about the proposed system.
• Evaluates whether a system will work in a given organizational climate.
11
Technical feasibility.• A measure of the
– Practicality of a technical solution– Availability of technical recourses and expertise
• Addresses three major issues – Is the proposed technology or solution practical?– Do we currently possess the necessary technology
(Hardware/Personnel) ?– Do we possess the necessary technical expertise?
12
Schedule feasibility• A measure of how reasonable a project time table is.
– Can the solution be designed and implemented within an acceptable time period?
– how much time is available to build the new system?
– when it can be built ?
• Mandatory / Desirable deadlines.
13
Economic feasibility. • a measure of the cost-effectiveness of a project
– Is the solution cost-effective?– Whether the solution will pay for itself?– How profitable the solution is?
• Once the specific requirements and solutions have been identified
– Weight the costs and benefits of each alternative (Cost benefit Analysis)
e.g. Personnel cost, Computer cost, Training, Software, Tangible and Intangible benefits
14
Legal Feasibility
• A measure of how well a solution can be implemented within existing legal and contractual obligations.
• understand potential legal and contractual ramifications of the system
* copyright law* non-disclosure clauses and non-compete clauses* code ownership (if developed with outside
assistance) -- be VERY specific* labor laws* foreign trade, and labor regulations* Financial & Accounting standards* governmental constraints, and pending legislation
1
Cost Benefit Analysis• Determines the cost effectiveness of a project or
solution
• The purpose of a cost/benefit analysis is to answer questions such as:
- Is the project justified (because benefits outweigh costs)?
- Can the project be done, within given cost constraints?- What is the minimal cost to attain a certain system?- What is the preferred alternative, among candidate
solutions?
2
How much will the system cost?• Two types of costs, costs associated with
– Developing the system• Can be estimated from the outset of a project• Should be refined at the end of each phase• One time costs (will not recur after the project has
been completed – Operating a system
• Can be estimated only after specific computer-based solutions have been defined
• Recur throughout the lifetime of the system
3
How much will the system cost?
• System development Cost Categories– Personnel costs– Computer Usage– Training– Supply, duplication, and equipment costs– Cost of any new computer equipment and software
4
What benefits will the system provide?
• Benefits – increase profit– Decrease costs– Can be classified as
• Tangible benefits – a benefit that can be easily quantified.
• Intangible benefits – a benefit that is believed to be difficult or impossible to quantify
5
Is the proposed system cost effective
• Cost effectiveness techniques
– Payback Analysis– Return on Investment Analysis– Net present value Analysis
6
Payback Analysis• A technique for determining if and when an investment
will pay for itself• How long will it take (usually, in years) to pay back the
project, and accrued costs:– Total costs (initial + incremental) - Yearly return (or savings)
7
Return-on-Investment (ROI) Analysis
• A technique that compares the lifetime profitability of alternative solutions
Lifetime benefits - Lifetime costsLifetime costs
8
Net Present value Analysis
• Compares the annual discounted costs and benefits of alternative solutions
• Spreadsheets such as Excel, Lotus 1-2-3 can be used to calculate all these values
1
Feasibility Analysis of Candidate systems
• During the decision analysis phase of system analysis, – Identifies candidate system solutions – Analyses the solution for feasibility
• Can use two alternatives to compare and contrast candidate system solutions – Candidate System Matrix– Feasibility Analysis Matrix
Use A Matrix Format
2
Candidate Systems Matrix• Used to document similarities and
differences between candidate systems
– Compare candidate systems– Offers no analysis– Columns represent candidate solutions– Rows represent characteristics that
differentiate the candidates
3
Candidate Systems Matrix
• Example
Candidate 1 Name
Candidate 2 Name
Candidate 3 Name
StakeholdersKnowledgeProcessesCommunications
TemplateTemplate
4
Candidate Systems Matrix• Example
Candidate 1 Name
Candidate 2 Name
Candidate 3 Name
StakeholdersKnowledgeProcessesCommunications
Identify how the Identify how the system will interact system will interact with people, and other with people, and other systemssystems
TemplateTemplate
5
Candidate Systems Matrix• Example
Candidate 1 Name
Candidate 2 Name
Candidate 3 Name
StakeholdersKnowledgeProcessesCommunications
Identify how data stores Identify how data stores be implemented, be implemented, inputs will be captured, inputs will be captured, outputs will be generatedoutputs will be generated
TemplateTemplate
6
Candidate 1 Name
Candidate 2 Name
Candidate 3 Name
StakeholdersKnowledgeProcessesCommunications
Identify How (manual) Identify How (manual) business process will business process will be modified, how be modified, how computer processes computer processes will be implementedwill be implemented
Candidate Systems Matrix• Example
TemplateTemplate
7
Candidate Systems Matrix• Example
Candidate 1 Name
Candidate 2 Name
Candidate 3 Name
StakeholdersKnowledgeProcessesCommunications
Identify how Identify how processes and data processes and data will be distributed.will be distributed.
TemplateTemplate
8
Feasibility Analysis Matrix
• Used to rank candidate systems– Columns represent candidate response– Rows correspond to the feasibility criteria– Cell contain the feasibility assessment notes
for each candidate
9
Feasibility Analysis MatrixWeighting Candidate1 Candidate2 Candidate3
Description
Operational Feasibility
Cultural Feasibility
Legal Feasibility
Technical Feasibility
Economic Feasibility
Schedule Feasibility
Weighted Score
1
The System ProposalA report / presentation of a recommended solutionUsually a formal written report or oral presentationIntended for system owners and users
Formal writtenreport
Oral presentation
System ownersAnd
End Users
2
Written Report• The most abused method used by analysts• Consists of
– Primary Elements • Actual information• E.g. introduction, conclusion
– Secondary Elements• Package the report• Reader can easily identify the report and its primary elements• Add a professional polish.
3
Secondary elements for a written report
Letter of transmittalTitle pageTables of contentsList of Figures, illustrations, and tablesAbstract or executive summary
(primary elements are presented in this portion of the report)Appendixes
4
Formal Presentation• A special meeting
• Used to sell new ideas and gain approval for new systems
• Can be also used forSell a new system, sell new ideas, sell change, head off criticisms, address concerns, verify conclusion, clarify facts and report progress.
Problems at the end of Chapter 11 in Ref. 1
1
Requirements AnalysisIdentifying Requirements
Correct systems can only be built if you know exactly what the
user needswhat the system must do
Therefore most important factor in building correct systems is to first clearly define what the system must do
For that we should have a better communication between system users and the analyst.
Systems Analyst
2
Requirements Analysis
Importance of Communication
- Analyst must ensure that no ambiguities arise, during the discussions between various people involved in the analysis phase
- Different jargon used by different people may cause problems
- Reduce misunderstandings between the end-users and developers
3
Requirements AnalysisExample:
Ambiguous Requirement Statement
Identify the mode of transportation to transfer a single individual from home to place of work
ManagementInterpretation IT Interpretation User Interpretation
4
Disadvantages of not identifying user requirements correctly
• The system will exceed time schedules and cost schedules
• The user may not be satisfied with the system requirements. Therefore, they may not use the system
• The cost of maintenance may be excessively high• The system may be unreliable and prone to errors• The reputation of the IT staff on the team will be
tarnished
5
Process of Requirements Discovery
• Consists of– Problem discovery and analysis (already
discussed in Chapter 3)– Requirements discovery (the process and
techniques used by systems analysts to identify or extract system problems and requirements from the user community )
– Documenting and analyzing requirements– Requirements management
6
Requirements Discovery
• Can start to define requirements after understanding the problem
• Must use effective methods for gathering information (Fact Finding)
• After completing the process of fact finding use various tools to document the requirements
7
Requirements Discovery…
• The process and techniques used by systems analysts to– Identify– Analyze– Understand
SystemRequirements
Systems Analyst
Systems UserSystems Owner
Works with
Works with
8
Requirements Discovery…
System Requirements
Specify what the information system must do, or what property / quality the system must have
9
Requirements Discovery…
System Requirements
Functional Requirements
Specify what the information system must do
Non functional RequirementsSpecify a property / quality the system must have
e.g. user friendliness, Security etc. Refer page 209 Ref1 table 6-1
10
Requirements Discovery…
System requirements can be gathered by– using discussions with users, about their
requirements– building systems that satisfy these requirements
11
Requirements Discovery…System requirements should meet the following criteria
– Consistent: not conflicting / ambiguous– Complete: describe all possible system inputs and
responses– Feasible: satisfied based on the available resources
and constraints – Required: truly needed and fulfill the purpose of the
system– Accurate: stated correctly– Traceable: directly map to the functions and
features of the system– Verifiable: defined so that they can be demonstrated
during testing.
12
Documenting and Analyzing Requirements
• Assemble or document the gathered information / draft requirements in an– Organized– Understandable– Meaningful way.
• Provide direction for the modeling techniques
13
Documenting and Analyzing Requirements…
• Documenting the draft requirements– Use various tools to draft the initial findings
• Use cases: describe the system functions from the external users’ perspective
• Decision tables: document an organization’s complex business policies and decision making rules
• Requirement tables: document each specific requirement.
14
Documenting and Analyzing Requirements…
• Analyzing Requirements– Fact finding activities produce requirements that
are in conflict with one another
– Requirements analysis activity• Discover and resolve the problems with the
requirements • Reach agreement on any modifications to satisfy
the stakeholders
15
Requirements Management
• Help to alleviate the many problems associated with changing requirements– Emerging new requirements– Changing existing requirements
• Encompasses – Policies– Procedures– Processes
Refer Page 215 Ref1
1
Fact Finding TechniquesFact-Finding
A formal processUses techniques to collect / gather information about
System requirementsProblemsPreferences
Also known as Information gatheringUsed across the entire development cycleExtremely critical in the requirement analysis phase
2
Fact Finding Techniques…
Sampling of Existing documents
Research and site visits Observations of
the work environment
QuestionnairesInterviews
Prototyping
Joint requirements planning
3
Fact Finding Ethics
• Come across sensitive datae.g. employee profile: salaries, performance history, medical history, career plans etc.
• Leaving sensitive documents in plain view on the desks or publicly discuss sensitive data could cause great harm to the organization
• Therefore, analysts must take great care to protect security and privacy of any facts
4
Fact Finding Techniques…
First document, that analyst should seek out is the organizational chart
Should be analyzed to make sure that they are relevant and up-to-date
Sampling of existing Documentation– When you are studying an existing system, you can get
a good idea by studying existing
Documentation FilesForms
5
Fact Finding Techniques…
Research and Site Visits
Thoroughly, research the problem domain.Identify the material that are relevant and reliable
Intranets
Good sources of information
Computer tradeJournals
Reference booksInternet
World Wide Web
6
Observations of the work environmentSystems Analyst participates in or watches a person perform activities to learn about the system
Fact Finding Techniques…
Often used when validity of data collected through other methods is in question or the complexity of certain aspects of the system prevents a clear explanation by the end users.
7
Fact Finding Techniques…
Observations of the work environment…
Advantages
Relatively inexpensive
Data gathered by observation can be highly reliable
Allows systems analyst to do work measurements
Systems analyst is able to see exactly what is being done
8
Disadvantages
I don’t like being watched
Observations of the work environment…
Fact Finding Techniques…
People usually feel uncomfortable when being watched.
Work being observed may not involve the level of difficulty or volume normally experienced during that time
Some tasks may not always be performed in the manner in which they are observed by the system analyst. Etc…
Refer page 218 Ref1 – The Railroad Paradox
1
Questionnaires
Advantages :
Special purpose documents Allow the analysts to collect information and opinions from a large audience.
Relatively inexpensive way of gathering data.
Most questionnaires can be answered quicklyAllow individuals to maintain anonymity
Responses can be tabulated and analyzed
Fact Finding Techniques…
quickly etc.
2
Disadvantages:Questionnaires…
The number of respondents is often lowMostly suited for closed questionsNo guarantee that an individual will answer or
expand on all the questions
Good Questionnaires are difficult to prepare
No immediate opportunity to clarify a vague or incomplete answer to any question.
Fact Finding Techniques…
3
Fact Finding Techniques…
Questionnaires…
Types of Questionnaires
Free-format : A question is asked, and the respondent records the answer in the space provided after the question.
Fixed-format : contains questions that require specific responses from individuals
4
Fact Finding Techniques…
Questionnaires…There are 3 types of fixed-format questions
1. multiple-choice questions: Given several answers to select one. e.g. Yes, No type
2. rating questions: Given a statement and asked to use supplied responses to state an opinion.
3. ranking questions: Given several possible answers to be ranked in order of preference or experience
Refer Page 221-222 Ref1
5
Fact Finding Techniques…
Interviews– Most commonly used technique in analysis– Collects information from individuals face to face.– Must possess good human relations skills for
dealing effectively with different type of people
- Can be used to achieve any of the following goals:* find facts * get the end-user involved* verify facts * clarify facts* generate enthusiasm * identify requirements* solicit ideas and opinions.
6
Interviews…Advantages
Mot
ivat
ion
Fact Finding Techniques…
Gives the analyst an opportunity to motivate the interviewee to respond freely and openly to questions.Allow the analyst to look for more feedback from the interviewee.Permit the analyst to ask questions from each individual etc.New ideas may arise
7
Disadvantages
Very time consuming. Therefore costly approach
Success of interviews is highly dependent on the systems analyst’s human relations skill.
Interviews may be impractical due to the location of interviewees etc.
Interviews…
Fact Finding Techniques…
8
Types of InterviewsUnstructured interviews
conducted with only a general goal / subject in mind
contain only a few questions if any, specific ones
Interviewer counts on interviewee to provide a frame work and direct the conversation
Structured interviewsinterviewer has a specific set of questions to ask of
the interviewee
Interviews…
Fact Finding Techniques…
9
Fact Finding Techniques…
Interviews…
Types of Interview Questions
• Open-ended questions– Allows the interviewee to respond in any way
that seems appropriate
• Closed-ended questions – Restrict answers to either specific choices or
short, direct responses
1
Fact Finding Techniques…
How to conduct an Interview?Select Interviewees
Interview the end users of the information system you are studying.
A formal organizational chart will help you identify these individuals and their responsibilities.
Always make an appointment with the interviewee.
Higher the management level of the interviewees, less time should be spent.
Interviews…
2
Interviews…
Fact Finding Techniques…
Prepare for the InterviewPrepare an interview guide - checklist of specific questions interviewer will ask the intervieweeAvoid the type of questions such as:
Loaded questions e.g Do you need to include both of these columns for this report?
Leading questions e.g. You are not going to use this operator code, are you?
Biased questions e.g. How many codes do we need for food classification in the inventory file? I think 20 should cover it ?
How to conduct an Interview?
3
Fact Finding Techniques…
Interview question guidelines :Use clear and concise languageDon’t include your opinion as part of a questionAvoid long or complex questionsAvoid threatening questionsverify before you leave
The purpose of the interview is to investigate, not to evaluate or criticize
Prepare for the InterviewHow to conduct an Interview?
Interviews…
4
Fact Finding Techniques…
The actual interview consist of three phases:Conduct the Interview
How to conduct an Interview?Interviews…
Interview Opening : Intended to influence or motivate the interviewee to participate
Interview body : Obtain interviewee’s response to your list of questions
Interview conclusion : Express your appreciation. Important for maintaining good relationship and trust.
5
Fact Finding Techniques…
Prototyping
– Building a small working model of the users’requirements or a proposed design for an information system
– Usually a design technique
– Can also be used to perform fact-finding requirement analysis (discovery prototyping)
– Allows analyst to quickly create mock forms and tables to simulate the implemented system.
6
Fact Finding Techniques…
Prototyping…Analyst will
develop a model
following an initialanalysis
A repeat visit may thenvalidate
the model with the user
Agreement is reached
on the model
Further detailed
data may be gathered to elaborate the model
7
Fact Finding Techniques…
Prototyping…
This iterative approach serves a number of purposes:
there is always a record of information gathered to date ensures correctness of the information as you continually verify the results with the userAnalyst does not get too far ahead using wrong assumptions
8
Fact Finding Techniques…
Prototyping…
AdvantagesAllow users and developers to experiment with the
software and develop with an understanding
Helps to determine feasibility and usefulness of the system
Minimize the time spent for fact-finding and help define more stable requirements.
9
Fact Finding Techniques…
Prototyping…
DisadvantagesDeveloper may need to be trained in the
prototyping approach
Prototype can only simulate system functionality and are incomplete in nature.
May extend the development schedule
Increase the development costs
10
Highly structured group meeting are conducted to analyze problems and define requirements.
JRP is a subset of a more comprehensive joint application development or JAD technique
Joint Requirement Planning (JRP)
Fact Finding Techniques…
11
Joint Requirement Planning (JRP)
Fact Finding Techniques…
JRP ParticipantsSponsorServe as JRP champion. Single person in top
management who makes the final decision
Facilitator Single individual who plays the role of the leader or
facilitator. Someone who has excellent communication skills
12
Fact Finding Techniques…
Joint Requirement Planning (JRP)…
JRP Participants…Users and ManagersNumber of participants from the user and management.
Both users and managers are relied on to ensure that their critical success factors are being addressed
Scribes Those who are keeping responsible for keeping records
pertaining to everything discussed in the meeting. System analysts frequently play this role
13
Fact Finding Techniques…
Joint Requirement Planning (JRP)…
JRP Participants…IT Staff
IT personnel who primarily listen and take notes regarding issues and requirements. Usually consists of members of the project team.
Refer page 229-234 Ref1
14
Fact Finding Techniques…
Document Flow Diagrams– Used to identify physical movement of
documents.
Purchase Order
….…..
PurchPurch..Dept.Dept.
SupplierSupplier
15
Fact Finding Techniques…
Document Flow Diagrams…
– shows • where the document comes from, • where it goes to , and • what it is called.
Purchase Order
….…..
PurchPurch..Dept.Dept.
SupplierSupplier
16
Fact Finding Techniques…
Document Flow Diagrams…
Used to examine the flow of documents within the existing system.
Example:Purchasing Purchasing
SystemSystem
OrderInvoiceDelivery note
Delive
ry no
te
SupplierSupplier
PurchPurch..Dept.Dept.
StoresStores
17
Fact Finding Techniques…
System boundary
Order
InvoiceDelivery note
Delive
ry note
SupplierSupplier PurchPurch..Dept.Dept.
StoresStores
Document Flow Diagrams…
Example:Purchasing SystemPurchasing System
18
Fact Finding Techniques…
System boundary
Order
InvoiceDelivery note
Delive
ry note
SupplierSupplier PurchPurch..Dept.Dept.
StoresStores
Document Flow Diagrams…
Example:Purchasing SystemPurchasing System
MaintenanceMaintenance
19
Fact Finding Techniques…
Document Flow Diagrams…
Advantages / Usefulness
Used to identify the documents in the systemIdentify the flow of documents To understand the workflow of the existing system Used to define the system boundary Used to draw Data Flow Diagrams after further analyzing
20
Documentation
Documentation is both a communication tool and a management tool.
It is a communication tool :– because it contains a repository of all work done to date and
makes it available to all persons working on related parts of a large project.
– Such a repository can prevent unnecessary repetitions when someone leaves the project team.
– Proper documentation ensures that all the information developed about the system is always available to new people joining the project.
21
Documentation…
Documentation is also a management tool:
It supports management in two ways:
– gives access to the latest work to all project personnel and thus reduces the chance of work having to be repeated.
– is the only project deliverable, specially in the early project phases, and thus serves to determine project status and progress. Is also a part of the phase output.
22
Documentation…
• Requirement Definition Document
– A formal document that communicates the requirements of a proposed system to key stakeholders
– Serves as a contract for the systems project
– Final deliverable of the requirements analysis phase
– Also known as requirements statement, requirements specification, and functional specification.
23
Documentation…
• Requirement Definition Document
– Consists of • Functions and services the system should provide• Nonfunctional requirements (system’s features,
characteristics, and attributes)• Constraints• Information about other systems with which the system must
interface– No standard format for the document
Refer page 214 Ref1 Figure 6-2 (Sample Requirements Definition Outline)
24
Documentation…
• Requirement Definition Document
– Readers of the document
• System Owners and Users (to specify their requirements and any changes that may arise)
• Managers (to prepare project plans and estimates)
• Developers (to understand what is required and to develop tests to validate the system)
1
Modeling Methods
How to simplify, present / document a complex
problem?
The answer is just Simple, use MODELS
Model : A pictorial representation of reality.
SAMPLE FLOOR PLAN
2
Process Modeling
Introduction
– Technique for organizing and documenting the structure and flow of data through a system’s process and the logic, policies, and procedures to be implemented by a system’s process.
– Consists of various types of process models.
3
Models
Logical Models Physical Models
Process Modeling
Other names: ~Essential model~Conceptual model ~Business model
Other names: ~ Implementation Model~ Technical model
4
Logical Process Models• Show what a system is or does.• Implementation – independent
– depict the system independent of any technical dependence
• Illustrates the essence of the system• Used to Depict business and non technical
requirements• Used to document system’s Process focus from the
systems owners’ and users’ perspective• Encourage creativity• Reduce the risk of missing business requirements• Allows better communication with end-users in non-
technical / less technical languages.
5
Physical Process Models
• Show not only what a system is or does. But also how the system is physically and technically implemented.
• Implementation –dependent
• Reflect technology choices and the limitations of those technology choices
• Used to Depict technical designs
6
Program Structure ChartsLogic Flow ChartsDecision Tables, are some
examples for various types of process models found in early software engineering methods and programming.
Data Flow Diagram : Popular System Analysis Process Model.
Process Modeling
7
Data Flow Diagrams
• Shows the flow of data through the system and the processing performed by the system
• Other words : bubble chart, transformation graph, and process model
• Some analysts draw a decomposition diagram before DFD
• There exist several competing symbol sets for DFDs.– Gane and Sarson notation is widely popular
8
Elements in a DFD(Gane and Sarson Symbols)
SupplierSupplierPurchasingSystem
An External AgentA Process
OrdersOrders
A Data Store
Invoice
A Data Flow
9
Elements in a DFD(Gane and Sarson Symbols)
- A Process is work performed by a system In response to incoming data flows or conditions and it transforms incoming data flow into outgoing data flow.
A Synonym is transform
Process name
A Processes orWork to be done
Represented by a rounded rectangle
10
Elements in a DFD(Gane and Sarson Symbols)
Represented by a square
An external agent is an outside person (e.g. supplier, customer), organization unit (e.g. other dept), system (other business systems), or organization (e.g. Bank) that interact with the system. Also called an external entity.
External External AgentAgent
An External Agent
11
Elements in a DFD(Gane and Sarson Symbols)
Represented by a square
External AgentsProvide the net inputs
into the system and receive net outputs from the system being defined.
Externalexternal to the system
being analyzed or designed.
External External AgentAgent
An External Agent
12
Elements in a DFD(Gane and Sarson Symbols)
Data storeData store A Data Store is an “inventory” of data. That is, stored data intended for later use (data at rest). Also known as a file or database.
A Data Store
Represented by the open-end box
13
Elements in a DFD(Gane and Sarson Symbols)
A Data Store
• Data stores should describe “things” about which the business wants to store data.
• These includePersons: Customer, EmployeePlaces: Building, Room, CampusObjects: Book, Machine, ProductEvents: Invoice, Order, Registration, RenewalConcepts: Course, Fund, Stock
14
Elements in a DFD(Gane and Sarson Symbols)
Data flow name
A Data Flow
• Represent inputs or outputs, to or from the processes.• The arrow head indicates the direction of data flow. • Label the arrows with the name of the data that moves through it.• Data in motion
Represented by an arrow
15
The Context Data Flow Diagrams
• A diagram that shows the system as a “black box”and its main interfaces with its environment.
• Used to document the scope of the system
• Also known as environmental model.
ProcessProcess
External External AgentAgent
External External AgentAgent
External External AgentAgent
External External AgentAgent
16
The Context Data Flow Diagrams
• Used to clarify and agree the scope of the investigation
• Shows the interfaces between the system under investigation and the external agents with which it communicates
• Subject to constant change – Because the scope of any project is always
subject to change
17
The Context Data Flow Diagrams
• Can be drawn without considering the Document Flow Diagram
• Need to identify – the data flows and – the external agents needed for the context
diagram
18
The Context Data Flow Diagrams• Think the system as a container• Distinguish the inside from the outside• Ignore the inner workings of the container• Find out the net inputs to the system
– Business transactions a system must respond to
• For each net input determine its source (External Agents)• Find out the net outputs from the system
– Responses produced by the system
• For each net output find the destination (External Agents)• Identify any external data stores,
– Files or databases of other systems
19
Task 1
Identify all sources and recipients of data to/from the system.
20
Task 2
• Identify major data flows to and from the System
21
Task 3
• Convert each source or recipient into external agents
SupplierSupplier
22
Task 4
• Add the data flows between each external agent and the process representing the entire system.
PurchasingSystem
OrderSupplierSupplier
Invoice
Delivery note
23
Data Flow Diagrams
• Draw Context Diagram• Level 0 (Top Level) Data Flow Diagram• Level 1 Data Flow Diagram• Continue up to elementary functions
24
Bank Payment System
Consider a system in a bank whereby account holders get their withdrawals effected.
Whenever an account holder wants to withdraw some cash, he presents a cheque or withdrawal slip.
The account is checked for the appropriate balance.
If balance exists, the cash is paid and the account is updated.
25
Context Diagram
Withdrawal Acknowledgement
Cheque/Withdrawal Slip
BankBankPaymentPaymentSystemSystem
AccountAccountHolderHolder
26
Decomposition
• Is the act of breaking a system into its component subsystems , processes and sub processes.
• Top level function is then decomposed to its component functions
27
Is an act of breaking a system into its component subsystems, processes, and sub processes.
Process Decomposition
0UCSC System
1Payroll sub system
2Registration sub System
1.1Process
2.1Process
1.2Process
2.2Process
1.1.1Sub Process
1.1.2Sub Process
1.1.1.1
1.1.1.2
Decomposition
Diagram
28
Context Diagram
Withdrawal Acknowledgement
Cheque/Withdrawal Slip
BankBankPaymentPaymentSystemSystem
AccountAccountHolderHolder
29
Top Level DFD – Step 1
Withdrawal Acknowledgement
Cheque/Withdrawal Slip
VerifyA/C
Balance
Debit Withdrawal
AccountAccountHolderHolder
30
Top Level DFD – Step 2
Withdrawal Acknowledgement
VerifyA/C
Balance
Debit Withdrawal
AccountAccountHolderHolder
Cheque/Withdrawal Slip
31
Top Level DFD – Step 3
• Identify the Data Stores
Account MasterAccount Master
32
Top Level DFD – Step 4
• Identify the other data flows.Get current balance
Account MasterVerifyA/C
Balance
Current Balance
33
Top Level DFD – Step 4
• Identify the other data flows.Transfer the verified details
Debit Withdrawal
VerifyA/C
Balance
Verified details
34
Top Level DFD – Step 4
• Identify the other data flows.update new balance
Debit Withdrawal
Account Master New Balance
35
Cheque/Withdrawal Slip
Verified DetailsCurrent
BalanceNewBalance
Account MasterAccount Master
1VerifyA/C
Balance
2Debit
Withdrawal
With
draw
al
Ack
now
ledg
emen
t
AccountAccountHolderHolder
AccountAccountHolderHolder
Top Level Diagram
36
Illegal Data Flows
E1 E2
D1E1
E1
A process is A process is needed toneeded to
Exchange dataExchange dataFlows betweenFlows between
ExternalExternalagentsagents
E2
D1E1A process is A process is needed to needed to
Update / useUpdate / useA dataA datastorestore
Illegal data flowsIllegal data flows Corrected data flowsCorrected data flows
37
Illegal Data Flows
D2D1
D1 E1
A process is A process is needed toneeded to
present datapresent dataFrom a From a
data storedata store
D1 E1
Illegal data flowsIllegal data flows Corrected data flowsCorrected data flows
A process is A process is needed toneeded tomove datamove dataFrom one From one Store to Store to anotheranother
D2D1
38
Another Common error
Process 1
No data flow should ever go unnamed
1
CASE STUDYLibrary System
2
Library SystemLibrary supports
– Lending – Cataloging – Registration of Members
and Books– Reservation– Inquiries– Correspondence
All activities are done manually
3
Library SystemTo Analyze and Design a Library System
– What are the Documents in the system?
– Study the physical movements of documents
4
Library System
• Documents in the system
– Application form– Student Id– Membership card– Reminders– Borrowing slips etc.– Reservation ready notice
5
Library System
• Identify the physical movements of documents.– Document Flow Diagram
• Modeling method or technique used to illustrate movements of documents.
Membership application
….…..
StudentStudentLibrarianLibrarian
6
Converting Document Flow Diagrams to DFDs
• What process generates this document flow?• What process receives this document ?• Is the document stored by a process?• Where is the document stored?• Is the document created from stored data?
7
Document Flow Diagrams for the Library System
New memberdetails
System boundary
Mem
ber cardM
em. Card+slip Fine SlipReminder
Stud
ent r
egis
trat
ion
form
Stud
ent c
ard
MemberMember
Admin.Admin.LibraryLibrary
Settle fin
e
StudentStudent
MemberMember
8
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.
9
LibrarySystem
New
member
Details
Member card
Mem. Card+slipRem
inder
Fine
Slip
Settle
fineMemberMember
MemberMember
Admin.Admin.
Context Diagram
10
New member
Details
Member cardMem. Card+slip
Reminder
Fine S
lip
Settle
fine
Lending Returning
MemberRegistration Library
System
MemberMember
MemberMember
Admin.Admin.
Top Level Diagram
11
Top Level Diagram
New member Details
Mem
ber card
Mem. Card+slipReminder
Fine SlipSettle fine
Lending
ReturningMember
Registration
MemberMember
Admin.Admin.
MemberMember
12
Mem. Registration
Borrowing Details
Data Stores
Book Details
13
Top Level Diagram
Mem
ber
card
Mem. Card+slip
ReminderFine Slip
Settle fine
Lending
Returning
MemberRegistration
Mem. Registration Book Details
Borrowing Details
MemberMember
Admin.Admin.
New member details
member details
Book details
Borrowing details
return details Book details
New member Details
14
Documenting Elements in DFD
• Element name is not enough.• More important for processes
You need to convert these into programs
A(int w){
a=a-w;
}
Debit Withdrawal
15
The Functional Decomposition Diagram
• Shows the top-down functional decomposition / the structure of the system
• Break the system into its component subsystems , processes and sub processes
• Top level function is then decomposed to its component functions
• Provides an outline for drawing the data flow diagrams
16
The Functional Decomposition Diagram
The SystemThe System
The SystemThe System
Function1Function1 Function2Function2 Function nFunction n
Event1Event1 Event2Event2 Event3Event3 Event4Event4 Event5Event5 Event nEvent n--11 Event nEvent n
Context Context diagramdiagram
Decomposition Decomposition diagramdiagram
17
Event Diagram
• A data flow diagram that depicts the context for a single event
• Shows the inputs, outputs, and data store interactions for the event.
• Users are not overwhelmed by the overall size of the system
• A powerful communication tool between users and technical professionals
18
The SystemThe System
Function1Function1 Function2Function2 Function nFunction n
Event1Event1 Event2Event2 Event3Event3 Event4Event4 Event5Event5 Event nEvent n--11 Event nEvent n
Event1Event1 Event5Event5 EventnEventn
Decomposition Decomposition diagramdiagram
Event diagramsEvent diagrams
Event Diagram
19
Event Diagram• For each event, illustrate the following
– The inputs and their sources• Sources are shown as external agents• The data structure for each input should be recorded in
the repository– The outputs and their destination
• Destinations are depicted as external agents• The data structure for each output should be recorded
in the repository– Any data stores from which records must be
read– Any data stores from which records must be
created, deleted, or updated
20
Process Descriptions
• Structured English• Decision Table• Decision Tree
Eg. A Process that has to determine whether a customer is to be given credit
21
Structured English
• A language and syntax, based on the relative strengths of structured programming and natural English, for specifying the underlying logic of elementary processes on process models.
22
Structured English
IFIF credit limit exceededTHENTHEN
IFIF Customer has bad payment historyTHENTHEN refuse creditELSEELSE
IFIF purchase above Rs.10000/=THENTHEN refuse creditELSEELSE refer to manager
ELSEELSE allow credit
23
Credit limit exceeded
Credit limit not exceeded Allow credit
Bad payment history
Refuse credit
Good payment History
Purchase below Rs.10000/=
Purchase above Rs10000/= Refuse credit
Refer to Manager
A graph or model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility.
Decision Tree
24
Decision Table
• A tabular form of representation that specifies a set of conditions and their corresponding actions
• Very useful for specifying complex policies and decision making rules
25
Cond
ition
Actio
nY-TRUE N-NOT TRUE X-TAKE ACTION
Decision Table
Credit limit exceeded Y Y Y Y N N N
Y N
Y
X
N
X
N
Y N
N
X X
XX
X
Refuse X
Refer Manager
Y
N
N
N
Y
Y
N
Good payment history Y
Purchase above Rs.10000/=
Y
Allow Credit
1
Data Modeling
• A technique for defining business requirements for a database
• Also known as database modeling• There are several notations• Actual model is called an ERD – Entity Relationship
Diagram
– Shows data in terms of the entities and relationships described by the data.
– There exist several notations for an ERD– Martin notation is widely used.
2
Data Modeling…
Entity Relationship DiagramsShows data in terms of the entities and relationships described by data.
Entities
An entity is something about which the business needs to store data.
Synonyms – entity type and entity class
3
Entity Relationship Diagrams…
Data Modeling…
Entity: is a class of
Persons(Customer,Employee)
Places(Building,Room)
Objects(Book,Product)
Events(Flight,Invoice)
Concepts(Account,Fund)
about which we need to capture and store data.
4
Entity Relationship Diagrams…
Data Modeling…
Entity Instance
An entity instance is a single occurrence of an entity. Every entity must have an identifier or key to uniquely identify each instance.
5
Entity Relationship Diagrams…
Data Modeling…
Symbol:Consider Martin notations.
DEPARTMENTEMPLOYEE
The named rounded rectangle represent the entity. –A line represent the relationship. –
6
Entity Relationship Diagrams…
Data Modeling…
Attribute:is a descriptive property or characteristics
of an entity. Sometimes called as element, property, or field.
7
Entity Relationship Diagrams…
Data Modeling…
A key is an attribute, or group of attributes that assumes a unique value for each entity instance. It is sometimes called an identifier.
EMPLOYEENIC_NOName
Address Age …. …. …. This person can be
identified using his ID number.
8
Entity Relationship Diagrams…
Data Modeling…
Compound Attribute is one that actually consist of other attributes.
Synonyms- composite attribute, concatenated attribute
Example : Street Address Postal Code
CountryCity
Student name Last NameLast Name
First NameFirst NameMiddle NameMiddle Name
Address
9
Entity Relationship Diagrams…
Data Modeling…
The values for each attribute are defined in terms of three properties:
1. Data type – What type of data can be stored in that attribute (Number, Date, Text etc).
2. Domain – What values an attribute can legitimately take on.
Refer to table 8-2 in pg 273 Ref1
3. Default – Is the value that will be recorded if not specified by the user.
10
Entity Relationship Diagrams…
Data Modeling…
Relationships
Natural business association that exists between one or more entities
E.g.. A Current Student is enrolled in one or more curricula
STUDENTSTUDENT CURRICULACURRICULAis enrolled inis enrolled in
11
Entity Relationship Diagrams…
Data Modeling…
CardinalityDefines the minimum and maximum number of occurrences of one entity that may be related to a single occurrences of the other entity.
or
Exactly one
12
Entity Relationship Diagrams…
Data Modeling…
Cardinality
I might be married or not…
Zero or one
I may have one, some friends or
none…
Zero, one or more
13
Entity Relationship Diagrams…
Data Modeling…
Cardinality…I have to work at least in one, or more projects.
I am working on many projects.
One or more
More than one
14
Entity Relationship Diagrams…
Data Modeling…
DegreeNumber of entities that participate in the relationship
Degree =1
Recursive Relationship – Relationship that exists between different instances of the same entity.
EMPLOYEESupervise
15
Entity Relationship Diagrams…
Data Modeling…
Degree…
Degree =2
Binary Relationship - When two different entities participates in a relationship
DEPARTMENTWorksEMPLOYEE
16
Degree =3
Ternary or 3-ary Relationship -
When more than two different entities participates in a relationship.
Degree… PROJECT EMPLOYEE
LOCATION
ASSIGNMENT
requiresrequires Is givenIs given
offersoffers
Entity Relationship Diagrams…
Data Modeling…
17
Synchronization of System Models
• Data and process models represent different views of the same system
• These views are interrelated
• Thus, modelers need to synchronize the different views to ensure consistency and the completeness of the total system specification.
Synchronization is the process of maintaining consistency between the different types of models
18
Object Modeling
• A technique for identifying objects within the systems environment and identifying the relationships between those objects.
• Object Modeling techniques prescribe the use of methodologies and diagramming notations that are completely different from the ones used for data modeling and process modeling.
19
Object Modeling Methods
• In the late 80s and early 90s– Booch Method – Grady Booch– Object Modeling Technique (OMT) – James Rumbaugh– Object-Oriented Software Engineering – Ivar Jacobson
• To avoid problems of having many different methods, In 1997,– Unified Modeling Language (UML) - Grady Booch,
James Rumbaugh, Ivar Jacobson
20
System Concepts for Object Modeling
• Objects– Something that is or is capable of being seen,
touched, or otherwise sensed and about which users store data and associate behavior
– Types of objects• Person – e.g. employee, customer, instructor, student • Place – e.g. warehouse, building, room, office• Thing – e.g. product, vehicle, computer, videotape• Event – e.g. an order, payment, invoice, application• Sensual – e.g. phone call, meeting
21
System Concepts for Object Modeling…
• Attributes– The data that represents characteristics of
interest about an objecte.g. Object : Customer
Attributes : Customer no, first name, last name, home address, work address, contact no,…etc.
22
System Concepts for Object Modeling…
• Object instance– Each specific person, place, thing, or event, as
well as the values for the attributes of that object.
– Sometimes referred to as an Object.– Drawn using a rectangle with the name of the
object instance– The name consists of the attribute that
uniquely identifies it, followed by a colon and then the name of the class in which the object has been categorized.
23
System Concepts for Object Modeling…
• Object instancee.g. A “CUSTOMER” Object Instance
001:Customer001:Customer
customerNocustomerNo =001=001lastNamelastName = = PereraPererafirstNamefirstName = Ann= AnnhomePhoneNohomePhoneNo = 0112123456= 0112123456city = Colombocity = Colombo
001:Customer001:CustomerOROR
Object name Object name is underlined is underlined and centeredand centered
24
System Concepts for Object Modeling…
• Behavior– The set of things that an object can do and that
correspond to functions that act on the object’s data or attributes.
– Also known as a method, operation or service
e.g. Object : Doorbehavior : open, shut, lock or unlock
25
System Concepts for Object Modeling…
• Encapsulation– Packaging of several items together into one unit
(both attributes and behavior of the object)
– The only way to access or change an object’s attribute is through that object’s specific behavior.
– Objects encapsulates what they do.• That is, they hide the inner workings of their operations
– from the outside world– and from other objects
26
System Concepts for Object Modeling…
EncapsulationWhen an object carries out its operations,
those operations are hidden.
The TV hides its operations
from the person
watching it.
E.g. When most people watch a television show, - they usually don’t know or care about the complex electronics that sit in back of the TV screen - or the operations that are happening.
27
System Concepts for Object Modeling…
Class name• Object class– A set of object instances
that share the same attributes and behaviors.
– Also referred to as a class.e.g. UML notation for the
object class ‘BOOK’
Attributes of the class
Book-ISBN
-title
-copyrightDate
-edition+open()
+close()
Behaviors
28
System Concepts for Object Modeling…
An Object instancee.g.
00--0909--341234341234--5 : Book5 : Book
ISBN = 0ISBN = 0--0909--341234341234--55title = Programming in C++title = Programming in C++copyrightDatecopyrightDate = 2006= 2006edition = 7thedition = 7th
00--0707--231539231539--3 : Book3 : Book
ISBN = 0ISBN = 0--0707--231539231539--33title = Systems Analysistitle = Systems AnalysiscopyrightDatecopyrightDate = 2001= 2001edition = 5thedition = 5th
29
System Concepts for Object Modeling…
• Inheritance– The concept wherein methods and/or attributes
defined in an object class can be inherited or reused by another object class.
e.g. some individuals in the room might be classified as STUDENTS and TEACHERS.
Thus, STUDENT and TEACHER object classes are members of the object class PERSON
30
System Concepts for Object Modeling…
Person ClassPerson Class
Student ClassStudent Class Teacher ClassTeacher Class
Student AStudent A Student BStudent B Teacher ATeacher A Teacher BTeacher B
• Inheritancee.g. Cont…
31
System Concepts for Object Modeling…
• Generalization / Specialization– A technique wherein the attributes and behaviors
that are common to several types of object classes are grouped / abstracted into their own class called a super type.
– The attributes and methods of the supertype object class are then inherited by those object classes (subtype)
– Sometimes abbreviated as gen/spec.
32
System Concepts for Object Modeling…
Specialization
Generalization StudentStudent
GPAGPAClassificationClassification
enrollenrolldisplayGPAdisplayGPA
firstNamefirstNamelastNamelastNamebirthdatebirthdategendergenderwalkwalkjumpjumptalktalksleepsleep
PersonPerson
firstNamefirstNamelastNamelastNamebirthdatebirthdategendergenderwalkwalkjumpjumptalktalksleepsleep
Inheritable Inheritable AttributesAttributes
And And behavior behavior
++TeacherTeacher
rankrank
lecturelecture
33
System Concepts for Object Modeling…
• Generalization / Specialization
StudentStudent
PersonPerson
TeacherTeacher
Vehicle
Bus Car Truck
* Specialized classes inherits from the parent class
34
System Concepts for Object Modeling…
• Object Class Relationships– A natural business association that exists
between one or more objects and classes
e.g. You interact with a text book by reading it,with a telephone by using it,
People interact with each other by communicating with them.
35
System Concepts for Object Modeling…
• Object / Class Association– When you turn on your TV, in object oriented
terms, you are in an association with your TV.
– An association is unidirectional (one way) or bi-directional (two way).
eg. is married to
– Some times an object might be associated with another in more than one way.
Gihan is a co-worker of DamithGihan is a friend of Damith
36
System Concepts for Object Modeling…
• Object / Class Associatione.g.
A CUSTOMER PLACES zero or more ORDERSAn ORDER IS PLACED BY one and only one CUSTOMER
CustomerCustomer OrderOrder0..*0..*PlacesPlaces
Represent the Represent the relationship relationship
between the classesbetween the classes
37
System Concepts for Object Modeling…
• Multiplicity– The minimum and maximum number of occurrences of
one object class for a single occurrence of the related object class.
e.g. Exactly one -> 1 or leave blank
Zero or 1 -> 0..1Zero or more -> 0..* or *1 or more -> 1..*Specific range -> 7..9
Refer Figure 10-5 pg 377 Ref1 for more details
38
System Concepts for Object Modeling…
• Aggregation– A relationship in which one larger “whole” class
contains one or more smaller “parts” classes. Conversely, a smaller “part” class is part of a “whole” larger class.
e.g. A club – a club is made up of several club membersA computer – a computer contains a case, CPU, motherboard, power supply …etc.
39
System Concepts for Object Modeling…
• Aggregationsome more examples…
0..* 0..*Glider Plane Engine
UML notation
Whole object Part ObjectsTeam Player0..* 12..18
40
System Concepts for Object Modeling…
• Composition– An aggregation relationship in which the
“whole” is responsible for the creation and destruction of its “parts”.
– If the “whole” were to die, the “part” would die with it.
– A stronger form of aggregation. • The relationship between club and club member
would not be composition, because members have a life out-side the club and can, belong to multiple clubs.
41
System Concepts for Object Modeling…
• Composition– Drawn with a filled diamond.
School Department1 1..*
Each “part” can belong to only one “whole”, therefore, multiplicity needs to be specified only one for the “part”
Components will live and die with the whole object
42
System Concepts for Object Modeling…
• Polymorphism– Literally meaning “many forms”, the concept that
different objects can respond to the same message in different ways.
e.g. Consider the WINDOW and DOOR objects
Behavior : Close“Slides downwards”
Behavior : Close“Swings shut”
Both have the common behaviorBut the way it has been carried
Out differs from one another
Systems Design
• Produces a design specification for the new system.• Also known as physical design.• Design inputs, outputs, files, databases and other
computer based components
DesignAnalysis
Systems analysis - emphasize on the business problem
Systems design - emphasize on the technical or implementation concerns of the system.
Task2
Task1
Systems Design…
– Modern structured design– Information engineering– Prototyping– JAD– RAD– Object-oriented design
Systems Design Approaches
Proc
ess A
Process A1
Process A2
Process A3
Process A4
Process A11
Process A12
Process A13
Modern Structured Design
-
• is a process-oriented technique for breaking up a large program into a hierarchy of modules
• result in a computer program that is easier to implement and maintain (change).
• synonyms are top-down program design and structured program Design.
-
• 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…
1.2.1Get Sales
Transaction
1.2Calculate
Sales Total
1.2.2Adds to
Total
1.2.3Output
Total
Sales
Transaction
SalesTransaction
SalesTotal
SalesTotal
Modern Structured Design…
Structure Chart
• 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 SequenceBy convention, modules are executed from left to right in each level.Thus in the given example, module Get Sales Transaction is called before module Adds-To-Total. Module Output Total is the last module to be called.Certain conventions are also used to represent decisions and repetition.Decisions occur whenever a calling module has to decide to call only one of a number of modules.
Modern Structured Design…
Structure Chart
Decisions are modeled by a diamond symbol.
Payment
Cash Cheque
@ Payment pays either cash or Cheque
Or
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
Structure Chart is a technique used in ModernStructured Design
The objective of structured design is to produce a good design.
Modern Structured Design…
• Model driven and data centered, but PROCESS-sensitive technique for planning, analyzing, and designing information systems.
• Primary tool of information engineering is a data model diagram (ERD).
• Involves conducting a business area requirements analysis from which information system applications are carved out and prioritized.
Information Engineering (IE)
Prototyping:The prototyping approach is an iterative process
involving a close working relationship between the designer and the users.
Prototyping
Prototyping encourages and requires active end-user participation.Iteration and change are a natural consequence of systems development - that is end-users tend to change their minds. Prototyping endorses the philosophy that end-users will not know what they want until they see it.
Key Benefits:
Prototyping…
Prototypes are an active, model that end-users can see, touch, feel, and experience.An approved prototype is a working equivalent to a paper design specification, with one exception --errors can be detected much earlier.Prototyping can increase creativity because it allows for quicker user feedback, which can lead to better solutions.Prototyping accelerates several phases of the life cycle, possibly bypassing the programmer.
Key Benefits:
Prototyping…
Prototyping encourages ill-advised shortcuts through the life cycle.
Disadvantages:
Prototyping…
JAD emphasize participative developmentamong 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.
Joint Application Development (JAD)…
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.
RAD calls for the interactive use of structured and prototyping to define the users’ requirements and design the final system.
Using structured techniques, the developer first builds the preliminary data and process models of the business requirements.
Prototypes then help the analyst and users to verify those requirements and to formally refine the data and process models.
Rapid Application Development (RAD)…
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
An application architecture defines the technologies to be used by (and used to build) one, more, or all information systems in terms of its data, process, interface and how these components interact across a network.
It serves as an outline or blueprint for detailed design and implementation.
Primary tool : Physical data flow diagram
Application Architecture
Application Architecture and Modeling
• Model the technical and human decisions to be implemented as part of an information system.
• They communicate technical choices and other design decisions to those who will actually construct and implement the system.
ID (optional)
Implementation
Action verb +
Noun or Object Phrase
Process
Physical Data Flow Diagrams (PDFD)
A physical process is either a processor, such as a computer or person, or a technical implementation of specific work to be performed, such as a computer program or manual process.
Physical Process
Physical Data Flow Diagrams (PDFD)…
# Logical processes may be assigned to physical processors such as PCs, servers, mainframes, people, or devices in a network. A physical DFD would model that network structure.
# Each logical process must be implemented as one or more physical processes as some logical processes must be split into multiple physical processes.
Characteristics of Physical DFDs
Physical Data Flow Diagrams (PDFD)…
• Represents any of the following:– Planned implementation of an input to / output from
a physical process.– A database command or action (create, read,
update, or delete)– Import of data from or the export of data to another
information system across a network.– Flow of data between two modules within the same
program.
Physical Data Flows
Physical Data Flow Diagrams (PDFD)…
Implementation method:Data flow name
Data flow name(Implementation method)
Physical Data Flow Representation
ORRefer Figure 13-2 pg 482 Ref1 to learn how to apply one of these naming conventions in physical DFDs
Physical Data Flows…
PRINTOUT:Salary Equity Report
eg.
Physical Data Flow Diagrams (PDFD)…
• No change from logical DFD to Physical DFD.
– External agents were classified during systems analysis as outside the scope of the systems and therefore, not subject to change.
– Only a change in requirements can initiate a change in external agents
Physical External Agents
Physical Data Flow Diagrams (PDFD)…
• Represents the implementation of one of the following:– A database– A table in a database– A file (computer/non computerized)– A tape / Media backup of anything important– Temporary file needed by a program (e.g. Tax
Tables)
Physical Data Stores
Physical Data Flow Diagrams (PDFD)…
Representation of physical data stores
ID(opt)
Implementation Method : Data Store Name
ID(opt)
Data Store Name(Implementation Method)
OR
Physical Data Stores
Physical Data Flow Diagrams (PDFD)…
Purchase OrdersPurchase Orders
MS Access:MS Access:Purchase OrdersPurchase Orders
Logical Data store
Physical Data store
Implementation : A table in a database
Physical Data Stores
Physical Data Flow Diagrams (PDFD)…
• 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 Database…
– 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
Design the System Interface…
– Package all the specifications from the previous design tasks into a set of specifications.
– Guide the computer programmers activities.
– Inputs : database, input, and output specifications
Package Design Specifications
• Reevaluate project feasibility & update project plan
• Project manager facilitates the task
• Analysts and owners should consider the possibility that, based on the completed design work, the overall project schedule, cost estimates, and other estimates may need to be adjusted.
• The deliverable : updated project plan– Should include a detailed plan for the construction phase
that should follow.
Update the Project Plan
• System analysts must continuously read popular trade journals to stay abreast of the latest technologies and techniques that will keep their customers and their information systems competitive.
• The information system framework provides one suitable framework for understanding IT architecture.
• Today information systems are – no longer monolithic, mainframe computer based
systems.– Built on some combination of networks (Distributed)
Information Technology Architecture
• All the components are hosted by a central, multi user system
• User interact with the host computer via terminals• All of the actual processing and work is done on the host
computer
Centralized Systems
I have all system data
I am doing all processing
Provide interfaces
Databases
• 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…
• Presentation layer – actual user interface which presents inputs and outputs to the user
• Presentation logic layer – any processing that must be done to generate the presentation. e.g. editing input data, formatting output data
• Application logic layer– all the logic and processing required to support the actual business application and rules. e.g. credit checking, calculations, data analysis
• Data manipulation layer – commands and logic required to store and retrieve data to and from the database
• Data layer – the actual stored data in the in a database
Architecture Layers
Distributed Systems…
• There are three types of distributed system architectures– File server architecture– Client server architecture– Internet based architecture
Distributed Systems…
Stored on the File Server
Executed on the Client
Executed on the Client
Executed on the Client
Displayed on the Client
PRESENTATIONLAYER
PRESENTATIONLOGIC LAYER
APPLICATIONLOGIC LAYER
DATA MANIPULATION
LAYER
DATA LAYER
FILE SERVER
SOLUTION
Distributed Systems…
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…
Disadvantages– Large amount of unnecessary data must be
moved between the client and the server– Reduce network and application performance– The client PC must be robust.– Data base integrity can be easily compromised
File server Architecture…
Distributed Systems…
Stored on the Database Server
Executed on the Database Server
Executed on the Server
Displayed on the Client
PRESENTATIONLAYER
PRESENTATIONLOGIC LAYER
APPLICATIONLOGIC LAYER
DATA MANIPULATION
LAYER
DATA LAYER
Executed on the Client
Stored on the Database Server
Executed on the Database Server
Executed on the Client
Displayed on the Client
Executed on the Client
Stored on the Database Server
Executed on the Database Server
Executed on the Application Server
Displayed on the Client
Executed on the Client
DISTRIBUTED PRESENTATION
(2 TIER)
DISTRIBUTED DATA
(2 TIER)
DISTRIBUTED DATA &
APPLICATION(2 TIER)
CLI
ENT
/ SER
VER
SO
LUTI
ON
Distributed Systems…
Client Server ArchitectureThe presentation, presentation logic, application
logic, data manipulation and data layers are distributed between client PC’s and one or more servers.
Client Computers :
Any combination of personal Computers or Workstations, “sometimes connected”
Distributed Systems…
AccountsSales
Design
Construction
Client/Server Architecture…
Distributed Systems…
• Clients may be thin or flat
Client/Server Architecture…
A personal that does not have to be very powerful (acts as a
terminal) e.g. Remote desktop
a personal computer, notebook computer, or
work station that is typically powerful
e.g. Almost all PCs
Distributed Systems…
• Server must be more powerful and capable than a server in the file server model
• Several types of servers may be used in a client/server solution.
– Database Server : A server that hosts one or more databases.
– Transaction Server : a server that hosts services which ensure that all database updates for a transaction succeed or fail as a whole.
Client/Server Architecture…
Distributed Systems…
– Application Server : A server that hosts application logic and services for an information system
– Messaging or Groupware Server : A server that hosts services for groupware.
– Web Server : A server that hosts internet or intranet web sites
Client/Server Architecture…
Distributed Systems…
• Client / Server – Distributed Presentation – A client/server system in which presentation and
presentation logic are shifted from the server to reside on the client
• Client / Server – Distributed Data– A client/server system in which the data and data
manipulation layers are placed on servers and other layers are placed on clients. Also called two-tiered client/server computing.
Client/Server Architecture…
Distributed Systems…
• Client / Server – Distributed Data and Application– client/server system in which the data and data
manipulation layers are placed on their own server (s). – Application logic is placed on its own server– Presentation logic and Presentation are placed on the
clients.– Also, called three-tiered, or n-tiered, client/server
computing
Client/Server Architecture…
Distributed Systems…
Stored on the Database Server
Executed on the Database Server
Distributed from the Web Server
Executed on the Application Server
Displayed on the Client
PRESENTATIONLAYER
PRESENTATIONLOGIC LAYER
APPLICATIONLOGIC LAYER
DATA MANIPULATION
LAYER
DATA LAYER
NETWORKCOMPUTING
SOLUTION
Distributed Systems…
Internet-based Architecture• Presentation and presentation logic
layers are implemented in a client side web browser
• The presentation logic layer then connects to the application logic layer that run on an application server,
• Subsequently connects to the database server/s
Distributed Systems…
• Client-server and network computing made it possible to distribute data without loss of control
• Control is accomplished through advances in distributed relational database technology
Data Architectures
• 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
• The software required to implement distributed relational databases
• Controls access to and maintenance of the stored data in the relational format
• Provides back-ups, recovery and security• Also called as client-server database
management systemse.g. Oracle, SQL Server, Sybase
Distributed Relational Database Management System (RDBMS)
• Supports two types of data
– Data partitioning : truly distributes rows and columns to specific database servers with little or no duplication between servers
– Data replication : duplicates some or all tables on more than one database server.
Distributed Relational Database Management System (RDBMS)
• For a given information system application the data architecture must specify the RDBMS technology and the degree to which data will be partitioned or replicated.
• One way to record these decisions is to record them in a physical data store
For more information Refer pg 495 Ref1
Data Architectures
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
Interface 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
Process Architectures
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
• 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 Management...
It is the process ofScoping Planning
Staffing
DirectingControllingOrganizing
the development of an acceptable system at a minimum cost within a specified time frame.
Project Management...
Necessary to ensure that the project
Resulting Information
SystemAcceptable to the customer
Delivered on time
Delivered within Budget
Customer
PM is a cross life cycle activity because it overlaps all phases of any systems development methodology.
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 projectsFailure to establish upper-management commitment to the project
Lack of organization’s commitment to the system development methodology
Taking shortcuts through or around the system development methodology
Premature commitment to a fixed budget and schedule
Poor estimating techniques
Premature commitment to a fixed budget and schedule
Poor estimating techniques
Project Management...
Over optimism
The mythical man-month
Inadequate people management skills
Failure to adapt to business change
Insufficient resources
Failure to “manage to the plan”
Major cause of project failure is that most project managers were not educated or trained to be project managers.
Causes of failed projects…
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
Business Achievement Competencies
Problem-Solving Competencies
People Management Competencies
Self-Management Competencies
Influence Competencies
Project Manager Competencies…
Project Management...
Refer Table 4-1 pg 123 Ref1 for more details
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...
A PERT chart is a graphical network model that depicts a project’s tasks and the relationships between those tasks.
Project Management Tools and Techniques…
Eg.
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...
Gantt Chart– The most commonly used project scheduling
and progress evaluation tool– a simple horizontal bar chart that depicts project
tasks against a calendar. – Each bar represents a named project task. – The tasks are listed vertically in the left-hand
column.
Project Management Tools and Techniques…
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
• The use of automated software tools that support the drawing and analysis of system models, detailed descriptions and associated specifications.
• Some CASE tools also provide prototyping and code generation capabilities.
Computer-Assisted Systems Engineering (CASE)
It is filling Automatically
Computer-Assisted Systems Engineering (CASE)
It is the application of information technology to system development activities, technique and methodologies. Case toolsare programs that automate or support phases of a system development life cycle.
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 FacilitiesTo use the repository, the CASE tools provide
some combination of facilities– Diagramming tools: used to draw the system
models required or recommended in most system development methodologies
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 mock-ups 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
• 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)
Computer-Assisted Systems Engineering (CASE)
• Forward and Reverse Engineering– Two distinct ways to develop system models.Forward Engineering: a CASE tool capability that
can generate initial software or database code directly from system models.
e.g. generate a program directly from a flow chartReverse Engineering: a CASE tool capability that
can automatically generate initial system models from software or database code
e.g. generate a flow chart from an existing program
Computer-Assisted Systems Engineering (CASE)
• Systems designed to automate the stages of Systems Development.
• Capable of bringing clear benefits to Systems Development.
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)
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.