Dear Desktop Engineering Reader:
Back in April, the computers at American Airlines seized, grounding more than 1,000 flights. The company reported that a “software glitch” brought down its primary and backup systems. My guess is that it was a quality issue: Somebody made a teensy-weensy code change or loaded a minor patch from a vendor onto the primary computer. The code was not properly vetted and thousands of sore passengers and millions of lost dollars later, it was backed out. How’d you like to be the guy explaining this tweak to the boss?
I’ve come not to bury programmers or AA. Software development is a bear. The thing is that software development is more unruly every day as complexity soars and as the competitive difference between products from company X and company Y lies in its software.
This is why ALM (application lifecycle management) is every bit as important as your CAD, CAE, BOM, or PLM systems. ALM can bring focus, efficiency, effectiveness, and sanity to the software development process, all of which better your chances of producing high-quality code from the start. Arguably, the most crucial role performed by ALM is requirements management. These capabilities can bring collaborative, cross-discipline communications to your new product development, QA, and release teams, whether a team is down the hall or down under in Sydney.
Today’s Check It Out link takes you to a white paper from PTC called “Improve Quality and Decrease Time to Market with Better Requirements Management.” This 11-page PDF provides a broad overview of the state of requirement management tools as well as an in-depth description of what requirements management in PTC Integrity ALM software means for you.
The shortest part of the paper covers the present state of requirements management at many outfits and commercial offerings. They’re not that hot, according to the anonymous author. Many tools for the job are inflexible, so they’re not used. This leaves teams disconnected from one another and management groping for the reins. So, development teams labor in isolation and, late in the cycle, their work is united like strangers at an arranged marriage.
The problem here is that designs, specifications, and components change. Without data flowing freely between disciplines, out of the loop people make decisions on old, half right, or plain wrong information. This results in a mad management scramble to forge compromises so that the product rolls out more or less on time. That process throws off schedules and budgets and gives you rework, maybe scrap, and less than ideal products. Worst of all, such haste can lead to recalls or other forms of generating unpleasant headlines.
The bulk of the paper covers requirements management in PTC Integrity in granular detail and how it can help you avoid that litany of woes. There’s a lot to say. Key functionalities include customizable traceability to keep cross-disciplinary teams informed of what’s going on; reuse and requirements change management coupled with real-time metrics; and requirements capture. That traceability capability not only fosters inter-departmental collaboration, it handles compliance initiatives.
The nub of it is that PTC Integrity is a single unified solution for managing requirements in direct relationship to the downstream development, quality assurance, and deployment phases of the lifecycle. It’s flexible to your company’s processes, and teams collaborate through a common process with a unified interface.
I found “Improve Quality and Decrease Time to Market with Better Requirements Management” a chilling read. Not that it hypes horror. It’s more matter of fact than breathless, actually. But what it has to say about what real requirements management can do also says a lot about what we’re not doing. Software has become the medium that differentiates you from them. Quality is the name of the game. Failure to harmonize the disciplines creating new products and underpinning our world are legion: warped maps on a much-hyped app, a hot-selling car recalled because status indicator lights went nuts, and a major airline’s computers screeching to a halt. Download this paper. It has lots of information that you should consider as you evaluate your processes.
Thanks, Pal. – Lockwood
Anthony J. Lockwood
Editor at Large, Desktop Engineering