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
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.e. i. 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 ..
occurring to user and/or analyst could be stated here. possibly in a few lines 3.Problem Definition document 1. Project Objectives: state objective of the project defined for the problem 4. Preliminary Ideas: possible solutions. if any. Problem Statement: Concise statement of problem. 7 . Project Title 2.
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 .Problem Definition document« 5. Project Scope: give overall cost estimate as ballpark figure 6.
Feasibility Study To get better understanding of problems and reasons by studying existing system. design. if available ± Are there feasible solutions? ± Is the problem worth solving? Consider different alternatives Essentially covers other steps of methodology (analysis.) in a µcapsule¶ form Estimate costs and benefits for each alternative 9 . etc.
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 .Feasibility Study« Make a formal report and present it to management and users.
laws. union agreements. regulations. etc. ? 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.
Costs One-time (initial) costs include equipment. software development. site preparation Recurring costs include salaries. rentals. training. vary with volume of workload 12 . consultation. supplies. depreciation Fixed and variable costs. maintenance.
Benefits Benefits could be tangible (i. etc. 13 .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.) ± Reduction in errors ± Ability to handle more workload 14 . finances.
etc. 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. hence estimate time first 15 . space. electricity.) ± Personnel (for development and operations) costs are function of time.
while investment is today.Financial Analysis Consider time-value of money. 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 .
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 .Financial Analysis « Cost is µinvestment¶ in the project.
0 Introduction: A brief statement of the problem. and constraints that affect the project 2.0 Alternatives: A presentation of alternative system specifications. criteria that were used in selecting the final approach 18 .FEASIBILITY STUDY Report 1. the environment in which the system is to be implemented.0 Management Summary and Recommendations: Important findings and recommendations 3.
FEASIBILITY STUDY « 4.0 Legal Ramifications (if any) 8.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 Other Project-Specific Topics 19 .0 Cost-Benefit Analysis 6.
ambiguous SRS often cause for project failures and disputes 20 . incomplete.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. inconsistent.
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 .
± What: calculate take-home pay ± How: procedure (allowances. deductions. e. 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. outputs. and also other important constraints (legal.) 23 . social. processing) and performance requirements.g.SRS « It identifies all functional (inputs.. taxes etc.
correlating. and iterating again for more details ± Focus on what gets done or needs to be done ± Focus on business entities. their interactions.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. business events. identifying gaps. « 24 .
computerized systems) Often goes outside in : what outputs needed.e. records kept (files. what records kept.. . (i. which inputs provide data. go inwards from system boundaries) 25 . how records updated..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. ledgers. what processing done. outputs.
durations. « 26 .Interviews Identify users. domain knowledge. purpose ± Keep records and verify/confirm details ± Needs to sometimes µprompt¶ users in visualizing requirements Need good communication skills. patience. their roles and plan interviews in proper order to collect details progressively and systematically Conducting interviews is an art ! ± Workout scope.
classified and conceptualized (at multiple level of details) Tools/repositories available (describe inputs. files.Organizing Findings Massive amount of information is collected from interviews. study of existing systems Need to be organized. outputs. usages. computations. functions): help in checking consistency and completeness 27 . recorded.
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 .Organizing « Create models or projections from different perspectives ± Way to handle complexity (divide-and-conquer) ± Hide unnecessary details Reduces errors.
outputs. users and data sources ± Decompose the process into sub processes. DFD) very useful 29 . show data flows for them ± Function Decomposition and Data Flow Diagrams (FDD.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.
vision ± Incorporate new needs ± Improve work flows (BPR: business process re-engg) ± Introduce efficiency/effectiveness 30 . experience.requires innovation.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 .
maintenance.5 Overview of Developer¶s Responsibilities: In terms of development.1 PURPOSE: clearly state purpose of this document 1. 31 . Abbreviations as applicable 1.3 Definitions: Acronyms.4 REFRENCES: to other documents 1. installation.Requirement Specification Format (Based on IEEE Recommendation) 1. etc. Introduction 1.2 SCOPE: by whom and how it will be used 1. training.
Requirement Specification Format 2.3 USER CHARACTERISTICS: who they are and what training they may need 2. including data flow diagrams 2. resources.1 PRODUCT PERSPECTIVE: relationship with other products and principle interfaces 2.4 GENERAL CONSTRAINTS: about schedule. etc. 32 . cost. GENERAL DESCRIPTION 2.2 PRODUCT FUNCTIONS OVERVIEW: general overview of tasks.
1.1..2 INPUTS 3.1.3 PROCESSING 3.4 OUTPUTS 3.1 FUNCTIONAL REQUIREMENT 3.2«.1.Requirement Specification Format « 3.1 INTRODUCTION 3. (repeat similarly for each function) 33 .
etc. through-put (in measurable terms) 34 . response time. etc.Requirement Specification Format « 4. operating systems. errors messages. Performance Requirements Capacity requirements (no of users. screen formats. 4. no of files).1 User Interfaces: a preliminary user manual giving commands. outputs.2 Hardware Interfaces: with existing as well as new or special purpose hardware 4. External Interface Requirements 4.3 Software Interfaces: with other software packages. 5.
Requirement Specification Format « 6. Design Constraints 6. 7 Other Requirements Possible future extensions Note: All sections are not required for all projects. storage capacities. etc.g.1 Standards Compliance: software development standards as well as organizational standards (e. auditing) 6. for reports.. ` operating systems.2 Hardware Limitations: available machines. 35 .
type of solutions (batch/on-line).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. including make or buy Propose a range of alternatives : low-cost. automation boundaries. medium cost and comprehensive high cost solutions 36 .
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. alternatives. «). checks consistency. « Phase ends with a clear choice 37 . DB design. prepare implementation schedule.Alternatives For each alternative. completeness. prepare high-level system design (in terms of architecture.
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 .
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 .System Architecture Decompose a complex system: ± Partitions (vertical) ± Layers (horizontal) Define subsystems/modules as building blocks Modules make calls on each other ± Pass data.
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 Used in functional methodology to depict modules and their calling relationships Hierarchical structure: module at level i calls modules at level i+1. 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 .
Problem Specification: include here the data-flow diagrams. Software structure: give the high-level software structure chart identifying major modules and major data elements in their interfaces 4.Design Document Format 1. Data Definitions: for major data structure. Requirements Tracing: indicate which modules meet which requirements 44 . files and database 5. Introduction 2. Module Specifications: indicate inputs. purpose and subordinate modules for each software module 6. entry-relationship diagrams 3. outputs.
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. access method«) Hardware specifications (as applicable) Test plans Implementation schedule Ends in technical review 46 . psuedo-code) File design (organization.
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 .
type. content(data elements and/or groups). access keys. optional elements. criteria ± Record ( or group of data elements) name. description. file organization 53 .Data Dictionary « It stores data about the following : ± Data element name. validation. length. synonym. description. description. volume. repeated elements(arrays) ± File/data store name. associated record(s).
programming language. frequency of execution. description. description. volume) External entities ± Programs (or. level number. source. processes) Name. record name. author 54 .Data Dictionary « ± Data flows (includes inputs and outputs) name. 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 .
g. 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 .. drawing and editing of diagrams).CASE Tools « Benefits of CASE ± Improves productivity by providing assistance in development activities ± Automates tedious tasks (e.
g..CASE Tools « CASE tool typically include: ± Diagramming tools to support analysis. for database schema design from E-R diagrams) 58 . 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.
CASE Tools « ± Interface generators for defining dialogs (screens). etc. reports. allocation of resources and tracking of progress 59 . (useful for prototypes) ± Code generators: converting specifications into source code ± Management tools: project management facilities for scheduling of activities. inputs.
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 .
content of each file and file organization ± Based on how data is accessed/processed ± Statistical characterization of data 62 .Database Design « Physical design: decide how many files.
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 .
summary report. exceptional report. how often.Report Design Obtain following details ± Destination: external or internal ± Nature of report: detailed report. periodic or ad hoc report ± Information need served by the report and contents of report ± When. destroy) 64 . and volume of output ± Action to be taken at destination and time-frame for action ± Final disposal of report (file.
« ± Content sequencing ± Content presentation Format. Cash Receipt.Report design « Report design includes ± Content design Data items. headings. layout. LIC premium notice. Library claims. aggregates (control totals). tables.« 65 . « Pre-printed forms Exercise: study some familiar outputs: railway ticket. editing of values. charts. spacing.
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. Including controls for validation Developing clear instructions for input preparation 67 .Input design « Input Design Consists of ± ± ± ± ± Identifying input contents based on purpose Sequencing values Layout design: spacing. special boxes.
IIT JEE application 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.
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 .
µpull-down¶ menus). or voice This is an area of study by itself 70 . menu based (with nested menus.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.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.