Software Processes

Iteration in SDLC
1. Iteration assumes no one gets the right results the first
time
2. Do some analysis, then some design, then do some
further analysis, until you get it right
3. Not always realistic to complete analysis before
starting design
4. Waterfall no longer applies - Phases become blurred
5. Decisions are not frozen at the end of each phase
6. Good for projects where requirement specifications are
hard to arrive at
Iteration in SDLC

Iteration is the process of looping

through the same development
activities multiple times, sometimes at
increasing levels of detail or accuracy
A newer method: rapid prototyping (with iteration)

Requirements
Gathering
(Analysis)
Quick
Design

Build
Prototype

Evaluate and
Refine Requirements

Engineer
Project
Rapid prototyping model

Req. Change
Rapid Prototype

Verify
Redesign

Verify
Re-implementation

Test

Operations

Retirement
Spiral model sectors
 Objective setting
Specific objectives for the phase are identified
 Risk assessment and reduction
Risks are assessed and activities put in place to
reduce the key risks
 Development and validation
A development model for the system is chosen which
can be any of the generic models
 Planning
The project is reviewed and the next phase of the
spiral is planned
 Spiral Model
Risk
Planning Analysis

With each iteration around the

spiral progressively more complete
versions of the software are built.
The spiral model enables the Customer
Evaluation Engineering

developer, and the customer, to

understand and react to risk at
each evolutionary level.
Each loop around the spiral implies that project costs and
schedules may be modified.
This creates problems in fixed-price project.

FediteC
The Spiral Approach to Development

 Project starts out handling few risks

 Project expands in next iteration to address
more risks
 Eventually the system is completed (all risks
addressed)
 At the middle (start of the project) there is low
risk and project is still small easy to manage
 You work out from the middle, expanding out
your project
Spiral life cycle (cont.)

The spiral life cycle model.

 The Risk-Driven Approach.
 A different approach born out of the
 evolution of the Waterfall Model.
 Encompasses the previous models as
 special cases, and can make use of a
 combination of models.
 Risk analysis asks, “ What are the areas of
uncertainty, and what is the probability that they will
slow the progress of development?”
I. Software specification

The process of establishing what

services are required and the constraints
on the system’s operation and development
 Requirements engineering process
Feasibility study
Requirements and analysis
Requirements specification
Requirements validation
Design methods

Systematic approaches to developing a

software design
 The design is usually documented as a set of
graphical models
 Possible models
Data-flow model
Entity-relation-attribute model
Structural model
Object models
Software validation
 Verification and validation is intended to show
that a system conforms to its specification and
meets the requirements of the system customer
 Involves checking and review processes and
system testing
 System testing involves executing the
system with test cases that are derived from
the specification of the real data to be
processed by the system
METHODOLOGIES,MODELS,TOOLS & TECHNIQUES

 A SYSTEM HAS A VARIETY OF AIDS TO

ASSIST IN ANALYSIS AND DESIGN
.AMONG THEM ARE
METHODOLOGIES,MODELS,TOOLS & TECHNIQUES
 TECHNIQUES,MODELS & TOOLS IN
SYSTEM ANALYSIS & DESIGN

TECHNIQUES MODELS

TOOLS
METHODOLOGIES

 IT PROVIDES GUIDELINES FOR

COMPLETING EVERY ACTIVITY IN
SYSTEM DEVELOPMENT LIFE CYCLE.
 IT CONTAINS INSTRUCTIONS ABOUT
HOW TO USE TECHNIQUES AND
MODELS IN SYSTEM ANALYSIS .
MODELS

 FLOW CHART
 DATA FLOW DIAGRAM
 ENTITY RELATION SHIP DIAGRAM
 STRUCTURE CHART
 USE CASE DIAGRAM
 CLASS DIAGRAMS
 SEQUENCE DIAGRAMS
RECORDING INFORMATION ABOUT SOMETHING
IN THE REAL WORLD,IS THE BASIC PURPOSE
OF VARIOUS TOOLS USED IN
SOFTWARE DEVELOPMENT.
IT IS A REPRESENTATION OF SOME
IMPORTANT ASPECT OF THE REAL WORLD.
IT IS AN ABSTRACTION OF AN ASPECT OF
PARTICULAR IMPORTANCE TO US
EXAMPLE:- MODEL OF A AIRPLANE :-It is important to
have a small model that shows its shape in 3 dimensions
TOOLS:-

 DRAWING/GRAPHICS APPLICATIONS
 WORD PROCESSOR
 COMPUTER AIDED SYSTEM
