Requirements and Estimation Process From a CMM Level 5 Organization Alan Prosser.

Slides:



Advertisements
Similar presentations
INTRODUCTION 1. Business systems and QA Department business systems 2. All the bug reports and all the bug tracking systems are very similar.
Advertisements

Configuration Management Main issues:  manage items during software life cycle  usually supported by powerful tools.
Sponsored by the U.S. Department of Defense © 2002 by Carnegie Mellon University July 2002 Pittsburgh, PA Lecture 6: Team Planning.
The System Development Life Cycle
Software Delivery. Software Delivery Management  Managing Requirements and Changes  Managing Resources  Managing Configuration  Managing Defects 
Project Management.
CS 5521 Configuration Management the problem Not a simple task! –Different versions of software usually is in the field during the life cycle –Different.
SE 555 Software Requirements & Specification Requirements Management.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
CSC 395 – Software Engineering Lecture 25: SCM –or– Expecting Change From Everything But Vending Machines.
Validating and Improving Test-Case Effectiveness Author: Yuri Chernak Presenter: Lam, Man Tat.
Course Technology Chapter 3: Project Integration Management.
CSE Senior Design II Test Planning Mike O’Dell Based on an earlier presentation by Mike O’Dell, UTA.
Software Configuration Management
Software Configuration Management
CSSE 375 Software Construction and Evolution: Configuration Management
CSCI ClearQuest 1 Rational ClearQuest Michel Izygon - Jim Helm.
Copyright 2002 Prentice-Hall, Inc. Managing the Information Systems Project 3.1 Chapter 3.
Systems Analysis and Design in a Changing World, 6th Edition
1 Building and Maintaining Information Systems. 2 Opening Case: Yahoo! Store Allows small businesses to create their own online store – No programming.
Software Testing Lifecycle Practice
Seattle Area Software Quality Assurance Group Release and Configuration Management, The Acceleration of Change and Its Contribution To Software Quality.
Software Configuration Management
SIUE Injury Tracking System Project Plan. Team Members: Robbie Marsh Robbie Marsh –Project Manager/Webmaster Ken Metcalf Ken Metcalf –Lead Programmer.
Conditions and Terms of Use
SERVICE MANAGER 9.2 CHANGE PRESENTATION JUNE 2011.
Project Tracking. Questions... Why should we track a project that is underway? What aspects of a project need tracking?
Software Development Process and Management (or how to be officious and unpopular)
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
CMM Level 2: Repeatable Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Team Skill 6: Building the Right System Managing Change (28)
INFO 637Lecture #101 Software Engineering Process II Review INFO 637 Glenn Booker.
Applied Software Project Management
QUALITY ASSURANCE PRACTICES. Quality Plan Prepared and approved at the beginning of project Soft filing system approach followed. Filing location – –
INFO 424 Team Project Practicum Week 2 - Launch report, Project tracking, Review report Glenn Booker Notes largely from Prof. Hislop.
Configuration Management and Change Control Change is inevitable! So it has to be planned for and managed.
Software Configuration Management (SCM). Product Developer Disciplines One view of the world is that there are three types of activities are required.
CPSC 871 John D. McGregor Change management Module 2 Session 3.
Configuration Management Main issues:  manage items during software life cycle  usually supported by powerful tools ©2008 John Wiley & Sons Ltd.
Information Systems System Analysis 421 Chapter 3 Managing the Information Systems Project.
Project Management. Introduction  Project management process goes alongside the system development process Process management process made up of three.
Degree and Graduation Seminar Integration Management
Timesheet training Version: Introduction Duration: 1.5 hours Purpose: Guide on how to use Timesheet.
~ pertemuan 4 ~ Oleh: Ir. Abdul Hayat, MTI 20-Mar-2009 [Abdul Hayat, [4]Project Integration Management, Semester Genap 2008/2009] 1 PROJECT INTEGRATION.
T Project Review Muuntaja I1 Iteration
Copyright © 2007, Oracle. All rights reserved. Using Change Management.
Waste Management Inspection Tracking System (WMITS)
TMP3413 Software Engineering Lab Lab 01: TSPi Tool Support.
Chapter 7: Delivery, Installation, and Documentation Ronald J. Leach Copyright Ronald J. Leach, 1997, 2009, 2014,
Configuration Control (Aliases: change control, change management )
Software Engineering Process - II 7.1 Unit 7: Quality Management Software Engineering Process - II.
Configuration & Build Management. Why Software Configuration Management ? The problem: Multiple people have to work on software that is changing More.
Chapter 25 – Configuration Management 1Chapter 25 Configuration management.
The System Development Life Cycle
Software Project Configuration Management
Chapter 10, Software Configuration Management
Essentials of UrbanCode Deploy v6.1 QQ147
Software Configuration Management
Configuration Management Why do we need it? What does it do?
Manfred Huber Based on an earlier presentation by Mike O’Dell, UTA
د. حنان الداقيز خريف /28/2016 Software Quality Assurance ضمان جودة البرمجيات ITSE421 5 – The components of the SQA.
Sponsored by the RMS Center
The System Development Life Cycle
The Features of a Product or System
Test Planning Mike O’Dell (some edits by Vassilis Athitsos)
Course: Module: Lesson # & Name Instructional Material 1 of 32 Lesson Delivery Mode: Lesson Duration: Document Name: 1. Professional Diploma in ERP Systems.
OWASP Application Security Verification Standard
Software Testing Lifecycle Practice
Presentation transcript:

