Information Systems Development - PowerPoint PPT Presentation

Loading...

PPT – Information Systems Development PowerPoint presentation | free to download - id: 6d5e15-NTkyN



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:

Title: Slide 1 Author: S&D Last modified by: S&D Created Date: 3/1/2010 8:03:50 PM Document presentation format: On-screen Show (4:3) Other titles – PowerPoint PPT presentation

Number of Views:19
Avg rating:3.0/5.0
Date added: 11 October 2019
Slides: 196
Provided by: S824
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 Quadrant Determine 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 Quadrant Evaluate 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 Quadrant Develop next-level product
  • Typical activities
  • Create a design
  • Review design
  • Develop code
  • Inspect code
  • Test product

29
Spiral Quadrant Plan 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 show Where data comes from How it
flows The processes performed on it Where 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
Data Dictionary
  • A tool for recording and processing information
    (metadata)
  • about the data that an organization uses.
  • A central catalogue for metadata.
  • Can be integrated within the DBMS or be separate.
  • May be referenced during system design,
    programming, and
  • by actively-executing programs.
  • Can be used as a repository for common code
    (e.g. library
  • routines

108
Benefits of a DDS
  • it is a central store of information about the
    database (a summary of the structure of the
    database).
  • improved documentation and control
  • consistency in data use
  • easier data analysis
  • reduced data redundancy
  • simpler programming
  • the enforcement of standards
  • better means of estimating the effect of change.
  • helps DBA manage the database
  • informs users of database scope
  • Facilitates communication between users and
    database administrators
  • Allows the DBMS to manage the creation, access,
    and modification of tables and their components

109
  • DDS Facilities
  • A DDS should provide two sets of facilities
  • To record and analyze data requirements
    independently of
  • how they are going to be met - conceptual data
    models
  • (entities, attributes, relationships).
  • To record and design decisions in terms of
    database or file
  • structures implemented and the programs which
    access them -
  • internal schema.
  • One of the main functions of a DDS is to show the
    relationship
  • between the conceptual and implementation views.
    The mapping
  • should be consistent - inconsistencies are an
    error and can be
  • detected here.

110
Typical DD Contents
  • Data elements
  • names, data type
  • Tables
  • owner, creation date, access specifications, size
  • Indexes
  • name, attributes involved, creation date
  • Authorized users
  • names, type(s) of access
  • Integrity Constraints

111
Chapter (4) Part three System Analysis Models
and Techniques (UML)
112
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
113
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.
114
Example of UML
115
1- Use Case Diagram
  • A Use Case is a scenario y of using a system that
    describes limited interaction between a system
    and actors in the field
  • Use case represents the steps in a specific
    business functions or process
  • It is a complete description of the functionality
    of the system and its environment

116
Purpose of Use Case Diagram
  • The purpose for using use cases is to
  • Uncover and describe all tasks that need doing in
    a system (of both human and system actors)
  • To analyse what functionality that need
    developing for the system
  • The use of use cases must mean that the right
    functional requirements are made of the IT system
    (the requirements of the business)

117
  • Use case strengths
  • It works well as an analytical tool to represent
    external behavior
  • It is simple and easy to pick up
  • It is easy to understand, both for the business
    and from the technological aspect
  • It is a widely recognised market standard
  • customer and supplier or operators and
    technicians can jointly work out and understand
    the operational functionality
  • It brings structure, and ensure complete analysis

118
Use cases are documented in two ways
  • Use Case diagrams
  • Give an overview of visible use scenarios in the
    system
  • Describes what actors that interact with the
    system
  • Describes any linkages between use cases
  • Verbal description
  • Describes the content of each use case
  • Typically uses a pre-defined template

119
Components of Use Case Diagram
1- Actor external entity represents actor
roles, that is, a type of user of the system with
stick figure and specific label 2- Use
cases represent a sequence of interaction for a
type of functionality ( actor request s the
system to perform a specific function with
certain label) 3- Association line from
actor to use case
120
Example of Use Case Diagram
Student resisted in a specific course and faculty
update student grades and output generating
121
Note that
Use case can also interact with other use cases,
when the out comes of one use case is
incorporated by another use case
122
Relationships between Use Cases
  • 1. Generalization - use cases that are
    specialized versions of other use cases.
  • 2. Include - use cases that are included as parts
    of other use cases. Enable to factor common
    behavior.
  • 3. Extend - use cases that extend the behavior of
    other core use cases. Enable to factor variants.

123
1. Generalization
  • The child use case inherits the
  • behavior and meaning of the
  • parent use case.
  • The child may add to or
  • override the behavior of its parent.

124
More about Generalization
125
ExampleDraw use case diagram for library system
as follow 1- the main actors of the system are
client, supervisor, and employee 2- client can
request the system to borrow a certain book or
make reservation for it 3- client fine payment
for the system 4- employee can also borrow book
or order a certain title for the client 5-
supervisor check orders and fine payment
126
Use Case Diagram Example1 (Library)
library system
borrow
client
employee
reserve
Order title
Fine payment
supervisor
A Library System.
127
Use Case Diagram for Student Assessment
Management System
Grade system
Record grades
Student
View grades
Teacher
Distribute Report cards
Create report cards
Printing administrator
128
2. Include
  • The base use case explicitly incorporates the
    behavior of another use case at a location
    specified in the base.
  • The included use case never stands alone. It only
    occurs as a part of some larger base that
    includes it.

129
More about Include
  • Enables to avoid describing the same flow of
    events several times by putting the common
    behavior in a use case of its own.

130
More about Include
ltltincludegtgt
ltltincludegtgt
ltltextendgtgt
ltltextendgtgt
131
Use Case Example (self service machine)
Self Service Machine
ltltincludesgtgt
customer
ltltincludesgtgt
Restock according to sales
ltltincludesgtgt

ltltincludesgtgt
supplier
Close Machine
132
3. Extend
  • The base use case implicitly incorporates the
    behavior of another use case at certain points
    called extension points.
  • The base use case may stand alone, but under
    certain conditions its behavior may be extended
    by the behavior of another use case.

133
More about Extend
  • Enables to model optional behavior or branching
    under conditions.

134
More about Extend
ltltextendgtgt
ltltextendgtgt
ltltextendgtgt
ltltextendgtgt
135
Example
136
Other examples
137
Use Case Diagram (Narrative Description)
  • Name Purchase ticket
  • Description
  • 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.

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

139
University Record System (URS)
  • A University record system should keep
    information about its students and academic
    staff.
  • Records for all university members are to include
    their id number, surname, given name, email,
    address, date of birth, and telephone number.
  • Students and academic staff each have their own
    unique ID number studN (students), acadN
    (academic employee), where N is an integer
    (Ngt0).
  • In addition to the attributes mentioned above
  • Students will also have a list of subjects they
    are enrolled in. A student cannot be enrolled in
    any more than 10 subjects.
  • Academic employees will have a salary, and a list
    of subjects they teach. An academic can teach no
    more than 3 subjects.

140
Some Actions Supported by URS
  • The system should be able to handle the following
    commands.
  • Add and remove university members (students, and
    academic staff)
  • Add and Delete subjects
  • Assign and Un-assign subjects to students
  • Assign and Un-assign subjects to academic staff.

141
Use Case Diagram - URS System
URS
add member
delete member
system user
academic
add subject
del subject
assg subject
unass subject
enrol subject
unenrol subject
142
Example. Automatic teller machine (ATM) Withdraw
money using a Visa card Summary This use case
allows a Visa card holder, who is not a customer
of the bank to withdraw money if his/her daily
limit allows it. 1. The Visa CardHolder inserts
his/her smart card in the ATMs card reader. 2.
The ATM verifies that the card that has been
inserted is a smartcard. 3. TheATM asks the Visa
CardHolder to enter his/her pin number. 4. The
Visa CardHolder enters his/her pin number. 5. The
ATM compares the pin number with the one that is
encoded on the chip of the smartcard. 6. The ATM
requests an authorisation from the Visa
authorisation system 7. The Visa authorisation
system confirms its agreement and indicates the
daily withdrawal limit. 8. The ATM asks the Visa
CardHolder to enter the desired withdrawal
amount. 9. The Visa CardHolder enters the desired
withdrawal amount. 10. The ATM checks the amount
against the daily withdrawal limit.
143
11. The ATM asks the Visa CardHolder if he/she
would like a receipt. 12. The Visa CardHolder
requests a receipt. 13. The ATM returns the card
to the Visa CardHolder. 14. The Visa CardHolder
takes his/her card. 15. The ATM issues the
banknotes and a receipt. 16. The Visa CardHolder
takes the banknotes and the receipt. Variations
Temporarily incorrect pin number At step 5, the
Visa CardHolder fails to enter a correct pin
number 6. The ATM informs the CardHolder that the
pin is incorrect for the first or second time. 7.
The ATM records the failure on the smartcard. The
scenario goes back to step 3. Variations The
amount requested is greater than the
daily withdrawal limit
144
2-Class Diagrams
  • Class diagrams represent the structure of the
    system.
  • It represents a detailed view of a single use
    case shows the classes that participate in the
    use case and documents the relationship among the
    classes

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

Note that DFD and class diagram is a logical
model ( each of them evolve into code modules,
data objects)
146
Components of Class Diagram
  • 1- Class rectangle class name at the top
    followed by class attributes and methods
  • 2- lines relationships between classes through
    label
  • 3- Cardinality describes how instance of one
    class relate to instance of another class
  • 0. zero or many
  • 0.1 zero or one
  • One and only one
  • 1. one or many

147
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

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

149
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).

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

151
1-to-1 and 1-to-Many Associations
1-to-1 association
1-to-many association
152
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
153
Composition
  • A solid diamond denote composition, a strong form
    of aggregation where components cannot exist
    without the aggregate.

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

155
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()
156
URS - High Level Class Diagram
URSDataBase
1
has

UniversityMember
Subject
010
0..3
AcademicStaff
Student

1
157
(No Transcript)
158
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()
159
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

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

161
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
162
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
163
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.

164
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
165
Activities Diagram
Start
Activity diagrams describe the workflow behaviour
of a system
Fork
Branch
Merge
Joint
End
166
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
167
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.

168
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.
169
System Design Phases
1- design the technical architecture ( hardware,
software, telecommunications equipment 2-
design the system models
170
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.

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

172
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 subs
About PowerShow.com