Software Engineering Lecture 18.

Slides:



Advertisements
Similar presentations
Slide 3.1 © The McGraw-Hill Companies, 2002 Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach
Advertisements

CHAPTER 3 SOFTWARE LIFE-CYCLE MODELS.
Lecture # 2 : Process Models
SOFTWARE PROCESS MODELS. Software Process Models  Process model (Life-cycle model) -steps through which the product progresses Requirements phase Specification.
CSE 470 : Software Engineering The Software Process.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
CS 5150 Software Engineering
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 2 Software Processes.
CS 501: Software Engineering
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
Incremental Model Requirements phase Verify Specification phase Verify
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Chapter 2- Software Process Lecture 4. Software Engineering We have specified the problem domain – industrial strength software – Besides delivering the.
CST 316 Process. Junior Project Process Provide necessary points of communication for individual effort. Allow a controllable division of labor. Divide.
1 CMPT 275 Software Engineering Software life cycle.
Chapter 2 The process Process, Methods, and Tools
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem Darwish.
CSE 308 Software Engineering Software Engineering Strategies.
SOFTWARE ENGINEERING MCS-2 LECTURE # 3. SOFTWARE PROCESS  A software development process, also known as a software development life- cycle (SDLC), is.
Software Engineering MCS-2 Lecture # 6
1/23 Prescriptive Process Models. 2/23 Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering Prescriptive.
Software Engineering II Lecture 3 Fakhar Lodhi. Software Life-Cycle Steps Life-cycle model (formerly, process model) –Requirements phase –Specification.
SOFTWARE LIFE-CYCLE MODELS
Slide 1 Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition Chapter 1: Introduction to Systems Analysis and Design Alan.
Slide 3.1 © The McGraw-Hill Companies, 2002 Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach
1 CS 501 Spring 2004 CS 501: Software Engineering Lecture 2 Software Processes.
Software Engineering At Glance. Why We Need Software Engineering? The aim of software engineering is to solve the software crisis Software is delivered.
Software Development Life Cycle (SDLC)
Software Model Process
Waterfall Model Software project Management. Waterfall Model  The Waterfall Model was first Process Model to be introduced. It is also referred to as.
Software Engineering, 8th edition. Chapter 4 1 Courtesy: ©Ian Sommerville 2006 FEB 13 th, 2009 Lecture # 5 Software Processes.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Software Engineering CE 501 Prepared by : Jay Dave.
Systems Development Life Cycle
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini II. Software Life Cycle.
Chapter 2: The Process. What is Process? Software Engineering Process is the glue that holds the technology layers together and enables rational and timely.
Software Development Overview
Methodologies and Algorithms
Software Engineering Management
Lecture 3 Prescriptive Process Models
Chapter 2 – Software Processes
Software Life Cycle “What happens in the ‘life’ of software”
CS 5150 Software Engineering
Software Processes (a)
V-Shaped SDLC Model Lecture-6.
Software development life cycle models
Software Process Models
Models of Software Development Life Cycle (SDLC)
Software Life Cycle Models
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
Software Processes.
Software Engineering Lecture 09 & 10.
Requirements and the Software Lifecycle
Introduction to Software Engineering
Chapter 2 Software Processes
Software life cycle models
An Overview of Software Processes
Software Development Life Cycle:-
Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach
Incremental Waterfall
Baisc Of Software Testing
CS310 Software Engineering Lecturer Dr.Doaa Sami
Software Processes Process should be
Software Processes.
Software Engineering Lecture 17.
Software Development Life Cycle Models
SDLC (Software Development Life Cycle)
Software Development Overview
Presentation transcript:

Software Engineering Lecture 18

Rapid Prototyping Model Requirement Definition System and Software Design Implementation and Unit Testing Integration and System Testing Operation and Maintenance Rapid Prototyping Real projects rarely follow the sequential flow that the model proposes. In general these phases overlap and feed information to each other. Hence there should be an element of iteration and feedback. A mistake caught any stage should be referred back to the source and all the subsequent stages need to be revisited and corresponding documents should be updated accordingly. Because of the costs of producing and approving documents, iterations are costly and require significant rework.

Incremental Model the product is partitioned into smaller pieces which are then built and delivered to the client in increments at regular intervals. Since each piece is much smaller than the whole, it can be built and sent to the client quickly. This results in quick feedback from the client and any requirement related errors or changes can be incorporated at a much lesser cost. As discussed above, the major drawbacks of the waterfall model are due to the fact that the entire product is developed and delivered to the client in one package. This results in delayed feedback from the client. Because of the long elapsed time, a huge new investment of time and money may be required to fix any errors of omission or commission or to accommodate any new requirements cropping up during this period. This may render the product as unusable. Incremental model may be used to overcome these issues. In a more risky version, once the user requirements have been elicited, the specifications of the first build are drawn up. When this has been completed, the specification team turns to the specification of the second build while the design team designs the first build. Thus the various builds are constructed in parallel, with each team making use of the information gained in the all the previous builds. This approach incurs the risk that the resulting build will not fit together and hence requires careful monitoring.

Incremental Model Requirements phase Verify Specification phase Verify Architectural design Verify For each build: Perform detailed design, implementation and integration, test, deliver to client Maintenance phase Development Maintenance Retirement

Incremental Model (cont.) Build 1 Implementation, integration Deliver to client Design Specification Implementation, integration Deliver to client Design Specification Build 2 Build 3 Implementation, integration Deliver to client Design Specification Build n Implementation, integration Deliver to client Design Specification Specification team Implementation, integration team Design team

Synchronize and Stabilize Model The requirements analysis interviews of potential customers are conducted and requirements document is developed. Once these requirements have been captured, specifications are drawn up. The project is then divided into 3 or 4 builds. Each build is carried out by small teams working in parallel. At the end of each day the code is synchronized (test and debug) and at the end of the build it is stabilized by freezing the build and removing any remaining defects. Because of the synchronizations, components always work together. The presence of an executable provides early insights into operation of product.

Rapid Application Development (RAD) Rapid application development is another form of incremental model. It is a high speed adaptation of the linear sequential model in which fully functional system in a very short time (2-3 months). This model is only applicable in the projects where requirements are well understood and project scope is constrained. Because of this reason it is used primarily for information systems.