Requirements Management and Changes Copyright, 2003 © Jerzy R. Nawrocki Requirements.

Slides:



Advertisements
Similar presentations
Planning at CMM level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements Engineering.
Advertisements

The Baseline Personal Process Copyright, 1999 © Jerzy R. Nawrocki Jerzy Nawrocki Personal Software Process Lecture 3.
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
Procedures for CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Sponsored by the U.S. Department of Defense © 2002 by Carnegie Mellon University July 2002 Pittsburgh, PA Lecture 6: Team Planning.
Configuration Management Managing Change. Points to Ponder Which is more important?  stability  progress Why is change potentially dangerous?
RequisitePro (1) Copyright, 2001 © Jerzy R. Nawrocki Quality Management Lecture.
Quality Assurance Copyright, 2002 © Jerzy R. Nawrocki Quality Management Auxiliary.
SE 555 Software Requirements & Specification Requirements Management.
CSC 395 – Software Engineering Lecture 25: SCM –or– Expecting Change From Everything But Vending Machines.
Software Configuration Management (SCM)
Introduction to ISO 9001:2000 Copyright, 2002 © Jerzy R. Nawrocki Quality Management.
Configuration Management
Software Configuration Management
Software Configuration Management (SCM)
CSSE 375 Software Construction and Evolution: Configuration Management
Configuration Management Avoiding Costly Confusion mostly stolen from Chapter 27 of Pressman.
Project Planning Copyright, 2002 © Jerzy R. Nawrocki Quality Management Auxilliary.
The Key Process Areas for Level 2: Repeatable Ralph Covington David Wang.
RequisitePro (2) Copyright, 2001 © Jerzy R. Nawrocki Requirements Engineering.
Rational Suite and CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Requirements specification Copyright, 2001 © Jerzy R. Nawrocki Quality Management.
Configuration Management Copyright, 2002 © Jerzy R. Nawrocki Quality Management.
Copyright © Jerzy R. Nawrocki Requirements Review Requirements Engineering & Project.
Software Configuration Management (SCM)
Soft Tech Development Inc. 1 Software Project Tracking A CMM Level 2 Key Process Area Soft Tech Development Inc.
Quality Model for Requirements Eng. Copyright, 2002 © Jerzy R. Nawrocki Quality.
1 Software Development Configuration management. \ 2 Software Configuration  Items that comprise all information produced as part of the software development.
Standard SRS Copyright, 2001 © Jerzy R. Nawrocki Requirements Engineering Lecture.
Requirements Verification & Validation Requirements Engineering & Project Management.
Creator: ACSession No: 16 Slide No: 1Reviewer: SS CSE300Advanced Software EngineeringFebruary 2006 (Software Quality) Configuration Management CSE300 Advanced.
Good Practices of Requirements Eng. Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Project Planning Copyright, 2002 © Jerzy R. Nawrocki Requirements Engineering.
CMM Level 2: Repeatable Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Quality of Usage Scenarios Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
© Mahindra Satyam 2009 Configuration Management QMS Training.
SOFTWARE CONFIGURATION MANAGEMENT. Change is inevitable when computer software is built. And change increases the level of confusion among software engineers.
Implementing XP at PUT Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Introduction to Requirements Engineering Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Configuration Management and Change Control Change is inevitable! So it has to be planned for and managed.
RequisitePro (1) Copyright, 2001 © Jerzy R. Nawrocki Requirements Engineering.
Introduction to Requirements Eng. Copyright, 2001 © Jerzy R. Nawrocki Requirements.
Configuration Management at CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Quality Model for RE Process Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Software Configuration Management (SCM) Source: Pressman, R., Software Engineering: A Practitioner ’ s Approach. Boston: McGraw Hill, Inc., 2005; Ghezzi,
Change Management Requirements Engineering & Project Management Lecture 10.
Objectives Understand Corrective, Perfective and Preventive maintenance Discuss the general concepts of software configuration management.
1 Chapter 12 Configuration management This chapter is extracted from Sommerville’s slides. Text book chapter 29 1.
DiscussionsDiscussions Copyright, 2001 © Jerzy R. Nawrocki Requirements Engineering.
Introduction to Quality Management Copyright, 2000 © Jerzy R. Nawrocki Quality.
Configuration Management (II) Copyright, 2000 © Jerzy R. Nawrocki Requirements.
~ pertemuan 4 ~ Oleh: Ir. Abdul Hayat, MTI 20-Mar-2009 [Abdul Hayat, [4]Project Integration Management, Semester Genap 2008/2009] 1 PROJECT INTEGRATION.
Quality Assurance at CMM Level 2 Copyright, 2000 © Jerzy R. Nawrocki Requirements.
Software Engineering Lecture 9: Configuration Management.
TMP3413 Software Engineering Lab Lab 01: TSPi Tool Support.
Configuration & Build Management. Why Software Configuration Management ? The problem: Multiple people have to work on software that is changing More.
Software Configuration Management (SCM)
Introduction for the Implementation of Software Configuration Management I thought I knew it all !
Software Configuration Management
Requirements Engineering Lecture 13
Requirements Engineering Lecture 4
Requirements Engineering Lecture 2
Chapter 11: Software Configuration Management
Software Configuration Management
Software Configuration Management
Introduction to PRINCE 2
Baseline – IEEE definition
Chapter 11: Software Configuration Management
Requirements Engineering Lecture 6
Presentation transcript:

