Index
A
- acceptance environment
- Agile/Scrum methodology, How to Apply the Best Practice
- assumptions, about metrics, Make Assumptions about Your Metrics Explicit-Using Norms with the GQM Approach
- automated builds, Requirement: Automated Builds
- automated deployment, Automate Deployment-Metrics Overview
- automated testing, Automate Tests-Metrics Overview
- assumptions about metrics, Assumptions Regarding These Metrics
- best practice application, How to Apply the Best Practice-How to Apply the Best Practice
- CI and, Use Continuous Integration, Requirement: Automated Tests
- common objections to metrics, Common Objections to Test Automation Metrics
- field experience, Metrics Overview
- for detecting root causes of bugs, Automated Testing Finds Root Causes of Bugs Earlier with Little Effort
- managing in practice, Managing Test Automation in Practice-Assumptions Regarding These Metrics
- measuring benefits of, Managing Test Automation in Practice
- measuring development effort for, Managing Test Automation in Practice
- metrics overview, Metrics Overview
- motivation for, Motivation
- optimal amount of, Managing Test Automation in Practice
- unit tests for code that already works, Objection: Why Invest Effort in Writing Unit Tests for Code That Is Already Working?
- when failed tests have no noticeable effects in production, Objection: Failing Tests Have No Noticeable Effects
- automation, CI as facilitator of, CI Facilitates Further Automation
- automobile industry, Introduction
- averages, outliers vs., Assumption: Averages are more important than outliers
B
- baseline, Measuring the DTAP Street in Practice
- best practices
- automated deployment, How to Apply the Best Practice
- automated testing, How to Apply the Best Practice-How to Apply the Best Practice
- CI, How to Apply the Best Practice
- controlled DTAP, How to Apply the Best Practice
- development standards, Development Standards Help Enforce Best Practices, How to Apply the Best Practice-Code Quality Control
- DoD, How to Apply the Best Practice-How to Apply the Best Practice
- for documentation, How to Apply the Best Practice
- GQM approach, How to Apply the Best Practice-Metric
- implementing one practice at a time, One Practice at a Time
- metric pitfalls and, Avoid the Metric Pitfalls
- overview of, An Overview of the Development Best Practices in This Book
- persistence in application of, Applying the Best Practices Requires Persistence
- third-party code, How to Apply the Best Practice-Manage the Usage and Versions of Libraries and Frameworks Centrally
- version control systems, How to Apply the Best Practice-Integrate Your Code Regularly
- black-box tests, Automate Tests
- branches, long-lived, Integrate Your Code Regularly
- branching, Important Best Practices for CI
- broken windows effect, The Contribution of Each Developer Matters
- bugs, testing for (see automated testing)
- builds
- burndown chart, Make Definition of Done Explicit
C
- car industry, Introduction
- changes, tracking, Tracking Changes
- CI (see Continuous Integration)
- classification, scaling of, Assumption: Measurements are comparable
- code integration, regularity of, Integrate Your Code Regularly
- code quality control, Code Quality Control, Metrics Overview
- code, testable, Automated Testing Reduces the Number of Bugs
- codebase, estimating weak spots in, Managing Test Automation in Practice
- coding style, Coding Style
- commit messages, version control systems and, Objection: Measuring the Recommendations Is Unfeasible (for Example, Whether Commits Are Specific)
- commits
- consistency, development standards and, Development Standards Lead to Predictable Software Development
- continuous delivery, CI Facilitates Further Automation
- Continuous Integration (CI), Use Continuous Integration-Metrics Overview
- control
- controlled DTAP, Control Development, Test, Acceptance, and Production Environments-Metrics Overview
- best practice application, How to Apply the Best Practice
- common objections to metrics, Common Objections to DTAP Control Metrics
- development bottleneck discovery with, Controlled DTAP Reveals Development Bottlenecks and Explains Problems More Easily
- field experience, Metrics Overview
- GQM model for measuring in practice, Measuring the DTAP Street in Practice-Measuring the DTAP Street in Practice
- lead time predictions and, Controlled DTAP Allows for Good Predictions
- metrics overview, Metrics Overview
- motivation for, Motivation
- reduction of dependence on specialist knowledge, Controlled DTAP Reduces Dependence on Key Personnel
- separation of concerns between development phases, Controlled DTAP Clarifies Responsibilities Between Development Phases
- speed of DTAP street, Objection: A Controlled DTAP Street Is Slow
- test/acceptance environment separation, Objection: There Is No Need to Distinguish Test and Acceptance Environments
- convention over configuration principle, Coding Style
- cost, automated deployment and, Objection: Automating Deployment Is Too Costly
- coverage, by good tests, How to Apply the Best Practice
- craft, Introduction
D
- decision-making, metrics and, Common Objections to GQM
- Definition of Done (DoD), Objection: DoD Makes the Team Feel Less Responsible
- Agile/Scrum background for, Make Definition of Done Explicit
- best practice application, How to Apply the Best Practice-How to Apply the Best Practice
- common objections to using, Common Objections to Using Definition of Done-Objection: Changing the DoD May Mean Extra Work
- elements of, How to Apply the Best Practice
- extra work with, Objection: Changing the DoD May Mean Extra Work
- field experience with, Objection: Changing the DoD May Mean Extra Work
- making explicit, Make Definition of Done Explicit-Objection: Changing the DoD May Mean Extra Work
- motivation for using, Motivation
- overhead and, Objection: DoD Is Too Much Overhead
- proving success with, With a DoD You Can Track Progress and Prove Success
- software quality assurance, A DoD Focuses on Software Quality
- team responsibility and, Objection: DoD Makes the Team Feel Less Responsible
- technical maintenance and, Objection: With DoD There Is No Room for Technical Maintenance
- tracking progress with, With a DoD You Can Track Progress and Prove Success
- DeMarco, Tom, Preface
- dependency management
- deployment issues, Objection: Time Spent on Fixing Deployment Issues Is Increasing
- deployment, automated (see automated deployment)
- derived metrics, Metric
- design decisions
- developers, importance of contributions, The Contribution of Each Developer Matters
- development best practices (see best practices)
- development bottlenecks, Controlled DTAP Reveals Development Bottlenecks and Explains Problems More Easily
- development capacity, test capacity balance with, Measuring the DTAP Street in Practice
- development environment
- Development Process Assessment (DPA), Measuring and Benchmarking Development Process Maturity
- development standards, Standardize the Development Environment-Metrics Overview
- best practice application, How to Apply the Best Practice-Code Quality Control
- best practices enforced by, Development Standards Help Enforce Best Practices
- choosing combinations of technologies, Considerations for Combinations of Technologies
- code quality control, Code Quality Control
- coding style, Coding Style
- common objections to, Common Objections to Standardization
- controlling using GQM, Controlling Standards Using GQM-Controlling Standards Using GQM
- defining process standards, Defining Process Standards
- developers' opinion inventory, Controlling Standards Using GQM
- discussion overhead and, Development Standards Decrease Discussion Overhead
- documentation and, Standardize Tooling and Technologies—and Document It
- field experience, Metrics Overview
- metrics overview, Metrics Overview
- motivation for, Motivation
- on multiple technologies, Objection: Can You Standardize on Multiple Technologies?
- organizational fit, Objection: Organization Unfit for Standardization
- predictability and, Development Standards Lead to Predictable Software Development
- simplification of process/code, Development Standards Simplify Both the Development Process and Code
- standardization of tooling/technologies, Standardize Tooling and Technologies—and Document It
- violations and, Objection: We Cannot Work Like This!
- Development, Test, Acceptance, and Production (DTAP)
- controlled (see controlled DTAP)
- controlled vs. uncontrolled, Motivation
- Dijkstra, Edsger, Control Development, Test, Acceptance, and Production Environments
- direct metrics, Metric
- distributed version control, Control Code Versions and Development Branches
- documentation, Document Just Enough-Metrics Overview
- best practice application, How to Apply the Best Practice
- common objections to, Common Objections to Documentation
- discussion minimization, Documentation Retains Knowledge and Helps to Avoid Discussion
- field experience, Metrics Overview
- goal assessment and, Documentation Helps You to Know Whether You Are Reaching Your Goals
- keeping current, concise, accessible, Keep Documentation Current, Concise, and Accessible
- knowledge retention, Documentation Retains Knowledge and Helps to Avoid Discussion
- level of detail for, Keep Documentation Current, Concise, and Accessible, Metrics Overview
- maintenance burden of, Managing Your Documentation
- managing, Managing Your Documentation-Managing Your Documentation
- metrics overview, Metrics Overview
- motivation for, Motivation
- required elements, Required Elements of System Documentation
- scattered knowledge about system and, Objection: Knowledge about System Is Scattered
- team disagreements on, Objection: Disagreement in the Team
- testing and, Automated Testing Reduces the Number of Bugs
- time limitations, Objection: No Time to Write Documentation
- DoD (see Definition of Done)
- DPA (Development Process Assessment), Measuring and Benchmarking Development Process Maturity
- DTAP (Development, Test, Acceptance, and Production)
- controlled (see controlled DTAP)
- controlled vs. uncontrolled, Motivation
G
- generated code, version control and, Control Code Versions and Development Branches
- Git, Control Code Versions and Development Branches
- goal assessment, documentation as means of, Documentation Helps You to Know Whether You Are Reaching Your Goals
- Goal-Question-Metric (GQM) approach, The Goal-Question-Metric Approach
- as means of choosing metrics, Software Development as an Observable Process
- automated deployment, Measuring the Deployment Process-Measuring the Deployment Process
- automated testing, Managing Test Automation in Practice-Assumptions Regarding These Metrics
- best practice application with, How to Apply the Best Practice-Metric
- common objections to, Common Objections to GQM
- controlling development standards with, Controlling Standards Using GQM-Controlling Standards Using GQM
- deriving metrics from measurement goals, Derive Metrics from Your Measurement Goals-Objection: Yes, Good Metric, but We Cannot Measure This
- documentation management, Managing Your Documentation
- for measuring DTAP street in practice, Measuring the DTAP Street in Practice-Measuring the DTAP Street in Practice
- for third-party code dependency management, Measuring Your Dependency Management-Measuring Your Dependency Management
- goal definition with, Goal
- making assumptions about metrics explicit, Make Assumptions about Your Metrics Explicit-Using Norms with the GQM Approach
- metrics in, Metric
- motivation for using, Motivation
- questions in, Question
- using norms with, Using Norms with the GQM Approach
- version control and, Control Code Versions and Development Branches-Metrics Overview
- version control systems, Controlling Versions in Practice-Controlling Versions in Practice
- goals
- GQM approach (see Goal-Question-Metric approach)
M
- maintenance
- manual merging, CI vs., CI Is More Reliable Than Manual Merging
- maturity of team, Objection: Changing the DoD May Mean Extra Work
- McCabe complexity, Metric
- measured observations, Software Development as an Observable Process
- measurement, Software Development as an Observable Process
- Mercurial, Control Code Versions and Development Branches
- merging
- metric in a bubble, Motivation
- metric pitfalls, Motivation, Avoid the Metric Pitfalls
- metrics
- assumptions about, Make Assumptions about Your Metrics Explicit-Using Norms with the GQM Approach
- averages vs. outliers, Assumption: Averages are more important than outliers
- common objections to/solutions for, Objection: Yes, Good Metric, but We Cannot Measure This
- common pitfalls in selecting/applying, Motivation
- comparable meanings of, Assumption: Measurements are comparable
- decision-making and, Common Objections to GQM
- deriving from measurement goals, Derive Metrics from Your Measurement Goals-Objection: Yes, Good Metric, but We Cannot Measure This
- (see also Goal-Question-Metric approach)
- finding explanations for deviations from expectations, Find Explanations Instead of Judgments When Metrics Deviate from Expectations
- trends vs. facts, Assumption: Trends are more important than precise facts
- metrics galore, Motivation
- mocking, How to Apply the Best Practice
- modification, independent, Version Control Allows Independent Modification
- Mozi, Standardize the Development Environment
P
- Pascal, Blaise, Document Just Enough
- patching policies, Metrics Overview
- permission, for deployment, Objection: We Are Not Allowed to Deploy in Production By Ourselves
- personnel, key
- perverse incentives, Avoid the Metric Pitfalls
- planning, Agile, Make Definition of Done Explicit
- portability, automated deployment and, Automated Deployment Is Flexible
- precision, trends vs., Assumption: Trends are more important than precise facts
- predictability
- predictions, lead time, Controlled DTAP Allows for Good Predictions
- process control
- process frameworks, What This Book Is Not
- process standards, Defining Process Standards
- product (inherent) quality, Software Product Quality in ISO 25010
- Product owner, Make Definition of Done Explicit
- production environment
- productivity, functionality implemented as measure of, Controlling Versions in Practice
- progress, tracking with DoD, With a DoD You Can Track Progress and Prove Success
S
- sanity tests, How to Apply the Best Practice
- (see also end-to-end tests)
- scaling of classification, Assumption: Measurements are comparable
- scope, DoD and, How to Apply the Best Practice
- Scrum, Make Definition of Done Explicit
- (see also Agile/Scrum methodology)
- short iterations, Make Definition of Done Explicit
- SIG (Software Improvement Group), About the Software Improvement Group (SIG)
- single platform deployment, Objection: Single Platform Deployment Does Not Need Automation
- SMART nonfunctional requirements, Objection: Changing the DoD May Mean Extra Work
- SMART test criteria, Metrics Overview
- smoke tests, How to Apply the Best Practice
- (see also end-to-end tests)
- software development
- Software Improvement Group (SIG), About the Software Improvement Group (SIG)
- software quality, A DoD Focuses on Software Quality
- source code, independent modification of, Version Control Allows Independent Modification
- source files, merging of, Version Control Allows Automatic Merging of Versions
- specialist knowledge
- sprint planning, Make Definition of Done Explicit
- stakeholder, Make Definition of Done Explicit
- standardization
- static code analysis, Code Quality Control
- story point, Make Definition of Done Explicit
- stubbing, How to Apply the Best Practice
- style checkers, Coding Style
- style of coding, Coding Style
- subjective (experienced) quality, Software Product Quality in ISO 25010
- subjective metrics, Metric
- Subversion, Control Code Versions and Development Branches
- success, proving with DoD, With a DoD You Can Track Progress and Prove Success
T
- TDD (Test Driven Development), Automated Testing Reduces the Number of Bugs
- team maturity, Objection: Changing the DoD May Mean Extra Work
- technical maintenance, Objection: With DoD There Is No Room for Technical Maintenance
- technology choices, documentation of, Keep Documentation Current, Concise, and Accessible
- test capacity, development capacity and, Measuring the DTAP Street in Practice
- Test Driven Development (TDD), Automated Testing Reduces the Number of Bugs
- test environment
- test failures, How to Apply the Best Practice
- test maintenance, How to Apply the Best Practice
- testing approach
- third-party code
- base-level quality of, Third-Party Code Has at Least Base-Level Quality
- best practice application, How to Apply the Best Practice-Manage the Usage and Versions of Libraries and Frameworks Centrally
- central repository for, Manage the Usage and Versions of Libraries and Frameworks Centrally
- change of library source code by developers, Do Not Let Developers Change Library Source Code
- common objections to metrics, Common Objections to Third-Party Code Metrics
- dependency management measurement, Measuring Your Dependency Management-Measuring Your Dependency Management
- dependency updates, Ensure Quick Response to Dependency Updates
- determining maintainability advantages of, Determine the Specific Maintainability Advantages of Using an External Codebase
- field experience, Metrics Overview
- maintenance benefit determination, Objection: Does Third-Party Code Actually Lead to Maintenance Benefits?
- management of usage, Manage Usage of Third-Party Code-Metrics Overview
- metrics overview, Metrics Overview
- motivation for using, Motivation-Managing Usage of Third-Party Code Makes a System’s Behavior More Predictable
- predictability of system behavior, Managing Usage of Third-Party Code Makes a System’s Behavior More Predictable
- safety/dependability, Objection: Safety and Dependability of Third-Party Libraries
- time/effort savings with, Using Third-Party Code Saves Time and Effort
- update management, Keep Third-Party Code Up-to-Date
- update problems, Objection: We Cannot Update a Particular Library
- tooling
- treating the metric, Motivation, Controlling Versions in Practice
- treemap report, Managing Test Automation in Practice
- trends, precise numbers vs., Assumption: Trends are more important than precise facts
V
- velocity, of a development team, Make Definition of Done Explicit
- version control systems
- automatic merging, Version Control Allows Automatic Merging of Versions
- basics, Control Code Versions and Development Branches
- best practice application, How to Apply the Best Practice-Integrate Your Code Regularly
- CI and, Requirement: Version Control
- code integration and, Integrate Your Code Regularly
- commit messages and, Objection: Measuring the Recommendations Is Unfeasible (for Example, Whether Commits Are Specific)
- commits and, Commit Specifically and Regularly
- common objects to metrics for, Common Objections to Version Control Metrics
- field experience, Metrics Overview
- GQM and, Control Code Versions and Development Branches-Metrics Overview
- in practice, Controlling Versions in Practice-Controlling Versions in Practice
- inconsistent use of, Objection: We Use Different Version Control Systems
- metrics overview, Metrics Overview
- motivation for using, Motivation
- recommendation measurement, Objection: Measuring the Recommendations Is Unfeasible (for Example, Whether Commits Are Specific)
- versions, automatic merging of, Version Control Allows Automatic Merging of Versions
- violations, development standards and, Controlling Standards Using GQM-Controlling Standards Using GQM, Objection: We Cannot Work Like This!
- Voltaire, Next Steps
..................Content has been hidden....................
You can't read the all page of ebook, please click
here login for view all page.