1 Information Systems Development (IS501) Dr.Doaa Nabil

1

Information Systems Development

(IS501)

Dr.Doaa Nabil

Chapter (1)

System Development Life

Cycle (SDLC)

2

Systems Development Life Cycle (SDLC) : is a general term used to describe the method and process of developing a new information systemSDLC provides:

StructureMethodsControlsChecklist

Result of that: successful development Without that: risk for

missed deadline, low quality .3

SDLC Models

A framework that describes the activities performed at each stage of a software development project.

4

Build-and-fix model

Waterfall model

Rapid prototyping model

Incremental model

Spiral model

SDLC Models (cont.)

5

Build-and-fix modelBuild-and-fix modelBuilding without specifications or

attempt at designTotally unsatisfactory for large

projectsDifficult to maintain

6

7

Waterfall ModelWaterfall 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.

8

9

When to use the Waterfall When to use the Waterfall ModelModelRequirements 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

10

Waterfall StrengthsWaterfall 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

11

Waterfall DeficienciesWaterfall 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)

12

Rapid Application Model Rapid Application Model (RAD)(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

13

14

When to use RADWhen to use RADReasonably well-known requirementsUser involved throughout the life

cycleProject can be time-boxed Functionality delivered in incrementsHigh performance not requiredLow technical risks System can be modularized

15

RAD StrengthsRAD 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.

16

RAD WeaknessesRAD 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.

17

Incremental SDLC ModelIncremental 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.

18

19

When to use the When to use the Incremental Model 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

20

Incremental Model Incremental Model Strengths 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

21

Incremental Model Incremental Model Weaknesses 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

22

Spiral SDLC ModelSpiral SDLC ModelAdds risk analysis,

and 4gl RAD

prototyping to the

waterfall model

Each cycle involves

the same sequence of

steps as the waterfall

process model

23

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

Spiral QuadrantSpiral QuadrantDetermine objectives, alternatives and Determine objectives, alternatives and

constraintsconstraints

Objectives: functionality,

performance,hardware/software interface,

critical success factors, etc.

Alternatives: build, reuse, buy, sub-contract,

etc.

Constraints: cost, schedule, interface, etc.26

Spiral QuadrantSpiral Quadrant

Evaluate alternatives, identify and Evaluate alternatives, identify and resolve risks 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

27

Spiral QuadrantSpiral QuadrantDevelop next-level productDevelop next-level product

Typical activities:◦ Create a design◦ Review design◦ Develop code◦ Inspect code◦ Test product

28

Spiral QuadrantSpiral QuadrantPlan next phasePlan next phase

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

29

Spiral Model StrengthsSpiral Model StrengthsProvides early indication of

insurmountable risks, without much costUsers see the system early because of

rapid prototyping toolsCritical high-risk functions are developed

firstThe design does not have to be perfect Users can be closely tied to all lifecycle

stepsEarly and frequent feedback from usersCumulative costs assessed frequently

30

Spiral Model Spiral Model WeaknessesWeaknesses

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

31

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

What’s the Difference Between What’s the Difference Between “Method” and “Methodology”?“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

34

Assessing MethodsAssessing MethodsResearch Question(s) is/are keyMethods must answer the

research question(s)Methodology guides application

35

summarysummary

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“

36

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.

1-39

A Simple System A Simple System Development ProcessDevelopment Process

Simplified System Development Process

General Problem-Solving Steps

System initiation 1. Identify the problem.

System analysis 2. Analyze and understand the problem.3. Identify solution requirements or

expectations.

System design 4. Identify alternative solutions and choose the “best” course of action.

5. Design the chosen solution.

System implementation 6. Implement the chosen solution.7. Evaluate the results. If the problem is not

solved, return to step 1 or 2 as appropriate.

Systems Development Systems Development Process OverviewProcess Overview

40

System Development System Development Process OverviewProcess 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.

41

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 system2- to understand the underlying causes and effects of the problems3- to understand the benefits of exploiting opportunities4- 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 system’s 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

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


•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 user’s 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

Example of use case Example of use case diagramdiagram Web store

Find an item

Order an item

Check order

Customer

Registered customer

Order fast delivery

Free search

Structured search

<<include>>

<<extend>>

Actor (person)

62

63

Teacher

Student

Printing administrator

Grade system

Record grades

View grades

DistributeReport cards

Create report cards

Example of use case Example of use case diagramdiagram

64

Example of use case Example of use case diagramdiagram

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

getViolation(id)

Example sequence Example sequence diagramdiagram

Clerk

:ViolationsDialog

:ViolationsController

:ViolationsDBProxy

lookupviewButton()

id=getID()

v:TrafficViolation

display(v)

<<create>>

v

Lookup Traffic Violation

May be a

pseudo-method DB is queried

and the result is returned as an object

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 ModelsSystem 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 system’s 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 A data-flow diagramdata-flow diagram ( (DFDDFD) is a graphical ) is a graphical representation of the flow of data through an representation of the flow of data through an Information Systems. Information Systems.

*DFD is a Systems Analyst’s Toolkit to describe an *DFD is a Systems Analyst’s Toolkit to describe an information system in a graphical techniques.information system in a graphical techniques.

* * Graphical descriptions of the sources and Graphical descriptions of the sources and destinations of data. They show:destinations of data. They show:Where data comes fromWhere data comes fromHow it flowsHow it flowsThe processes performed on itThe processes performed on itWhere it goesWhere it goes

Data Flow Diagram (DFD)

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 .

73

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.

74

Data Flow Diagram Symbols

A data flow diagram consists of four basic elements:External entities (Data sources and

destinations –sink)Data flowsProcessesData stores

75

DFD Symbols (DFDs use four basic symbols)Gane and Sarson

SymbolsSymbols Name Yourdon Symbols

APPLY PAYMENT

ProcessContain Business logic

Identify a specific function

Verb & Adjective

APPLY PAYMENT

BANK DEPOSITData Flow

Represents one or more data item

Noun & Adjective

BANK DEPOSIT

STUDENTS

Data StoreMust be connected to a process with data flow

Noun & Adjective

STUDENTS

CUSTOMER

External EntitySource: supplies data to the system.

Sink: receives data from the system.

Must be connected to a process with data flow

CUSTOMER

76


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

77


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.

78

Data Flow Diagram Data Flow Diagram

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

CustomerProcessPayment

Cash Rec’t & Remittance Slip

79

Data Flow DiagramData Flow Diagram

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

CustomerProcessPayment

Customer Inquiry

Customer Payment

80

Data Flow DiagramData 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

81

1.0

Process

Combinations that must be avoidedSpontaneous generation process

Black hole process

Gray hole process

DATA OF BIRTH CALCULATE FINAL GRADE GRADE

1.0

1.0

1.0

Process

Process

82

DATA FLOW DIAGRAMSDATA 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

83

Data StoreD1

84

Guidelines for Drawing DFDs1. 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. Don’t cross lines.

1. In order to keep the diagram uncluttered, you can repeat Data Stores or External Entity on a diagram.

5. Provide a unique name and reference number for each process, you should not have more than 9 process symbols.

6. Obtain as much user input and feedback as possible.

85

Continue Guidelines for Drawing DFDs

Step 1:Draw the Context Diagram ◦It is a top-level view of an information

system that shows the system’s boundaries and scope.

Step 2: Draw DFD Level-0 ◦It represents a system’s major processes,

data flows and data stores at a high level of detail.

Step 3: Draw the Lower-Level Diagram◦ DFD level 1,2,….

86

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”

87

Context Diagram example

Data store are not shown in the context diagram.

88


PayrollProcessing

System

Depart-ments

HumanResources

Govt.Agencies

Employees

Bank

Manage-ment

Time cards

New employee form

Employee change form

Tax report &

payment

Employee checks

Payroll checkPayroll report

• This is the context diagram for the S&S payroll processing system .

0

89


1.0Updateempl.

Payrollfile

2.0Pay

Employ-ees

5.0UpdateGen.

Ledger

4.0Pay

taxes

3.0Preparereports

Employee/Payroll file

GeneralLedger

HumanResources

Depart-ments Employees

Bank

Govt.Agencies

Manage-ment

EmployeeChange

form

New employeeform

Timecards

Employeechecks

Payrollcheck

PayrollDisburse-ment data

Payroll taxdisb. voucher

Tax report& payment

Payrollreport

This diagram shows the next level of detail for the context diagram

90


1.0Updateempl.

Payrollfile

2.0Pay

Employ-ees

5.0UpdateGen.

Ledger

4.0Pay

taxes

3.0Preparereports


GeneralLedger

HumanResources


Bank

Govt.Agencies

Manage-ment

EmployeeChange

form

New employeeform

Timecards

Employeepaychecks

Payrollcheck



Tax report& payment

Payrollreport

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.

91

Data Flow Diagram example

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

92

DFD BalanceDFD Balance

CUSTOMER

Transform Customer

Food Order

1.0

Management Report

KITCHEN

RESTAURANTMANAGER

Food OrderCustomer Order

Receipt

UpdateInventory

UpdateGoods Sold

2.03.0

INVENTORYD2GOODS SOLDD1

GoodsSold Data

Inventory Data

Formatted Goods Sold Data

Formatted Inventory Data

Daily InventoryDepletion AmountsDaily Goods

Sold AmountsProduce

ManagementReport

4.0

93

Level 1 DiagramLevel 1 Diagram

ProcessCustomer

Order

1.1

Customer Order

PROCESS 1 ON THE LEVEL 0 DIAGRAM

SUB PROCESS 1 THIS LEVEL 1DIAGRAM

TransformOrder to KitchenFormat

1.3

Customer Order Food Order

GenerateCustomer

Receipt

1.2

Customer Order

Generate Inventory

Decrements

Customer Order

Customer Order

1.5

1.4Generate Good SoldIncrements

InventoryData

Goods Sold Data

ReceiptNOTE HOW WE HAVE THE SAME INPUTS AND OUTPUTS AS THE ORIGINAL PROCESSSHOWN IN THE LEVEL 0 DIAGRAM

94

Another Level 1 DiagramAnother Level 1 Diagram

Management Report

Daily InventoryDepletion Amounts

Daily GoodsSold Amounts Produce

ManagementReport

4.0

4.1Access

Goods Soldand Inventory

Data

Daily GoodsSold Amounts

Daily InventoryDepletion Amounts

Inventory Data

Goods Sold Data

4.2Aggregate

Goods Soldand Inventory

Data

PrepareManagement

Report

4.3 Management Report

ORGINAL LEVEL 0 PROCESS

LEVEL 1 PROCESSES

PROCESSES 2.0 AND 3.0 ON THE LEVEL 0 DIAGRAMDO NOT NEED FURTHER DECOMPOSTION

95

Balancing DFDsBalancing ensure that the input

and output data flows of the parent DFD are maintained on the child DFD.

96

Unbalancing exampleContext Diagram

DFD

97

Data Flow Diagram Rules

Let’s 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 boundaries—where it starts and stops. If you’re not sure about a process, include it for the time being.

98


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.

99


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.

100

Data Flow Diagram RulesData Flow Diagram RulesRULE 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.

101

Data Flow Diagram RulesData Flow Diagram RulesRULE 14: You’re 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 preparer’s name

102

Data Flow Diagram : an Data Flow Diagram : an exampleexample

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 employee’s 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.

103


1.0Updateempl.

Payrollfile

2.0Pay

Employ-ees

5.0UpdateGen.

Ledger

4.0Pay

taxes

3.0Preparereports


GeneralLedger

HumanResources


Bank

Govt.Agencies

Manage-ment

EmployeeChange

form

New employeeform

Timecards

Employeepaychecks

Payrollcheck



Tax report& payment

Payrollreport

104

Data Flow Diagram Data Flow Diagram SummarySummary

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 nameData cannot move directly from a

source to a sink

105

106

Chapter (4) Part two


Techniques (Data Dictionary)

107

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

Data Dictionary

108

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

Benefits of a DDS

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.

Typical DD ContentsTypical DD ContentsData elements

◦ names, data typeTables

◦ owner, creation date, access specifications, size

Indexes◦ name, attributes involved, creation date

Authorized users◦ names, type(s) of access

Integrity Constraints

110

111

Chapter (4) Part three


Techniques (UML)

112

UML DiagramUML Diagram – – What is UML?What is UML?

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

Specifying Visualizing Constructing Documenting

Business Modeling Communications

113

UML Different Diagrams

*Use case diagramsDescribe the functional behavior of the system as seen by the user.

*Class diagramsDescribe the static structure of the system: Objects, Attributes, and Associations.

*Sequence diagramsDescribe the dynamic behavior between actors and the system and between objects of the system.

*State chart diagramsDescribe the dynamic behavior of an individual object as a finite state machine.

*Activity diagramsModel the dynamic behavior of a system, in particular the workflow, i.e. a flowchart.

114

Example of UML

115

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

1- Use Case Diagram

116

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)