ENGINEERING TOOLS
 DATABASE MANAGEMENT
APPLICATION
TOOLS:-

 TOOLS IS A SOFTWARE SUPPORT

THAT HELPS TO CREATE MODELS OR
OTHER COMPNENTS REQUIRED IN
THE PROJECT.
TECHNIQUES:-
 STRATEGIC PLANNING TECHNIQUES
 PROJECT MANAGEMENT TECHNIQUES
 USER INTERVIEWING TECHNIQUES
 RELATIONAL DATABASE DESIGN TECHNIQUES
 STRUCTURED ANALYSIS TECHNIQUES
 STRUCTURED DESIGN TECHNIQUES
 STRUCTURED PROGRAMMING TECHNIQUES
 SOFTWARE TESTING TEHNIQUES
 OBJECT ORIENTED ANALYSIS AND DESIGN
TECHNIQUES.
 A TECHNIQUE IN A SYSTEM
DEVELOPMENT IS COLLECTION OF
GUIDELINES THAT HELPS THE
ANALYST COMPLETE THE SYSTEM
DEVELOPMENT ACTIVITY OR TASK.
 OBJECT ORIENTED APPROACH TRADITIONAL APPROACH
EVENTS &
EVENT TABLE

ENTITY
USE CASE CLASS CONTEXT
RELATION SHIP
DIAGRAMS DIGRAMS DIAGRAM
DIAGRAM

DFD
SCENARIOS
FRAGMENTS

SEQUENCE STATE CHART

DETAILS DFDs DIAGRAM 0
DIAGRAMS DIAGRAMS
 STRUCTURED APPROACH TO
ANALYSIS
 OBJECT ORIENTED APPROACH TO
ANALYSIS
 INFORMAL APPROACH TO ANALYSIS
HOW STRUCTURED ANALYSIS LEADS
TO STRUCTURED DESIGN

MODERN
STRUCTURED
ANALYSIS
Events
Data flow diagrams
Entity relationship diagram

STRUCTURED
DESIGN
It defines the
program modules
base upon the
data flow diagrams

STRUCTURED
PROGRAMMING
Program each module using
programming language
WEAKNESSES OF STRUCTURED
APPROACH
 It is considered to be weak because critics desired a
more comprehensive and rigorous set of techniques to
make system development more like an engineering
discipline and less like an art.
 Many people thought the transition from the data flow
diagram in (structured analysis) to structure chart (in
structured design) did not work well in practice
 They thought that entity relationship diagrams and data
modeling were much more important than modeling
processes with the data flow diagram.
SYSTEM FLOW CHART
Maintain customer
information
program
Customer
database
Customer order
program Accounting
Sales analysis Order transaction
database
program
Shipper
Order fulfillment remote
program system
Inventory
database

Catalog
Shipping
Sales analysis Catalog/Promo
maintainance documents
tions database
reports program

catalogs
 STRUCTURE CHART FOR CREATE NEW ORDER PROGRAM

CREATE NEW
ORDER
Customer information Order information

Order financials

Order line items Customer information

Customer information

RECORD BULD PROCESS PRODUCE

CUSTOMER ORDER ORDER CONFIRMATION
INFORMATION TRANSACTION

Customer information Credit Order &

Order information Order id Valid flag information payment info
Customer information

GET CHECK WRITE

PROCESS CREDIT
GET CREATE ORDER TRANSACTION
ORDER ITEM AUTHORIZATION
CUSTOMER CUSTOMER INFORMATION
INFORMATION RECORD

Item id,qty
Item information
Price,QOH

CREATE ORDER
GET GET INVENTORY LINE
REQUESTED ITEMS ITEMS
ITEM
ENTITY RELATIONSHIP DIAGRAM FOR CUSTOMER SUPPORT
SYSTEM OF RMO

A customer can place

zero or more orderS
(OPTIONAL CONDITION)

Customer Order
Customer address Order id
Billing address Order date
amount
Contact number

An order must be placed by

exactly one customer
(MANDATORY CONDITION)
 Zero or more
(optional)

One or more
mandatory
Zero or one
(optional)
 Customer Order Order item
Customer address Order id Item ID
Billing address Order date Quantity
Contact number amount price
 catalog

product

Inventory shipper

Order item shipment

Return item

customer Order
order transaction
 catalog
CLASS S
EASON

