Phases in Software Development

Presenter:
Prof. N. L. Sarda
I.I.T. Bombay

m
Software Development Lifecycle
Let us review the main steps

Problem Definition

Feasibility Study

Analysis

System Design

Detailed Design

Implementation

Maintenance
A separate planning step for large
applications may be introduced after
feasibility

Problem Definition
To answer: µWhat is the Problem¶
Where and by whom is the problem felt?
Meet users and Management and obtain
their agreement that there is a problem
If problem exists, and it needs to be solved

It becomes a project

Commitment of funds implied

á
Problem Definition«
Prepare a brief statement of problem

Avoids misunderstandings

Get concurrence from user/management

Usually short : 1 or 2 pages
Estimate cost and schedule for the next
feasibility step
Estimate roughly overall project cost to give
users a sense of project scope. The
estimates become more refined in later steps

ë
Problem Definition «
This step is short; lasts a day or two
Proper understanding and characterization
of problem essential

To discover cause of the problem

To plan directed investigation

Else, success is unlikely

¢
Problem Definition «
Possible initial characterization of problems

Existing system has poor response time, i.e., it
is slow

Unable to handle workload

Problem of cost: existing system uneconomical

Problem of accuracy and reliability

Requisite information is not produced by system

Problem of security

_
Problem Definition document
1. Project Title
2. Problem Statement: Concise statement of
problem, possibly in a few lines
3. Project Objectives: state objective of the
project defined for the problem
4. Preliminary Ideas: possible solutions, if
any, occurring to user and/or analyst could
be stated here.

V
Problem Definition document«
5. Project Scope: give overall cost estimate
as ballpark figure
6. Feasibility Study: indicate time and cost
for the next step
Notes

Do not confuse between problems and
solutions e.g., µdevelop computerized payroll¶
cannot be a problem

No commitment is implied to preliminary ideas

±
Feasibility Study
To get better understanding of problems and
reasons by studying existing system, if
available

Are there feasible solutions?

Is the problem worth solving?
Consider different alternatives
Essentially covers other steps of methodology
(analysis, design, etc.) in a µcapsule¶ form
Estimate costs and benefits for each
alternative
ß
Feasibility Study«
Make a formal report and present it to
management and users; review here
confirms the following:

Will alternatives be acceptable

Are we solving the right problem

Does any solution promise a significant return
Users/management select an alternative
Many projects µdie¶ here

m
Types of Feasibility
Economical : will returns justify the
investment in the project ?
Technical : is technology available to
implement the alternative ?
Operational : will it be operationally feasible
as per rules, regulations, laws,
organizational culture, union agreements,
etc. ?

mm
Costs
One-time (initial) costs include equipment,
training, software development,
consultation, site preparation
Recurring costs include salaries, supplies,
maintenance, rentals, depreciation
Fixed and variable costs; vary with volume
of workload

m
Benefits
Benefits could be tangible (i.e. quantifiable)
or intangible
Saving (tangible benefits) could include

Saving in salaries

Saving in material or inventory costs

More production

Reduction in operational costs, etc.

má
Benefits «
Intangible benefits may include

Improved customer service

Improved resource utilization

Better control over activities (such as
production, inventory, finances, etc.)

Reduction in errors

Ability to handle more workload

më
Estimating Costs
How to estimate costs so early in the project?

Decompose the system and estimate costs of
components; this is easier and more accurate
than directly estimating cost for the whole system

Use historical data whenever available

Use organization's standards for computing
overhead costs (managerial/secretarial support,
space, electricity, etc.)

Personnel (for development and operations) costs
are function of time, hence estimate time first

m¢
Financial Analysis
Consider time-value of money; while
investment is today, benefits are in future!
Compute present value P for future benefit F
by
P = F/ (1+I)n
where I is prevailing interest rate and n is year of
benefit
Take into account µlife¶ of system: most
systems have life of 5-7 years

m_
Financial Analysis «
Cost is µinvestment¶ in the project, benefits
represent µreturn¶
Compute payback period in which we
recover initial investment through
accumulated benefits
Payback period is expected to be less than
system life !
Are there better investment alternatives?

mV
 FEASIBILITY STUDY Report
1.0 Introduction:
A brief statement of the problem, the environment
in which the system is to be implemented, and
constraints that affect the project
2.0 Management Summary and Recommendations:
Important findings and recommendations
3.0 Alternatives:
A presentation of alternative system specifications;
criteria that were used in selecting the final
approach

m±
FEASIBILITY STUDY «
4.0 System Description
An abbreviated version of information contained
in the System-Specification or reference to the
specifications
5.0 Cost-Benefit Analysis
6.0 Evaluation of Technical Risk
7.0 Legal Ramifications (if any)
8.0 Other Project-Specific Topics

