2003 Mateusz Żochowski, Marcin Borzymek Software Life Cycle Analysis.

Slides:



Advertisements
Similar presentations
Prescriptive Process models
Advertisements

1 Software Processes A Software process is a set of activities and associated results which lead to the production of a software product. Activities Common.
Software Process Models
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
CS487 Software Engineering Omar Aldawud
CSE 470 : Software Engineering The Software Process.
Systems Analysis and Design II
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.
1 Chapter 7 Lifecycle Planning. 2 Lifecycles - Introduction A lifecycle model is a prescriptive model of what should happen between the first glimmer.
Software development lifecycle The power of process Cycle Life Software.
Software Process Models
Alternate Software Development Methodologies
CS 5150 Software Engineering
Software Engineering. How many lines of code? Average CS1004 assignment: 200 lines Average CS4115 project: 5000 lines Corporate e-commerce project: 80,000.
Software Engineering.
Object-oriented Analysis and Design
1 Building and Maintaining Information Systems. 2 Opening Case: Yahoo! Store Allows small businesses to create their own online store – No programming.
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
1 CSE 403 Software Lifecycle Models Reading: Rapid Development Ch. 7, 25 (further reading: Ch. 21, 35, 36, 20) These lecture slides are copyright (C) Marty.
Chapter 2 The process Process, Methods, and Tools
IT Systems Analysis & Design
THE PROTOTYPING MODEL The prototyping model begins with requirements gathering. Developer and customer meet and define the overall objectives for the software.
Lecture # 04 & 05 CS314 Introduction To Software Development Software Development Process (SDP) Instructor :Muhammad Janas khan
 Software Models.  A software life-cycle model is a descriptive and diagrammatic representation of the software life-cycle. This includes a series of.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Prescriptive Process Models
CSE Senior Design I Building a Plan Instructor: Vassilis Athitsos Several of the slides in this module are a modification and amplification of slides prepared.
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
Methodologies. Contents Waterfall Model Evolutionary Models Incremental Development.
Software Engineering MCS-2 Lecture # 6
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
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.
An Introduction to Software Engineering
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.
September 30, 2010COMS W41561 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser
Software Development Life Cycle (SDLC)
Software Project Management Iterative Model & Spiral Model.
 Many models have been proposed to deal with the problems of defining activities and associating them with each other  The first model proposed was the.
The Code and Fix model It is a simple two phase model. In first phase: code is developed In second phase: fix the code until the client is not satisfied.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Software Development Life Cycle (SDLC)
CSE 403, Spring 2008, Alverson Software Development Lifecycle The Power of Process.
Software Lifecycle Models A software lifecycle model is a standardised format for planning organising, and running a new development project.
Software Development Life Cycle(SDLC)‏
Chapter 2 Software Development Model and 1. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
By : Hisham Kahlifa Shreef Foda Khaled monir Tamer medhat Supervisor : Dr Doaa Nabil.
Software Lifecycle Models Place of Testing in Software Lifecycle 1.
Statement of Work Lecture. SOW The statement of work is the basis of the contract between the pro- poser and the customer, and is often incorporated into.
Chapter 2- Software Development Process  Product Components  Software Project Staff  Software Development Lifecycle Models.
SOFTWARE DEVELOPMENT Presented By : Emporiumtech This presentation is brought you by
Slide 3.1 © The McGraw-Hill Companies, 2002 SOFTWARE LIFE-CYCLE MODELS.
Software Development - Methodologies
Methodologies and Algorithms
Appendix B Agile Methodologies
Lecture 3 Prescriptive Process Models
CS 5150 Software Engineering
V-Shaped SDLC Model Lecture-6.
Software Process Models
IT Systems Analysis & Design
Methodologies For Systems Analysis.
Software Lifecycle Models
SDLC Model A framework that describes the activities performed at each stage of a software development project.
Lecture 02: Software Lifecycle Models
Software life cycle models
Lecture 03: Software Lifecycle Models
Software Process Models
Incremental Waterfall
Software Processes Process should be
Presentation transcript:

2003 Mateusz Żochowski, Marcin Borzymek Software Life Cycle Analysis

2003 Mateusz Żochowski, Marcin Borzymek Why Planning? Streamline project Streamline project Improve development speed Improve development speed Improve quality Improve quality Improve project tracking and control Improve project tracking and control Improve client relations Improve client relations

2003 Mateusz Żochowski, Marcin Borzymek Inappropriate or Lack of a Lifecycle Model Slow work Slow work Repeated work Repeated work Unnecessary work Unnecessary work Frustration Frustration

2003 Mateusz Żochowski, Marcin Borzymek Lifecycle Models Pure Waterfall Pure Waterfall Modified Waterfalls Modified Waterfalls Spiral Spiral Code-and-Fix Code-and-Fix Evolutionary Prototypes Evolutionary Prototypes Staged Delivery Staged Delivery Design-to Schedule Design-to Schedule Extreme Programming Life Cycle Extreme Programming Life Cycle

2003 Mateusz Żochowski, Marcin Borzymek Pure Waterfall Orderly sequence of steps Orderly sequence of steps Review at the end of each phase Review at the end of each phase Discontinuous phases Discontinuous phases

2003 Mateusz Żochowski, Marcin Borzymek Waterfall Rapid Development, 1996

2003 Mateusz Żochowski, Marcin Borzymek Waterfall Benefits Finds errors in early stages Finds errors in early stages Minimizes planning overhead since it can be done up front Minimizes planning overhead since it can be done up front Structure minimizes wasted effort, so it works well for technically weak or inexperienced staff Structure minimizes wasted effort, so it works well for technically weak or inexperienced staff

2003 Mateusz Żochowski, Marcin Borzymek Waterfall Disadvantages No tangible results until the end No tangible results until the end Inflexible Inflexible Excessive documentation Excessive documentation Backing up to address mistakes is difficult Backing up to address mistakes is difficult

2003 Mateusz Żochowski, Marcin Borzymek Waterfall Summary - performs well for products with clearly understood requirements -it's weaknesses frequently make it inadvisable when rapid development is needed. In those cases, modified models may be more effective.

2003 Mateusz Żochowski, Marcin Borzymek Modified Waterfalls Waterfall with Subprojects Waterfall with Subprojects Waterfall with Risk Reduction Waterfall with Risk Reduction

2003 Mateusz Żochowski, Marcin Borzymek Waterfall With Subprojects Subprojects Subprojects Rapid Development, 1996

2003 Mateusz Żochowski, Marcin Borzymek Waterfall With Subprojects Benefits Logically independent subsystems Logically independent subsystems Each subproject can proceed at own pace Each subproject can proceed at own pace

2003 Mateusz Żochowski, Marcin Borzymek Waterfall With Subprojects Disadvantages Unforeseen interdependencies Unforeseen interdependencies

2003 Mateusz Żochowski, Marcin Borzymek Waterfall With Risk Reduction Risk-reduction spiral at top Risk-reduction spiral at top Rapid Development, 1996

2003 Mateusz Żochowski, Marcin Borzymek Waterfall With Risk Reduction Benefits Reduce risk Reduce risk Best of Waterfall and Risk Reduction models Best of Waterfall and Risk Reduction models Not limited to requirements Not limited to requirements

2003 Mateusz Żochowski, Marcin Borzymek Spiral (Cinnamon Roll) Risk-oriented Risk-oriented Miniprojects Miniprojects Iterations Iterations Determine objectives, alternatives, and constraints Determine objectives, alternatives, and constraints Identify and resolve risks Identify and resolve risks Evaluate alternatives Evaluate alternatives Develop deliverables Develop deliverables Plan the next iteration Plan the next iteration Commit to an approach for the next iteration Commit to an approach for the next iteration

2003 Mateusz Żochowski, Marcin Borzymek Spiral (Cinnamon Roll) Rapid Development, 1996

