let us review the main steps

8/14/2019 Let Us Review the Main Steps

1/71

1


2/71

2

Let us review the main steps

Problem Definition Feasibility Study

Analysis

System Design Detailed Design

Implementation

Maintenance

A separate planning step for large applicationsmay be introduced after feasibility


3/71

3

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


4/71

4

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 nextfeasibility step

Estimate roughly overall project cost to give usersa sense of project scope. The estimates becomemore refined in later steps


5/71

5

This step is short; lasts a day or two

Proper understanding and characterization ofproblem essential

To discover cause of the problem

To plan directed investigation

Else, success is unlikely


6/716

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/717

1. Project Title

2. Problem Statement: Concise statement ofproblem, possibly in a few lines

3. Project Objectives: state objective of the

project defined for the problem4. Preliminary Ideas: possible solutions, if any,

occurring to user and/or analyst could be

stated here.


8/718

5. Project Scope: give overall cost estimate asballpark figure

6. Feasibility Study: indicate time and cost for thenext step

Notes

Do not confuse between problems and solutions

e.g., develop computerized payroll cannot be aproblem

No commitment is implied to preliminary ideas


9/719

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/7110

Make a formal report and present it to

management and users; review here confirms thefollowing:

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/71

11

Economical : will returns justify the investmentin the project ?

Technical : is technology available to implementthe alternative ?

Operational : will it be operationally feasible asper rules, regulations, laws, organizational

culture, union agreements, etc. ?


12/71

12

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/71

13

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/71

14

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/71

15

How to estimate costs so early in the project?

Decompose the system and estimate costs ofcomponents; this is easier and more accurate thandirectly 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/71

16

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 ofbenefit

Take into account life of system: most systemshave life of 5-7 years


17/71

17

Cost is investment in the project, benefits

represent returnCompute payback period in which we recover

initial investment through accumulated benefits

Payback period is expected to be less thansystem life !

Are there better investment alternatives?


18/71

18

1.0 Introduction:

A brief statement of the problem, the environment inwhich the system is to be implemented, and constraintsthat 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/71

19

4.0 System Description

An abbreviated version of information contained inthe 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/71

20

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


21/71

21

A very challenging task

Users may not know exactly what is needed or howcomputers can bring further value to what is beingdone 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/71

22

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 notcaptured here become 2 to 25 times more costlyto remove later


23/71


24/71

24

Interviewing clients and users essential to

understand their needs from the systemOften existing documents and current mode of

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, businessevents,

Analysis Process


25/71


26/71

26

Identify users, their roles and plan interviews in

proper order to collect details progressively andsystematically

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, domainknowledge, patience,


27/71

27

Massive amount of information is collected from

interviews, study of existing systems

Need to be organized, recorded, classified andconceptualized (at multiple level of details)

Tools/repositories available (describe inputs,outputs, files, computations, usages, functions):

help in checking consistency and completeness


28/71

28

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/71

29

Focuses on functions/processes and data flowing

between themUses 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 dataflows for them

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


30/71

30

Study existing system: What is done and how

Prepare physical current DFDConvert 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


31/71

31

(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 asapplicable

1.4 REFRENCES: to other documents

1.5 Overview of Developers Responsibilities: In terms ofdevelopment, installation, training, maintenance, etc.


32/71

32

2. GENERAL DESCRIPTION

2.1 PRODUCT PERSPECTIVE: relationship with otherproducts and principle interfaces

2.2 PRODUCT FUNCTIONS OVERVIEW: general overview

of tasks; including data flow diagrams2.3 USER CHARACTERISTICS: who they are and

what training they may need

2.4 GENERAL CONSTRAINTS: about schedule,resources, cost, etc.


33/71

33

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)


34/71

34

4. External Interface Requirements

4.1 User Interfaces: a preliminary user manualgiving commands, screen formats, outputs,errors messages, etc.

4.2 Hardware Interfaces: with existing as well as newor 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)


35/71

35

6. Design Constraints

6.1 Standards Compliance: software developmentstandards 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 extensionsNote:

All sections are not required for all projects.


36/71

36

Objective : To formulate alternatives abouthow the problem should be solved

Input is SRS from previous step

Consider several technical alternatives based

on type of technology, automationboundaries, type of solutions (batch/on-line), including make or buy

Propose a range of alternatives : low-cost,medium cost and comprehensive high costsolutions


37/71

37

For each alternative, prepare high-levelsystem design (in terms of architecture, DB

design, ); prepare implementationschedule, 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, checksconsistency, completeness, alternatives,

Phase ends with a clear choice


38/71

38

