Chapter 2 Software Process: A Generic View

Slides:



Advertisements
Similar presentations
Chapter 2 The Software Process
Advertisements

May 14, May 14, 2015May 14, 2015May 14, 2015 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific University, Azusa,
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
CS487 Software Engineering Omar Aldawud
Computer Engineering 203 R Smith Process/Plan Model 7/ Development Process Models Development Process Models are different ways to look at the processes.
SOFTWARE ENGINEERING LECTURE-3 CSE-477.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 2 Process: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Software Process CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology December 17, 2002.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Developed by Reneta Barneva, SUNY Fredonia The Process.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Chapter 3 Software process Structure Chapter 3 Software process Structure Moonzoo Kim KAIST 1.
Capability Maturity Model
Chapter : Software Process
Process: A Generic View
Process: A Generic View n A software process  is a roadmap to building high quality software products.  provides a framework for managing activities.
1 Software Engineering Muhammad Fahad Khan Software Engineering Muhammad Fahad Khan University Of Engineering.
Software Engineering II Lecture 1 Fakhar Lodhi. Software Engineering - IEEE 1.The application of a systematic, disciplined, quantifiable approach to the.
Chapter 2 The process Process, Methods, and Tools
Chapter 2 The Process.
N By: Md Rezaul Huda Reza n
Chapter 2 Process: A Generic View
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.
College of Engineering and Computer Science Computer Science Department CSC 131 Computer Software Engineering Fall 2006 Lecture # 1 (Ch. 1, 2, & 3)
Chapter 2 소프트웨어공학 Software Engineering 임현승 강원대학교
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
PART ONE The Product and the Process Chapter 2 The Process  Software Engineering: A Layered Technology a “quality” focus process model methods tools.
Introduction to Software Engineering LECTURE 2 By Umm-e-Laila 1Compiled by: Umm-e-Laila.
Chapter 2 Process: A Generic View
Lecture 1 Introduction to Software Engineering
Software Engineering Lecture # 17
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 2 The Software Process Discussion of the Software Process: Process Framework,
Lecture Topics covered CMMI- - Continuous model -Staged model PROCESS PATTERNS- -Generic Process pattern elements.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Software Engineering - I
CS Process Improvement CMM Hans Van Vliet, Software Engineering, Principles and Practice, 3 rd edition, John Wiley & Sons, Chapter 6. W. Humphrey,
Process Improvement. It is not necessary to change. Survival is not mandatory. »W. Edwards Deming Both change and stability are fundamental to process.
CMMI. 1.Initial - The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual.
Process: A Generic View
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
Developed by Reneta Barneva, SUNY Fredonia The Process.
The Software Process Chapter – II. Topics S/w Engg – A layered Technology A Process Framework Process Patterns Process Assessment Product and Process.
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.
1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2.
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.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
1 Chapter 2 A Generic View of Process Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
1 2.1 Software Engineering Software engineering is a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software;
Software Engineering Introduction.
Software Engineering (CSI 321) Software Process: A Generic View 1.
Software Engineering CE 501 Prepared by : Ashwin Raiyani.
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.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 6/e Chapter 2.
1 Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 7th edition by Roger S. Pressman.
CS4311 Spring 2011 Process Improvement Dr
Software Life Cycle “What happens in the ‘life’ of software”
Software Engineering (CSI 321)
Information Technology Project Management – Fifth Edition
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 Process: A Generic View
Chapter 2 The Process.
Chapter 2 The Process.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 2 Process: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Software Engineering Lecture 16.
Software Engineering I
Capability Maturity Model
Capability Maturity Model
Presentation transcript:

Chapter 2 Software Process: A Generic View

Quick Look What is software process Who does the process A series of predictable steps that helps you create a timely, high-quality result. Who does the process Software engineers and their managers adapt the process to their needs and then follow it

Quick Look (cont.) Why is it important What are the steps It provides stability, control, and organization to an activity that can, if left uncontrolled, become quite chaotic What are the steps At a detailed level, the process that you adopt depends on the software you’re building

Quick Look (cont.) What is the work product Programs, documents, and data How do I ensure that I’ve done it right Employing software process assessment mechanisms Indicators Quality, timeliness, long-term viability

Software engineering Fritz Bauer, 1969 IEEE, 1993 The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines IEEE, 1993 The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software

Software Engineering is a Layered Technology tools methods process model a “quality” focus

Layered Technology (cont.) Any engineering approach must rest on an organizational commitment to quality Software process is the glue that holds the technology layers together and enables rational and timely development of computer software

Layered Technology (cont.) Software engineering methods provide the technical how-to’s for building software Communication, requirement analysis, design modeling, program construction, testing, and support Software engineering tools provide automated or semi-automated support for the process and the methods CASE (Computer-Aided Software Engineering)

A Generic View of Software Engineering The work associated with software engineering can be categorized into three generic phases The definition phase focuses on what The development phase focuses on how The support phase focuses on change associated with correction, adaptation, enhancement, and prevention

A Process Framework Process framework Framework activities work tasks work products milestones & deliverables QA checkpoints Umbrella Activities

Framework Activities Communication Planning Modeling Construction Analysis of requirements Design Construction Code generation Testing Deployment

