Yesterday I attended the MSDN evening session about Application Life cycle Management (ALM) with Visual Studio Team System (VSTS).
It was very interesting and very well presented by Yves Goeleven (Compuware Belgium). He was very knowledgeable about the subject and VSTS in particular. His presentation was a good mix between slides and demo's so you had a good feel what actually was meant.
Still I have some "concerns" about the subject. Concerns are formulated as "I wish I knew how to ...."
- Position VSTS/TFS as an ALM tool or more as an SDLC tool? Yes there are hooks (extensibility)....
- Capture the requirements from the customer in VSTS? And manage them in VSTS? Yes a wokitem will be the "materialization" of a requirement. But is this still the language of the customer?
- To model use case diagrams, UML class diagrams , User stories
- To integrate with operations (deployment, monitoring, incidents , capacity management)
I looked up the the terms ALM and SDLC. Application Lifecycle Management (ALM) is the administration and control of an application from inception to its demise. It embraces requirements management, system design, software development , testing , configuration management and operating the information system. The following picture tries to capture that idea.
Key is that the life of application does not start at the beginning of development. It start somewhere in the “business”. The end of application is not when it is delivered or even installed. It must be kept up and running to serve the business. It is also called life cycle because in effect an “application” is never finished. It is not something like a tangible product that rolls out a factory. It’s an ongoing process where new insights and requirements shape the life of an application, hence application life cycle management. As the business changes, information requirements change, and the cycle continues. Sometimes resulting in the demise of an existing system and the birth of a new application.
The software development Lifecycle (SDLC) on the other hand has everything to do with developing the information system. But it gets kicked of by the business and hands over application to operations. It is also a lifecycle because within one ALM cycle because it is the rare exception that everything is said from the beginning. So there can be several iterations before an applications gets to be delivered to the business. On the other hand of course a change request or new requirements can trigger of a new ALM cycle.
In order to achieve business objectives within an organization via information systems, user functional and non functional requirements must be defined in a consistent manner, prioritized and monitored. The administration and control of the information needs of users (Requirement Management) is therefore primary motor in the ALM and de facto also in the SDLC. All the “knowledge” that’s is necessary to transform these requirements into an information system is produced during the SDLC and put into a repository (or a collection of repositories). This will for the test basis for the test cases that will be used to verify it the information does what needs to do.
The SDLC will take that the requirement will be turned into architecture and design specifications which will eventually lead into code doing what the business expects it to do. Herein lies the objective of testing. Testing actually is conducted throughout the SDLC. Testing preparation can even start as soon as the requirements are written down (testable requirements concept). During development in the form of unit and unit integration testing or system testing (functional, security , performance ,etc). Before the application get rolled-out, the business itself can conduct test in the form of user (functional) acceptance test. Also operations can conducts acceptance tests that verify the operational requirements.
In order to achieve business objectives within an organization via information systems, user functional and non functional requirements must be defined in a consistent manner, prioritized and monitored. The administration and control of the information needs of users (Requirement Management) is therefore primary motor in the ALM and de facto also in the SDLC. All the “knowledge” that’s is necessary to transform these requirements into an information system is produced during the SDLC and put into a repository (or a collection of repositories). This will for the test basis for the test cases that will be used to verify it the information does what needs to do.
The SDLC will take that the requirement will be turned into architecture and design specifications which will eventually lead into code doing what the business expects it to do. Herein lies the objective of testing. Testing actually is conducted throughout the SDLC. Testing preparation can even start as soon as the requirements are written down (testable requirements concept). During development in the form of unit and unit integration testing or system testing (functional, security , performance ,etc). Before the application get rolled-out, the business itself can conduct test in the form of user (functional) acceptance test. Also operations can conducts acceptance tests that verify the operational requirements.
The input for establishing these test case are the expectations of the business. Ideally written down in the form of requirement, detailed functional specification and design documents. So there is a strong link between all the knowledge of what the system must do and all the information of how system is going to be tested.
A integrated system (or an integrated set of tools) should bring some added value to manage this link. Because the objective of testing is to report if the system does what it needs to do. So traceability is a key feature of this tool. Other benefits are accountability (who did what when), visibility (what did we do so far).
So if we would define testing as a kind of “fit-for-purpose” activity, testing is another gatekeeper in the life cycle. With the results of testing the stakeholders (customer/project lead) can take a decision based on facts if there will be release or not (ALM cycle) or within the SDLC cycle if something has to be corrected before release.
Monitoring the information system in production and the actual usage of the application will further keep the ALM cycle running by incident reporting (functional and non-functional).
So were does VSTS/TFS fit in this story?
I tried use the following picture to get some (visual) answers.
I can see several aspects being covered by VSTS while others (at this time) seem to not be (immediately) clear to me. Maybe this will change over time as learn more about ALM and VSTS/TFS in particular? I would be glad to hear your insights on the subject.
Best regards,
Alexander
It is important that you use the ID (ie. GUID) to specify the subscription. You can also look it up in the Subscription table of the reportserver database.
In Visual Studio 2008 you get the navigation buttons by default at a little bit more!