Streamlined Action Plan Code Review Process Ken Kopatz Software Process Improvement Network (SPIN) Meeting 30 June 2000.

Slides:



Advertisements
Similar presentations
Requirements Specification and Management
Advertisements

A presentation from June 20, 2000 Jim Brosseau The ‘How-To’ of Software Process Improvement.
Business Driven Technology Unit 5 Transforming Organizations Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution.
Formal Technical Reviews
Chapter 15 Design, Coding, and Testing. Copyright © 2005 Pearson Addison-Wesley. All rights reserved Design Document The next step in the Software.
Software Development Process. Process Improvement Using the Shewhart Cycle 1.PLAN - Plan a change aimed at improvement, collect data, and establish a.
CIS 375 Bruce R. Maxim UM-Dearborn
CSE Senior Design II Test Planning Mike O’Dell Based on an earlier presentation by Mike O’Dell, UTA.
Design, Implementation and Maintenance
“80% of software projects fail”  Standish Report (1995) Standish Report 16.2% completed on-time and on-budget with all features and functions as initially.
Software Configuration Management
Release & Deployment ITIL Version 3
Effective Methods for Software and Systems Integration
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
INFO 637Lecture #31 Software Engineering Process II Launching & Strategy INFO 637 Glenn Booker.
Extreme Programming Software Development Written by Sanjay Kumar.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
Module CC3002 Post Implementation Issues Lecture for Week 6 AY 2013 Spring.
1EMC CONFIDENTIAL—INTERNAL USE ONLY Bugs – From Finding to Preventing Jacky Guo.
Galin, SQA from theory to implementation © Pearson Education Limited 2004 Review objectives Formal design reviews (FDRs) Participants Preparations The.
Software Testing Life Cycle
Project Management : Techniques and Tools (60-499) Fall 2014 / Winter 2015.
Software Inspections. Defect Removal Efficiency The number of defects found prior to releasing a product divided by The number of defects found prior.
Performance Improvement. 2 Steps to Performance Improvement 1. Define the Problem 2. Define Duties or Behaviors to be Improved 3. Establish Priorities.
© 2012 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S.
Testing E001 Access to Computing: Programming. 2 Introduction This presentation is designed to show you the importance of testing, and how it is used.
Building Hotel reservation System !!! The Project Life Cycle refers to a logical sequence of activities to accomplish the project’s goals or objectives.
Testing -- Part II. Testing The role of testing is to: w Locate errors that can then be fixed to produce a more reliable product w Design tests that systematically.
Fun, fun, fun. But first … the code review Preparation Process.
John D. McGregor Session 2 Preparing for Requirements V & V
© Mahindra Satyam 2009 Configuration Management QMS Training.
TESTING LEVELS Unit Testing Integration Testing System Testing Acceptance Testing.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Product Documentation Process Infosys Technologies Ltd. Bangalore.
Software Development Problem Analysis and Specification Design Implementation (Coding) Testing, Execution and Debugging Maintenance.
MANUAL TESTING KS SESSION PRESENTED BY 26/11/015 VISHAL KUMAR.
Project management Topic 7 Controls. What is a control? Decision making activities – Planning – Monitor progress – Compare achievement with plan – Detect.
©2007 · Georges Merx and Ronald J. NormanSlide 1 Chapter 9 Software Quality Assurance.
Axios Systems IT Service Management Solutions TM Report and Follow Up Follow-up-makes-the –world- go-round Brian Kerr, Axios Systems.
Requirements Management Overview NIGMS Software Development.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.1.
CSC444F'07Lecture 41 CSC444 Software Engineering Top 10 Practices.
 Software Testing Software Testing  Characteristics of Testable Software Characteristics of Testable Software  A Testing Life Cycle A Testing Life.
Project Management Why do projects fail? Technical Reasons
Mahindra Satyam Confidential Quality Management System Software Defect Prevention.
Software Test Plan Why do you need a test plan? –Provides a road map –Provides a feasibility check of: Resources/Cost Schedule Goal What is a test plan?
REGRESSION TESTING Software Quality Engineering NC Zunaira Tariq Bese 19B Software Quality Engineering NC Zunaira Tariq Bese 19B.
Software Engineering Process - II 7.1 Unit 7: Quality Management Software Engineering Process - II.
 Software reliability is the probability that software will work properly in a specified environment and for a given amount of time. Using the following.
Software Project Configuration Management
CIS 375 Bruce R. Maxim UM-Dearborn
Software and Systems Integration
Quality Assurance: Early Work Items
Manfred Huber Based on an earlier presentation by Mike O’Dell, UTA
Software and System Delivery
Pega 9/14/2018 8:48 AM Definition of Done = ready for PO acceptance
Project Specification
Applied Software Implementation & Testing
Strategies For Software Test Documentation
Test Planning Mike O’Dell (some edits by Vassilis Athitsos)
استراتيجيات تعديل السلوك بين النظرية والتطبيق
Software Engineering: A Practitioner’s Approach, 6/e Chapter 2 Process: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Software Verification, Validation, and Acceptance Testing
QA Reviews Lecture # 6.
Software Development In Agile
Software Reviews.
3. Software Quality Management
Presentation transcript:

Streamlined Action Plan Code Review Process Ken Kopatz Software Process Improvement Network (SPIN) Meeting 30 June 2000

Overall Objective n Bugs are being introduced by overlooking of consequences of minor code changes.

Desired Results (Accomplish) n Catch coding errors which may be introduced during code modifications and additions causing regression problems n Catch coding errors which result in unanticipated related behavior n Catch coding errors before System Test

Desired Results (Change) n Implement Peer Reviews of code modifications/additions

Desired Results (Done) n All code is reviewed before being checked into CM for the next release

People n Each of the developers will be impacted u Additional workload in having to review others’ code u Additional workload in preparing code for review u Time freed by not having to respond to errors occurring in the field u Cost and schedule savings in not putting out fires u Perception of more work to do in the same time u Perception of shortened work schedule if not managed properly

People (ctnd) n Software project manager will be affected u Additional workload in reviewing code u Additional coordination ensuring reviews are done u Additional meetings u Release dates will be met u Fire fighting will be reduced

People (ctnd) n Senior managers u Not have to deal with customer complaints u Customer satisfaction will increase u Release schedules will be met with fewer interruptions and shortened System Test schedule

Change Factors n Concern: Additional workload u Extra time will be built into schedule to account for review time u Additional time should be realized from not having to fix problems u Current practice of reviewing Requirements Specs and Functional Design catch problems early and reduce rework

Change Factors (ctnd) n Concern: Personal criticism u Coding standards will establish an objective criteria for review u Current spec reviews are not personal

Change Factors (ctnd) n Concern: What standards should be followed u Coding standard will be written and agreed to u Checklists will provide simple validation for coder as well as reviewer

Change Factors (ctnd) n Concern: Creativity will be stifled u Standards will provide the framework for creativity u Creativity will be in the problem solving

Scope Boundaries n Reviews are limited to all new code and modifications to existing code n Existing code will not be reviewed n Code will be reviewed for style consistent with the existing code n Code will be reviewed for logical errors n Reviewers will consist of the project team

Deliverables

Actions

Actions (ctnd)