Professional Documents
Culture Documents
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
ë
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
ë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 «
_
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