phases in software development

8/9/2019 Phases in Software Development

1/72

1

Phases in Software Development

Presenter:

Prof. N. L. Sarda

I.I.T. Bombay


2/72

2

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 afterfeasibility


3/72

3

Problem Definition To answer: What is the Problem

Where and by whom is the problem felt?

Meet users and Management and obtaintheir agreement that there is a problem

If problem exists, and it needs to be solved

It becomes a project

Commitment of funds implied


4/72

4

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 giveusers a sense of project scope. The

estimates become more refined in later steps


5/72

5

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


6/72

6

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


7/72

7

Problem Definition document1. Project Title

2. Problem Statement: Concise statement of

problem, possibly in a few lines3. Project Objectives: state objective of the

project defined for the problem

4. Preliminary Ideas: possible solutions, if

any, occurring to user and/or analyst couldbe stated here.


8/72

8

Problem Definition document5. Project Scope: give overall cost estimate

as ballpark figure

6. Feasibility Study: indicate time and costfor the next step

Notes

Do not confuse between problems and

solutions e.g., develop computerized payrollcannot be a problem

No commitment is implied to preliminary ideas


9/72

9

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


10/72

10

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


11/72

11

Types of Feasibility Economical : will returns justify the

investment in the project ?

Technical : is technology available toimplement the alternative ?

Operational : will it be operationally feasible

as per rules, regulations, laws,

organizational culture, union agreements,etc. ?


12/72

12

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


13/72

13

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.


14/72

14

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


15/72

15

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


16/72

16

Financial Analysis Consider time-value of money; while

investment is today, benefits are in future!

Compute present value P for future benefit Fby

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


17/72

17

Financial Analysis Cost is investment in the project, benefits

represent return

Compute payback period in which werecover initial investment through

accumulated benefits

Payback period is expected to be less than

system life ! Are there better investment alternatives?


18/72

18

FEASIBILITY STUDY Report1.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


19/72

19

FEASIBILITY STUDY 4.0 System Description

An abbreviated version of information contained

in the System-Specification or reference to thespecifications

5.0 Cost-Benefit Analysis

6.0 Evaluation of Technical Risk

7.0 Legal Ramifications (if any)8.0 Other Project-Specific Topics


20/72

20

Requirements Analysis Objective: determine what the system must do

to solve the problem (without describing how)

Done by Analyst (also called RequirementsAnalyst)

Produce Software Requirements Specifications

(SRS) document

Incorrect, incomplete, inconsistent, ambiguous

SRS often cause for project failures and

disputes


21/72

21

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 cant 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


22/72

22

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 25times more costly to remove later


23/72

23

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, taxesetc.)


24/72

24

Analysis Process Interviewing clients and users essential to

understand their needs from the system

Often existing documents and current modeof operations can be studied

Long process: needs to be organizedsystematically 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


25/72

25

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)


26/72

26

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 invisualizing requirements

Need good communication skills, domain

knowledge, patience,


27/72

27

Organizing Findings Massive amount of information is collected

from interviews, study of existing systems

Need to be organized, recorded, classifiedand conceptualized (at multiple level of

details)

Tools/repositories available (describe

inputs, outputs, files, computations, usages,functions): help in checking consistency and

completeness


28/72

28

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 objectmodels commonly used

SRS format is great help in organizing requirements

in details


29/72

29

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


30/72

30

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 - requiresinnovation, experience, vision Incorporate new needs

Improve work flows (BPR: business processre-engg)

Introduce efficiency/effectiveness


31/72

31

Requirement Specification Format(Based on IEEE Recommendation)

1. Introduction

1.1 PURPOSE: clearly state purpose of this document1.2 SCOPE: by whom and how it will be used

1.3 Definitions: Acronyms, Abbreviations as

applicable

1.4 REFRENCES: to other documents1.5 Overview of Developers Responsibilities: In terms

of development, installation, training, maintenance,

etc.


32/72

32

Requirement Specification Format2. 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.


33/72

33

Requirement Specification Format 3.1 FUNCTIONAL REQUIREMENT

3.1.1 INTRODUCTION

3.1.2 INPUTS3.1.3 PROCESSING

3.1.4 OUTPUTS

3.2.. (repeat similarly for each function)


34/72

34

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.3Software 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)


35/72

35

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.


36/72

36

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


37/72

37

Alternatives For each alternative, prepare high-level

system design (in terms of architecture, DBdesign, ); 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


38/72

38

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


39/72

39

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


40/72

40

Structure Chart Used in functional methodology to depict modules

and their calling relationships

Hierarchical structure: module at level icalls 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 passingbetween modules, and also show main iterations and

decision-making without much details

Techniques are available to go from DFD to structure

charts


41/72

41

Structure Chart Notation

Modules on level 2 can be decomposed further


42/72

42

Notation


43/72

43

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


44/72

44

Design Document Format1. Introduction2. 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, purposeand subordinate modules for each software module

6. Requirements Tracing: indicate which modules meet

which requirements


45/72

45

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


46/72

46

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


47/72

47

Implementation

Programs are coded, debugged and documented

Initial creation of data files and their verification

Individual modules as well as whole system istested

Operating procedures are designed

User does acceptance of the system

System is installed and switch-over affected


48/72

48

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


49/72

49

Design Technique and Tools Study issues and important parameters in

design of each component

Output design

Input design

File design

Software architecture design


50/72

50

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.


51/72

51

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)


52/72

52

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


53/72

53

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


54/72

54

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


55/72

55

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


56/72

56

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


57/72

57

CASE Tools Benefits of CASE

Improves productivity by providing assistance indevelopment activities

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

Permits checks for consistency andcompleteness in data collected and developmentsteps

Ensures uniform and consistent developmentmethodology

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


58/72

58

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)


59/72

59

CASE Tools Interface generators for defining dialogs

(screens), inputs, reports, etc. (useful for

prototypes)

Code generators: converting specifications intosource code

Management tools: project management

facilities for scheduling of activities, allocation

of resources and tracking of progress


60/72

60

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


61/72

61

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


62/72

62

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


63/72


64/72

64

Report Design Obtain following details

Destination: external or internal

Nature of report: detailed report, summary

report, exceptional report, periodic or ad hocreport

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)


65/72

65

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,


66/72

66

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


67/72

67

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


68/72

68

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


69/72

69

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 anaction

Provide on-line help

Simplify interaction using special function keys


70/72

70

Interactive Dialog Design Provide hierarchical ordering of dialogs and

permit users to go forwards and backwards

Dialog types: textual commands, menubased (with nested menus, pull-down

menus), natural language, or voice

This is an area of study by itself


71/72

71

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


72/72

THANK YOU

phases in software development

Documents