Purpose of Use Case Diagram

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

Use cases are documented in two waysUse cases are documented in two waysUse Case diagrams

oGive an overview of visible use scenarios in the system

oDescribes what actors that interact with the system

oDescribes any linkages between use cases

Verbal descriptionoDescribes the content of each use

case oTypically uses a pre-defined template

118

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

Passenger

Purchase Ticket

120

Example of Use Case DiagramExample of Use Case Diagram

student

registration

updatinggrades

outputgenerating

faculty

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.

parent

child

124

registration

graduateregistration

non-graduateregistration

More about GeneralizationMore about Generalization

125

Example:Draw 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 client5- supervisor check orders and fine payment

126

Use Case Diagram Use Case Diagram –– Example1 Example1 (Library)(Library)

A Library System.

client employee

supervisor

library system

borrow

reserve

Order title

Fine payment

127

Use Case Diagram for Student Use Case Diagram for Student Assessment Management Assessment Management System System

Teacher

Student

Printing administrator

Grade system

Record grades

View grades

DistributeReport cards

Create report cards

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.

base included<<include>>

129

More about IncludeMore about IncludeEnables to avoid describing the

same flow of events several times by putting the common behavior in a use case of its own.

updatinggrades

outputgenerating

verifyingstudent id

<<include>>

