|
Building a Meaningful Metric Mousetrap Metrics provide data points that can both benefit and endanger and organization. Metrics can be used positively to build a better organization and can be used negatively to punish organizations and people therein. Many times, those that use the metrics negatively do it purposefully, but other times, they are not aware of the way they are using them. This is why it is important to have a metrics culture that apply metrics in a positive manner, provides an understanding of the metric, and then actually utilize metrics to manage an organization.
|
|
|
Finding the Right Mix of ALM Processes and Tools for Design and Implementation Configuration management is complex. As a product evolves, CM gets even more complex, as complexity breeds problems. So how do we continually march our product configurations toward higher and higher quality? You need good people, process, tools, and automation. People define and put the processes in place. Tools are used to automate the processes and to bury the complexity of CM below the user level. Development is a process that takes ideas and turns them into products. There are many techniques and tools to do design and implementation. The right mix is required to effectively develop a competitive product. On the management side of things, the same is true. Application lifecycle management requires the right set of processes and tools to allow the design efforts to be properly leveraged and to yield the best quality.
|
|
|
Establishing Effective Software Metrics for the Measures You Want The goal of software metrics is to have a rich collection of data and an easy way of mining the data to establish the metrics for those measures deemed important to process, team, and product improvement. When you measure something and publish the measurement regularly, improvement happens. This is because a focus is brought on the public results.
|
|
|
Lean Metrics for Agile Software Configuration Management Taking an lean-agile slant on metrics for configuration management, the authors focus on ways to measure the value CM and SCM adds to the project and product and how to measure flow and waste.
|
|
|
Change Management Is Essential to the Building Processes Building is considered to be one of the fundamentals of configuration management, even though some might argue that building isn't really CM. The reason it is fundamental is that the build/verification cycle provides proof of reproducibility if done correctly. It forces CM to be done correctly so that only the objects from the CM repository are used to reproduce the build. When formal build processes are correct, they need no information that resides outside of a CM repository. When properly done, the build record is created prior to the build (i.e., a build notice) rather than as a result of the build, with that record being used to drive the build process. An integral change management capability is an essential component of such a build process.
|
|
|
The Renaissance Builder This month we would like to turn the spotlight on to that oft neglected and under-valued specimen the build engineer. In the physical world, the term “building” has traditionally inspired status and respect. We just have to think of structures from the pyramids to medieval cathedrals to skyscrapers.
|
|
|
Are You Still Building from the Tip Revisions? How do you build? How do you select the source code files to include in a build? How do you identify the revisions, or versions, of the files to include a build? Do you build from the tip revisions in your version control system or do you build by selecting a specific revision of every source code file? Do members of the development team specify the changes to include in each build or do you sweep in all changes implemented at the time of the build? When do you build from revisions in the mainline of the version control system? When do you build from revisions in a branch?
|
|
|
The Business of Software Development The software development business, once the domain of a few advanced technology companies, is now pervasive. Why? Because software is less costly and easier to modify than hardware. At first glance this is obvious; building a software telephone switch is a lot less costly than the hardware equivalent. Looking more closely, though, software products have far more features and, therefore, are more complex than hardware products. Software is easier to change, but this just adds to the level of complexity, especially on the management side. Software allows us to build products that are more complex.
|
|
|
A Christmas (Configuration) Carol (Abridged) We have endeavored in this ghostly little tale, to raise the Ghost of an Idea, which shall not put our readers out of humour with themselves, with each other, with the season, or with us. May it haunt their houses pleasingly, and provide inspiration this season!
|
|
|
The Largest Case Study of Code Reviews—Ever In May 2006, we wrapped up the largest case study of peer code review ever published, done at Cisco Systems®. The software was MeetingPlace® — Cisco's computer-based audio and video teleconferencing solution. Over 10 months, 50 developers on three continents reviewed every code change before it was checked into version control. We collected data from 2500 reviews of a total of 3.2 million lines of code.
This article summarizes our findings.
|
|