Requirements Management and Changes Copyright, 2003 © Jerzy R. Nawrocki Requirements Engineering Lecture 10 Requirements Engineering Lecture 10

J. Nawrocki, Requirements Management.. IntroductionIntroduction SCI = “ Information that is created as part of the software engineering process.” [ R.Pressman ] Types of SCIs: computer programs (source code or exec) documents (also requirem. specification) data (e.g. test cases) Soft. Configuration Item (SCI) if (a > b) a-= b;  18 27

J. Nawrocki, Requirements Management.. IntroductionIntroduction A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. Baseline [IEEE ] SpecificationDesignCodeTest cases

J. Nawrocki, Requirements Management.. Base- line IntroductionIntroduction Baseline or SCI? Engineering Change it! Change control SCI FTR SCI Baseline library Baseline

J. Nawrocki, Requirements Management.. Soft. Configuration Control Board SCCB SCCBSCCB Authorises: the establishment of software baselines, the identification of configuration items, the creation of products from the baseline library. Represents the interests of the project manager and all groups affected by changes to baselines. Reviews and authorises changes.

J. Nawrocki, Requirements Management.. CMM & Change Management Ac5. Change requests & problem reports for all SCIs are initiated, recorded, reviewed, approved, and tracked according to a documented procedure. Remove 2nd floor!

J. Nawrocki, Requirements Management.. CMM & Change Management Change control Change request Err User S.C. Manager Change request Developer Change report SCCB Deci- sion

J. Nawrocki, Requirements Management.. CMM & Change Management Change control Change request Err UserS.C. Manager Change request Developer Change report SCCB Deci- sion Change order P. Manager

J. Nawrocki, Requirements Management.. CMM & Change Management Change request Change request number: Sender: Sender’s Date: Urgency: Importance: Description: Evaluator: Evaluate by: Type (in/external)

J. Nawrocki, Requirements Management.. CMM & Change Management Change report Change request number: Evaluator: Evaluator’s Date: Urgency: Importance: Is the change justifiable? Main risk factors: Possible implementor: Change implement. effort (expect): Change evaluation effort (actual):

J. Nawrocki, Requirements Management.. Overview of RE guidelines The requirements document Requirements elicitation Reqs analysis & negotiation Describing requirements System modelling Requirements validation Requirements management RE for critical systems BasicIntermAdv

J. Nawrocki, Requirements Management.. Basic guidelines Requirements management Uniquely identify each requirement

J. Nawrocki, Requirements Management.. Basic guidelines Requirements management Uniquely identify each requirement Tag

J. Nawrocki, Requirements Management.. Basic guidelines Requirements management Uniquely identify each requirement Define policies for requirements management Requirements Management Policy Goal : Understand the requirements Obligatory practices : 1. Define specialised terms using the template available at

J. Nawrocki, Requirements Management.. Basic guidelines Requirements management Uniquely identify each requirement Define policies for requirements management Define traceability policiesDefine traceability policies

J. Nawrocki, Requirements Management.. Basic guidelines Traceability policy Traceability information Who is responsible Problems Visions Requirements (FURPS) Acceptance test cases User documentation Design Code

J. Nawrocki, Requirements Management.. Basic guidelines Requirements management Uniquely identify each requirement Define policies for requirements management Define traceability policiesDefine traceability policies Maintain a traceability manual

J. Nawrocki, Requirements Management.. Intermediate guidelines Requirements management Use a database to manage requirements Define change management policies Identify global system requirements

J. Nawrocki, Requirements Management.. Advanced guidelines Requirements management Identify volatile requirements Record rejected requirements

J. Nawrocki, Requirements Management.. SummarySummary CMM approach to changes Requirements management practices

J. Nawrocki, Requirements Management.. Quality assessment 1. What is your general impression? (1 - 6) 2. Was it too slow or too fast? 3. What important did you learn during the lecture? 4. What to improve and how?