<<include>>

130

Passenger

PurchaseSingleTicket

PurchaseMultiCard

NoChange

<<extend>>

Cancel

<<extend>>

<<include>>

CollectMoney

<<include>>

More about Include

131

Use Case – Example (self Use Case – Example (self service machine)service machine)

Close Machine

Restock

Close Machine

Open Machine

<<includes>>

<<includes>>

Collect

Open Machine

<<includes>>

<<includes>>

Buy a product

Restock according to sales

customer

supplier

Self Service 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.

base extending<<extend>>

133

More about ExtendMore about ExtendEnables to model optional

behavior or branching under conditions.

Exam copy request

Exam-grade appeal

<<extend>>

134

Passenger

PurchaseTicket

TimeOut

<<extend>>

NoChange

<<extend>>OutOfOrder

<<extend>>

Cancel

<<extend>>

More about More about ExtendExtend

135

ExampleExample

placephone call

cellularnetwork

user

receivephone call

placeconference

call

receiveadditional

call

usescheduler

<<extend>>

<<extend>>

Cellular Telephone

Other examplesOther examples

OpenIncident

AllocateResources

HelpDispatcher<<include>>

<<include>>

OpenIncident

AllocateResources

ConnectionDown<<extend>>

<<extend>>

Authenticate

Authenticate

