Software Development Process Models Derived from Dr. Fawcett’s slides Phil Pratt-Szeliga CSE 784 Fall 2009.

Slides:



Advertisements
Similar presentations
Software Quality Assurance Plan
Advertisements

Software Engineering CSE470: Process 15 Software Engineering Phases Definition: What? Development: How? Maintenance: Managing change Umbrella Activities:
SEP1 - 1 Introduction to Software Engineering Processes SWENET SEP1 Module Developed with support from the National Science Foundation.
More CMM Part Two : Details.
Software Life Cycles ECE 417/617: Elements of Software Engineering
Stepan Potiyenko ISS Sr.SW Developer.
Software Development Process Models. The Waterfall Development Model.
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
CSE 784 Software Studio Phil Pratt-Szeliga Fall 2010 Slides Derived From: Dr. Fawcett.
Software Architecture and Specification Derived from Dr. Fawcett’s slides Phil Pratt-Szeliga Fall 2010.
Software lifecycle. CS351 - Software Engineering (AY2004)2 Software lifecycle “student view” Design & Specification Coding Testing (optional) Hand it.
Configuration Management
Software Process CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology December 17, 2002.
Capability Maturity Model
What is Business Analysis Planning & Monitoring?
Effective Methods for Software and Systems Integration
The Key Process Areas for Level 2: Repeatable Ralph Covington David Wang.
Capability Maturity Model Part One - Overview. History Effort started by SEI and MITRE Corporation  assess capability of DoD contractors First.
Chapter 2 The process Process, Methods, and Tools
Dillon: CSE470: SE, Process1 Software Engineering Phases l Definition: What? l Development: How? l Maintenance: Managing change l Umbrella Activities:
N By: Md Rezaul Huda Reza n
Software Quality Assurance Activities
1 Chapter 2 The Process. 2 Process  What is it?  Who does it?  Why is it important?  What are the steps?  What is the work product?  How to ensure.
J. R. Burns, Texas Tech University Capability Maturity Model -- CMM n Developed by the Software Engineering Institute (SEI) in 1989 –SEI is a spinoff.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Introduction to Software Engineering LECTURE 2 By Umm-e-Laila 1Compiled by: Umm-e-Laila.
S Q A.
Lecture 1 Introduction to Software Engineering
Software Engineering - Spring 2003 (C) Vasudeva Varma, IIITHClass of 39 CS3600: Software Engineering: Standards in Process Modeling CMM and PSP.
Capability Maturity Models Software Engineering Institute (supported by DoD) The problems of software development are mainly caused by poor process management.
Software Engineering Lecture # 17
Extreme/Agile Programming Prabhaker Mateti. ACK These slides are collected from many authors along with a few of mine. Many thanks to all these authors.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Testing Workflow In the Unified Process and Agile/Scrum processes.
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 2 The Software Process Discussion of the Software Process: Process Framework,
Large Scale Software Systems Derived from Dr. Fawcett’s Notes Phil Pratt-Szeliga Fall 2010.
Software Development Cycle What is Software? Instructions (computer programs) that when executed provide desired function and performance Data structures.
Software Engineering Spring (C) Vasudeva VarmaClass of 32 CS3600: Software Engineering: Process and Product* *Most of the Content drawn.
Georgia Institute of Technology CS 4320 Fall 2003.
1 김 수 동 Dept. of Computer Science Soongsil University Tel Fax
CS Process Improvement CMM Hans Van Vliet, Software Engineering, Principles and Practice, 3 rd edition, John Wiley & Sons, Chapter 6. W. Humphrey,
Chapter 4 프로세스 모델 Process Models
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Software Architecture and Specification 2 Derived from Dr. Fawcett’s slides Phil Pratt-Szeliga Fall 2009.
COMP 6710 Course NotesSlide 3-0 Auburn University Computer Science and Software Engineering Course Notes Set 3: Software Process Maturity Computer Science.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome  Introductions  What is your experience with RUP  What is.
Process Asad Ur Rehman Chief Technology Officer Feditec Enterprise.
Software Engineering (CSI 321) Software Process: A Generic View 1.
Meghe Group of Institutions Department for Technology Enhanced Learning 1.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Lectures 2 & 3: Software Process Models Neelam Gupta.
Welcome to Software Project Management. CONVENTIONAL SOFTWARE MANAGEMENT The BEST and WORST thing about software is its flexibility. 1.Software development.
CS223: Software Engineering Lecture 18: The XP. Recap Introduction to Agile Methodology Customer centric approach Issues of Agile methodology Where to.
Review of Definitions Software life cycle: –Set of activities and their relationships to each other to support the development of a software system Software.
Software Project Management Unit 1. Evolving role of software S/w now a days resides in the mobile, mainframes The main role of the s/w is to transform.
Advanced Software Engineering Dr. Cheng
Methodologies and Algorithms
CSC 355 – Newer Approaches to System Development Life Cycles & Processes, Spring 2017 March 2017 Dr. Dale Parson.
Lecture 3 Prescriptive Process Models
CSE 784 Software Studio class notes
CS4311 Spring 2011 Process Improvement Dr
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
Quality Measurable characteristic Cyclomatic complexity Cohesion
Software Engineering I
Software Reviews.
Presentation transcript:

