Information Systems Development

1
Information Systems Development
(IS501) Dr.Doaa Nabil
2
Chapter (1) System Development Life Cycle (SDLC)
3
Systems Development Life Cycle (SDLC) is a
general term used to describe the method and
process of developing a new information
system SDLC provides Structure Methods Control
s Checklist Result of that successful
development Without that risk for missed
deadline, low quality .
4
SDLC Models
A framework that describes the activities
performed at each stage of a software development
project.
5
SDLC Models (cont.)

• Build-and-fix model
• Waterfall model
• Rapid prototyping model
• Incremental model
• Spiral model

6
Build-and-fix model

• Building without specifications or attempt at
  design
• Totally unsatisfactory for large projects
• Difficult to maintain

7
(No Transcript)
8
Waterfall Model

• Requirements defines needed information,
  function, behavior, performance and interfaces(
  specification and planning).
• Design data structures, software architecture,
  interface representations, algorithmic details.
• Implementation source code, database, user
  documentation, testing, installation, and
  maintenance.

9
(No Transcript)
10
When to use the Waterfall Model

• Requirements are very well known (A set of high
  quality, stable user requirements exist )
• Product definition is stable
• Technology is understood
• New version of an existing product
• The user require all complete system at once
• Previous experience of building similar systems
  exist
• The duration of the project is two years or less

11
Waterfall Strengths

• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff, track)
• Works well when quality is more important than
  cost or schedule

12
Waterfall Deficiencies

• All requirements must be known upfront
• Deliverables created for each phase are
  considered frozen inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of
  software development iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the
  system (until it may be too late)

13
Rapid Application Model (RAD)

• Requirements planning phase (a workshop
  utilizing structured discussion of business
  problems)
• User description phase automated tools capture
  information from users
• Construction phase productivity tools, such as
  code generators, screen generators, etc. inside a
  time-box. (Do until done)
• Cutover phase -- installation of the system,
  user acceptance testing and user training

14
(No Transcript)
15
When to use RAD

• Reasonably well-known requirements
• User involved throughout the life cycle
• Project can be time-boxed
• Functionality delivered in increments
• High performance not required
• Low technical risks
• System can be modularized

16
RAD Strengths

• Reduced cycle time and improved productivity with
  fewer people means lower costs
• Time-box approach mitigates cost and schedule
  risk
• Customer involved throughout the complete cycle
  minimizes risk of not achieving customer
  satisfaction and business needs
• Focus moves from documentation to code .
• Uses modeling concepts to capture information
  about business, data, and processes.

17
RAD Weaknesses

• Accelerated development process must give quick
  responses to the user
• Risk of never achieving closure
• Hard to use with legacy systems
• Requires a system that can be modularized
• Developers and customers must be committed to
  rapid-fire activities in an abbreviated time
  frame.

18
Incremental SDLC Model

• Construct a partial implementation of a total
  system
• Then slowly add increased functionality
• The incremental model prioritizes requirements of
  the system and then implements them in groups.
• Each subsequent release of the system adds
  function to the previous release, until all
  designed functionality has been implemented.

19
(No Transcript)
20
When to use the Incremental Model

• Risk, funding, schedule, program complexity, or
  need for early realization of benefits.
• Most of the requirements are known up-front but
  are expected to evolve over time
• A need to get basic functionality to the market
  early
• On projects which have lengthy development
  schedules
• On a project with new technology

21
Incremental Model Strengths

• Develop high-risk or major functions first
• Each release delivers an operational product
• Customer can respond to each build
• Uses divide and conquer breakdown of tasks
• Lowers initial delivery cost
• Initial product delivery is faster
• Customers get important functionality early
• Risk of changing requirements is reduced

22
Incremental Model Weaknesses

• Requires good planning and design
• Requires early definition of a complete and fully
  functional system to allow for the definition of
  increments
• Well-defined module interfaces are required (some
  will be developed long before others)
• Total cost of the complete system is not lower

23
Spiral SDLC Model

• Adds risk analysis, and 4gl RAD prototyping to
  the waterfall model
• Each cycle involves the same sequence of steps as
  the waterfall process model

24

• When to use The spiral Model
• Some user experience is required to refine and
  complete the requirements
• Some parts of the implementation may depend on
  future technology
• New user requirements are anticipated but not yet
  known
• Some user requirements may be significantly more
  difficult to meet than others, and it is decided
  not to allow them to delay a usable delivery.
•  

25
Spiral Quadrant

• Determine objectives, alternatives and
  constraints
• Evaluate alternatives, identify and resolve
  risks
• Develop next-level product
• Plan next phase

26
Spiral QuadrantDetermine objectives,
alternatives and constraints

• Objectives functionality, performance,hardware/so
  ftware interface, critical success factors, etc.
  
• Alternatives build, reuse, buy, sub-contract,
  etc.
• Constraints cost, schedule, interface, etc.

27
Spiral QuadrantEvaluate alternatives, identify
and resolve risks

• Study alternatives relative to objectives and
  constraints