Authenticate

WithPassword

WithCard

136

Use Case Diagram (Narrative Description)

Name: Purchase ticketDescription:

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.

137

Use Case Diagrams: SummaryUse case diagrams represent external

behaviorUse case diagrams are useful as an

index into the use casesUse case descriptions provide meat of

model, not the use case diagrams.All use cases need to be described for

the model to be useful.

138

139

University Record System University Record System (URS)(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 (N>0).

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 Some Actions Supported by URSby 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 SystemUse Case Diagram - URS System

systemuser academic

student

URS

delete member

add member

add subject

del subject

assg subject

unass subject

enrol subject

unenrol subject

142

Example. Automatic teller machine (ATM)Withdraw money using a Visa cardSummary: This use case allows a Visa card holder, who is not acustomer of the bank to withdraw money if his/her daily limit allows it.1. The Visa CardHolder inserts his/her smart card in the ATM’s cardreader.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 encodedon the chip of the smartcard.6. The ATM requests an authorisation from the Visa authorisation system7. The Visa authorisation system confirms its agreement and indicatesthe daily withdrawal limit.8. The ATM asks the Visa CardHolder to enter the desiredwithdrawal 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 numberAt step 5, the Visa CardHolder fails to enter a correct pin number6. The ATM informs the CardHolder that the pin is incorrect for thefirst 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 dailywithdrawal limit

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

144

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 many0….1 zero or one1 One and only one1….* one or many

Table zone2priceEnumeration getZones()Price getPrice(Zone)

TariffSchedule

Attributes and operations Attributes and operations visibilityvisibilityAttributes visibilityThey 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

147

InstancesInstances

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.

zone2price = {{‘1’, .20},{‘2’, .40},{‘3’, .60}}

tariff_1974:TarifSchedule

Actor vs. InstancesActor vs. InstancesWhat 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”).

