SOFTWARE

ANALYSIS
AND
SOFTWARE
DESIGN

TYPES OF REQUIREMENTS
ALONG DIFFERENT VIEWS
Functional Requirements (FRs)
Structural Functional Requirements
Functional, i.e., Function-oriented
Informational. i.e., Information-oriented
Behavioral Functional Requirements

Non-Functional Requirements (NFRs)

FUNCTION ORIENTED PROBLEM

ANALYSIS
Creates a hierarchy of functions
Also called (process, activity, work-step, transactions,
transforms, bubbles)
Root is most abstract
Leaf nodes the most detailed
Most methods use data flow diagrams and dictionaries
Examples
SRD structured requirements definition
SADT
Information Engineering
Modern structured Analysis
Problem statement Language

PROCESS MODELING
A data flow diagram (DFD) is a tool (and type of
process model) that depicts the flow of data
through a system and the work or processing
performed by that system.
DFDs have become a popular tool for business
process redesign.

DATA FLOW DIAGRAMS

Existed long before computers

Show the flow of data through a system
System

Organization
Company
A computer hardware system
A software system

Icons

Data on the move named arrows

Transformations of data named bubbles
Sources and destinations of data named rectangles
(terminators)
Data in static storage two parallel lines

DATA FLOW DIAGRAM

NOTATIONS
Data Store
Process
A process transforms
incoming data flow into
outgoing data flow.

Data stores are repositories

of data in the system. They
are sometimes also
referred to as files.

Dataflow
Dataflows are pipelines
through which packets of
information flow. Label the
arrows with the name of the
data that moves through it.

Yourdon and Coad

Process Notations

Gane and Sarson

Process Notation

Yourdon and
Coad
Datastore
Notation

Gane and Sarson

Datastore Notations

External Entity
External entities are objects outside
the system, with which the system
communicates. External entities are
sources and destinations of the
system's inputs and outputs.

DATAFLOW DIAGRAMS

DATA FLOW DIAGRAM

LAYERS
Data flow diagrams are drawn in several nested layers
A single process node on a high level diagram can be expanded
to show a more detailed data flow diagram.
Draw the context diagram first, followed by various layers of
data flow diagrams.

CONTEXT DIAGRAMS

A context diagram is a top level (also known as Level 0)

data flow diagram. It only contains one process node
(process 0) that generalizes the function of the entire
system in relationship to external entities.

DFD LEVELS
The first level DFD shows the main processes
within the system. Each of these processes
can be broken into further processes until you
reach pseudocode.

DATA FLOW DIAGRAMS

Rules
All names must be unique
Not a flow chart no order implied
No logical decisions
Dont get bogged down in detail

Leveling
Preserve the number of inputs and outputs between the
levels

I1

O1

A
I2

A1

I1
I2

A2

A3
data

O
1

DIFFERENCE BETWEEN
DFD AND FLOWCHARTS
Processes on DFDs can operate in parallel (at-the-sametime)
Processes on flowcharts execute one at a time
DFDs show the flow of data through a system
Flowcharts show the flow of control (sequence and
transfer of control)
Processes on one DFD can have dramatically different
timing
Processes on flowcharts are part of a single program
with consistent timing

Illegal Data Flows

DATA DICTIONARIES
Used to augment the Data Flow Diagrams
Repository
Layout
Name of the item
Alias
Description/Purpose
Related data items
Range of values
Data flows
Data structure definition/form

A SIMPLE PROCESS
MODEL

TRADITIONAL APPROACHES TO ENTERPRISE

MODELING
SADT (STRUCTURED ANALYSIS AND DESIGN
TECHNIQUE)
Background
in use since the mid-seventies
inspiration for many commercial tools
View
"System" refers to any enterprise/organization, physical,
manufacturing,and SW system
Context Analysis should involve
technical assessment: feasibility of system architecture
Are the components and inter-relationships technically realizable?

operational assessment: system performance in a working

environment
Can the system perform task X in less than a week of time?
economic assessment: costs & impacts of system implementation

& use

SADT (STRUCTURED ANALYSIS

AND DESIGN TECHNIQUE)