• Identify risks (lack of experience, new
  technology, tight schedules, poor process, etc.
• Resolve risks (evaluate if money could be lost by
  continuing system development

28
Spiral QuadrantDevelop next-level product

• Typical activities
• Create a design
• Review design
• Develop code
• Inspect code
• Test product

29
Spiral QuadrantPlan next phase

• Typical activities
• Develop project plan
• Develop configuration management plan
• Develop a test plan
• Develop an installation plan

30
Spiral Model Strengths

• Provides early indication of insurmountable
  risks, without much cost
• Users see the system early because of rapid
  prototyping tools
• Critical high-risk functions are developed first
• The design does not have to be perfect
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users
• Cumulative costs assessed frequently

31
Spiral Model Weaknesses

• Time spent for evaluating risks too large for
  small or low-risk projects
• Time spent planning, resetting objectives, doing
  risk analysis and prototyping may be excessive
• The model is complex
• Risk assessment expertise is required
• Spiral may continue indefinitely
• Developers must be reassigned during
  non-development phase activities
• May be hard to define objective, verifiable
  milestones that indicate readiness to proceed
  through the next iteration

32
Chapter (2) Information Systems Development
Life Cycle Phases
33
The use of a methodology improves the practice of
information systems development. A methodology
may include
Methodology
- A series of phases.- A series of
techniques.- A series of tools.- A training
scheme.- A philosophy.
Method consists of the collection of data through
observation and experimentation, and the
formulation and testing of hypotheses.
34
Whats the Difference Between Method and
Methodology?

• Method
• Techniques for gathering evidence
• The various ways of proceeding in gathering
  information

• Methodology
• The underlying theory and analysis of how
  research does or should proceed, often influenced
  by discipline

35
Assessing Methods

• Research Question(s) is/are key
• Methods must answer the research question(s)
• Methodology guides application

36
summary

• a research method is a technique for (or way of
  proceeding in) gathering evidence"
• methodology is a theory and analysis of how
  research does or should proceed

37
Techniques include ways to evaluate the costs and
benefits of different solutions and methods to
formulate the detailed design necessary to
develop computer applications.
Techniques
Examples- Flowcharts.- An organization
Chart.- Manual documents specification.- Grid
chart.- Discussion records.
38
Tools are software packages that aid aspects of
information systems development.
Tools
Examples- MS Project.- Power designer.- Visio.
39
A Simple System Development Process
Simplified System Development Process General Problem-Solving Steps
System initiation Identify the problem.
System analysis Analyze and understand the problem. Identify solution requirements or expectations.
System design Identify alternative solutions and choose the best course of action. Design the chosen solution.
System implementation Implement the chosen solution. Evaluate the results. If the problem is not solved, return to step 1 or 2 as appropriate.
40
Systems Development Process Overview
41
System Development Process Overview

• System initiation the initial planning for a
  project to define initial project scope, goals,
  tasks schedule, and budget.
• System analysis the study of a business problem
  domain to recommend improvements and specify the
  business requirements and priorities for the
  solution.
• System design the specification or construction
  of a technical, computer-based solution for the
  business requirements identified in a system
  analysis.
• System implementation the construction,
  installation, testing, and delivery of a system
  into production, provide training for the system
  users.

42
1- Initiation (Planning)Phase
It involves determining a solid plan for
developing your information system. It involves
the following three primary activities 1- define
the system to be developed (determine which
system is required to support the strategic
goals of organization) 2- set the project
scope ( it defines the high level system
requirements through writing project scope
document in one paragraph) 3- develop the project
plan ( what , when, and who questions of systems
activities to be performed)
43
Chapter (3) System Analysis
44
system analysis
It involves end users and IT specialists working
together to gather, understand , and document the
business requirements for the proposed system
through writing (Joint Application Development
report)

• A requirement is a feature that the system must
  have or a constraint that it must satisfy to be
  accepted by the client.

• Requirements engineering aims at defining the
  requirements of the system under construction.

45
Joint Application Development report
It is a highly structured workshop that brings
together users, managers, and information systems
specialists to jointly define and specify user
requirements, technical options, and external
designs( inputs, outputs, and screen)
46
Joint Application Development report
There are numerous of benefits to JAD 1- it
tends to improve the relationship between users,
management, and information systems professionals
( increase confidence between user and
management) 2- it tends to improve the computer
literacy of users and managers as well as the
business and application literacy of information
systems specialists 3- it places the
responsibility for conflict resolution where it
belongs 4- it decrease the total system
development time by integrating and getting
multiple interviews into the structured workshop
5- it lowers the cost of the systems development
by getting the requirements correctly defined and
prioritized the first time
47
System Analysis Phases
Systems analysis consists of three phases 1-
survey project feasibility ( survey phase) 2-
study and analyze the current system ( study
phase) 3- define and prioritize users
requirements ( definition phase)
48
System Analysis Phases (survey phase)
It answer the question is this project worth
looking at? The fundamental objectives of the
survey phase are 1- to identify the problem,
opportunities , and ,or directives that initiated
this project request 2- to determine if solving
the problems exploiting the opportunities, and
satisfying the directives will benefit the
business
49
System Analysis Phases (survey phase)
Survey Phase Activities 1- Conduct initial
interview ( 45-60 minutes) to record lists of
people, data, activities, locations and networks,
and existing technology, list of problems,
opportunities, constraints, ideas, opinions (
fact finding techniques) 2- define the project
scope ( of the proposed project through drawing
context model that determine the boundaries and
scope of the system data scope- process scope-
network scope function point analysis) 3-
classify problems , opportunities, and possible
solutions ( a quick fix, enhancement, new
development , visibility, priority, and solution
in the matrix form) 4- established a proposed
project plan 5- present survey findings and
recommendations
50
System Analysis Phases (Study phase)
It answer the questions are the problems
really worth solving? is a new system really
worth building? ( using JAD in one week and one
three day workshop) The fundamental objectives
of the study phase are 1- to understand the
business environment of the system 2- to
understand the underlying causes and effects of
the problems 3- to understand the benefits of
exploiting opportunities 4- to understand the
implications of noncompliance with directives
51
System Analysis Phases (Study phase)
Study Phase Activities 1- assign project
roles 2- learn about current system 3- model
the current systems 4- analyze problems and
opportunities 5- establish new systems
objectives 6- modify project plan and scope 7-
review findings and recommendations
52
System Analysis Phases (Definition phase)
It answer the questions What does the user
need and want from a new system? The
fundamental objectives of the definition phase
are 1- to define business ( nontechnical)
requirements that address problems identified
with the current system 2- to define business
requirements that discover opportunities
identified with the current system 3- to define
business requirements that fulfill directives
53
System Analysis Phases (Definition phase)

• Definition Phase Activities
• 1- identify requirements
• Requirements engineering includes two main
  activities
• Requirements elicitation, which results in the
  specification of the system that the client
  understands. It requires the collaboration of
  several groups of participants with different
  backgrounds. (functional requirements,
  nonfunctional requirements, use cases, and
  scenarios)
• Requirements Analysis, which results in an
  analysis model that the developers can
  unambiguously interpret
• 2- model system requirements through drawing
• data model diagram to model data requirements
  for many new systems that serve at the starting
  point for designing files and databases

54
System Analysis Phases (Definition phase)

• Data flow diagram to model the processing
  requirements for most new systems that serve at
  starting point for designing computer based
  methods and application programs
• Connectivity diagrams that map the above people,
  data, and activities to geographical locations
  that serve at start point for designing the
  communication systems for distributing the data,
  activities, and people
• 3- build discovery prototype ( if necessary)
• 4- prioritize business requirements
• 5- review requirements specifications

55
System Analysis Modeling and Techniques
1- Functional Decomposition Diagrams 2- Data
Flows Diagrams 3- Unified Modeling Language ( Use
Case Diagrams , Sequence Diagrams) 4- Fact -
Finding
56
1- Functional Decomposition Diagrams(FDD)

• It is a top down representation of a function or
  process ( Structure chart)
• Break main business functions down into lower
  level functions and processes

Course Administration
Course Enrolment
Course Attendance
Course Completion
Course Assessment
Course Certification
Course Payment
Course Application
57
Functional Decomposition Diagrams(FDD) example
58
2- Data Flows Diagrams(DFD)
It show how the system stores, processes, and
transforms data
59

• DFD Very popular tool for describing functions of
  a system in terms of processes and data used by
  them
• FDD may be done before DFD or we may prepare DFDs
  directly
• Have more contents than FDDs
• Flow of data is shown, not flow of control
• DFDs are simple pictorial representations easily
  understood by users and management.
• facilitate top-down development

60
3- Unified Modeling Language ( Use Case Diagrams)

• It is widely used method of visualizing and
  documenting information systems from a users
  view point
• It uses object oriented design concepts, but it
  is independent of any specific programming
  language
• It use to describes business processes and
  requirements generally
• It provides various graphical tools such as use
  case diagrams and sequence diagrams

61
Use Case Diagrams

• It represents the interaction between users and
  the information systems
• User becomes an actor, with specific role that
  describes how he interacts with the system

62
Example of use case diagram
Web store
Actor (person)
Free search
Find an item
Structured search
Customer
ltltincludegtgt
Order an item
Order fast delivery
ltltextendgtgt
Check order
Registered customer
63
Example of use case diagram
Grade system
Record grades
Student
View grades
Teacher
Distribute Report cards
Create report cards
Printing administrator
64
Example of use case diagram
65
Sequence Diagrams

• It shows the timing of interactions between
  objects as they occur
• System analyst might use a sequence diagram to
  show all possible outcomes or focus on a single
  scenario

66
Example sequence diagram
Clerk
lookup
viewButton()
idgetID()
getViolation(id)
May be a pseudo-method
ltltcreategtgt
v
display(v)
67
4- Fact -Finding Techniques

• It involves answers to five familiar questions
  who, what ,where, when, and how
• For each question you must ask another very
  important question why

68
Chapter (4) Part One System Analysis Models and
Techniques (Data Flow Diagram)
69

• System analysts use many graphical models and
  techniques to describe an information systems
  such as
• Data Flow Diagram (Process and data Modeling)
• Unified Modeling Language (object oriented
  modeling)

70
System Models

• A model is a representation of reality. Just as a
  picture is worth a thousand words, most system
  models are pictorial representations of reality.

71
What is Process Modeling?

• Process modeling is a technique for organizing
  and documenting the structure and flow of data
  through a systems processes.
• A business user, when questioned will usually
  focus on the processes of that operation.
• A process may be defined as an action or series
  of actions which produce a change or development.
• The process view of a system may be modeled by a
  Data Flow Diagram

72
A data-flow diagram (DFD) is a graphical
representation of the flow of data through an
Information Systems. DFD is a Systems
Analysts Toolkit to describe an information
system in a graphical techniques. Graphical
descriptions of the sources and destinations of
data. They showWhere data comes fromHow it
flowsThe processes performed on itWhere it
goes
Data Flow Diagram (DFD)
73
Advantage

• A major advantage of a DFD is a graphical nature
  that makes a good communication tool between
• User and analyst
• Analyst and System designer
• Users are able to visualize
• How the system will operate.
• What the system will accomplish .
• How the system will be implemented .

74
Disadvantage

• A DFD becomes difficult to understand when it has
  more than 7 to 9 processes.
• A DFD does not provide an information about
• the timing or ordering of processes
• whether processes will operate in sequence or in
  parallel.

75
Data Flow Diagram Symbols

• A data flow diagram consists of four basic
  elements
• External entities (Data sources and destinations
  sink)
• Data flows
• Processes
• Data stores

76
DFD Symbols (DFDs use four basic symbols)
Gane and Sarson Symbols Symbols Name Yourdon Symbols
APPLY PAYMENT Process Contain Business logic Identify a specific function Verb Adjective APPLY PAYMENT
BANK DEPOSIT Data Flow Represents one or more data item Noun Adjective BANK DEPOSIT
STUDENTS Data Store Must be connected to a process with data flow Noun Adjective STUDENTS
CUSTOMER External Entity Source supplies data to the system. Sink receives data from the system. Must be connected to a process with data flow CUSTOMER
77
Data Flow Diagram Symbols

• 1- External Entities
• Data sources and destinations (or sink)
• Appear as squares
• Represent organizations, individuals, or
  organizational units that send or receive data
  used or produced by the system
• An item can be both a source and a destination
• Used to define system boundaries
• Named with a noun

78
Data Flow Diagram Symbols

• 2-Data flows
• Appear as arrows, named with nouns
• Represent the flow of data between sources and
  destinations, processes, and data stores
• A data flow can be used to represent the
  creation, reading, deletion, or updating of data
  in a file or database (data store).
• At least one end of every data flow should either
  come from or go to a process.

79
Data Flow Diagram

• If two data elements flow together, then the use
  of one data flow line is appropriate.

Process Payment
Customer
Cash Rect Remittance Slip
80
Data Flow Diagram

• If the data elements do not always flow together,
  then multiple lines will be needed.

Process Payment
Customer
Customer Inquiry
Customer Payment
81
Data Flow Diagram

• 3-Processes
• Appear as circles
• Represent the transformation of data
• Must be numbered and labeled with a single action
  verb and an object
• Avoid the use of the word and in the process
  name

1.0
Process
82
Combinations that must be avoided

• Spontaneous generation process
• Black hole process
• Gray hole process
• DATA OF BIRTH CALCULATE
  FINAL GRADE
• GRADE

1.0
Process
1.0
Process
1.0
83
DATA FLOW DIAGRAMS

• 4- Data stores
• Appear as two horizontal lines, named with a noun
• Represent a temporary or permanent data
  repository
• Flow out of a data store retrieval
• Flow into a data store inserting or updating
• Data stores on a DFD are related to entities on
  an ERD

D1
Data Store
84
(No Transcript)
85
Guidelines for Drawing DFDs

1. Draw the context diagram so it fits on one page.
2. Use the name of the information system as the
   process name in the context diagram.
3. Use unique names within each set of symbols.
4. Dont cross lines.
5. In order to keep the diagram uncluttered, you can
   repeat Data Stores or External Entity on a
   diagram.
6. Provide a unique name and reference number for
   each process, you should not have more than 9
   process symbols.
7. Obtain as much user input and feedback as
   possible.

86
Continue Guidelines for Drawing DFDs

• Step 1Draw the Context Diagram
• It is a top-level view of an information system
  that shows the systems boundaries and scope.
• Step 2 Draw DFD Level-0
• It represents a systems major processes, data
  flows and data stores at a high level of detail.
• Step 3 Draw the Lower-Level Diagram
• DFD level 1,2,.

87
Context Diagram

• The highest level of DFD is called a context
  diagram.
• It provides a summary-level view of the system.
• It depicts a data processing system and the
  external entities that are
• Sources of its input
• Destinations of its output
• The process symbol is numbered with a 0

88
Context Diagram example

• Data store are not shown in the context diagram.

89
DATA FLOW DIAGRAMS
Govt. Agencies
Depart- ments
Tax report payment
Time cards
Payroll Processing System
Employees
0
Employee checks
Payroll check
New employee form
Bank
Employee change form
Human Resources
Payroll report
Manage- ment

• This is the context diagram for the SS payroll
  processing system .

90
DATA FLOW DIAGRAMS
Depart- ments
Employees
Employee checks
Human Resources
New employee form
Time cards
1.0 Update empl. Payroll file
2.0 Pay Employ- ees
Employee Change form
Payroll check
Bank
Payroll Disburse- ment data
3.0 Prepare reports
5.0 Update Gen. Ledger
This diagram shows the next level of detail for
the context diagram
Payroll tax disb. voucher
Payroll report
4.0 Pay taxes
Manage- ment
Tax report payment
Govt. Agencies
91
DATA FLOW DIAGRAMS
Depart- ments
Employees
Employee paychecks
Human Resources
New employee form
Time cards
1.0 Update empl. Payroll file
2.0 Pay Employ- ees
Employee Change form
Payroll check
Bank
Suppose we exploded Process 2.0 (pay employees)
in the next level. The sub-processes would be
numbered 2.1, 2.2, 2.3, etc.
Payroll Disburse- ment data
3.0 Prepare reports
5.0 Update Gen. Ledger
Payroll tax disb. voucher
Payroll report
4.0 Pay taxes
Manage- ment
Tax report payment
Govt. Agencies
92
Data Flow Diagram example

• Diagram 0 provides an overview of all the
  components that interact to form the overall
  system

93
DFD Balance
KITCHEN
CUSTOMER
Customer Order
1.0
Food Order
Receipt
Transform Customer Food Order
3.0
2.0
Update Inventory
Update Goods Sold
Inventory Data
Goods Sold Data
Formatted Inventory Data
Formatted Goods Sold Data
INVENTORY
D2
GOODS SOLD
D1
Daily Inventory Depletion Amounts
Daily Goods Sold Amounts
4.0
Produce Management Report
Management Report
RESTAURANT MANAGER
94
Level 1 Diagram
PROCESS 1 ON THE LEVEL 0 DIAGRAM
SUB PROCESS 1 THIS LEVEL 1 DIAGRAM
1.1
1.3
Transform Order to Kitchen Format
Process Customer Order
Customer Order
Food Order
Customer Order
Inventory Data
1.5
Customer Order
Generate Inventory Decrements
Customer Order
Customer Order
1.4
1.2
Generate Good Sold Increments
Generate Customer Receipt
Goods Sold Data
Receipt
NOTE HOW WE HAVE THE SAME INPUTS AND OUTPUTS AS
THE ORIGINAL PROCESS SHOWN IN THE LEVEL 0 DIAGRAM
95
Another Level 1 Diagram
Daily Goods Sold Amounts
Daily Inventory Depletion Amounts
4.0
ORGINAL LEVEL 0 PROCESS
Produce Management Report
Management Report
LEVEL 1 PROCESSES
Daily Inventory Depletion Amounts
4.1
4.2
Inventory Data
Daily Goods Sold Amounts
Access Goods Sold and Inventory Data
Aggregate Goods Sold and Inventory Data
Goods Sold Data
Management Report
4.3
Prepare Management Report
PROCESSES 2.0 AND 3.0 ON THE LEVEL 0 DIAGRAM DO
NOT NEED FURTHER DECOMPOSTION
96
Balancing DFDs

• Balancing ensure that the input and output data
  flows of the parent DFD are maintained on the
  child DFD.

97
Unbalancing example

• Context Diagram
• DFD

98
Data Flow Diagram Rules

• Lets step through some guidelines on how to
  create a DFD.
• RULE 1 Understand the system. Observe the flow
  of information and interview people involved to
  gain that understanding.
• RULE 2 Ignore control processes and control
  actions (e.g., error corrections). Only very
  critical error paths should be included.
• RULE 3 Determine the system boundarieswhere it
  starts and stops. If youre not sure about a
  process, include it for the time being.

99
Data Flow Diagram Rules

• RULE 4 Draw the context diagram first, and then
  draw successively greater levels of detail.
• RULE 5 Identify and label all data flows.
• RULE 6 Data flows that always flow together
  should be grouped together. Those that do not
  flow together should be shown on separate lines.
• RULE 7 Show a process (circle) wherever a data
  flow is converted from one form to another.
  Likewise, every process should have at least one
  incoming data flow and at least one outgoing data
  flow.

100
Data Flow Diagram Rules

• RULE 8 Processes that are logically related or
  occur simultaneously can be grouped in one
  process.
• RULE 9 Number each process sequentially. A
  process labeled 5.0 would be exploded at the next
  level into processes numbered 5.1, 5.2, etc. A
  process labeled 5.2 would be exploded into 5.2.1,
  5.2.2, etc.
• RULE 10 Process names should include action
  verbs, such as update, prepare, etc.

101
Data Flow Diagram Rules

• RULE 11 Identify and label all data stores.
• RULE 12 Identify and label all sources and
  destinations. An entity can be both a source and
  destination. You may wish to include such items
  twice on the diagram, if needed, to avoid
  excessive or crossing lines.
• RULE 13 As much as possible, organize the flow
  from top to bottom and left to right.

102
Data Flow Diagram Rules

• RULE 14 Youre not likely to get it beautiful
  the first time, so plan to go through several
  iterations of refinements.
• RULE 15 On the final copy, lines should not
  cross. On each page, include
• The name of the DFD
• The date prepared
• The preparers name

103
Data Flow Diagram an example

• The first paragraph of the narrative for the
  payroll process reads as follows
• When employees are hired, they complete a new
  employee form. When a change to an employees
  payroll status occurs, such as a raise or a
  change in the number of exemptions, human
  resources completes an employee change form. A
  copy of these forms is sent to payroll. These
  forms are used to create or update the records in
  the employee/payroll file and are then stored in
  the file. Employee records are stored
  alphabetically.

104
DATA FLOW DIAGRAMS
Depart- ments
Employees
Employee paychecks
Human Resources
New employee form
Time cards
1.0 Update empl. Payroll file
2.0 Pay Employ- ees
Employee Change form
Payroll check
Bank
Payroll Disburse- ment data
3.0 Prepare reports
5.0 Update Gen. Ledger
Employee/ Payroll file
Payroll tax disb. voucher
Payroll report
4.0 Pay taxes
Manage- ment
Tax report payment
Govt. Agencies
105
Data Flow Diagram Summary

• The data flow diagram focuses on the logical flow
  of data.
• Inputs to a process are always different than
  outputs
• Objects always have a unique name
• Data cannot move directly from a source to a sink

106
Chapter (4) Part two System Analysis Models and
Techniques (Data Dictionary)
107
Chapter (4) Part three System Analysis Models
and Techniques (UML)
108
UML Diagram What is UML?

• The Unified Modeling Language (UML) is a
  standard  language for modeling object-oriented
  anlyasis

Constructing
Documenting
Visualizing
Communications
Business Modeling
109
UML Different Diagrams Use case
diagrams Describe the functional behavior of the
system as seen by the user. Class
diagrams Describe the static structure of the
system Objects, Attributes, and
Associations. Sequence diagrams Describe the
dynamic behavior between actors and the system
and between objects of the system. State chart
diagrams Describe the dynamic behavior of an
individual object as a finite state
machine. Activity diagrams Model the dynamic
behavior of a system, in particular the
workflow, i.e. a flowchart.
110
Example of UML
111
Use Case Diagrams

• Used during system analysis(requirements
  elicitation stage) to represent external behavior
• Actors represent roles, that is, a type of user
  of the system
• Use cases represent a sequence of interaction for
  a type of functionality
• The use case model is the set of all use cases.
  It is a complete description of the functionality
  of the system and its environment

112
Actors

• An actor models an external entity which
  communicates with the system
• User
• External system
• Physical environment
• An actor has a unique name and an optional
  description.
• Examples
• Passenger A person in the train
• GPS satellite Provides the system with GPS
  coordinates

113
Use Case

• A use case represents a class of functionality
  provided by the system as an event flow.
• A use case consists of
• Unique name
• Participating actors
• Entry conditions
• Flow of events
• Exit conditions
• Special requirements

114
Use Case Example

• Name Purchase ticket
• Participating actor Passenger
• Entry condition
• Passenger standing in front of ticket
  distributor.
• Passenger has sufficient money to purchase
  ticket.
• Exit condition
• Passenger has ticket.

• Event flow
• 1. Passenger selects the number of zones to be
  traveled.
• 2. Distributor displays the amount due.
• 3. Passenger inserts money, of at least the
  amount due.
• 4. Distributor returns change.
• 5. Distributor issues ticket.

115
The ltltextendgtgt Relationship

• ltltextendgtgt relationships represent exceptional or
  seldom invoked cases.
• The exceptional event flows are factored out of
  the main event flow for clarity.
• Use cases representing exceptional flows can
  extend more than one use case.
• The direction of a ltltextendgtgt relationship is to
  the extended use case

ltltextendgtgt
ltltextendgtgt
ltltextendgtgt
ltltextendgtgt
116
The ltltincludegtgt Relationship

• An ltltincludegtgt relationship represents behavior
  that is factored out of the use case.
• An ltltincludegtgt represents behavior that is
  factored out for reuse, not because it is an
  exception.
• The direction of a ltltincludegtgt relationship is to
  the using use case (unlike ltltextendgtgt
  relationships).

ltltincludegtgt
ltltincludegtgt
ltltextendgtgt
ltltextendgtgt
117
Other examples
118
Use Case Diagrams Summary

• Use case diagrams represent external behavior
• Use case diagrams are useful as an index into the
  use cases
• Use case descriptions provide meat of model, not
  the use case diagrams.
• All use cases need to be described for the model
  to be useful.

119
Class Diagrams
TariffSchedule
Trip
Enumeration getZones() Price getPrice(Zone)
zoneZone pricePrice

• Class diagrams represent the structure of the
  system.
• Class diagrams are used
• during requirements analysis to model problem
  domain concepts
• during system design to model subsystems and
  interfaces
• during object design to model classes.

120
Classes
Name
Signature
Attributes
Operations

• A class represent a concept.
• A class encapsulates state (attributes) and
  behavior (operations).
• Each attribute has a type.
• Each operation has a signature.
• The class name is the only mandatory information

121
Attributes and operations visibility

• Attributes visibility
• They should always be private (? information
  hiding)
• Other classes can access an attribute value using
  get and set methods
• Operation visibility
• public (the operation is part of the class
  interface)
• - private (the operation can only be accessed
  by the class itself)
• protected (in abstract classes, operations
  that can be used by subclasses only).
• This visibility constraint, in abstract classes,
  can also be used for attributes

122
Instances
tariff_1974TarifSchedule
zone2price 1, .20,2, .40, 3, .60

• An instance represents a phenomenon.
• The name of an instance is underlined and can
  contain the class of the instance.
• The attributes are represented with their values.

123
Actor vs. Instances

• What is the difference between an actor and a
  class and an instance?
• Actor
• A coherent set of roles that users of use cases
  play when interacting with these use cases. An
  actor has one role for each use case with which
  it communicates. (UML 1.5 definition)
• An entity outside the system to be modeled,
  interacting with the system (Pilot) (text book
  definition)
• Class
• An abstraction modeling an entity in the problem
  domain, inside the system to be modeled
  (Cockpit)
• Object
• A specific instance of a class (Joe, the
  inspector).

124
Associations
TarifSchedule
Enumeration getZones() Price getPrice(Zone)

• Associations denote relationships between
  classes.
• The multiplicity of an association end denotes
  how many objects the source object can
  legitimately reference.

125
1-to-1 and 1-to-Many Associations
1-to-1 association
1-to-many association
126
Aggregation

• An aggregation is a special case of association
  denoting a consists of hierarchy.
• The aggregate is the parent class, the components
  are the children class.

1
0..2
127
Composition

• A solid diamond denote composition, a strong form
  of aggregation where components cannot exist
  without the aggregate.

128
Generalization

• Generalization relationships denote inheritance
  between classes.
• The children classes inherit the attributes and
  operations of the parent class.
• Generalization simplifies the model by
  eliminating redundancy.

129
From Problem Statement to Code
Problem Statement
A stock exchange lists many companies. Each
company is identified by a ticker symbol
Class Diagram
lists
Java Code
public class StockExchange public Vector
m_Company new Vector() public class Company
public int m_tickerSymbol public
Vector m_StockExchange new Vector()
130
(No Transcript)
131
UML Sequence Diagrams

• Used during requirements analysis
• To refine use case descriptions
• to find additional objects (participating
  objects)
• Used during system design
• to refine subsystem interfaces
• Classes are represented by columns
• Messages are represented by arrows
• Activations are represented by narrow rectangles
• Lifelines are represented by dashed lines

selectZone()
insertCoins()
pickupChange()
pickUpTicket()
132
UML Sequence Diagrams Nested Messages
ZoneButton
Dataflow
to be continued...

• The source of an arrow indicates the activation
  which sent the message
• An activation is as long as all nested activations

133
Sequence Diagram Observations

• UML sequence diagram represent behavior in terms
  of interactions.
• Complement the class diagrams which represent
  structure.
• Useful to find participating objects.
• Time consuming to build but worth the investment.

134
Use case diagram
System boundary

• overview the usage requirements
• presentations project stakeholders
• "the meat" of the actual requirements

Actor
Actor An actor is a person, organization, or
external system that plays a role in one or more
interactions with your system
Use case
Use case A use case describes a sequence of
actions that provide something of measurable
value to an actor and is drawn as a horizontal
ellipse
System boundary indicates the scope of your
system.  Anything within the box represents
functionality that is in scope and anything
outside the box is not
Online C2C shopping
135
Class Diagram
Name
Class diagrams show the classes of the system,
their interrelationships (including inheritance,
aggregation, and association), and the operations
and attributes of the classes.

• Associations
• Aggregation
• Generalization

Relations
Attributes
Operations
136
Relationships between Class Diagrams

• Association -- a relationship between instances
  of the two classes. There is an association
  between two classes if an instance of one class
  must know about the other in order to perform its
  work. In a diagram, an association is a link
  connecting two classes.
• Aggregation -- an association in which one class
  belongs to a collection. An aggregation has a
  diamond end pointing to the part containing the
  whole.
• Generalization -- an inheritance link indicating
  one class is a superclass of the other. A
  generalization has a triangle pointing to the
  superclass.

137
Sequence Diagram
Object Class

• A sequence diagram is
• An interaction diagram that details how
  operations are carried out.
• What messages are sent and when.
• Sequence diagrams are organized according to time

Message
Operations
Lifeline
138
Activities Diagram
Start
Activity diagrams describe the workflow behaviour
of a system
Fork
Branch
Merge
Joint
End
139
State Machine Diagram

• A State Machine diagram
• shows the possible states of
• the object and the transitions
• that cause a change in state.

?
What is different between activities and
Statemachine diagram
140
System Design

• System design is the transformation of an
  analysis model into a system design model ( build
  a technical blueprint of how the proposed system
  will work).
• Project team turns its attention to the system
  from a physical to technical point of view
• Developers also select strategies for building
  the system, such as
• The hardware/software strategy.
• The persistent data management strategy.
• The global control flow.
• The access control policy.
• The handling of boundary conditions.

141
System Design Output
The result of system design is a model that
includes a subsystem decomposition and a clear
description of each of these strategies. System
design is not algorithmic. Developers have to
make trade-offs among many design goals that
often conflict with each other. They also cannot
anticipate all design issues that they will face
because they do not yet have a clear picture of
the solution domain.
142
System Design Phases
1- design the technical architecture ( hardware,
software, telecommunications equipment 2-
design the system models
143
System Design Activities

• System design is decomposed into several
  activities, each addressing part of the overall
  problem of decomposing the system
• Identify design goals. Developers identify and
  prioritize the qualities of the system that they
  should optimize.
• Design the initial subsystem decomposition.
  Developers decompose the system into smaller
  parts based on the use case and analysis models.
  Developers use standard architectural styles as a
  starting point during this activity.
• Refine the subsystem decomposition to address the
  design goals. The initial decomposition usually
  does not satisfy all design goals. Developers
  refine it until all goals are satisfied.

144
Implementation Mapping Models to Code

• Now, We could implement a system that realizes
  the use cases specified during requirements
  elicitation and system design.
• However, as developers start putting together the
  individual subsystems developed in this way, they
  are confronted with many integration problems.
• Different developers have probably handled
  contract violations differently.
• Undocumented parameters may have been added to
  the API to address a requirement change.
  Additional attributes have possibly been added to
  the object model, but are not handled by the
  persistent management system, possibly because of
  a miscommunication. As the delivery pressure
  increases, addressing these problems results in
  additional improvised code changes and
  workarounds that eventually yield to the
  degradation of the system.
• The resulting code would have little resemblance
  to our original design and would be difficult to
  understand.
• We describe a selection of transformations to
  illustrate a disciplined approach to
  implementation to avoid such a system
  degradation. These include
• optimizing the class model
• mapping associations to collections
• mapping operation contracts to exceptions
• mapping the class model to a storage schema.

145
Testing

• Testing is the process of finding differences
  between the expected behavior specified by system
  models and the observed behavior of the
  implemented system.
• Unit testing finds differences between the object
  design model and its corresponding component.
• Structure testing finds differences between the
  system design model and a subset of integrated
  subsystems.
• Functional testing finds differences between the
  use case model and the system.
• Performance testing finds differences between
  nonfunctional requirements and actual system
  performance.
• When differences are found, developers identify
  the defect causing the observed failure and
  modify the system to correct it. In other cases,
  the system model is identified as the cause of
  the difference, and the model is updated to
  reflect the state of the system.
• The goal of testing is to design tests that
  exercise defects in the system and to reveal
  problems.
• Testing is usually accomplished by developers
  that were not involved with the construction of
  the system.

146
Terminology

• Reliability The measure of success with which
  the observed behavior of a system confirms to
  some specification of its behavior.
• Failure Any deviation of the observed behavior
  from the specified behavior.
• Error The system is in a state such that further
  processing by the system will lead to a failure.
• Fault (Bug) The mechanical or algorithmic cause
  of an error.
• There are many different types of errors and
  different ways how we can deal with them.

147
Dealing with Errors

• Verification
• Assumes hypothetical environment that does not
  match real environment
• Proof might be buggy (omits important
  constraints simply wrong)
• Modular redundancy
• Expensive
• Declaring a bug to be a feature
• Bad practice
• Patching
• Slows down performance
• Testing (this lecture)
• Testing is never good enough

148
Another View on How to Deal with Errors

• Error prevention (before the system is released)
• Use good programming methodology to reduce
  complexity
• Use version control to prevent inconsistent
  system
• Apply verification to prevent algorithmic bugs
• Error detection (while system is running)
• Testing Create failures in a planned way
• Debugging Start with an unplanned failures
• Monitoring Deliver information about state. Find
  performance bugs
• Error recovery (recover from failure once the
  system is released)
• Data base systems (atomic transactions)
• Modular redundancy
• Recovery blocks

149
Some Observations

• It is impossible to completely test any
  nontrivial module or any system
• Theoretical limitations Halting problem
• Practial limitations Prohibitive in time and
  cost
• Testing can only show the presence of bugs, not
  their absence (Dijkstra)

150
Testing Activities
Requirements Analysis Document
Subsystem Code
Requirements Analysis Document
Unit
System Design Document
T
est
Tested Subsystem
User Manual
Subsystem Code
Unit
T
est
Integration
Tested Subsystem
Functional
Test
Test
Functioning System
Integrated Subsystems
Tested Subsystem
Subsystem Code
Unit
T
est
All tests by developer
151
Testing Activities continued
Clients Understanding of Requirements
User Environment
Global Requirements
Accepted System
Validated System
Functioning System
Performance
Acceptance
Installation
Test
Test
Test
Usable System
Tests by client
Tests by developer
Users understanding
System in
Use
Tests (?) by user
152
Types of Testing

• Unit Testing
• Individual subsystem
• Carried out by developers
• Goal Confirm that subsystems is correctly coded
  and carries out the intended functionality
• Integration Testing
• Groups of subsystems (collection of classes) and
  eventually the entire system
• Carried out by developers
• Goal Test the interface among the subsystem

153
System Testing

• System Testing
• The entire system
• Carried out by developers
• Goal Determine if the system meets the
  requirements (functional and global)
• Acceptance Testing
• Evaluates the system delivered by developers
• Carried out by the client. May involve executing
  typical transactions on site on a trial basis
• Goal Demonstrate that the system meets customer
  requirements and is ready to use
• Implementation (Coding) and testing go hand in
  hand

154
Unit Testing

• Informal
• Incremental coding
• Static Analysis
• Hand execution Reading the source code
• Walk-Through (informal presentation to others)
• Code Inspection (formal presentation to others)
• Automated Tools checking for
• syntactic and semantic errors
• departure from coding standards
• Dynamic Analysis
• Black-box testing (Test the input/output
  behavior)
• White-box testing (Test the internal logic of the
  subsystem or object)
• Data-structure based testing (Data types
  determine test cases)

155
Black-box Testing

• Focus I/O behavior. If for any given input, we
  can predict the output, then the module passes
  the test.
• Almost always impossible to generate all possible
  inputs ("test cases")
• Goal Reduce number of test cases by equivalence
  partitioning
• Divide input conditions into equivalence classes
• Choose test cases for each equivalence class.
  (Example If an object is supposed to accept a
  negative number, testing one negative number is
  enough)

156
Black-box Testing (Continued)

• Selection of equivalence classes (No rules, only
  guidelines)
• Input is valid across range of values. Select
  test cases from 3 equivalence classes
• Below the range
• Within the range
• Above the range
• Input is valid if it is from a discrete set.
  Select test cases from 2 equivalence classes
• Valid discrete value
• Invalid discrete value
• Another solution to select only a limited amount
  of test cases
• Get knowledge about the inner workings of the
  unit being tested gt white-box testing

157
White-box Testing

• Focus Thoroughness (Coverage). Every statement
  in the component is executed at least once.
• Four types of white-box testing
• Statement Testing
• Loop Testing
• Path Testing
• Branch Testing

158
Integration Testing Big-Bang Approach
Unit Test A
Dont try this!
Unit Test B
Unit Test C
Unit Test D
Unit Test E
Unit Test F
159
Bottom-up Testing Strategy

• The subsystem in the lowest layer of the call
  hierarchy are tested individually
• Then the next subsystems are tested that call the
  previously tested subsystems
• This is done repeatedly until all subsystems are
  included in the testing
• Special program needed to do the testing, Test
  Driver
• A routine that calls a subsystem and passes a
  test case to it

160
Bottom-up Integration
Test E
Test F
Test C
Test G
161
Pros and Cons of bottom up integration testing

• Bad for functionally decomposed systems
• Useful for integrating the following systems
• Object-oriented systems
• real-time systems
• systems with strict performance requirements

162
System Testing

• Functional Testing
• Structure Testing
• Performance Testing
• Acceptance Testing
• Installation Testing
• Impact of requirements on system testing
• The more explicit the requirements, the easier
  they are to test.
• Quality of use cases determines the ease of
  functional testing
• Quality of subsystem decomposition determines the
  ease of structure testing
• Quality of nonfunctional requirements and
  constraints determines the ease of performance
  tests

163
Structure Testing

• Essentially the same