2003 Mateusz Żochowski, Marcin Borzymek Spiral Benefits Management control Management control Early indication of fatal risks Early indication of fatal risks Flexible Flexible

2003 Mateusz Żochowski, Marcin Borzymek Spiral Disadvantages Complicated Complicated Requires attentive, and knowledgeable management Requires attentive, and knowledgeable management

2003 Mateusz Żochowski, Marcin Borzymek Possible Applications High risk projects High risk projects Poorly understood requirements Poorly understood requirements Poorly understood architecture Poorly understood architecture Potential performance problems Potential performance problems Problems in the underlying technology Problems in the underlying technology Combine with other lifecycle models Combine with other lifecycle models Terminate with waterfall or other lifecycle Terminate with waterfall or other lifecycle Incorporate other lifecycle models as iterations Incorporate other lifecycle models as iterations

2003 Mateusz Żochowski, Marcin Borzymek Spiral Summary -it's beneficial to run a series of risk-reduction iterations which can be followed by a waterfall or other non-risk-based lifecycle

2003 Mateusz Żochowski, Marcin Borzymek Code-and-Fix Informal Informal Unstructured Unstructured Rapid Development, 1996

2003 Mateusz Żochowski, Marcin Borzymek Code-and-Fix Benefits No overhead No overhead Requires little expertise Requires little expertise

2003 Mateusz Żochowski, Marcin Borzymek Code-and-Fix Disadvantages No means of assessing progress No means of assessing progress No quality management No quality management No risk management No risk management

2003 Mateusz Żochowski, Marcin Borzymek Possible Applications Small proof-of-concept programs Small proof-of-concept programs Short-lived demos Short-lived demos Throwaway prototypes Throwaway prototypes

2003 Mateusz Żochowski, Marcin Borzymek Evolutionary Prototyping Develop system concept as the project progresses Develop system concept as the project progresses Begin with the most visible aspects Begin with the most visible aspects Prototype Prototype Rapid Development, 1996

2003 Mateusz Żochowski, Marcin Borzymek Evolutionary Prototyping Benefits Steady, visible signs of progress Steady, visible signs of progress Less documentation Less documentation

2003 Mateusz Żochowski, Marcin Borzymek Evolutionary Prototyping Disadvantages Impossible to schedule release Impossible to schedule release Excuse to use code-and-fix development Excuse to use code-and-fix development

2003 Mateusz Żochowski, Marcin Borzymek Possible Applications Rapidly changing requirements Rapidly changing requirements Customer reluctant to commit to requirements Customer reluctant to commit to requirements Do not understand application area Do not understand application area Strong demand for development speed Strong demand for development speed

2003 Mateusz Żochowski, Marcin Borzymek Evolutionary Delivery Similar to Evolutionary Prototyping Similar to Evolutionary Prototyping Refine version based upon customer feedback Refine version based upon customer feedback Emphasizes core of the system Emphasizes core of the system

2003 Mateusz Żochowski, Marcin Borzymek Evolutionary Delivery Rapid Development, 1996

2003 Mateusz Żochowski, Marcin Borzymek Evolutionary Delivery Benefits Can accommodate customer requests Can accommodate customer requests Allows a degree of midtime changes Allows a degree of midtime changes Provides visible results Provides visible results

2003 Mateusz Żochowski, Marcin Borzymek Evolutionary Delivery Disadvantages Difficult to schedule release Difficult to schedule release May lead to Code-and-Fix development May lead to Code-and-Fix development

2003 Mateusz Żochowski, Marcin Borzymek Design-to-Schedule Prioritize features Prioritize features Unsure if final release will be reached Unsure if final release will be reached Rapid Development, 1996

2003 Mateusz Żochowski, Marcin Borzymek Design-to-Schedule Benefits Ensure product release for a particular date Ensure product release for a particular date Most important features completed first Most important features completed first

2003 Mateusz Żochowski, Marcin Borzymek Design-to-Schedule Disadvantages Wasted effort specifying unfinished stages Wasted effort specifying unfinished stages Could complete one or more stages if time was not wasted specifying several unfinished stages Could complete one or more stages if time was not wasted specifying several unfinished stages