mß
Requirements Analysis
Objective: determine what the system must do
to solve the problem (without describing how)
Done by Analyst (also called Requirements
Analyst)
Produce Software Requirements Specifications
(SRS) document
Incorrect, incomplete, inconsistent, ambiguous
SRS often cause for project failures and
disputes


Requirements Analysis «
A very challenging task

Users may not know exactly what is needed or
how computers can bring further value to what
is being done today

Users change their mind over time

They may have conflicting demands

They can¶t differentiate between what is possible
and cost-effective against what is impractical
(wish-list)

Analyst has no or limited domain knowledge

Often client is different from the users
m
SRS
SRS is basis for subsequent design and
implementation
First and most important baseline

Defines µcontract¶ with users

Basis for validation and acceptance
Cost increases rapidly after this step;
defects not captured here become 2 to 25
times more costly to remove later


SRS «
It identifies all functional (inputs, outputs,
processing) and performance requirements,
and also other important constraints (legal,
social, operational)
Should be adequately detailed so that

Users can visualize what they will get

Design and implementation can be carried out
Covers what and how at business level; e.g.,

What: calculate take-home pay

How: procedure (allowances, deductions, taxes
etc.)
á
Analysis Process
Interviewing clients and users essential to
understand their needs from the system
Often existing documents and current mode
of operations can be studied
Long process: needs to be organized
systematically

Interviewing, correlating, identifying gaps, and
iterating again for more details

Focus on what gets done or needs to be done

Focus on business entities, their interactions,
business events, «
ë
Analysis Process «
Identify users and important business entities
Get functional (domain) knowledge
Interview users or get details through
questionnaires
Examine existing system : study existing forms,
outputs, records kept (files, ledgers,
computerized systems)
Often goes outside in : what outputs needed,
which inputs provide data, what processing done,
what records kept, how records updated, .. (i.e.,
go inwards from system boundaries)
¢
Interviews
Identify users, their roles and plan
interviews in proper order to collect details
progressively and systematically
Conducting interviews is an art !

Workout scope, durations, purpose

Keep records and verify/confirm details

Needs to sometimes µprompt¶ users in
visualizing requirements
Need good communication skills, domain
knowledge, patience, «
_
Organizing Findings
Massive amount of information is collected
from interviews, study of existing systems
Need to be organized, recorded, classified
and conceptualized (at multiple level of
details)
Tools/repositories available (describe
inputs, outputs, files, computations, usages,
functions): help in checking consistency and
completeness

V
Organizing «
Create models or projections from different
perspectives

Way to handle complexity (divide-and-conquer)

Hide unnecessary details
Reduces errors, ensures consistency/completeness
Data-flow diagrams (for processing), entity-
relationship models (for data domain) and object
models commonly used
SRS format is great help in organizing requirements
in details
±
Structured Analysis
Focuses on functions/processes and data
flowing between them
Uses top-down decomposition approach

Initially see the application as a single process
and identify inputs, outputs, users and data
sources

Decompose the process into sub processes,
show data flows for them

Function Decomposition and Data Flow
Diagrams (FDD, DFD) very useful

ß
Structured Methodology
Study existing system: What is done and how
Prepare physical current DFD
Convert this DFD to logical DFD

Remove physical implementation-specific details
Define boundary for automation (scope)
Prepare DFD for proposed system - requires
innovation, experience, vision

Incorporate new needs

Improve work flows (BPR: business process
re-engg)

Introduce efficiency/effectiveness
á
Requirement Specification Format
(Based on IEEE Recommendation)
1. Introduction
1.1 PURPOSE: clearly state purpose of this document
1.2 SCOPE: by whom and how it will be used
1.3 Definitions: Acronyms, Abbreviations as
applicable
1.4 REFRENCES: to other documents
1.5 Overview of Developer¶s Responsibilities: In terms
of development, installation, training, maintenance,
etc.

ám
Requirement Specification Format
2. GENERAL DESCRIPTION
2.1 PRODUCT PERSPECTIVE: relationship with
other products and principle interfaces
2.2 PRODUCT FUNCTIONS OVERVIEW: general
overview of tasks; including data flow diagrams
2.3 USER CHARACTERISTICS: who they are and
what training they may need
2.4 GENERAL CONSTRAINTS: about schedule,
resources, cost, etc.

á
Requirement Specification Format «
3.1 FUNCTIONAL REQUIREMENT
3.1.1 INTRODUCTION
3.1.2 INPUTS
3.1.3 PROCESSING
3.1.4 OUTPUTS
3.2«.. (repeat similarly for each function)