Umbrella Activities Software project management Formal technical reviews Software quality assurance Software configuration management Document preparation and production Reusability management Measurement Risk management

The Process Model: Adaptability the framework activities will always be applied on every project ... BUT the tasks (and degree of rigor) for each activity will vary based on: the type of project (an “entry point” to the model) characteristics of the project common sense judgment; concurrence of the project team

The CMMI Software Engineering Institute (SEI) at Carnegie Mellon University Capability Maturity Model Integration (CMMI) for determining an organization’s current stat of process maturity The CMMI defines each process area in terms of “specific goals” and the “specific practices” required to achieve these goals. Specific goals establish the characteristics that must exist if the activities implied by a process area are to be effective. Specific practices refine a goal into a set of process-related activities. http://www.sei.cmu.edu/cmmi

The CMMI (cont.) One model, two representations Staged: organizational maturity approach Continuous: process capability approach

The CMMI (cont.)

The CMMI (cont.) 5 levels Initial Managed Defined Quantitatively managed Optimized

outcome depends on individuals 1. Initial Process: undefined, ad hoc Result: outcome depends on individuals Lacking: any reasonable process

tracks documents, cost, schedule, functionality (after fact) Result 1. INITIAL Process undefined, ad hoc, depends on individuals 2. Managed Process tracks documents, cost, schedule, functionality (after fact) Result repeatable only on similar projects Lacking: complete process

Lacking: predictable outcomes 2. REPEATABLE Basic project management to track cost & schedule, repeatable on similar projects 3. Defined Process documented, standardized, tailorable Result consistency Lacking: predictable outcomes

4. Quantitatively managed 3. DEFINED Consistent: Documented, standardized, tailorable 4. Quantitatively managed Process detailed measurement; control Result process and products with quantified quality predictability Lacking mechanism for process improvement

Continual process improvement through quantitative feedback; 4. MANAGED Predictable: process & products measured 5 Optimized Process Continual process improvement through quantitative feedback; Extensible scope Innovative ideas and technologies Graphics reproduced with permission from Corel.

The CMMI (cont.) The SEI has associated key process areas (KPAs) with each of the maturity levels The KPAs describe those software engineering functions that must be present to satisfy good practice at a particular level

The CMMI (cont.) Each KPA is described by identifying the following characteristics Goals Commitments Abilities Activities Methods for monitoring implementation Methods for verifying implementation

The CMMI (cont.) 18 KPAs are defined across the maturity model and mapped into different levels of process maturity Level 2 Software configuration management, software quality assurance, software subcontract management, software project tracking and oversight, software project management, requirement management Level 3 …

Process Areas for CMMI

Process Patterns Process patterns define a set of activities, actions, work tasks, work products and/or related behaviors A template is used to define a pattern An example process pattern template proposed by Ambler in 1998 Pattern name Intent Type Initial context Problem Solution Resulting context Related patterns Known uses/examples

Process Patterns (cont.) Typical examples: Customer communication (a process activity) Analysis (an action) Requirements gathering (a process task) Reviewing a work product (a process task) Design model (a work product)

Process Assessment The process should be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering. Many different assessment options are available: SCAMPI CBA IPI SPICE (ISO/IEC15504) ISO 9001:2000 Plan-do-check-act

Assessment and Improvement

Personal Software Process (PSP) What is it Developed by a team leaded by W.S. Humphrey in 1995 at CMU/SEI PSP is a software engineering methodology by which an individual software developer can continuously improve his or her abilities, in particular: learn to make accurate predictions of time required and quality obtained; improve the quality of the software produced; learn how to evaluate technology and methods. Source: http://www.ipd.uka.de/PSP/

Personal Software Process (cont.) Recommends five framework activities: Planning High-level design High-level design review Development Postmortem

Personal Software Process (cont.) PSP emphasizes the need to record and analyze the types of errors you make, so you can develop strategies to eliminate them PSP represents a disciplined, metrics-based approach to software engineering

PSP Defect Type Standard Class Description 10 Documentation problem: documents, comments, or messages are misunderstandable or wrong FIX: correct the document, the comment, or the message 20 Syntax/Static problem: a defect that can USUALLY be detected by the compiler (syntax errors, missing declarations etc. Defects that the compiler has caught only by luck count in other classes!) FIX: correct syntactic or compiler-findable static semantic defect. 30 Build/Package problem: errors in version control or in change management FIX: create or use correct version or correct the change 40 Assignment problem: one-statement defects in data management or procedure calls (e.g. wrong operand or operator in expression, wrong object assigned to, assignment missing or duplicated, call to wrong procedure, call missing) FIX: correct one statement

Team Software Process (TSP) What is it TSP provides a defined process framework for managing, tracking and reporting the team's progress. Using TSP, an organization can build self-directed teams that plan and track their work, establish goals, and own their processes and plans.

Team Software Process (cont.) TSP defines the following framework activities: Launch High-level design Implementation Integration and test Postmortem TSP makes a wide variety of scripts, forms, and standards to guide team members For example, scripts for project launch

Team Software Process (cont.)

PSP, TSP, and CMMI

The Primary Goal of Any Software Process: High Quality Remember: High quality = project timeliness Why? Less rework!