KEY PROCESS AREAS (KPAs)

Slides:



Advertisements
Similar presentations
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
Advertisements

Software Configuration Management
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
Requirements - Why What and How? Sriram Mohan. Outline Why ? What ? How ?
SE 555 Software Requirements & Specification Requirements Management.
Software Engineering Institute Capability Maturity Model (CMM)
Change Request Management
Capability Maturity Model
How the Change Control Process Affects Project Quality
The Key Process Areas for Level 2: Repeatable Ralph Covington David Wang.
S T A M © 2000, KPA Ltd. Software Trouble Assessment Matrix Software Trouble Assessment Matrix *This presentation is extracted from SOFTWARE PROCESS QUALITY:
Software Engineering II Lecture 1 Fakhar Lodhi. Software Engineering - IEEE 1.The application of a systematic, disciplined, quantifiable approach to the.
N By: Md Rezaul Huda Reza n
Cybersecurity: Engineering a Secure Information Technology Organization, 1st Edition Chapter 7 Software Supporting Processes and Software Reuse.
Software Configuration Management (SCM)
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.
Michael Dermody September 2010  Capability Maturity Model Integration ◦ Is a Trademark owned by the Software Engineering Institute (SEI) of Carnegie.
CMM Level 2 KPA’s CS 4320 Fall Requirements Management 1 Goals: – System requirements allocated to software are controlled using a baseline for.
IT Requirements Management Balancing Needs and Expectations.
1 Requirements Management - General concepts - Noureddine Abbadeni King Saud University College of Computer and Information Sciences Based on “Software.
Georgia Institute of Technology CS 4320 Fall 2003.
Software Requirements: Overview and Motivation Gruia-Catalin Roman and Christopher Gill CSE 436 January 2007 Department of Computer Science and Engineering.
© Mahindra Satyam 2009 Configuration Management QMS Training.
SWEN 5130 Requirements Engineering 1 Dr Jim Helm SWEN 5130 Requirements Engineering Requirements Management Under the CMM.
Introduction to Requirements Engineering Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Develop Project Charter
Software Requirements and Design Khalid Ishaq
Ch-1 Introduction The processes used for executing a software project have major effect on quality of s/w produced and productivity achieved in project…
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
Purpose: The purpose of CMM Integration is to provide guidance for improving your organization’s processes and your ability to manage the development,
An Agile Requirements Approach 1. Step 1: Get Organized  Meet with your team and agree on the basic software processes you will employ.  Decide how.
Requirements Management with Use Cases Module 2: Introduction to RMUC Requirements Management with Use Cases Module 2: Introduction to RMUC.
Software Engineering Lecture 9: Configuration Management.
Configuration Control (Aliases: change control, change management )
Configuration & Build Management. Why Software Configuration Management ? The problem: Multiple people have to work on software that is changing More.
Poka-yoke in software A software products company sells application software to an international market. The pull-down menus and associated mnemonics provided.
Your Prescription for Requirements Management 1. Assumptions The prescription for requirements management is based on the following assumptions:  The.
Chapter 25 – Configuration Management 1Chapter 25 Configuration management.
Capability Maturity Model. What is CMM? n CMM: Capability Maturity Model n Developed by the Software Engineering Institute of the Carnegie Mellon University.
Change Request Management
Configuration Management
Software Configuration Management
Software Project Configuration Management
Measuring Change Activity
State of Michigan Achieving Software Process Improvement with
Chapter 18 Maintaining Information Systems
Configuration Management
McCall’s Quality Factors
TechStambha PMP Certification Training
Development Projects / Analysis Projects / On-site Service Projects
Change Control Process—I
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 #2
CS 790M Project preparation (I)
Chapter 3: The Requirements Workflow
The Features of a Product or System
Engineering Processes
Baseline – IEEE definition
Quality Measurable characteristic Cyclomatic complexity Cohesion
Software Engineering Lecture 16.
Software Engineering I
Capability Maturity Model
Applied Software Project Management
SVV Lec: software process assurance.
Chapter 3: Project Integration Management
Capability Maturity Model
Managing Project Work, Scope, Schedules, and Cost
CS 426 CS 791z Topics on Software Engineering
Software Reviews.
CS 426 CS 791z Topics on Software Engineering
Presentation transcript:

KEY PROCESS AREAS (KPAs) As Defined by SOFTWARE ENGINEERING INSTITUTE (SEI) “SOFTWARE ENGINEERING AND MANAGEMENT PRACTICES” LEVEL 1 - INITIAL LEVEL 2 -REPEATABLE PROJECT PLANNING PROJECT TRACKING & OVERSIGHT SUBCONTRACT MANAGEMENT SOFTWARE QUALITY ASSURANCE SOFTWARE CONFIGURATION MANAGEMENT REQUIREMENTS MANAGEMENT 49 6

Requirement Management and CMM Requirements Management KPA Goals The software requirements are controlled to establish a baseline for software engineering and management use. Software plans, products, and activities are kept consistent with the software requirements

The Requirement Problem The goal of software development is to develop quality software – on time and on budget – that meets customers’ real needs Project success depends on good requirement management Requirement errors are the most common type of software development errors and the most costly to fix

The root causes of project failure Lack of user input is responsible for : 13% of all project failures Incomplete requirements and specifications: 12% of all project failures Changing requirements: 12% of all project failures The Standish Group

European Software Process Improvement Training Institute Survey for Largest Software problems

Requirement Management A systematic approach to eliciting, organizing, and documenting the requirements of the system, and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system.

Requirement Management Establishing and maintaining an agreement with the customer on the requirement for the software project. It involves Defining the requirement baseline Reviewing proposed requirement changes and evaluating the likely impact of each proposed change before deciding whether to approve it Incorporating approved requirement changes in the project in a controlled manner

Requirement Management Keeping project plans current with the requirements Negotiating new commitments based on estimated impact on changed requirements Tracing individual requirements to their corresponding design, source code, and test cases Tracking requirement status and change activity throughout the project

Requirement Attributes Go beyond the description of intended functionality Attributes are used to establish a context and background for each requirement Can be used to filter, sort, or query to view selected subset of the requirements

Attributes Requirement ID Creation date Created by Last modified on Last modified by Version number Status Origin Subsystem Product Release Priority

Requirement Status Proposed The requirement has been requested by a source who has the authority to provide requirements Approved The requirement has been analyzed, its impact on the rest of the project has been estimated, and it has been allocated to the baseline for a specific build number or product release. The software development group has committed to implement the requirement

Continued 3. Implemented The code that implements the requirement has been designed, written, and unit tested

Requirement Status Verified The implemented requirement has been verified through the selected approach, such as testing or inspection. The requirement has been traced to pertinent test cases. The requirement is now considered complete Deleted A planned requirement has been deleted from the baseline. Include an explanation of why and by whom the decision was made to delete the requirement

Change Request Status Originator submits a change request Evaluator performed impact analysis CCB decided not to make the change submitted Evaluated Rejected Change Approved Change was canceled Approved Modifier has made the change and requested for verification Verification failed Canceled Change was canceled Change Made Modifier has installed the product Closed Verifier has confirmed the change Change was canceled Modifier has installed the product Verified

Converge

Managing Scope Creep

Changing Requirements - 1 Requirements will change, no matter what Software organizations and professionals must learn to manage changing requirements A major issue in requirements engineering is the rate at which requirements change once the requirements phase has “officially” ended

Software Engineering II Lecture 36 Fakhar Lodhi

Recap