The problem with this traditional model is that it doesn’t necessarily fit in very well with what the rest of the organization is doing, particularly if you are developing applications which are part of the ongoing estate of your organization.
In many traditional development shops, the most important stuff is considered to happen during development. At some point the application is signed off or accepted, it is thrown over the wall into production and the development team sails off into the sunset, with the satisfaction of another job well done!
Typically applications spend perhaps only 20-30% of their overall life in development. The majority of the life cycle is spent in production with regular changes being made to that application.
Smaller changes or bug fixes might follow a rather different life cycle than a full blown change. Larger changes may merit a new project to be setup which goes through the lifecycle again, but this time starting with an already existing application.
Applications are often modified for a new project in parallel to small bug fixes and enhancements being made and released. You need to ensure that a major new release of an application also includes all the little bug fixes that were made to the previous version and are already in production.
With the end to end service focus of ITIL V3, the importance of applications to the user experience and importance of usability across a set of applications that make up an end to end service has also increased.
So if your organization is implementing an ITIL V3 CMS (or has a V2 federated CMDB), then your ALM will be exchanging information via: problems, known errors, changes and releases.