áá
Requirement Specification Format «
4. External Interface Requirements
4.1 User Interfaces: a preliminary user manual
giving commands, screen formats, outputs,
errors messages, etc.
4.2 Hardware Interfaces: with existing as well as
new or special purpose hardware
4.3 Software Interfaces: with other software
packages, operating systems, etc.
5. Performance Requirements
Capacity requirements (no of users, no of files),
response time, through-put (in measurable terms)
áë
Requirement Specification Format «
6. Design Constraints
6.1 Standards Compliance: software development
standards as well as organizational standards
(e.g., for reports, auditing)
6.2 Hardware Limitations: available machines, `
operating systems, storage capacities, etc.
7 Other Requirements
Possible future extensions
Note:
All sections are not required for all projects.

á¢
System Design
Objective : To formulate alternatives about
how the problem should be solved
Input is SRS from previous step
Consider several technical alternatives
based on type of technology, automation
boundaries, type of solutions (batch/on-line),
including make or buy
Propose a range of alternatives : low-cost,
medium cost and comprehensive high cost
solutions
á_
Alternatives
For each alternative, prepare high-level
system design (in terms of architecture, DB
design, «); prepare implementation
schedule, carry out cost-benefit analysis
Prepare for technical and management
review

Costs rise sharply hereafter

Costs can be quantified better at this stage

Technical review uncovers errors, checks
consistency, completeness, alternatives, «
Phase ends with a clear choice
áV
Design goals
Processing component: main alternatives

Hierarchical modular structure in functional
approach

Object-oriented model and implementation
Different design methodologies for
functional and OO
Data component

Normalized data base design using ER model

De-normalization for performance

Physical design : indexes
á±
System Architecture
Decompose a complex system:

Partitions (vertical)

Layers (horizontal)
Define subsystems/modules as building blocks
Modules make calls on each other

Pass data, obtain results
Maximize module independence and minimize module
interdependence

Cohesion and coupling characteristics

Essential for maintenance
Decompose until manageable units for coding and
testing obtained
áß
Structure Chart
Used in functional methodology to depict modules
and their calling relationships
Hierarchical structure: module at level Ú calls modules
at level Ú
; control flow not shown
Modules at higher levels generally do coordination
and control; modules at lower levels do i/o and
computations
Structure chart may show important data passing
between modules, and also show main iterations and
decision-making without much details
Techniques are available to go from DFD to structure
charts
ë
Structure Chart Notation

Modules on level 2 can be decomposed further

ëm
Notation «

ë
OO Approach
Large systems decomposed into packages
Design consists of classes

Have structure (properties)

Have behavior (methods/operations)

Inheritance major feature in OO for re-use
Class diagrams show static structure of the
system
Interaction diagrams are used to capture
dynamic behavior of classes and objects

ëá
Design Document Format
1. Introduction
2. Problem Specification: include here the data-flow
diagrams, entry-relationship diagrams
3. Software structure: give the high-level software
structure chart identifying major modules and major data
elements in their interfaces
4. Data Definitions: for major data structure, files and
database
5. Module Specifications: indicate inputs, outputs, purpose
and subordinate modules for each software module
6. Requirements Tracing: indicate which modules meet
which requirements

ëë
Detailed Design
Specific implementation alternative already
selected in previous step giving

Overall software structure

Modules to be coded

Database/file design
In this step, each component is defined
further for implementation

ë¢
Detailed Design «

Deliverables include

Program specifications (e.g. psuedo-code)

File design (organization, access method«)

Hardware specifications (as applicable)

Test plans

Implementation schedule
Ends in technical review

ë_
Implementation

Programs are coded, debugged and documented

Initial creation of data files and their verification

Individual modules as well as whole system is
tested

Operating procedures are designed

User does acceptance of the system

System is installed and switch-over affected

ëV
Operations & Maintenance

Systems must continue to serve user needs
correctly and continuously

Maintenance activities consist of
Removing errors
Extending present functions
Adding new functions
Porting to new platforms

ë±
Design Technique and Tools
Study issues and important parameters in
design of each component

Output design

Input design

File design

Software architecture design

ëß
Techniques and tools «
Study useful techniques

Data Flow Diagrams

E-R Diagrams

Data Dictionary

Program Structure Charts

Structured Programming

Program Testing
Understand role of CASE tools in software
development.

¢
Data Dictionary
It is a repository (i.e., catalog) of information
about a system (which gets collected during
various phases)

Definition of data

Structure of data

Usage of data (in processing)

¢m
Data dictionary «
It is a very useful tools as it

Permits better documentation control and
management of data about data

Facilitates standardization in data usage

Prevents errors, inconsistencies and
redundancy in data definitions

Enables cross-referencing and check for
completeness

Acts as a valuable input in analysis and design
activities and reduces development and
implementation effort
¢
Data Dictionary «
It stores data about the following :

Data element
name, description, synonym, type, length, validation,
criteria

Record ( or group of data elements)
name, description, content(data elements and/or
groups), optional elements, repeated elements(arrays)

File/data store
name, description, associated record(s), volume,
access keys, file organization

¢á
Data Dictionary «

Data flows (includes inputs and outputs)
name, description, record name, source, destinations,
volume)
External entities

Programs (or, processes)
Name, description, level number, frequency of execution,
programming language, author

¢ë
Data Dictionary «
Data Dictionary also stores relationships
between above entities (cross-referencing
info)

which programs make an application

which programs use what files and how
DD may be automated or manual
Often part of CASE tool

¢¢
CASE Tools
Computer Assisted Software Engineering
(CASE)
Provides a set of tools for analysis and
design tasks
Provides a methodology/environment for
building software

¢_
CASE Tools «
Benefits of CASE

Improves productivity by providing assistance in
development activities

Automates tedious tasks (e.g., drawing and
editing of diagrams), version management

Permits checks for consistency and
completeness in data collected and development
steps

Ensures uniform and consistent development
methodology

Improves quality of software (as methodology is
enforced and quality control can be applied)

¢V
CASE Tools «
CASE tool typically include:

Diagramming tools to support analysis, design
and documentation
Data flow diagrams
E-R diagrams
Program structure charts
OO design

Data dictionary for gathering information and for
checking consistency and completeness

Design tools (e.g., for database schema design
from E-R diagrams)

¢±
CASE Tools «

Interface generators for defining dialogs
(screens), inputs, reports, etc. (useful for
prototypes)

Code generators: converting specifications into
source code

Management tools: project management
facilities for scheduling of activities, allocation
of resources and tracking of progress

¢ß
Design Guidelines/approaches
Let us review design techniques for some of
the main components of a software system

Database design

Report design

Input design in general and interactive dialogue
design in particular

_
Database Design
2-step process: logical design and physical
design
Logical design: what data to be stored

Examine data contained in data stores in DFD

Develop thorough understanding of information
domain of the application

Represent the domain by E-R diagram which
shows logical data relationships

Carry out logical database design from ER
diagram
Identity key fields
_m
Database Design «

Physical design: decide how many files,

content of each file and file organization

Based on how data is accessed/processed

Statistical characterization of data

_
Choosing physical organization
Influential factors

Activity ratio: per-cent of records processed in
one run

Volatility: frequency of updates and distribution
of updates over records/fields

File size and growth characteristics

Access keys: fields which are used for locating
records to be processed

Ordering of records for output

Processing speed/response time requirement of
application
_á
Report Design
Obtain following details

Destination: external or internal

Nature of report: detailed report, summary
report, exceptional report, periodic or ad hoc
report

Information need served by the report and
contents of report

When, how often, and volume of output

Action to be taken at destination and time-frame
for action

Final disposal of report (file, destroy)
_ë
Report design «
Report design includes

Content design
Data items, tables, aggregates (control totals),
headings, charts, «

Content sequencing

Content presentation
Format, editing of values, spacing, layout, «
Pre-printed forms
Exercise: study some familiar outputs:
railway ticket, LIC premium notice, Cash
Receipt, Library claims,«
_¢
Input Design
Objectives

Data capture at source to suit the environment and
operational conditions

Keep volume minimum: only capture relevant data;
capture static data only once

Avoid errors; design data validation and controls

__
Input design «
Input Design Consists of

Identifying input contents based on purpose

Sequencing values

Layout design: spacing, special boxes, etc.

Including controls for validation

Developing clear instructions for input
preparation

_V
Input Design «
Common validation criteria

Type check (numeric or not)

Range or limit check

Consistent relationships between items

Check digit

Table look-up for coded items

Hash totals (i.e. controls totals)

Record count
Ex: study these input forms: railway
reservation, IIT JEE application
_±
Interactive Dialog (GUI) Design
Required for on-line systems
Immediate response expected
Dialog may contain command or data
Need for security and integrity

Authorization and access control

On-line data validation

Provide for error correction and undoing an
action

Provide on-line help

Simplify interaction using special function keys
_ß
Interactive Dialog Design «
Provide hierarchical ordering of dialogs and
permit users to go forwards and backwards
Dialog types: textual commands, menu
based (with nested menus, µpull-down¶
menus), natural language, or voice
This is an area of study by itself

V
Summary
Each phase has a well defined task and a
deliverable
Feasibility establishes alternatives and
carries out cost-benefit analysis
Requirements analysis is very challenging
and SRS forms the first baseline
Design step consists of architecture,
database and interface design
Each phase ends in technical and
management review
Vm
O

V