Download Software engineering lec 2. and more Cheat Sheet Software Engineering in PDF only on Docsity! Classical Waterfall Model » Classical waterfall model divides life cycle into phases: ~ feasibility study, ~ requirements analysis and specification, ~ design, ~ coding and unit testing, ~— integration and system testing, ~ maintenance. Classical Waterfall Model Feasibility Study Req. Analysis Feasibility Study e Main aim of feasibility study:determine whether developing the product — financially worthwhile — technically feasible. e First roughly understand what the customer wants: — different data which would be input to the system, — processing needed on these data, — output data to be produced by the system, — various constraints on the behavior of the system. Activities during Feasibility Stud e Work out an overall understanding of the problem. e Formulate different solution strategies. e Examine alternate solution strategies in terms of: * resources required, « cost of development, and * development time. Activities during Feasibility Stud e Perform a cost/benefit analysis: — to determine which solution is the best. —you may determine that none of the solutions is feasible due to: « high cost, * resource constraints, « technical reasons. Requirements Gathering ° Gathering relevant data: — usually collected from the end- users through interviews and discussions. —For example, for a business accounting software: «interview all the accountants of the organization to find out their requirements. 10 Requirements Analysis con: » The data you initially collect” from the users: —would usually contain several contradictions and ambiguities: —each user typically has only a partial and incomplete view of the system. 11 Requirements Analysis con: e Ambiguities and contradictions: ~ must be identified — resolved by discussions with the customers. e Next, requirements are organized: ~— into a Software Requirements Specification (SRS) document. 12 Design In technical terms: —during design phase, software architecture is derived from the SRS document. e Two design approaches: — traditional approach, — object oriented approach. 15 Traditional Design Approach e Consists of two activities: —Structured analysis —Structured design 16 Structured Analysis Activity — ee e Identify all the functions to be performed. e Identify data flow among the functions. e Decompose each function recursively into sub-functions. ~ Identify data flow among the subfunctions as well. 17 Object Oriented Design ° First identify various o jects rea = world entities) occurring in the problem: ~ identify the relationships among the objects. ~ For example, the objects in a pay-roll software may be: * employees, * Managers, * pay-roll register, « Departments, etc. 20 Object Oriented Design con: ° Object structure — further refined to obtain the detailed design. e OOD has several advantages: —lower development effort, —lower development time, — better maintainability. 21 Implementation » Purpose of implementation — phase (coding phase): —translate software design into source code. 22 Integration and System Testing e Different modules are integrated in a planned manner: ~— modules are almost never integrated in one shot. — Normally integration is carried out through a number of steps. e During each integration step, ~ the partially integrated system is tested. 25 Integration and System Testing —_ 26 System Testing e After all the modules have been successfully integrated and tested: —system testing is carried out. e Goal of system testing: —ensure that the developed system functions according to its requirements as specified in the SRS document. 27 Iterative Waterfall Model e Classical waterfall model is idealistic: —assumes that no defect is introduced during any development activity. —in practice: + defects do get introduced in almost every phase of the life cycle. 30 Iterative Waterfall Model (CONT.) e Defects usually get detected much later in the life cycle: —For example, a design defect might go unnoticed till the coding or testing phase. 31 Iterative Waterfall Model (CONT.) e Once a defect is detected: — we need to go back to the phase where it was introduced ~ redo some of the work done during that and all subsequent phases. e Therefore we need feedback paths in the classical waterfall model. 32 Phase containment of errors e The principle of detecting errors as close to its point of introduction as possible: — is known as phase containment of errors. e Iterative waterfall model is most widely used model. ~ Almost every other model is derived from the waterfall model. 35 Prototyping Model e Before starting actual development, —a working prototype of the system should first be built. e A prototype is a toy implementation of a system: ~ limited functional capabilities, ~ low reliability, — inefficient performance. 36 Prototyping Model con: e The reason for developing a prototype is: —it is impossible to ~ “get it right" the first time, —we must plan to throw away the first product «If we want to develop a good product. 37 Prototyping Model con: e Requirements analysis and specification phase becomes redundant: ~ final working prototype (with all user feedbacks incorporated) serves as an animated requirements specification. e Design and code for the prototype is usually thrown away: ~ However, the experience gathered from developing the prototype helps a great deal while developing the actual product. 40 Prototyping Model con: e Even though construction of a working prototype model involves additional cost -- - overall development cost might be lower for: — systems with unclear user requirements, — systems with unresolved technical issues. e Many user requirements get properly defined and technical issues get resolved: — these would have appeared later as change requests and resulted in incurring massive redesign costs. 41 Evolutionary Model e Evolutionary model: — The system is broken down into several modules which can be incrementally implemented and delivered. e First develop the core modules of the system. e The initial product skeleton is refined into increasing levels of capability: — by adding new functionalities in successive versions. 42 Advantages of Evolutionary Model _ e Users get a chance to experiment with a partially developed system: — much before the full working version is released, e Helps finding exact user requirements: ~ much before fully working system is developed. e Core modules get tested thoroughly: ~— reduces chances of errors in final product. 45 Disadvantages of Evolutic lar e Often, difficult to subdivide problems into functional units: —which can be incrementally implemented and delivered. —evolutionary model is useful for very large problems, + where it is easier to find modules for incremental implementation. 46 Evolutionary Model with it ) — | e Many organizations use a combination of iterative and incremental development: —a new release may include new functionality — existing functionality from the current release may also have been modified. 47 Spiral Model con: e The team must decide: ~ how to structure the project into phases. e Start work using some generic model: — add extra phases « for specific projects or when problems are identified during a project. e Each loop in the spiral is split into four sectors (quadrants). 50 Spiral Model (con: Determine Objectives Identify & Resolve Risks Customer Evaluation of Prototype Dgvelop Next 51 Objective Setting (First Quadrant) — e Identify objectives of the phase, e Examine the risks associated with these objectives. — Risk: *any adverse circumstance that might hamper successful completion of a software project. e Find alternate solutions possible. 52 Spiral Model as a meta model e Subsumes all discussed models: —a single loop spiral represents waterfall model. — uses an evolutionary approach -- * iterations through the spiral are evolutionary levels. — enables understanding and reacting to risks during each iteration along the spiral. — uses: * prototyping as a risk reduction mechanism * retains the step-wise approach of the waterfall 55 mrnadvAoal Comparison of Different Life Cycle Models » Iterative waterfall mode — most widely used model. ~ But, suitable only for well-understood problems. e Prototype model is suitable for projects not well understood: ~— user requirements ~ technical aspects 56 Comparison of Different Life Cycle Models (CONT.) e Evolutionary model is suitable for large problems: —can be decomposed into a set of modules that can be incrementally implemented, — incremental delivery of the system is acceptable to the customer. e The spiral model: ~ suitable for development of technically challenging software products that are subject to several kinds of risks. 57