2003 Mateusz Żochowski, Marcin Borzymek Possible Applications Must have product by a specific date Must have product by a specific date Unconfident in scheduling abilities Unconfident in scheduling abilities

2003 Mateusz Żochowski, Marcin Borzymek Design-to-Tools Include functionality only if directly supported by existing software tools Include functionality only if directly supported by existing software tools Rapid Development, 1996

2003 Mateusz Żochowski, Marcin Borzymek Design-to-Tools Benefits Maximum functionality vs. time Maximum functionality vs. time Can be combined with other lifecycle models Can be combined with other lifecycle models Initial spiral Initial spiral Throwaway prototype Throwaway prototype Staged delivery Staged delivery Evolutionary delivery Evolutionary delivery Design-to-schedule Design-to-schedule

2003 Mateusz Żochowski, Marcin Borzymek Design-to-Tools Disadvantages Less control Less control Unable to implement all features Unable to implement all features Unable to implement features as intended Unable to implement features as intended Dependent on commercial software producers Dependent on commercial software producers

2003 Mateusz Żochowski, Marcin Borzymek Possible Applications Exceptionally time-sensitive projects Exceptionally time-sensitive projects

2003 Mateusz Żochowski, Marcin Borzymek Extreme Programming

2003 Mateusz Żochowski, Marcin Borzymek User Stories written by the customers as things that the system needs to do for them written by the customers as things that the system needs to do for them in the format of about three sentences of text in the customers terminology without techno- syntax in the format of about three sentences of text in the customers terminology without techno- syntax

2003 Mateusz Żochowski, Marcin Borzymek Release Plan create iteration plans for each individual iteration. create iteration plans for each individual iteration. estimate each user story in terms of ideal programming weeks estimate each user story in terms of ideal programming weeks estimate user stories velocity estimate user stories velocity

2003 Mateusz Żochowski, Marcin Borzymek Spike solutions is a very simple program to explore potential solutions is a very simple program to explore potential solutions figure out answers to tough technical or design problems figure out answers to tough technical or design problems helps to estimate project velocity helps to estimate project velocity

2003 Mateusz Żochowski, Marcin Borzymek Iteration During an iteration the user stories selected during the iteration planning meeting will be translated into acceptance tests. During an iteration the user stories selected during the iteration planning meeting will be translated into acceptance tests.

2003 Mateusz Żochowski, Marcin Borzymek Acceptance Tests The customer specifies scenarios to test when a user story has been correctly implemented The customer specifies scenarios to test when a user story has been correctly implemented No tests passed = no progress No tests passed = no progress A user story is not considered complete until it has passed its acceptance tests A user story is not considered complete until it has passed its acceptance tests

2003 Mateusz Żochowski, Marcin Borzymek Small Releases Small units of functionality can be released into the customer's environment early in the project - that gives valuable feedback Small units of functionality can be released into the customer's environment early in the project - that gives valuable feedback

2003 Mateusz Żochowski, Marcin Borzymek Choosing An Appropriate Lifecycle How well are requirements understood How well are requirements understood How well is system architecture understood How well is system architecture understood How much reliability is needed How much reliability is needed How likely are future revisions How likely are future revisions How much risk How much risk Need to make midcourse corrections Need to make midcourse corrections

2003 Mateusz Żochowski, Marcin Borzymek Choosing An Appropriate Lifecycle (cont.) Need to provide visible progress to customers Need to provide visible progress to customers Need to provide visible progress to management Need to provide visible progress to management How sophisticated is the model How sophisticated is the model

2003 Mateusz Żochowski, Marcin Borzymek Strengths & Weaknesses Rapid Development, 1996

2003 Mateusz Żochowski, Marcin Borzymek Strengths & Weaknesses (cont.) Rapid Development, 1996

2003 Mateusz Żochowski, Marcin Borzymek Questions?