Processing component: main alternatives

Hierarchical modular structure in functionalapproach

Object-oriented model and implementation

Different design methodologies for functionaland OO

Data component

Normalized data base design using ER model De-normalization for performance

Physical design : indexes


39/71

39

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 moduleinterdependence Cohesion and coupling characteristics Essential for maintenance

Decompose until manageable units for coding and

testing obtained


40/71

40

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 andcontrol; modules at lower levels do i/o andcomputations

Structure chart may show important data passing

between modules, and also show main iterations anddecision-making without much details

Techniques are available to go from DFD to structure

charts


41/71

41

Modules on level 2 can be decomposed further


42/71

42


43/71

43

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 thesystem

Interaction diagrams are used to capture dynamicbehavior of classes and objects


44/71

44

1. Introduction

2. Problem Specification: include here the data-flow diagrams,entry-relationship diagrams

3. Software structure: give the high-level software structurechart identifying major modules and major data elements in

their interfaces4. 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 whichrequirements


45/71

45

Specific implementation alternative alreadyselected 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/71

46

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/71

47

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/71

48

Systems must continue to serve user needscorrectly and continuously

Maintenance activities consist of Removing errors

Extending present functions

Adding new functions Porting to new platforms


49/71

49

Study issues and important parameters in design of

each component Output design

Input design

File design Software architecture design


50/71

50

Study useful techniques

Data Flow Diagrams

E-R Diagrams

Data Dictionary

Program Structure Charts Structured Programming

Program Testing

Understand role of CASE tools in softwaredevelopment.


51/71

51

It is a repository (i.e., catalog) of information about

a system (which gets collected during variousphases)

Definition of data

Structure of data Usage of data (in processing)


52/71

52

It is a very useful tools as it

Permits better documentation control andmanagement of data about data

Facilitates standardization in data usage

Prevents errors, inconsistencies and redundancyin data definitions

Enables cross-referencing and check forcompleteness

Acts as a valuable input in analysis and designactivities and reduces development andimplementation effort


53/71

53

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/71

54

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/71

55

Data Dictionary also stores relationshipsbetween above entities (cross-referencinginfo) which programs make an application

which programs use what files and how

DD may be automated or manual

Often part of CASE tool


56/71

56

Computer Assisted Software Engineering (CASE)

Provides a set of tools for analysis and designtasks

Provides a methodology/environment for building

software

CASE Tools


57/71

57

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 completenessin data collected and development steps

Ensures uniform and consistent developmentmethodology

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


58/71

58

CASE tool typically include:

Diagramming tools to support analysis, designand 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/71

59

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

prototypes) Code generators: converting specifications into

source code

Management tools: project managementfacilities for scheduling of activities, allocationof resources and tracking of progress


60/71

60

Let us review design techniques for some ofthe main components of a software system

Database design

Report design

Input design in general and interactive dialoguedesign in particular


61/71

61

2-step process: logical design and physicaldesign

Logical design: what data to be stored

Examine data contained in data stores in DFD

Develop thorough understanding of informationdomain of the application

Represent the domain by E-R diagram whichshows logical data relationships

Carry out logical database design from ERdiagram Identity key fields


62/71

62

Physical design: decide how many files, content ofeach file and file organization

Based on how data is accessed/processed

Statistical characterization of data


63/71

63

Influential factors

Activity ratio: per-cent of records processed inone run

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

File size and growth characteristics

Access keys: fields which are used for locatingrecords to be processed

Ordering of records for output

Processing speed/response time requirement ofapplication


64/71

64

Obtain following details

Destination: external or internal

Nature of report: detailed report, summaryreport, exceptional report, periodic or ad hocreport

Information need served by the report andcontents of report

When, how often, and volume of output

Action to be taken at destination and time-framefor action

Final disposal of report (file, destroy)


65/71

65

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, CashReceipt, Library claims,


66/71

66

Objectives

Data capture at source to suit the environment andoperational conditions

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

Avoid errors; design data validation and controls


67/71

67

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 inputpreparation


68/71

68

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/71

69

Required for on-line systems

Immediate response expectedDialog 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


70/71

70

Provide hierarchical ordering of dialogs and

permit users to go forwards and backwardsDialog types: textual commands, menu based

(with nested menus, pull-down menus), natural

language, or voice

This is an area of study by itself


71/71

Each phase has a well defined task and adeliverable

Feasibility establishes alternatives andcarries out cost-benefit analysis

Requirements analysis is very challenging andSRS forms the first baseline

Design step consists of architecture,

database and interface design Each phase ends in technical and

management review

let us review the main steps

Documents