149

AssociationsAssociations

Associations denote relationships between classes.

The multiplicity of an association end denotes how many objects the source object can legitimately reference.

Enumeration getZones()Price getPrice(Zone)

TarifSchedule

* pricezone

TripLeg

*

1-to-1 and 1-to-Many 1-to-1 and 1-to-Many AssociationsAssociations

1-to-1 association

1-to-many association

*

draw()

Polygon

x:Integery:Integer

Point1

Has-capital

name:String

Country

name:String

City11

151

AggregationAggregation

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

Exhaust System

Muffler Tailpipe

0..2

CompositionComposition

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

3

TicketMachine

ZoneButton

GeneralizationGeneralization

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.

Button

ZoneButtonCancelButton

154

From Problem Statement to From Problem Statement to CodeCodeProblem Statement

A stock exchange lists many companies. Each company is identified by a ticker symbol

Class Diagram

Java Codepublic class StockExchange { public Vector m_Company = new Vector();};public class Company { public int m_tickerSymbol; public Vector m_StockExchange = new Vector();};

*StockExchange

tickerSymbol

Company*lists

155

156

URS - High Level Class URS - High Level Class DiagramDiagram

URSDataBase

UniversityMember

AcademicStaff Student

Subject

1

*has

1

*

has

teaches

0..3

1

takes *

0…10

157

UML Sequence DiagramsUML 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()

pickupChange()

pickUpTicket()

insertCoins()

PassengerTicketMachine

158

UML Sequence Diagrams: UML Sequence Diagrams: Nested MessagesNested Messages

The source of an arrow indicates the activation which sent the message

An activation is as long as all nested activations

selectZone()

PassengerZoneButton TarifSchedule Display

lookupPrice(selection)

displayPrice(price)

price

Dataflow

…to be continued...

Sequence Diagram Sequence Diagram ObservationsObservationsUML 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.

160

161

Use case diagramUse case diagram

Online C2C shopping

• 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

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

162

Class DiagramClass Diagram

Class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation, and association), and the operations and attributes of the classes.