SADT (STRUCTURED ANALYSIS AND DESIGN

TECHNIQUE

SADT (STRUCTURED ANALYSIS

AND DESIGN TECHNIQUE

Semantics of Arrows

In an actigram
Inputs are data that are consumed by the activity
Outputs are produced by the activity
Controls influence the execution of an activity but are not
consumed
Mechanism is a processor (machine, computer, person)

SADT (STRUCTURED ANALYSIS

AND DESIGN TECHNIQUE

SADT (STRUCTURED ANALYSIS

AND DESIGN TECHNIQUE

SADT (STRUCTURED ANALYSIS

AND DESIGN TECHNIQUE

Semantics of Arrows
In an actigram
Inputs are data that are consumed by the activity
Outputs are produced by the activity
Controls influence the execution of an activity but are not consumed
Mechanism is a processor (machine, computer, person) which makes the activity
happen

in a datagram
Inputs are activities that produce the data
Outputs consume the data
Controls influence the internal state of the data
Mechanism is a device for storage, representation, impl., etc.

A SIMPLE DATA MODEL

SADT
Structured Analysis and Design Technique
Phases:
SA
Activity diagrams combined to for activity network
Data diagrams combined to form data network

DT
Uses dataflow diagrams
Data dictionary
Pseudo algorithm representations for control information
Relational tables to indicate data element relations

SA ACTIVITY
DIAGRAM
Control

Inputs

Mechanism

Outputs

SA DATA DIAGRAM
Control

Generating

Resulting
Activity

Activity

Storage
Device

ESTIMATION OF
MAINTENANCE
COST

SOFTWARE
MAINTENANCE
:Maintenance is the process of changing system software after it
has been delivered to the customer.In other words, Maintenance is
about actions taken when a product does not function properly.
Software maintenance workload is very large, although in different
applications of its maintenance costs vary widely, but averagely,
the maintenance costs of large software development costs as high
as 4 times. Maintenance plays important role in various software
developments like Iterative development, Agile development and
Component Based Software Development. In the recent year,
software development turned into engineering through the
introduction of Component Based Software Development.

COST MAINTENANCE
Software has become the most expensive component of computer system projects.
The bulk of the cost of software development is due to the human effort, and most
maintenance cost estimation methods focus on this aspect and give estimates in
terms of person-months. Accurate software maintenance cost estimates are critical to
both developers and customers. They can be used for generating request for
proposals, contract negotiations, scheduling, monitoring and control. Underestimating
the costs may result in management approving proposed systems that then exceed
their budgets, with underdeveloped functions and poor quality, and failure to
complete on time. Overestimating may result in too many resources committed to the
project, or, during contract bidding, result in not winning the contract, which can lead
to loss of jobs. Accurate maintenance cost estimation is important because:
1.It can help to classify and prioritize development projects with respect to an overall
business plan.
2. It can be used to determine what resources to commit to the project and how well
these resources will be used.
3. Projects can be easier to manage and control when resources are better matched to
real needs.
4.Customers expect actual development costs to be in line with estimated costs.

MOTIVATION
The software cost estimation provides:
the vital link between the general concepts and
techniques of economic analysis and the particular
world of software engineering.
Software cost estimation techniques also provides an
essential part of the foundation for good software
management.

COST OF A PROJECT
The cost in a project is due to:
due the requirements for software, hardware and human
resources
the cost of software development is due to the human
resources needed
most cost estimates are measured in person-months
(PM)

COST OF A PROJECT (.)

the cost of the project depends on the nature and
characteristics of the project, at any point, the accuracy
of the estimate will depend on the amount of reliable
information we have about the final product.

SOFTWARE COST ESTIMATION

INTRODUCTION TO COCOMO
MODELS
The COstructive COst Model (COCOMO) is the most
widely used software estimation model in the world. It
The COCOMO model predicts the effort and duration of
a project based on inputs relating to the size of the
resulting systems and a number of "cost drives" that
affect productivity.

EFFORT
Effort Equation
PM = C * (KDSI)n (person-months)
where PM = number of person-month (=152 working hours),
C = a constant,
KDSI = thousands of "delivered source instructions" (DSI) and

n = a constant.

COCOMO MODELS
COCOMO is defined in terms of three different models:
the Basic model,
the Intermediate model, and
the Detailed model.

The more complex models account for more factors that

influence software projects, and make more accurate
estimates.

THE DEVELOPMENT MODE

the most important factors contributing to a project's
duration and cost is the Development Mode
Organic Mode: The project is developed in a familiar, stable
environment, and the product is similar to previously
developed products. The product is relatively small, and
requires little innovation.
Semidetached Mode: The project's characteristics are
intermediate between Organic and Embedded.

THE DEVELOPMENT MODE

the most important factors contributing to a project's
duration and cost is the Development Mode:

Embedded Mode: The project is characterized by tight,

inflexible constraints and interface requirements. An
embedded mode project will require a great deal of innovation.

COST ESTIMATION
PROCESS
Cost= Size Of The Project x
Productivity

COST ESTIMATION PROCESS

Effort

Size Table
Lines of Code
Number of Use Case
Function Point

Development Time
Estimation Process
Number of Personnel
Errors

CONCLUSION

Software maintenance cost estimation models helps to improve the impact of maintenance cost factor.
Barry W. Boehms in-depth analysis of 17 factors derived from the actual use of the software based on the
specific situation of the affected software, the cost of maintenance, the weight factors and work to make
proper adjustments software maintenance cost estimation closer to the actual value. We propose a
systematic approach for software maintenance cost estimation
model using fourth generation language environment on the basis of COCOMO II. This model is based on
three parameters which are given. Favorable results can be achieved by using model implementation. In
this paper the problems of estimating the cost of the maintenance process have been solved with our model
using fourth generation language environment and data collected from previous projects based on COCOMO
II model. By applying the proposed model and procedures to these historical data, control over current and
future maintainability can be improved and thereby unnecessary and unproductive maintenance costs can
be avoided. This model is applicable for providing the accurate estimates, improving the adaptability of
software, developing and understanding between the user, customer and third party.
As part of the future work, we will improve our cost estimation model by extending the data pool to cover
additional applications. The software estimation model has to be recalibrated and extended to more reflect
more closely the software development and maintenance practice. The future perspective this model can be
enhanced to calculate the maintenance cost of large data projects.