Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Software engineering lec 2., Cheat Sheet of Software Engineering

This is first lecture of software engineering course .you will be able to understand each concept very clearly.

Typology: Cheat Sheet

2020/2021

Available from 01/16/2022

nand-nandan
nand-nandan 🇮🇳

2 documents

1 / 57

Toggle sidebar

Related documents


Partial preview of the text

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
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved