Phases in Software Development
Prof. N. L. Sarda
I.I.T. Bombay
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.
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
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. ?
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
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.
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
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
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)
nwhere 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
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?
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
FEASIBILITY STUDY
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
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
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,
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
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
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.
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
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 i calls modules at level i+1; 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
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
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)
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
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)
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
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
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