Requirements and Estimation Process From a CMM Level 5 Organization Alan Prosser

Requirements and Estimation  This is a sample process for requirements and cost estimation process from a CMM level 5 organization. The organization was for a government contract, the software for the Space Shuttle Onboard computers (OBS stands for On Board Software). The contract has been through several companies, (IBM Federal Systems, Loral Space Systems, Lockheed Martin Space Information Systems and by now United Space Alliance).

Requirements and Estimation  There were 5 different CCBs and processes for software with 5-6 different risk levels and for changes vs. fixes. What I describe here is a high level view of the requirements change process to the 2-3 higher risk levels. (Level 2-3 use the same process from this view). –1 - Flight software - life and property depend on it –2 - Critical tools - affect 1s and 0s of FSW –3 - Non-critical, deliverable tools –4 - Organization use - used by organization but not customer –5 - Department use - helpful, but not a wide number of users –6 - Individual use tools - automation of personal, manual tasks

Requirements and Estimation  Basic Steps –Change Request (CR) goes to CCB –Functional Areas fill out PASS 1 –Back to CCB for PASS 1 (Requirements) approval –Functional Areas for Development and Verification fill out PASS 2 (Estimates) –Approval and schedule to a release by CCB

Requirements and Estimation  Change Request (CR) goes to CCB  Someone, either external (NASA) or internal, writes a CR, which is high level, mentions some kind of justification, what applications are affected, need date, etc. This document goes to the CCB, where it gets assigned a number and is entered into the Configuration Management Database (CMDB).  The CCB passes a copy the request on to each functional area affected. There are representatives of all functional areas at the CCB, some individuals represent several areas.  If anyone notices that a functional area is missing, it will be added.  Most team members at least get the CCB agendas for this purpose.

Requirements and Estimation  Functional Areas fill out PASS 1  A requirements analyst (RA) responsible for the area looks at the CR to see if a change of the baselined requirements are needed. If requirements will need to be changed, a cost and date estimate for the requirements change is required. An online form is filled out (PASS 1 Requirements) The form also has a place to reject the request.  A developer for the functional area looks at the CR and fills out a form to indicate that the change is small, medium, or large, if changes to requirements are needed, and suggests a release that may be possible or rejects the change with reasons. There is a form for development too (PASS 1 Development)

Requirements and Estimation  To CCB for PASS 1 (Requirements) approval –The forms automatically show up on the CCB agenda, and if they all say approve for writing requirements, the requirements cycle starts for each functional area. –Requirements cycle(s) until team agrees, then CCB can give PASS 1 approval Note that CRs that also affect FSW will also go through a similar CCB process there as well.

Requirements and Estimation  Requirements Cycle  The RA does investigation and writes a version of the requirements. The RA may look at any documentation, have interviews, brainstorming sessions, etc.  An internal review of the requirements is scheduled. There are representatives for verification and development and a backup RA, and a neutral (from other functional area) moderator. All major and minor errors are logged  When the team has approved the requirements, it goes to the CCB and customer (there is a customer rep at CCB). Any of them could point out changes needed, sending back to begin this cycle. Large changes have multiple cycles and may take months to write.

Requirements and Estimation  Functional Areas for Development and Verification fill out PASS 2 (Estimates) –Developers fill out estimates (Development PASS 2) –Verifiers fill out estimates (Verification PASS 2)

Requirements and Estimation  Developers fill out estimates (Development PASS 2) –A developer generates an initial list of components (modules, includes, etc) to change, enters a PASS 2 Development form with cost and schedule estimates. –Cost estimates are in Lines of Code and schedules are to particular releases.

Requirements and Estimation  Verifiers fill out estimates (Verification PASS 2) –A verifier (often the same person as RA and user) plans when in the development cycle they can do their testing, with an estimate of cost. A PASS 2 Verification form is filled out.

Requirements and Estimation  Approval and schedule to a release by CCB –After all PASS 2 forms and requirements are approved by the CCB, work can start on design and code.

Requirements and Estimation What is the result? –We have detailed requirements that have been reviewed or are at least visible to everyone. –We have a good chance that all affected areas are identified. –We have a fair estimate of the size of change and for small changes may know CIs. –We have a schedule agreed to by all. –We know when independent testing will be done with an estimate of cost.

Q & A

References  Fast Company wrote an article about culture and process improvement philosophy of the organization in issue 6, 12/1996-1/ “They Write the Right Stuff”  has a summary of the work Al did in the Space program