 © Ian Sommerville A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

Slides:



Advertisements
Similar presentations
Software Processes.
Advertisements

Software Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Unit 2. Software Lifecycle
Lectures 2 & 3 Software Processes.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 1 Slide 1 المحاضرة الثانية.
Software Processes Modified by Randy K. Smith
Chap 2. Software Processes
What is software? Computer programs and associated documentation
CSE 470 : Software Engineering The Software Process.
Adaptive Processes Software Processes Adaptive Processes.
1 Chapter 2 Software Processes An overview of conventional software process models, Rational Unified Process, and CASE tools.
EE6421/ED5031Software Engineering Slide 1 Section # 2 (Read Sommerville Ch (3 or 4) and Pressman Ch 2) Software Processes.
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.
Software Processes Overview
Software Engineering COMP 201 1COMP201 - Software Engineering Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP.
ISNE101 Dr. Ken Cosh. Recap  We’ve been talking about Software…  Application vs System Software  Programming Languages  Vs Natural Languages  Syntax,
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Software Processes Coherent sets of activities for specifying, designing, implementing and testing software systems.
SYSC System Analysis and Design
Software Process Models
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 3Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
©Ian Sommerville 2000 Software Engineering, 6th edition Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
CMSC 345, Version 1/03 An Overview of Software Processes Reference: Software Engineering, by Ian Sommerville, 6 th edition, Chapter 3.
Chapter 3 Software Processes.
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
Lecture 2 Software Processes CSC301-Winter 2011 Hesam C. Esfahani
Software Processes Sumber dari : cc.ee.ntu.edu.tw/~farn/courses/SE/ch4.ppt.
Software Processes.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1 Software Processes (Chapter 3)
Software Processes lecture 8. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Software Processes Software and Its Engineering - adopted & adapted from I. Sommerville, 2004.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 1 Software Processes l Coherent sets of activities for specifying, designing,
Lecture 3 Software Engineering Models (Cont.)
1 SWE Introduction to Software Engineering Lecture 4.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
CSc 461/561 Software Engineering Lecture 2 – Software Processes.
Chapter 2 – Software Processes Lecture 2 1Chapter 2 Software Processes.
An Introduction to Software Engineering
Chapter 2 Software Processes (2/2) Yonsei University 2 nd Semester, 2015 Sanghyun Park.
4. Software Processes Software Engineering. Objectives To introduce software process models To describe three generic process models and when they may.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Chapter 13: Software Life Cycle Models Omar Meqdadi SE 273 Lecture 13 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
CSC 480 Software Engineering Lecture 2 August 26, 2002.
September 30, 2010COMS W41561 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Chapter 2 – Software Processes Lecture 2 1Chapter 2 Software Processes.
Software Engineering, 8th edition. Chapter 4 1 Courtesy: ©Ian Sommerville 2006 FEB 13 th, 2009 Lecture # 5 Software Processes.
Software Engineering Saeed Akhtar The University of Lahore Lecture 3 Originally shared for: mashhoood.webs.com.
Chapter 2 Software Development Model and 1. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
1 SYS366 Week 2 - Lecture Visual Modeling and Process.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini II. Software Life Cycle.
Software Processes (a)
Chapter 2 SW Process Models
Software Processes.
Chapter 2 Software Processes
An Overview of Software Processes
Software Processes.
Presentation transcript:

 © Ian Sommerville A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

 The waterfall model  The Spiral model  The Evolutionary model  There are many variants of these models e.g. formal development where a waterfall-like process is used but the specification is a formal specification that is refined through several stages to an implementable design.  © Ian Sommerville

 Requirements analysis and definition  System and software design  Implementation and unit testing  Integration and system testing  Operation and maintenance  The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. One phase has to be complete before moving onto the next phase.  © Ian Sommerville

 Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.  Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.  Few business systems have stable requirements.  © Ian Sommerville

 Process is represented as a spiral rather than as a sequence of activities with backtracking.  Each loop in the spiral represents a phase in the process.  No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.  Risks are explicitly assessed and resolved throughout the process.  © Ian Sommerville

 Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality.  User requirements are prioritised and the highest priority requirements are included in early increments.  Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.  © Ian Sommerville

 Customer value can be delivered with each increment so system functionality is available earlier.  Early increments act as a prototype to help elicit requirements for later increments.  Lower risk of overall project failure.  The highest priority system services tend to receive the most testing.  © Ian Sommerville

 Focus on agile methods and how they differ from ordinary.  In 1980’s and early 1990s the best way to achieve better software was through project planning and case tools – complex big systems.  NOW – agile methods increment development and delivery (used in small and medium- sized projects).

 The best known agile methods  All requirements are expressed as scenarios (planning game) which are implemented directly as a series of tasks.  Have 10/12 principels/best pracctices. - test first development - test-first - unittest of each task - user involvement - use of automated test - pairprogramming

 When a programmer builds the system to create a new version, he or she must run all existing automated tests as well as the test for new functionality. Only accepted if all test execute succesfully.  Refactoring – look for possible improvements to the software and implements them immediately. Code should be rewitten to improve their clarity or structure.