Information Systems Development - PowerPoint PPT Presentation

Loading...

PPT – Information Systems Development PowerPoint presentation | free to download - id: 6debec-ZDE2Y



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Information Systems Development

Description:

Information Systems Development (IS501) Dr.Doaa Nabil * – PowerPoint PPT presentation

Number of Views:65
Avg rating:3.0/5.0
Slides: 169
Provided by: S824
Learn more at: http://shalash.yolasite.com
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com