Introduction to Software Engineering Lecture 3 André van der Hoek.

Slides:



Advertisements
Similar presentations
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 12, Software Life Cycle.
Advertisements

Computer Science Department
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Slide 3.1 © The McGraw-Hill Companies, 2002 Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach
CHAPTER 3 SOFTWARE LIFE-CYCLE MODELS.
SOFTWARE PROCESS MODELS. Software Process Models  Process model (Life-cycle model) -steps through which the product progresses Requirements phase Specification.
Software Development Life Cycle
Multimedia Specification Design and Production 2013 / Semester 1 / week 7 Lecturer: Dr. Nikos Gazepidis
Software Life-Cycle Models
The software process A software process is a set of activities and associated results which lead to the production of a software product. This may involve.
CHAPTER 1 SOFTWARE DEVELOPMENT. 2 Goals of software development Aspects of software quality Development life cycle models Basic concepts of algorithm.
Chapter 2 – Software Processes
Sharif University of Technology Session # 3.  Contents  Systems Analysis and Design Sharif University of Technology MIS (Management Information System),
Introduction to Software Engineering Lecture 4 André van der Hoek.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering.
OHT 6.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Development plan and quality plan objectives The elements of the development.
Software Engineering. How many lines of code? Average CS1004 assignment: 200 lines Average CS4115 project: 5000 lines Corporate e-commerce project: 80,000.
1 CS 425/625 Software Engineering CS 425/625 Software Engineering Software Processes Based on Chapter 4 of the textbook [SE-7] Ian Sommerville, Software.
Software Engineering.
Introduction to Software Engineering Dr. Basem Alkazemi
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
1 CS 691z/791z Topics on Software Engineering CS 691z/791z Topics on Software Engineering Software Processes Based on Chapter 4 of the book [SE-8] Ian.
Software Engineering General Project Management Software Requirements
CS 425/625 Software Engineering Software Processes
Information Systems Development Lecture 2: the idea of the Life Cycle.
Software lifecycle. CS351 - Software Engineering (AY2004)2 Software lifecycle “student view” Design & Specification Coding Testing (optional) Hand it.
Incremental Model Requirements phase Verify Specification phase Verify
Software Lifecycle Software Lifecycle Basics Lifecycle Models Methods and Tools.
Chapter 2- Software Process Lecture 4. Software Engineering We have specified the problem domain – industrial strength software – Besides delivering the.
Software Life Cycle Model
University of Toronto Department of Computer Science CSC444 Lec04- 1 Lecture 4: Software Lifecycles The Software Process Waterfall model Rapid Prototyping.
ICS 52: Introduction to Software Engineering Lecture Notes for Summer Quarter, 2003 Michele Rousseau Set 2 Partially based on lecture notes written by.
Chapter 2 The process Process, Methods, and Tools
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering.
Capability Maturity Models Software Engineering Institute (supported by DoD) The problems of software development are mainly caused by poor process management.
Software Life-Cycle Models Somnuk Keretho, Assistant Professor Department of Computer Engineering Faculty of Engineering, Kasetsart University
Software Engineering Management Lecture 1 The Software Process.
1 Project Risk Management Project Risk Management Dr. Said Abu Jalala.
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
Note Excerpts from Object-Oriented Software Engineering WCB/McGraw-Hill, 2008 Stephen R. Schach
Slide 2.1 CHAPTER 2 THE SOFTWARE PROCESS. Slide 2.2 Overview l Client, Developer, and User l Requirements Phase l Specification Phase l Design Phase l.
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Software Engineering II Lecture 3 Fakhar Lodhi. Software Life-Cycle Steps Life-cycle model (formerly, process model) –Requirements phase –Specification.
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 Life Cycle The software life cycle is the sequence of activities that occur during software development and maintenance.
Project & Risk Management For next class -- Pressman: 3, , 5.8, , 6.6 Introductions Software Development Processes Software Maturity 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.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
Connecting with Computer Science2 Objectives Learn how software engineering is used to create applications Learn some of the different software engineering.
Prototyping. Outline Risk Management Prototyping Kinds of Prototypes Example Activity 1.
September 30, 2010COMS W41561 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser
Software Engineering At Glance. Why We Need Software Engineering? The aim of software engineering is to solve the software crisis Software is delivered.
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering.
Software Development Life Cycle (SDLC)
Ch7: Software Production Process. 1 Waterfall models  Invented in the late 1950s for large air defense systems, popularized in the 1970s  Main characteristics:
Software Engineering Zhang Shuang
Chapter 1: Introduction Omar Meqdadi SE 3860 Lecture 1 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
CS 425/625 Software Engineering Software Processes
Chapter 2 SW Process 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 Engineering Lecture 09 & 10.
Software Development Process
Software life cycle models
Software Engineering Lecture 17.
Presentation transcript:

Introduction to Software Engineering Lecture 3 André van der Hoek

Today’s Lecture What makes software engineering difficult? An introduction to software life cycle models

Visibility vs…

…Invisibility Software as is cannot be viewed meaningfully Stack of paper Set of files Software cannot be interpreted easily How to read source code? How to read a million lines of source code? How to read a part of source code? Invisibility affects process How to measure progress? Is a bigger stack of paper closer to the end-result than a smaller stack of paper?

Manageable Complexity vs…

…Unmanageable Complexity Software cannot be easily abstracted Formulas Only in very few domains Diagrams, graphs, and other representations Typically non-hierarchical Far too many cross-references Few concepts are available to use in an abstraction Tension between high-level understanding and low-level detailed specification High-level understanding leaves out important details Aggregation often does not work

