Traceability of Relationships Between Artifacts

Технология проектирования программных систем

1. What is ALM? Which problems it solves?

Application lifecycle management (ALM) is the product lifecycle management (governance, development, and maintenance) of application software. It encompasses requirements management, software architecture, computer programming, software testing, software maintenance, change management, continuous integration, project management, and release management.

However, modern software development processes are not restricted to the discrete ALM/SDLC steps managed by different teams using multiple tools from different locations. Real-time collaboration, access to centralized data repository, cross-tool and cross-project visibility, better project monitoring and reporting are the key to develop quality software in less time.

This has given rise to the practice of Integrated Application Lifecycle Management, or Integrated ALM, where all the tools and tools' users are synchronized with each other throughout the application development stages.[citation needed] This integration ensures that every team member knows Who, What, When, and Why of any changes made during the development process and there is no last minute surprise causing delivery delays or project failure.

Today's application management vendors focus more on API management capabilities for third party best-of-breed tool integration which ensures that organizations are well-equipped with an internal software development system that can easily integrate with any IT or ALM tools needed in a project.

There has been talk to change the term ALM to ADLM (Application Development Life-cycle Management) to include DevOps.

Explain three pillars of ALM

Traceability of Relationships Between Artifacts

Some customers we have seen have stopped doing upgrades on his systems that were running in production because the company had poor or even no traceability in its systems. For these customers it was far too expensive to do upgrades because of the unexpected effects even a small change could have. The company had no way of knowing which original requirements were implemented where in the applications. This customer claimed, and we have seen and heard this in discussions with many other customers, that traceability can be a major cost driver in any enterprise if not done correctly. There must be a way of tracing the requirements all the way to delivered code—through architect models, design models, build scripts, unit tests, test cases, and so on—not only to make it easier to go back into the system when implementing bug fixes, but also to demonstrate that the system has delivered the things the business wanted. Another reason for traceability is internal as well as external compliance with rules and regulations. If we develop applications for the medical industry, for example, we need to have compliance with FDA regulations. We also need to have traceability when change requests are coming in so that we know where we updated the system and in which version we performed the update.

Дата добавления: 2015-10-24