What Application Lifecycle Management needs is more visibility into the software development life cycle (SDLC). Who is doing what? When? With what results? How are results affecting the quality and the final outcome of the application? How can we determine whether the project is on schedule, and assess whether it is truly ready to be released?
These problems have been troubling the industry for years. Yet, they are still not resolved. Some of the key Application Lifecycle Management issues that we will need to address to move forward are:
1) Requirements must be properly considered and defined. If the requirements are not defined completely and clearly, there is little to no chance that the software developed from those requirements will satisfy stakeholder expectations. Effective Application Lifecycle Management will require effective requirements management tools that are closely integrated with other parts of the Application Lifecycle Management infrastructure.
2) Requirements must be correlated to code and tests. Getting requirements properly defined is critical, but it’s not the end. Requirements must be remembered throughout the SDLC. If you don’t know which code is related to which requirement, as well as which tests verify each requirement, you have no objective way of determining whether each requirement is actually implemented. Moreover, knowing the relationship of code to requirements is essential for estimation and scheduling. Once you know the estimated LOC per requirement, you can estimate the size of the completed software project. If you then determine the developer work rate (the average LOC per day each developer can produce), you can estimate how long it will take to complete the project with your existing resources. If the result is not satisfactory, you can then use these metrics to determine whether you need to add resources or adjust your schedule.
3) The impact of changes during maintenance must be better tracked. Once the project moves from active development to maintenance, the problems change. Now, one of the key concerns becomes how to assess the impact of changes to requirements and to the product. When new requirements are added, you need to determine how they relate to and impact the existing requirements. Are older requirements being replaced? If so, how do you ensure that all of the old functionality is properly updated? Are new requirements being appended to existing ones? If so, how do they fit in? Will old use cases need to be modified? Will new ones need to be written? Additionally, when code is added or modified to implement the new requirements, you need a way to verify that those changes did not break the code’s previous functionality or have side effects that you did not anticipate and would not think to test.
In my opinion, Configuration Management as is will cease to exist in the future. The problem with the current Configuration Management systems is that they are overly focused on the code, and fail to provide a more holistic view of the project, especially in terms of its requirements . To meet the changing needs of the industry, Configuration Management systems will have to morph into infrastructures that support the entire SDLC. In other words, it will need to:
-
Track test cases
-
Track requirements
- Connect to the requirements management system
- Track which requirements and bug fixes are implemented in the code and verified by test cases
Effective requirements management is the basis for effectively communicating to the development team what it is supposed to produce, and is the only means to reliably determine whether the software produced actually implements the expected requirements. As long as Configuration Management systems do not track the correlation between requirements, code, and test cases, a tremendous amount of knowledge—the very knowledge that is critical to successful Application Lifecycle Management—will be difficult to retrieve, or lost altogether.
Essentially, today’s Configuration Management systems will need to evolve into integral components of project management systems that provide a single “control center” where you can monitor all aspects of your project—from its Java, C/C++, or .NET code, to its SOA or Web implementation, to its database—and get a full 360 degree view of it; not just a peek at the code-level details. This infrastructure should integrate with and pull information from source control management, bug tracking, and requirements management systems, as well as testing tools. It should collect and correlate data from the source code base, automated tests, and manual tests to provide comprehensive and objective insight into application quality, team productivity, and project risk factor. As software projects continue to grow more and more complex, this will be necessary for making informed Application Lifecycle Management decisions about project readiness, project scheduling, and resource allocation.
Dr. Adam Kolawa is cofounder and CEO of Parasoft, a vendor of automated error-prevention software and services based in Monrovia, CA. Dr. Kolawa, who is the coauthor of Bullet-proofing Web Applications (Wiley, 2001), has written and contributed hundreds of commentary pieces and technical articles for publications such as The Wall Street Journal, CIO, Computerworld, Dr. Dobb's Journal, and IEEE Computer. He has also authored numerous scientific papers on physics and parallel processing. He holds a PhD in theoretical physics from the California Institute of Technology.
Trackback(0)
 |
TrackBack URI for this entry
Subscribe to this comment's feed