Environment Can Be Changed vs…

…Environment Cannot Be Changed Software has to adhere to the “world” in which it is placed Cannot change the hardware Cannot change the way people do business The “world” is often not clearly specified How can you change something that you cannot specify? Leads to many software changes Perception is that software is easier to change

No Major Changes vs…

…Major Changes Software is remarkably easy to change Change the source code, recompile, rerun “One line here, one line there” Unfortunately, even small changes can have disastrous consequences A single wrong character can surreptitiously change the behavior of the software The effects of most changes are only visible in certain circumstances Sometimes, the environment does change Software is used in different organizations Software is used for different purposes

Drastic Consequences Deceased patients X-ray machine delivered very high doses because of a timing problem in its control software Crashed planes Software prevented pilots from performing emergency maneuvers Software had similar codes for different airports Decreased national security NSA computers down for four days due to a “software problem” Peter Neumann’s Risks Digest:

High Cost [Schach]

Cost of Change Progressively Higher [Schach]

Processes as a Remedy Institute processes through which software is engineered Cover all steps from initial idea and requirements to delivery, maintenance, and final retirement Make sure we do the right things/things right Make sure we do not forget to do anything Different processes for different kinds of software Not a silver bullet [Brooks “No Silver Bullet”] Software is still intrinsically difficult to deal with Processes help, but cannot guarantee anything Remember: People + Processes + Tools  Product

Processes Elements Activities (“Phases”) Artifacts Can include process specifications Resources People (their time and their cost) Tools (their time and their cost) Relationships between the elements Precedence, requires, provides, refines to, … Constraints Time Cost Qualities (repeatable process?)

Software Life Cycle Models Build-and-fix Waterfall Rapid prototyping Incremental Synchronize-and-stabilize Spiral A software life cycle model is a high-level process

Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

Rapid Prototyping Operations mode Retirement Build and discard simple prototype Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

FOR EACH BUILD Perform detailed design, implementation, and integration. Test. Deliver to client. Incremental Operations mode Retirement Requirements phase Verify Specification phase Verify Architectural design Verify Development Maintenance

Synchronize-and-Stabilize Specifications Implementation, Integration Deliver to client (version 1) SpecificationsDesign Implementation, Integration Deliver to client (version 2) SpecificationsDesign Implementation, Integration Deliver to client (version 3) SpecificationsDesign Implementation, Integration Deliver to client (version n) Specification teamDesign teamImplementation/integration team Design

Synchronize-and-Stabilize Specifications Implementation, Integration Deliver to client (version 1) SpecificationsDesign Implementation, Integration Deliver to client (version 2) SpecificationsDesign Implementation, Integration Deliver to client (version 3) SpecificationsDesign Implementation, Integration Deliver to client (version n) Specification teamDesign teamImplementation/integration team Design

Synchronize-and-Stabilize Specifications Implementation, Integration Deliver to client (version 1) SpecificationsDesign Implementation, Integration Deliver to client (version 2) SpecificationsDesign Implementation, Integration Deliver to client (version 3) SpecificationsDesign Implementation, Integration Deliver to client (version n) Specification teamDesign teamImplementation/integration team Design

Synchronize-and-Stabilize Specifications Implementation, Integration Deliver to client version 1 SpecificationsDesign Implementation, Integration Deliver to client version 2 SpecificationsDesign Implementation, Integration Deliver to client version 3 SpecificationsDesign Implementation, Integration Deliver to client version n Specification teamDesign teamImplementation/integration team Design

Synchronize-and-Stabilize Specifications Implementation, Integration Deliver to client version 1 SpecificationsDesign Implementation, Integration Deliver to client version 2 SpecificationsDesign Implementation, Integration Deliver to client version 3 SpecificationsDesign Implementation, Integration Deliver to client version n Specification teamDesign teamImplementation/integration team Design

Synchronize-and-Stabilize Specifications Implementation, Integration Deliver to client version 1 SpecificationsDesign Implementation, Integration Deliver to client version 2 SpecificationsDesign Implementation, Integration Deliver to client version 3 SpecificationsDesign Implementation, Integration Deliver to client version n Specification teamDesign teamImplementation/integration team Design

Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify Full spiral model is discussed in Sommerville

Boehm’s Top Ten Software Risks 1. Personnel shortfalls 2. Unrealistic schedules and budgets 3. Developing the wrong software functions 4. Developing the wrong user interface 5. “Gold plating” 6. Continuing stream of requirements changes 7. Shortfalls in externally furnished components 8. Shortfalls in externally performed tasks 9. Real-time performance shortfalls 10. Straining computer- science capabilities

A Comparison of Life Cycle Models ModelStrengthsWeaknesses Build-and-FixFine for small programs that do not require much maintenance Totally unsatisfactorily for nontrivial programs WaterfallDisciplined approach Document driven Delivered product may not meet client’s needs Rapid Prototyping Ensures that delivered product meets client’s needs A need to build twice Cannot always be used IncrementalMaximizes early return on investment Promotes maintainability Requires open architecture May degenerate into build-and-fix Synchronize- and-stabilize Future user’s needs are met Ensures components can be successfully integrated Has not been widely used other than in Microsoft SpiralIncorporates features of all the above models Can be used only for large-scale products Developers have to be competent at risk- analysis

Homework 1. Read Chapter 3 of van Vliet