This action might not be possible to undo. Are you sure you want to continue?
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
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
The estimates become more refined in later steps 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 give users a sense of project scope.
Problem Definition « This step is short. success is unlikely 5 . lasts a day or two Proper understanding and characterization of problem essential ± To discover cause of the problem ± To plan directed investigation ± Else.
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 « Possible initial characterization of problems ± Existing system has poor response time.
Preliminary Ideas: possible solutions. possibly in a few lines 3. if any. occurring to user and/or analyst could be stated here. Project Objectives: state objective of the project defined for the problem 4. Problem Statement: Concise statement of problem. Project Title 2. 7 .Problem Definition document 1.
Problem Definition document« 5.g. Feasibility Study: indicate time and cost for the next step Notes ± Do not confuse between problems and solutions e. Project Scope: give overall cost estimate as ballpark figure 6.. µ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. design.) in a µcapsule¶ form Estimate costs and benefits for each alternative 9 . etc. if available ± Are there feasible solutions? ± Is the problem worth solving? Consider different alternatives Essentially covers other steps of methodology (analysis.
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 .
etc. laws. ? 11 . organizational culture.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. union agreements. regulations.
maintenance. rentals. consultation. vary with volume of workload 12 .Costs One-time (initial) costs include equipment. training. software development. depreciation Fixed and variable costs. supplies. site preparation Recurring costs include salaries.
13 . quantifiable) or intangible Saving (tangible benefits) could include ± ± ± ± Saving in salaries Saving in material or inventory costs More production Reduction in operational costs.e.Benefits Benefits could be tangible (i. etc.
finances. inventory.Benefits « Intangible benefits may include ± Improved customer service ± Improved resource utilization ± Better control over activities (such as production.) ± Reduction in errors ± Ability to handle more workload 14 . etc.
space. hence estimate time first 15 . 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.Estimating Costs How to estimate costs so early in the project? ± Decompose the system and estimate costs of components. etc. electricity.) ± Personnel (for development and operations) costs are function of time.
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 .
criteria that were used in selecting the final approach 18 .FEASIBILITY STUDY Report 1. and constraints that affect the project 2. the environment in which the system is to be implemented.0 Introduction: A brief statement of the problem.0 Management Summary and Recommendations: Important findings and recommendations 3.0 Alternatives: A presentation of alternative system specifications.
0 Evaluation of Technical Risk 7.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 Legal Ramifications (if any) 8.0 Other Project-Specific Topics 19 .FEASIBILITY STUDY « 4.
inconsistent.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. ambiguous SRS often cause for project failures and disputes 20 . incomplete.
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 .
defects not captured here become 2 to 25 times more costly to remove later 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.
) 23 . deductions. outputs. 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. social. e. ± What: calculate take-home pay ± How: procedure (allowances.SRS « It identifies all functional (inputs.g. taxes etc. and also other important constraints (legal. processing) and performance requirements..
correlating. identifying gaps. « 24 .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. their interactions. business events. and iterating again for more details ± Focus on what gets done or needs to be done ± Focus on business entities.
. what processing done. which inputs provide data. (i.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. computerized systems) Often goes outside in : what outputs needed.. ledgers. records kept (files.e. outputs. . go inwards from system boundaries) 25 . what records kept. how records updated.
their roles and plan interviews in proper order to collect details progressively and systematically Conducting interviews is an art ! ± Workout scope. « 26 . domain knowledge. purpose ± Keep records and verify/confirm details ± Needs to sometimes µprompt¶ users in visualizing requirements Need good communication skills. durations. patience.Interviews Identify users.
functions): help in checking consistency and completeness 27 . study of existing systems Need to be organized.Organizing Findings Massive amount of information is collected from interviews. usages. outputs. recorded. computations. files. classified and conceptualized (at multiple level of details) Tools/repositories available (describe inputs.
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 .
outputs. users and data sources ± Decompose the process into sub processes.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. DFD) very useful 29 . show data flows for them ± Function Decomposition and Data Flow Diagrams (FDD.
requires innovation. vision ± Incorporate new needs ± Improve work flows (BPR: business process re-engg) ± Introduce efficiency/effectiveness 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 . experience.
Requirement Specification Format (Based on IEEE Recommendation) 1.5 Overview of Developer¶s Responsibilities: In terms of development. maintenance.1 PURPOSE: clearly state purpose of this document 1. installation.2 SCOPE: by whom and how it will be used 1. Introduction 1. etc.4 REFRENCES: to other documents 1.3 Definitions: Acronyms. Abbreviations as applicable 1. training. 31 .
32 . resources.Requirement Specification Format 2.3 USER CHARACTERISTICS: who they are and what training they may need 2.4 GENERAL CONSTRAINTS: about schedule. including data flow diagrams 2. cost. etc. GENERAL DESCRIPTION 2.1 PRODUCT PERSPECTIVE: relationship with other products and principle interfaces 2.2 PRODUCT FUNCTIONS OVERVIEW: general overview of tasks.
(repeat similarly for each function) 33 .1.1.4 OUTPUTS 3.1.2 INPUTS 3.Requirement Specification Format « 3.1.1 INTRODUCTION 3..2«.3 PROCESSING 3.1 FUNCTIONAL REQUIREMENT 3.
4. 5.1 User Interfaces: a preliminary user manual giving commands. screen formats. no of files). errors messages.3 Software Interfaces: with other software packages. Performance Requirements Capacity requirements (no of users. through-put (in measurable terms) 34 . outputs.2 Hardware Interfaces: with existing as well as new or special purpose hardware 4. External Interface Requirements 4.Requirement Specification Format « 4. etc. etc. response time. operating systems.
1 Standards Compliance: software development standards as well as organizational standards (e. auditing) 6. 35 . etc. Design Constraints 6. for reports.Requirement Specification Format « 6..g.2 Hardware Limitations: available machines. ` operating systems. storage capacities. 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. medium cost and comprehensive high cost solutions 36 . including make or buy Propose a range of alternatives : low-cost. automation boundaries. type of solutions (batch/on-line).
alternatives. DB design. prepare implementation schedule. «). « Phase ends with a clear choice 37 .Alternatives For each alternative. checks consistency. prepare high-level system design (in terms of architecture. completeness. 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.
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 .
and also show main iterations and decision-making without much details Techniques are available to go from DFD to structure charts 40 .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. modules at lower levels do i/o and computations Structure chart may show important data passing between modules. control flow not shown Modules at higher levels generally do coordination and control.
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 .
Software structure: give the high-level software structure chart identifying major modules and major data elements in their interfaces 4. entry-relationship diagrams 3. Data Definitions: for major data structure. files and database 5. outputs. Requirements Tracing: indicate which modules meet which requirements 44 . Module Specifications: indicate inputs. Problem Specification: include here the data-flow diagrams. Introduction 2. purpose and subordinate modules for each software module 6.Design Document Format 1.
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 .
psuedo-code) File design (organization. access method«) Hardware specifications (as applicable) Test plans Implementation schedule Ends in technical review 46 .Detailed Design « Deliverables include ± ± ± ± ± Program specifications (e.g.
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
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.
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 52 .
description. content(data elements and/or groups). repeated elements(arrays) ± File/data store name. description. validation. length. type.Data Dictionary « It stores data about the following : ± Data element name. file organization 53 . synonym. volume. optional elements. criteria ± Record ( or group of data elements) name. description. associated record(s). access keys.
description. author 54 .Data Dictionary « ± Data flows (includes inputs and outputs) name. processes) Name. volume) External entities ± Programs (or. level number. record name. description. frequency of execution. programming language. source. destinations.
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 .
drawing and editing of diagrams).CASE Tools « Benefits of CASE ± Improves productivity by providing assistance in development activities ± Automates tedious tasks (e.. 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 .g.
CASE Tools « CASE tool typically include: ± Diagramming tools to support analysis. for database schema design from E-R diagrams) 58 ..g. 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.
etc. inputs. reports. (useful for prototypes) ± Code generators: converting specifications into source code ± Management tools: project management facilities for scheduling of activities.CASE Tools « ± Interface generators for defining dialogs (screens). 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 .
and volume of output ± Action to be taken at destination and time-frame for action ± Final disposal of report (file. summary report. periodic or ad hoc report ± Information need served by the report and contents of report ± When. destroy) 64 .Report Design Obtain following details ± Destination: external or internal ± Nature of report: detailed report. exceptional report. how often.
editing of values. « ± Content sequencing ± Content presentation Format. Cash Receipt.« 65 . Library claims. tables. LIC premium notice. spacing.Report design « Report design includes ± Content design Data items. layout. charts. « Pre-printed forms Exercise: study some familiar outputs: railway ticket. headings. aggregates (control totals).
design data validation and controls 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.
etc. special boxes.Input design « Input Design Consists of ± ± ± ± ± Identifying input contents based on purpose Sequencing values Layout design: spacing. Including controls for validation Developing clear instructions for input preparation 67 .
controls totals) Record count Ex: study these input forms: railway reservation.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. IIT JEE application 68 .e.
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 .
menu based (with nested menus. µpull-down¶ menus). or voice This is an area of study by itself 70 .Interactive Dialog Design « Provide hierarchical ordering of dialogs and permit users to go forwards and backwards Dialog types: textual commands. natural language.
database and interface design Each phase ends in technical and management review 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.