Name

Attributes

Operations

Relations

• Associations• Aggregation

• Generalization

163

Relationships between Class Relationships between Class DiagramsDiagrams

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 DiagramSequence Diagram

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

Object: Class

Lifeline

Operations

Message

165

Activities DiagramActivities Diagram

Activity diagrams describe the workflow behaviour of a system

Start

Fork

Branch

MergeJoint

End

166

State Machine DiagramState Machine Diagram

A State Machine diagramshows the possible states ofthe object and the transitionsthat 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

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.

System Design Output

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

TerminologyTerminologyReliability: 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.

173

Dealing with ErrorsDealing with ErrorsVerification:

◦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

174

Another View on How to Deal Another View on How to Deal with Errorswith ErrorsError 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

bugsError recovery (recover from failure once the system is

released):◦Data base systems (atomic transactions)◦Modular redundancy◦Recovery blocks

175

Some ObservationsSome ObservationsIt is impossible to completely test

any nontrivial module or any system◦Theoretical limitations: Halting

problem◦Practial limitations: Prohibitive in

time and costTesting can only show the

presence of bugs, not their absence (Dijkstra)

176

Testing Activities Testing Activities

Tested Subsystem

SubsystemCode

FunctionalIntegration

Unit

TestedSubsystem

RequirementsAnalysis

Document

SystemDesign

Document

Tested Subsystem

Test Test

Test

Unit Test

Unit Test

User Manual

RequirementsAnalysis

Document

SubsystemCode

SubsystemCode

All tests by developerAll tests by developer

FunctioningSystem

IntegratedSubsystems

177

GlobalRequirements

Testing Activities Testing Activities continuedcontinued

User’s understandingTests by developerTests by developer

Performance Acceptance

Client’s Understanding

of Requirements

Test

FunctioningSystem

TestInstallation

User Environment

Test

System inUse

UsableSystem

ValidatedSystem

AcceptedSystem

Tests (?) by userTests (?) by user

Tests by clientTests by client

178

Types of TestingTypes of TestingUnit Testing:

◦Individual subsystem◦Carried out by developers◦Goal: Confirm that subsystems is correctly coded and

carries out the intended functionalityIntegration Testing:

◦Groups of subsystems (collection of classes) and eventually the entire system

◦Carried out by developers◦Goal: Test the interface among the subsystem

179

System TestingSystem TestingSystem 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

180

Unit TestingUnit TestingInformal:

◦Incremental codingStatic 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)

181

Black-box Testing 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)

182