Software Development Process Models Derived from Dr. Fawcett’s slides Phil Pratt-Szeliga CSE 784 Fall 2009

Overview Definitions Software Process Model Process Models  Waterfall  Spiral  Incremental Development  Design by Contract  Evolutionary  Extreme Programming  Microsoft Development

Definitions Model  A representation of the most essential features of a physical object or process  Used as a pattern for reasoning about, analyzing, or predicting behavior Software Process Model  A model of the phases, activities, products and roles of people involved with the development of software

Software Process Models: Overview A model of the way software is built Production of large scale software is a complex endeavor  Many documents are produced  Code is written Product code Prototype code Test code  Many reviews are held internally with the development team and for the customer  Enormous amounts of data are collected and used to manage the development and keep developers and customer apprised of the program’s status Models are used to  Guide developers in their day-to-day activities  Keep the program focused on it’s principle objectives  Promote communication through the use of standardized documentation and reviews

Waterfall Process Model A software development process that proceeds linearly in time through phases Originally taken from the construction industry where some types of changes late in the project can be prohibitively expensive or impossible Requirements Analysis design code and Unit Test integration test Qualification Test

Waterfall Development Roles Software Product Manager  Responsible for cost and schedule  Has ultimate authority on all software development decisions  Depends on Architect, Test Manager and Team Leaders to implement decisions

Waterfall Development Roles Software Architect  Responsible for top-level software partitioning, defining user interfaces  Manages interfaces between software developed by each team  Is the source of knowledge on how the system works

Waterfall Development Roles Test Manager  Responsible for Test Plan and Qualification  Develops, with the test team, test descriptions and procedures, usually by assigning them to individual teams for elaboration  Conducts the Test Readiness Review and Qualification Test

Waterfall Development Roles Team Leader  Responsible for one subsystem – may be one module or a family of modules  Responsible for production of B and C specifications for the team’s software Presents his or her B-Spec at the Software Requirements Specification Review Usually delegates C-Spec development to team members  Responsible, with other team leaders, for software integration  Responsible to fully support Test Manager for the team’s part of the system, including production of Test Descriptions, Test Procedures and test conduct

Waterfall Development Roles Team Members  Responsible for their assigned part of the team’s C-Specification, code and unit test  Usually present at two reviews Preliminary Design Review Critical Design Review

Waterfall Development Roles Quality Assurance  Responsible for continuing assessment of the software quality  Reports to the Program Manager

Waterfall Model: Customer Reviews Requirements Analysis  Software Specification Review Architecture B-Spec (DFDs + HIPOs + Data dict + RTM) Derived Requirements Design and requirements issues

Waterfall Model: Customer Reviews Design  Preliminary Design Review Module Structure Preliminary C-Specs  Module Charts, Structure Charts  Class Structures, HIPOs Resolution of design and requirements issues Derived Requirements Design and test issues  Critical Design Review Full C-Specs with Pseudo-code Resolution of design and test issues

Waterfall Model: Customer Reviews Code and Unit Test  Informal code walkthroughs and inspections Integration Testing  Test Readiness Review (TRR) Major Test Groups Test Procedures Test Equipment, environment

Waterfall Model: Customer Reviews Qualification Testing  Formal, step-by-step proof that system meets A and B level specification requirements Demonstration Inspection Analysis Test

