Automated Lifecycle Management
Automated Lifecycle Management - ERP meets the SDLC.The term "ALM" (Automated Lifecycle Management) has been getting a lot of exercise over the past few years. There are a lot of different people and vendors who use the term, and some variation on how they define it.
Collaborative Information Systems Integrations
One analogy I find fitting is "ERP meets the SDLC". ERP, or Enterprise Resource Planning, kicked off a binge of systems integrations projects in the past decade or so, all with grand goals of integrating information systems across the entire breadth of the manufacturing process. The result of these systems integrations projects (the successful ones, anyway) was to provide a more common view from different perspectives, so that people with different roles could share the same key data, but with different views depending on their role.
For example, if people in the purchasing department have access to warehouse inventories, they can better decide when and how much to order. You can get optimal efficiency with Just In Time (JIT) manufacturing and Supply Chain Management ("the other SCM").
With the SDLC (Software Development Life Cycle), the same general idea of ERP applies. In this case we're talking about integrating information systems related to the software development process rather than manufacturing processes. Just as with manufacturing information systems, many software companies evolve their information systems organically and independently. Business analysts define business requirements, which get translated into technical requirements and lead to software changes. Developers modify software based on those requirements. QA tests the software (usually focusing on the changes to direct test efforts), and tracks their lists of defects. Customer Support reports defects that got past developers and QA.
In the ERP/ALM mindset, the software production line is designed such that people in all those roles contribute to a common system (in reality, a system of systems). Bugs and new requirements are both drivers for change, and can be tracked the same way. A new engineer may be confused about a software change, and can easily trace it to the technial requirement that caused the change to be made, and from there to the business requirement from which the technical requirement was generated, and from there (in the extreme example) back to the "idea incubator" where he'll find wiki discussions from when the idea for the requirement was originally discussed. With such a high degree of transparency in the process afforded by integrated systems, the engineer can see a flaw in the original thinking, or any of the translations along the way, and "do the right thing" to fix it. And once the right thing is done, he knows what affected downstream customers (internal and external) may need a patch. CMMI Level 5, here we come! :)