DIAGRAM YEAR
DESCRIPTION
EFFECTIVE DTAE
END DATE
PRODUCT iTEM
Product_ID
1 ..* 0 ..*
VENDOR
GENDER
SEASON
DESCRIPTION
0 ..* 1
1 shipper
Inventory

1 1
0 ..*
0 ..* 0 ..*
* ..1 1
Order item shipment
Return item

0 ..*
1
1
customer 1 1..* Order
order transaction
0 ..*
OBJECT ORIENTED APPROACH
 Object Oriented Approach views an
information system as a collection of
interacting objects that work together to
accomplish tasks
 There are no processses or programs
;there are no files or data entities.
 The system consists of objects.
 Object is a thing in the cmputer system
that is capable of responding messages
 Object Oriented Analysis means defining
all of the types of objects that do the work
in the system and showing how the
objects interact to complete tasks.
 Object Oriented Design means defining all
of the additional types of objects
necessary to communicate with people
and devices in the system.
 OO Requierments:-
 EVENT TABLE
 CLASS DIAGRAM
 USE CASE DIAGRAM
 INTERACTION DIAGRAM(sequence
diagrams)
 A use case diagram is a graphical model
that summarizes the information about the
actors (external agents) and use case.
 The uses are identifies by considering
system as a whole.
 These uses normally derive from the
bussiness events identified in the event
table.
 USE CASE DIAGRAM WITH SYSTEM BOUNDARY
Automation Boundary

Look up item
availibility

Create new order

Update order

Order clerk
Customer

ORDER ENTRY SUBSYSTEM

 The Object Oriented Appraoch uses a
term USE CASE to describe an activity
the system carries out in response to an
event.
 You can think of a use case as a case or
situation where the system is used for
some purpose.
 USE CASE DIAGRAM WITH SYSTEM BOUNDARY
Automation Boundary

Look up Record back

order status order

Create order Record SHIPPER

return order fulfillment
Customer

Clerk ORDER FULFILLMENT SUBSYSTEM

 USE CASE DIAGRAM WITH SYSTEM BOUNDARY
Automation Boundary

Provide Distribute
catalog promotional
info package

Create customer Marketing

Update customer
charge
Customer account
adjustment Dept.

Clerk CUSTOMER MAINTAINANCE Management

SUBSYSTEM
 USE CASE DIAGRAM WITH SYSTEM BOUNDARY
Automation Boundary

Create new
catalog

Update catalog

Merchandising
Dept.
Create special
promotion

CATALOG MAINTAINANCE
SUBSYSTEM
 Following symbols are used to represent a
use case diagram:-
 A person involved called an actor
(represented by a stick figure).
 Connecting lines to show which actors
participate in use case.
 The use case is symbolized by an oval
with the name of the use case inside.
Scenarios:-

 A use case only shows that an actor

interacts with the computer system to
carry out a business activity .
 SEQUENCE DIAGRAM FOR
Look Up Item Availability

Product Inventory
Catalog
Item item

Customer Product item enquiry ()

Inventory item enquiry ()

Item inquiry()

Product info()
Item availability
details()
SEQUENCE DIAGRAM

 IT SHOWS THE SEQUENCE OF THE

INTERACTION BETWEEN OBJECTS
THAT OCCURS DURING THE FLOW OF
EVENTS OF A USE CASE.
 FOUR BASIC SYMBOLS ARE USED ON A
SEQUENCE DIAGRAM:-
 The actor symbol
 The object symbol represented by a rectangle
 The lifeline symbol represented by dashed line
 The message symbol represented by a
directional arrow with message description.
 SEQUENCE DIAGRAM FOR ORDER ENTRY SUBSYSTEM FOR
CUSTOMER SUPPORT SYSTEM

:Product item ::inventory item

[New customer] create

customer {customer
information}

customer :customer

Existing customer
Status:= Check status
Customer Name ,phone :order
NO

[First item] Create order Price=Check Price (Product ID)

Add to order (product_id Quantity:=CheckQuantity {Product
,description, Qty)
id,Description,QTY)

Add item confirmation {QOH > QTY }CreateItem (Item ID ,QTY) :Order item

Order complete (Credit card Ready to ship()

number)
Key points
 Requirements engineering is the process of
developing a software specification
 Design and implementation processes
transform the specification to an executable
program
 Validation involves checking that the system
meets to its specification and user needs
 Evolution is concerned with modifying the
system after it is in use