P. 1
Phases in Software Development

Phases in Software Development

|Views: 177|Likes:
Published by Ravi Narayan Bhat

More info:

Categories:Types, Research
Published by: Ravi Narayan Bhat on May 01, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPT, PDF, TXT or read online from Scribd
See more
See less

03/04/2013

pdf

text

original

Phases in Software Development

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

1

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
2

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

3

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
4

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

5

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

6

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.

7

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
8

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
9

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

10

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. ?

11

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

12

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.

13

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

14

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
15

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
16

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?

17

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
18

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

19

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
20

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
21

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

22

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.)
23

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, «
24

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)
25

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, «
26

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
27

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), entityrelationship models (for data domain) and object models commonly used ‡ SRS format is great help in organizing requirements in details
28

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
29

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
30

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.
31

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.

32

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)

33

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)
34

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.
35

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
36

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
37

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
38

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
39

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
40

Structure Chart Notation

‡ Modules on level 2 can be decomposed further
41

Notation «

42

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
43

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
44

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

45

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

46

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

47

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

48

Design Technique and Tools
‡ Study issues and important parameters in design of each component
± ± ± ± Output design Input design File design Software architecture design

49

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.
50

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)

51

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
52

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

53

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

54

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

55

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

56

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)
57

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)
58

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

59

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

60

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
61

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

62

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
63

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)
64

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,«
65

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

66

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

67

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
68

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
69

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

70

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
71

THANK YOU
72

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->