Software development can often be a very complex endeavor, so it is no wonder that important details can sometimes get lost in the process. Here, Bob Aiello discusses how to implement configuration management (CM) and traceability in a practical and realistic way.
While we know the technology, some configuration management (CM) experts don’t always have a strong enough business focus, which can be a real problem. Read on if you would like to understand what CM professionals need to know about business requirements and how CM can directly impact the business itself.
Traceability doesn't prevent errors and an audit trail does little to help me to recover from one. Does this mean they aren't valuable CM tools? On the contrary, audit trails and traceability are two of our most important CM tools for learning how to mitigate risk.
As we look to deploy or improve a requirements practice, the output should lead to a set of complete and quality requirements. A way to get there is to ensure that requirements have been captured in all pertinent categories and are testable. Often times, requirements focus on user needs and limited functional areas. But what may be overlooked are lesser requirements categories (e.g., security, usability, etc). It is therefore essential to capture requirements that ensure coverage in the requirements space.
Creating requirements involves tracking and documenting all of the criteria for a system's success. A requirements management tool, such as IBM Rational's RequisitePro, can support this effort. While the tool won't verify that the requirements are consistent, correct, complete, relevant, coherent, and testable, it can help manage the task more efficiently by allowing you to document, track, and maintain the requirements in an automated fashion.
William Gens sits down with Noel Wurst to describe "the art and science of traceability" ahead of his STAREAST session of the same name. Learn what makes traceability meaningful and such a valuable asset to projects, no matter how bad the requirements may seem to be.
Testing experts often disagree. Why? Different testers have different understandings of the role and mission of software testing. This session presents four schools of software testing, each with a different understanding of the purpose and foundation of testing. One school sees testing based on mathematics. Another sees it as an activity that needs to be planned and managed. A third sees it as a basis for understanding and improving software process. And the fourth sees it as an intelligence service, providing actionable information. These all sound reasonable enough, but each has provided the foundation for a school of testing and different hierarchies of values. Learn more about the four schools of software testing and the effects they have on your life. You may find that you, your colleagues, and management are operating in different schools.
Studies have shown that over fifty percent of software defects are attributed to poorly defined requirements. From a process improvement perspective, it is imperative that project managers establish a more effective and efficient way of defining and tracking business requirements. Jeff Tatelman describes a "how to" approach for developing a practical automated regression testing process using a traceability matrix and business event scenarios. Learn how requirements-based testing-coupled with a data-driven approach to test automation-can solve problems that plague most software development projects.