Waterfall Model: Reviews Audits:  Functional Configuration Audit (FCA) an Audit of both contracting office and contractor by outside agency to verify that contractual obligations have been met. Includes specification and test report reviews.  Physical Configuration Audit (PCA) an Audit of both contracting office and contractor by outside agency to verify that all the component parts purchased by the contract are in fact the ones tested and delivered.

Waterfall Model: Summary The waterfall model does a good job of capturing the essentials of large software development process  Activities Required  Roles of Specific Project Personnel  Products Generated It does not do a very good job of accounting for many realities of the development process:  Need for constant change due to: Requirements, Design and Implementation errors Performance deficits Accommodation of changes in another part of the system  Need to carefully control change  Discovery of unforeseen risks  Uncertainty of scheduling work that the team has not done before

Waterfall Model: Summary The failing of the waterfall model has prompted the development of several new variations  Incremental Development  Spiral Model  Design by Contract  Extreme Programming  Combinations of two or more of these

Side Note: Capability Maturity Model (CMM) Describes software development process in terms of five levels  Level 1 – Initial Ad hoc process, unpredictable results  Level 2 – Repeatable Disciplined process using standard management principles Key Process Areas:  Requirements Management, Project Planning, Project Tracking and Oversight, Configuration Management, Quality Assurance  Level 3 – Defined Standard Process applied consistently across organization  Level 4 – Managed Predictable Process using metrics gathered as part of the applied process  Level 5 – Optimizing Continuously improving process with a mandated process for defect prevention

Spiral Model Development proceeds through several prototypes, culminating in the completed system. Each prototype is developed according to the waterfall model  requirements analysis, code and unit test, integration, and system testing. Its intent is to deal effectively with the uncertainties and risks associated with a large new development.

Spiral Model

Incremental Development Model 1. Begins with requirements analysis and preliminary design 2. As soon as modules are defined, one is selected that has all of its dependencies met 3. This module’s development proceeds as with the Spiral Model, until unit test is complete 4. A summary level test (regression) is put in a test stub and used to verify the module’s operation 5. The module is then integrated into the baseline of code 6. Steps 2 through 4 are repeated until the project is complete 7. Qualification Test demonstrates that the software meets requirements

Incremental Development Model Requirements Analysis Preliminary Design Design Code & UT Integration Test Qualification Test Integration Test correct code partially tested code partially tested code --- phases modules

Design by Contract  A design process based on built in test  Uses assertions to guarantee correctness Pre-conditions  Conditions which must be satisfied by the caller Post-conditions  Conditions which the service supplier guarantees to hold after delivery of the service Invariants  Conditions which must hold at the end of every service invocation

Evolutionary Project Management Plan for frequent deliveries of a production quality system that run with growing functionality Goals  Budget cost and schedule for the complete project  Divide the project into a series of small delivery cycles  Focus on short-term, clear goals with a high expectation of meeting them  Deliver fully tested, production quality software with the right documentation at the end of each cycle

Evolutionary Project Management Goals  Solicit feedback from the customer and management at the end of each cycle  At the beginning of each cycle Reassess objectives Estimate effort  Make quality objectives part of the requirements  Conclude the project when the budgeted cost or schedule has been consumed Customer has the option to contract further work on the system

Evolutionary Project Management Inspection Process  All deliverable items are inspected using a walkthrough process lead by the originator. Inspectors Present: Project Manager Inspection committee of developers  All defects are recorded  The originator removes all defects and resubmits the item for inspection  This is repeated until the item meets or exceeds its planned level of quality

Extreme Programming A development process designed to develop high quality software using an incremental development process

Extreme Programming User stories are created by the customer that shed light on features needed Each user story is implemented, starting with the most important one  Analysis  Design  Code  Test  Production

Extreme Programming Test Driven Development is used for all implementation with Programmer Pairs Refactoring is used with TDD Short standup meetings are used to coordinate the team After each user story is implemented it should be of quality to deliver to the customer

References  The Capability Maturity Model, Software Engineering Institute, Addison Wesley, 1994  Process Improvement for Small Organizations, Kelly & Culleton, IEEE Computer, October 1999  Evolutionary Project Management, Woodward, IEEE Computer, October 1999   Software Development on Internet Time, Cusumano & Yoffie, IEEE Computer, October 1999