|
|
Unitizing Legacy and New Code for Unit Testing All code is unit testable, regardless of its origin and current state. Although it may not appear so, there are techniques you can use to safely get any piece of code under automated unit tests. Michael Feathers shows the dependency breaking techniques he has used to safely de-couple legacy code for unit testing. He discusses not only the different challenges in Java, C#, C++, and C but also common heuristics you can use to bring your code under test. Learn about the value and power of deterministic change with fully automated unit tests. Identify internal and external dependencies in sections of code and establish ways to break these dependencies with or without refactoring tools.
|
Michael Feathers, Object Mentor
|
|
|
Using Code Metrics to Target Refactoring Often times, deciding what code to refactor (rewrite) is based upon the code's smell, a subjective determination by developers. Learn about and see examples of static analysis techniques such as cyclomatic complexity, depth of inheritance, and fan-in/fan-out to augment developers' instinct with real data. For example, cyclomatic complexity is adept at spotting methods containing too much conditional logic. Deep hierarchy trees, problematic for testing, can be broken out into separate objects. Fan-in/fan-out analysis is effective at pinpointing brittle code that you should refactor. Armed with new methods to objectively spot smelly code and replace it with proven patterns, your code base will become more stable and maintainable.
|
Andrew Glover, Vanward Technologies
|
|
|
Defect Prediction with Reliability Growth Modeling Although typically used at places like NASA, reliability growth modeling also can be used for common business and financial applications. Reliability growth modeling predicts how many defects will be in your release, how quickly your testing should uncover them, and how many will still be present after delivery. You can use this information to make ship/no-ship decisions, manage test coverage, and appropriately staff the help desk. Using a free, downloadable tool, CASRE (Computer Aided Software Reliability Estimation) from the Jet Propulsion Laboratory, Michael Allegra outlines a step-by-step process to produce and interpret dynamic reliability growth models. Michael walks you through an example project, explains how to get started with modeling, and demonstrates that you don't have to be a rocket scientist to use it.
|
Michael Allegra, GSX
|
|
|
You've Just Been Named Manager of Software Process Improvement We have all heard of the accidental project manager, but how about the accidental irocess improvement manager? If you have fallen into the role of process improvement, there are tips and tricks to help you navigate through sometimes treacherous waters. As a former quality assurance manager, Sandi Oswalt returned from maternity leave to be told she had a new job--process improvement. In response to her question about the goals for process improvement, her boss simply said, "Hmmm? . . . Just improve." Fortunately, things got better from there for Sandi and eventually for the organization. Sandi shares some important insight from her first year: trust is key-sanitize information and ask permission; data speaks volumes-back conjecture up with basic metrics; let people find their own solutions; change is hard and takes time; all the mandates come from management; and finally, don't give up!
|
Sandi Oswalt, First American Credco
|
|
|
Establishing a CMMI Compliant Metrics Program Implementing a useful measurement program that also addresses the measurement requirements of the SEI CMMI® process areas can be a daunting task. Organizations pursuing Level 2 and Level 3 maturity have difficult decisions to make designing a measurement program that is both practical and fully compliant. Steve Lett describes the measurement requirements contained within the CMMI® Maturity Level 2 and 3 Process Areas (PAs). He then recommends a common sense approach and a set of measurements that will address all of the PA requirements. See examples of measurement charts and learn how they can be highly valued improvement tools within your organization. Find out about the prerequisites for success and the steps necessary to establish a measurement program.
|
Steven Lett, The David Consulting Group
|
|
|
A Manager's Survival Guide to Going Agile When software development teams move to Agile methodologies, they often leave the project managers behind. Traditionally trained project managers are confused about their new roles and responsibilities in an environment that no longer allows them to make stand-alone decisions. In this session, Michele Sliger focuses on re-defining the job of the project manager and their new-and often more important-role in development. Michele discusses the shift in a project manager's role from "boss" to one who serves and supports the team. Find out facilitation and collaboration skills can make you a better Agile project manager. Leave with a better understanding of the necessary changes to lead and support an Agile team and take away clear, practical guidelines to make these changes.
|
Michele Sliger, Rally Software Development
|
|
|
Agile Process Improvement and the Evolution toward Software Factories The concept of software factories is becoming a hot topic in software engineering circles. So, how can the factory model fit with Agile development practices? Damon Carr makes the case that Agile development is a stepping stone-not an alternative-to software factories. This is not the dreary vision of mindless workers in a factory. Instead, think of highly skilled individuals working with multi-million dollar machinery to develop systems. Even if you are not considering the factory model, Damon offers new practices that can reduce overall Agile development costs by as much as 40 percent. These include explicit refactoring to design patterns in your iterations, quantitative risk management, metrics for understanding the health of your project, and a new approach to team structure.
|
Damon Carr, AGILEFACTOR
|
|
|
Introduction to Agile Coaching Techniques In Agile processes such as Scrum and eXtreme Programming (XP), there is a coach whose primary function is to shepherd the process along and help keep everyone on the same page. On a traditional software team, there may be a product manager, project manager, technical lead, software architect, or even a user who informally takes on the role of coach. Based on his and the experiences of others as coaches, Christian Sepulveda shares his insights on this important role and the patterns that he employs as a coach. Understand why every team needs a coach, find out about the typical day in the life of a coach, and learn whether an individual acting as the coach also function in other roles. Find out how to balance the coaching needs of your organization and process.
|
Christian Sepulveda, Nominum Inc
|
|
|
A Guide to Using XP for Geographically Distributed Development Teams It has been said that eXtreme Programming (XP) and Agile development work only for development teams working closely together and collocated with their users. Because of the collaborative nature of Agile development, geographically disbursed team location often is used as a deciding factor against using Agile practices. So, how has XP worked at VA Software in the past two years with their distributed and offshore development team? In some cases it has worked very well ... in other cases, not well at all. The good news is that, because of XP’s fast turnaround and visibility, results were apparent after only a few weeks, allowing course corrections and schedule adjustments. Learn about the practices for XP, based on Mark Striebeck's real-world experiences, which can be applied to your teams whether they are distributed across town, across the country, or across the globe.
|
Mark Striebeck, VA Software Corporation
|
|
|
Let's Do It Over Again: Configuration Mismanagement Techniques Being told about good configuration management practices is boring and does not do this vital process justice. What if you do it badly, as many development groups do today? The ultimate failure in managing the configuration of a software product is having it so horribly out of control that it cannot be rebuilt and must be rewritten from scratch. Few developers can claim this spectacular achievement, but many projects employ configuration management practices that result in rework and a loss of reputation with customers. Using humor and sarcasm, Mark Pellegrini looks at examples of how poor configuration management practices can sabotage product development productivity and generally make everyone’s life miserable. Avoid embarrassment by creating and auditing baselines, releasing controlled betas, documenting build procedures, avoiding undocumented components, using version control, and much more.
|
Mark Pellegrini, Georgia Tech Research Institute
|