Black-box Testing Black-box Testing (Continued)(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 => white-box testing

183

White-box TestingWhite-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

184

Integration Testing: Big-Bang Integration Testing: Big-Bang ApproachApproach

Unit Test F

Unit Test E

Unit Test D

Unit Test C

Unit Test B

Unit Test A

System Test

Don’t try this!

185

Bottom-up Testing Bottom-up Testing StrategyStrategyThe subsystem in the lowest layer of

the call hierarchy are tested individuallyThen 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

SeatDriver(simulates VIP)

Seat Interface(in Vehicle Subsystem)

Seat Implementation

Stub Code Real SeatSimulated

Seat (SA/RT)186

Bottom-up IntegrationBottom-up IntegrationAB C D

GFE

Layer I

Layer II

Layer III

Test F

Test E

Test G

Test C

Test D,G

Test B, E, F

Test A, B, C, D,

E, F, G

187

Pros and Cons of bottom up Pros and Cons of bottom up integration testingintegration testing

Bad for functionally decomposed systems:Useful for integrating the following

systems◦ Object-oriented systems◦ real-time systems◦ systems with strict performance requirements

188

System TestingSystem TestingFunctional TestingStructure TestingPerformance TestingAcceptance TestingInstallation 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:

189

Structure TestingStructure TestingEssentially the same as white box testing.Goal: Cover all paths in the system

design◦Exercise all input and output parameters

of each component.◦Exercise all components and all calls

(each component is called at least once and every component is called by all possible callers.)

◦Use conditional and iteration testing as in unit testing.

190

Functional TestingFunctional Testing.

.

Essentially the same as black box testingGoal: Test functionality of systemTest cases are designed from the

requirements analysis document (better: user manual) and centered around requirements and key functions (use cases)

The system is treated as black box.Unit test cases can be reused, but in

end user oriented new test cases have to be developed as well.

191

Performance TestingPerformance Testing Stress Testing

◦ Stress limits of system (maximum # of users, peak demands, extended operation)

Volume testing◦ Test what happens if large

amounts of data are handled Configuration testing

◦ Test the various software and hardware configurations

Compatibility test◦ Test backward compatibility with

existing systems Security testing

◦ Try to violate security requirements

Timing testing◦ Evaluate response times and

time to perform a function Environmental test

◦ Test tolerances for heat, humidity, motion, portability

Quality testing◦ Test reliability, maintain-

ability & availability of the system

Recovery testing◦ Tests system’s response to

presence of errors or loss of data.

Human factors testing◦ Tests user interface with user

192

Acceptance TestingAcceptance TestingGoal: Demonstrate

system is ready for operational use◦ Choice of tests is made by

client/sponsor◦ Many tests can be taken

from integration testing◦ Acceptance test is

performed by the client, not by the developer.

Majority of all bugs in software is typically found by the client after the system is in use, not by the developers or testers. Therefore two kinds of additional tests:

Goal: Demonstrate system is ready for operational use◦ Choice of tests is made by

client/sponsor◦ Many tests can be taken

from integration testing◦ Acceptance test is

performed by the client, not by the developer.

Majority of all bugs in software is typically found by the client after the system is in use, not by the developers or testers. Therefore two kinds of additional tests:

Alpha test:◦ Sponsor uses the software

at the developer’s site.◦ Software used in a

controlled setting, with the developer always ready to fix bugs.

Beta test:◦ Conducted at sponsor’s site

(developer is not present)◦ Software gets a realistic

workout in target environment

◦ Potential customer might get discouraged

Alpha test:◦ Sponsor uses the software

at the developer’s site.◦ Software used in a

controlled setting, with the developer always ready to fix bugs.

Beta test:◦ Conducted at sponsor’s site

(developer is not present)◦ Software gets a realistic

workout in target environment

◦ Potential customer might get discouraged

193

194

Object Design (1/2) During analysis, we describe the application objects.

During system design, we describe the system in terms of its

architecture, such as its subsystem decomposition, global control flow,

persistency management, and hardware/software platform on which we

build the system. This allows the selection of off-the-shelf components

that provide a higher level of abstraction than the hardware.

During object design, we close the gap between the application objects

and the off-the-shelf components by identifying additional solution

objects and refining existing objects. Object design includes:

◦ reuse, during which we identify off-the-shelf components and design patterns

to make use of existing solutions

◦ service specification, during which we precisely describe each class interface

◦ object model restructuring, during which we transform the object design

model to improve its understandability and extensibility

◦ object model optimization, during which we transform the object design model

to address performance criteria such as response time or memory utilization.

195

Object Design (2/2) During object design, we identify and refine solution objects to realize the

subsystems defined during system design.

During this activity, our understanding of each object deepens:

◦ we specify the type signatures and the visibility of each of the operations.

◦ we describe the conditions under which an operation can be invoked and those

under which the operation raises an exception.

The focus of object design is on specifying the boundaries between objects.

At this stage in the project, a large number of developers concurrently refines

and changes many objects and their interfaces. The focus of interface

specification is for developers to communicate clearly and precisely about

increasingly lower-level details of the system.

The interface specification activities of object design include:

◦ identifying missing attributes and operations

◦ specifying type signatures and visibility

◦ specifying invariants

◦ specifying preconditions and postconditions.

Documents

1 Information Systems Development (IS501) Dr.Doaa Nabil