2006 CMBG Conference Mike Stout Spescom Software, Inc. Configuration Management For The Next Generation.

Slides:



Advertisements
Similar presentations
Configuration Management
Advertisements

CSC271 Database Systems Lecture # 18. Summary: Previous Lecture  Transactions  Authorization  Authorization identifier, ownership, privileges  GRANT/REVOKE.
NRC Perspective of Recent Configuration Management Issues Tom Farnholtz Chief, Engineering Branch 1 Division of Reactor Safety, Region IV June 2014 CMBG.
Software life cycle processes Purpose n A new international standard (ISO/IEC 12207:1995(E) that –establishes a common framework for software life cycle.
© 2010 Cengage Learning. Atomic Dog is a trademark used herein under license. All rights reserved. Chapter 4 Analyzing Jobs.
Computer Security: Principles and Practice
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development.
1 PMIG PUBLIC SECTOR PROCUREMENT BEST PRACTICES & LESSONS LEARNED Kevin James Barrie Kroukamp.
Basics of Good Documentation Document Control Systems
“Here’s why you need the new wheels, too…” Shawn and Steve Image from
Predicting Competitors’ Actions.
S/W Project Management
INFO 637Lecture #81 Software Engineering Process II Integration and System Testing INFO 637 Glenn Booker.
Commissioning of Fire Protection and Life Safety Systems Presented by: Charles Kilfoil Bechtel National Waste Treatment Plant Richland WA.
S oftware Q uality A ssurance Part One Reviews and Inspections.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Configuration Management Benchmarking Group Conference June 6 – 9, 2004 Kansas City, MO © 2004 CMBG Configuration Management Fundamentals including Margin.
Business Justification California Department of Social Services
Document Control Basics of Good Documentation and
SOFTWARE ENGINEERING1 Introduction. Software Software (IEEE): collection of programs, procedures, rules, and associated documentation and data SOFTWARE.
Software Maintenance.
2007 CMBG Conference David Hembree Institute of Nuclear Power Operations June 20, 2007 Charleston, SC INPO Perspective on Configuration Management.
Identify steps for understanding and solving the
Product Development Chapter 6. Definitions needed: Verification: The process of evaluating compliance to regulations, standards, or specifications.
Project Life cycles BTEC National.
IT Requirements Management Balancing Needs and Expectations.
2006 CMBG Conference Sam Melton Supervisor, Configuration Management Brunswick Nuclear Plant Progress Energy June 11-14, 2006 Richmond, VA CM04 Facility.
Rapid software development 1. Topics covered Agile methods Extreme programming Rapid application development Software prototyping 2.
Configuration Management Benchmarking Group Conference June 6 – 9, 2004 Kansas City, MO © 2004 CMBG Characteristics of a Good Calculation Program Presented.
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem.
Creating documentation and metadata: Recording provenance and context Jeff Arnfield National Climatic Data Center Version a1.0 Review Date.
ISO 9001 – an overview Tor Stålhane IDI / NTNU. ISO 9001 and software development ISO 9001 is a general standard – equally applicable to software development.
SOFTWARE ENGINEERING Chapter 1. Introduction We can’t run the modern world without software. Why? Discussion….
Systems Life Cycle A2 Module Heathcote Ch.38.
PAGE 1 New Plant - CM Configuration Management For The Next Generation Of Nuclear Facilities Joseph Burack Consulting Engineer Configuration Management.
Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun.
The Traditional System Development Life Cycle There are a number of important steps in the creation of a system, regardless of which approach you use.
Configuration Management of Post-Fukushima Regulations CMBG June 2013 David Gambrell Director, Severe Accident Management Southern Nuclear.
1 EE29B Feisal Mohammed EE29B: Introduction to Software Engineering Feisal Mohammed Ph: x3156.
Capturing the requirements  Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the.
Getting your specifications Right! Florence Gregg figpc ltd E:
OHTO -01 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it.
Configuration Management Fundamentals including Margin Management Bill Kline FirstEnergy Nuclear Operating Company (FENOC) June 2, 2008 Shell Beach, CA.
Requirements / Specifications. 01/18/10CS-499G2 Requirements Determine what the customer needs (wants) the software to do  What are requirements?  An.
MNP1163 (Software Construction).  SDLC and Construction Models  Construction Planning  Construction Measurement.
2006 CMBG Conference Keith A. Reinsmith PPL Susquehanna 2006 CMBG Conference June 11-14, 2006 Richmond, VA Configuration Management Awareness Training.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
CM Tools Data Management Trends Wednesday, June 4, 2008 Laurent Perkins Enterprise Informatics.
Objectives Understand Corrective, Perfective and Preventive maintenance Discuss the general concepts of software configuration management.
2006 CMBG Conference BREAKOUT 6: Master Equipment List & Data Base Management Facilitator: Tom Czerniewski Entergy June 11-14, 2006 Richmond, VA.
Requirements Engineering Requirements Validation and Management Lecture-24.
Project Management Strategies Hidden in the CMMI Rick Hefner, Northrop Grumman CMMI Technology Conference & User Group November.
Usability Engineering Dr. Dania Bilal IS 582 Spring 2007.
Project Management Enabling Quality Marien de Wilde, PMP April 2007.
Toward a New ATM Software Safety Assessment Methodology dott. Francesca Matarese.
 System Requirement Specification and System Planning.
Introduction for the Implementation of Software Configuration Management I thought I knew it all !
Configuration Management
OH&S Plant Obligations make
Outsourcing Modifications To Contractors
Configuration Management
The Systems Engineering Context
Development Projects / Analysis Projects / On-site Service Projects
Software Requirements
Reducing Managed Facility Configuration Information
SNC/SCANA – New Build Configuration Management
Jim Powers - Director, Fleet Engineering
Configuration Management AP-929, Revision 1 Mike Stout Chairman CMBG Steering Committee April 9, 2019 Cleveland 2005.
BREAKOUT 8: CM and The Next Generation of Plants
Presentation transcript:

2006 CMBG Conference Mike Stout Spescom Software, Inc. Configuration Management For The Next Generation

2006 CMBG Conference Agenda Purpose: Generate Discussion –Some issues we face today –Some of the causes –Some potential solutions –Discussion

2006 CMBG Conference Some of Today’s CM Issues Design Basis Information –Not captured by Architect/Engineer –Recovery by A/E manpower intensive and expensive –Tribal knowledge at A/E and tribe now gone –Some conflicts with License Basis information –Margin difficult to identify Information intended to convey ‘design’ to constructor is often not adequate in detail and/or format for operations and maintenance. Drawings –Too many to maintain with available resources –Large numbers of unincorporated changes –Many drawings not verified or validated –Differing levels of user training causes demand for multiple drawings with essentially the same information. –No drawings that were intended to support Plant Operations –How to tell which information is a ‘design requirement’ and which is intended simply to be ‘helpful’.

2006 CMBG Conference More of Today’s CM Issues Master Equipment List –Data from A/E not validated or collected under QA program controls –Data incomplete –Poor understanding of data quality vs. allowable use –No simple way to get errors/omissions corrected –Engineering ‘owns’ it, Maintenance/construction ignores need to provide updates. Failure to understand or appreciate the difference between controlling containers for information (eg; documents) and controlling the content (eg; the information). ‘Cool’ technology with no commitment to update the information, combined with lack of clarity on allowed or intended use of the information. –Plant video tours an example…if not updated when modifications are done, usually advertised as ‘for information only’. Meaning, for any safety related work, must verify (walkdowns). Why spend the money for the technology if walkdowns are still required? Terminology- ie; controlled vs. configuration controlled

2006 CMBG Conference Some Probable Causes A/E’s focused on ‘design-build-get paid’ Lack of Operations/Maintenance input in design/build contracts Focus on compliance with regulations over efficient operation Regulations don’t address quality of information or use Regulation requires “Records Management” but don’t address quality of information in use for operation, maintenance and modification.

2006 CMBG Conference Some Potential Solutions Pay the A/E to capture and deliver information for operations –Put it in the contract! –Don’t get stuck using the A/E’s information system ($$$$$) Require delivery in the format/system you intend to use Better yet, require A/E to use your format/system- no data conversion! –Ensure Ops/Maintenance get input here as well as Engineering Minimize the volume of information delivered Plan ahead for training operations, maintenance to use the information format to be provided Plan for operations and maintenance involvement in validating the information received Ensure you will be managing content, not just containers.