Traceability in VS2010
Always an interesting question, how does traceability work in VS2010?
To often asked without any context, or only asked from a requirements perspective. Still way too open to answer in a tweet. So, a post to canalize those questions a little bit more…
[see the image below for the numbers]
you can take two directions when talking about traceability. The first is focused on “work”, the work items repository part of TFS [on the left side of the green dotted line]. with work related traceability we can answer questions like “did we completed all tasks for that requirement?” [for more see the red list]. Information which is very important for every roll in the Application Lifecycle. A tester want to know if he can start testing, so he want to see if the developer is ready. A project manager wants to plan the work. Developers want to know if designers are ready to start with a stabile set of needs… and many more. All work related information, and information which can be tracked/ traced by using work item and its repository.
VS2010 main capability for work related traceability are the TFS work item repository [see image below from MSDN] and linking of work items, setting up a hierarchy.

We can breakdown requirements, or user stories, in tasks.
tasks that needs to be executed to get the requirement done. These tasks can have a parent-child relation [and other see Working with Link Types on MSDN]. Giving us the information we need in any kind of way, for example reports.

So far the work related traceability. The other kind of traceability
is based on artifacts, things we make during the application lifecycle, I will call them ALM artifacts. ALM artifacts are used to create the solution/ application. For example the source, XAML and configuration files which make the solution. But, also the diagrams which we created to make a correct, consistent and good communicated application architecture, we use them to drill down from the needs to code. And also test cases belong to the things we make during the application lifecycle [I can imaging when you get confused now, test cases are within VS2010 work item types, but they definitely belong to the artifacts section].
Use case – user story what is the difference… I often use both [see this piece of MSDN documentation for modeling requirements]. User stories are work item types and use cases are ALM artifacts. So, they are a great bridge between the ‘work-world’ and ‘artifact-world’. The good thing is the capability of VS2010 to link diagrams, and other model elements to work items. [How to: Link Work Items to Model Elements], this give us the capability to create a trace.
From the description and diagrams of the requirements, the often called problem domain, we have to make a big jump into the solution domain.
Diagrams are created like the component diagram and layer diagrams visualizing the high level pieces of the solution with the dependency and interfaces between these components and layers. [used this image in this post; the modeling world].
It is also a big gap for traceability, to get this a little bit better a solution can be the replaying of scenarios written down in the user stories and drawn in activities as described in this post; VS2010 Modeling; Create Lifeline from Component.
A trace back from component/layer to requirement can be a link from model element to the user story work items in where he is used. Never did this, it’s a manual process and probably people will forget the links, maybe with some kind of notification this would be valuable…
An interesting VS2010 capability is the connection between the layer diagram and the sources. This makes a trace possible between the high level design and the sources. See image below.
Because test cases are work item types in VS2010 they can be connected to any other ALM artifact, giving us the possibility to connect for example test cases to use case diagrams. Easier to accomplish and to maintain is the connection with test tasks and corresponding user story. But this doesn’t answers questions like; “which code is touched by this test”. VS2010 answers this question with Test Impact, see “Determining Which Builds Have Bug Fixes, New Features, or Requirements”, “Recommending Tests to Run That are Affected by Code Changes” and “Developing Tests from a Model”.
Another interesting traceability scenario can be build with test case generation, see this ‘old’ Model Based Testing beta 1 video. [some more info on MBT can be read on Rob’s blog]
Next, 



all have a work related task. So, not only traceability within the two sections is possible also traceability between the two sections is possible. answering questions like; “which task created this line of code?”… creating this link / trace is a manual task but it can be controlled by a check-in policy.

So, when someone asks you the question; “what about traceability in VS2010?” you now can canalize this and guide him/ her to the real traceability question they want to have answered [and tell the solution]….
< probably more to come on this interesting topic, also because the extensibility model of the diagrams is powerful enough to create your own required traceability between artifacts with notifications and work item linking… very very interesting >
VS2010 Modeling; Create Lifeline from Component
From the VS2010 MSDN sequence diagram documentation…
Relationship to other diagrams
You can use UML sequence diagrams together with other diagrams in several ways.
Lifelines and types
The lifelines you draw in a sequence diagram can represent typical instances of the components or classes in your system. You can create lifelines from types, and types from lifelines, and show the types on UML class diagrams and UML component diagrams. For more information, see Classes and Lifelines.
Beside we can create lifelines from/for classes we also can create lifelines for/from components… which is actually a very interesting feature.
Context menu on a component shows the create lifeline option [not available when clicking on a part ]

After the creation of several lifelines, you can draw the interactions between the components. There isn’t functionality like the bi-directional method creation in the class-sequence diagram interaction for the component-sequence diagram. Kind of logic, a component only has interfaces.
Why would you want to do this, create sequence diagrams for components?
While the component diagram
is a static view of your system the sequence diagram is dynamic, it visualizes the flow in your application, the sequence of actions that occur in the system. So, you could use sequence diagrams to validate your system, your component design. Take a scenario, a requirement scenario, and create a sequence of actions from in a sequence diagram
. By doing this you create a kind of simulated behavior of the component structure, which you can check on correctness and consistency.
The scenarios used for this can be found in the use case diagrams
, which describe the actions that take place on/in the system. Now describes a use case diagram not really a scenario, you better can use an activity diagram for that
, which can be based on the use case diagram as a kind of use case realization. Now the interesting thing is, testers use activity diagrams to create test cases, they have specific technologies to extract the right amount and type of scenarios [see http://robkuijt.nl/index.php?entry=entry080423-135750 ], these scenarios we can use to validate our component design which actually closes the loop.

It would be even more interesting and powerful if we not only could link sequence and component diagrams but also use case and activity diagrams making notification when an activity changes and a scenario can’t be run anymore on the purposed component… hard to accomplish, but interesting, versioning would be hard…
Microsoft Test and Lab Manager and security and permission settings
Within TFS you can set permissions, what people are aloud to do within projects and with 2010 in place also within project collections and within Microsoft Test and Lab Manager.
In some situations, project settings, you want to set these permissions. For example in the TMap process template there are different rolls responsible for different tasks. The Test Manager is responsible for the Master test plan, the Test infrastructure coordinator for the test infrastructure and tools, the test coordinator for the test plans, the runs and reports and the tester for creating and execution of the tests cases.
These rolls/ groups you also can find in the TMap Process Template.

All rolls have there specific restrictions. For example a Test Infrastructure Coordinator is aloud to setup lab environments but a Tester isn’t, and a test coordinator can create a test plan but a tester isn’t. A test manager and coordinator can edit test runs results. A tester can execute test cases but a developer can’t, a developer can change sources but a tester can’t… etc, etc… A frequent ask question by test organizations is: how can a set this restrictions…. the answer is it is easy but you need to have project edit permissions :-)
On several places you can set security permissions.
In the Team Foundation Admin Console, the same settings can be set within Visual Studio menu Team—> Team Project Collections Setting
You only can set project collection and TFS specific setting at this level, not that interesting for test management.
Within Visual Studio, right mouse click on within Team Explorer or by using the Team menu.
This is a more interesting place to set permissions for the test organization. For example in this setting a test coordinator is aloud to create test runs, but can’t change configurations and environments.
This results in the fact that he must contact the test infrastructure coordinator to maintain the test infrastructure. And he got a message when he tries to change a setting in Lab Center.

A hidden security setting [I call it hidden because its hard to find in my opinion and I had to search for the projectplan permissions] is a the Area and Iteration menu item, just below the ‘Group Membership’ item.
When clicking the ‘Areas and Iteration’ menu item and click on the bottom right of the dialog what appears you can set permissions for the selected Area node or Iteration node. For the test organization important manage test plan permissions can be set.
When you set this permission so a tester isn’t aloud to manage test plans he gets nice an clean messages when he tries to save one.

But, it gets even more interesting. When a tester isn’t aloud to manage test plans he also can’t add test cases to a test plan. So, the create new test case in the plan tab of MTLM also will result in a ‘Not Aloud Message’. While the tester is aloud to create test cases he isn’t aloud to add them to a test plan, within MTLM he has to create test cases in the ‘organize’ tab –> test case manager. So a test coordinator, or some one else who has the manage test plan permission can add it to the test plan.
I have spoken with test organizations who prefer this way of restrictions also have spoken with who don’t want this. Within the TMap Process Template, you will find a light weight implementation of these permissions settings. [not yet in the download ]
To mention all the permission settings locations, right click on the source control treeview and select properties, you can set permissions for source control in that dialog [ you also have to maintain the reporting server and the SharePoint server separately]. ping me if I forgot a security settings location…
VS2010 Microsoft.TeamFoundation.Collaboration… MyFavoriteNamspace
Got this message this morning, while not connected with the Internet. So this message won’t appear that often, when you are always connected.
Because it’s a kind of strange message, I just wanted to open VS 2010. so, it needed some investigation, where did it came from?
A very obvious place the Team Members menu…
Clicking ‘the personal settings’ menu showed the assembly which does the work, the section “collaboration” has a capability to set providers, collaboration platform providers… very very interesting!!
A quick look with the Architecture Explorer shows a nice provider model with a Office communicator provider and a MSN Messenger provider…
So this will give us the possibilities to create or own providers to get connected with our team members, curious when the first Facebook, LinkedIn or Zune social providers will be created.. Visual Studio and ALM are all about collaboration, so this is really a nice development.
[this is 2008 powertools functionality, see Brian’s post how to extend it; Extending the new TFS Team Members Power Tool]
Quick reference poster--the VSTS Rangers “scrumified“ process
from: Certified Scrum Developer course … we can finally remove the duck tape :)
The Accentient Scrum Developer course is an intensive five day experience for whole teams of developers. The course teaches teams how to turn product requirements into potentially shippable increments of software using the Scrum framework, Visual Studio 2010, and modern software engineering practices. Attendees will work in self-organizing, self-managing teams using a common instance of Visual Studio Team Foundation Server 2010 to achieve this goal.
SDL ‘Merged’ Process Template White Paper.
The SDL group just released a paper which describes the steps [seven easy steps] you need to take to merge the SDL specific process items with your existing process template.
Two New Security Tools for your SDL tool belt (Bonus: a “7-easy-steps” whitepaper)
Very nice work… Hopeful we get in the future the possibilities to merge process templates in a less manual way, but this works.
The steps described in this paper are based on unfold process template so you have to take this steps for every new project you create. An other way to merge template is by providing the XML and manually merge it with your existing template. A possibility described in this post “VSTS 2010 TMap Process Template 1,2 and 3”.

Enrich VSTA 2010 Use case diagram with SketchFlow Screens
A use case diagram visualizes the interaction of an external user with your system. So, you can say that in many situations [cases] that there is a need for an user interface, a screen.
Not that strange that RUP connects the user interface designer to use cases. [see image below at the bottom]
UML Type: Artifact
Something every diagram has in VSTS 2010 is the UML type ‘Artifact’. With this type we can attach physical pieces of information to or diagrams.
For example in this diagram below, I defined an artifact which points to a class file. [don’t think it very useful to associate C# class files with use cases.. but as an example]
Some nice functionality of this ‘artifact’ shapes gives us the capability to double click the shape and jumps to this file. More useful, what you also can do is point to a Word document with some additional information according to this use case diagram, double clicking will open the file in Word [or you’re preferred text editor].
Microsoft Expression Blend 3
SketchFlow is a visual tool for prototyping desktop and web applications [WPF/ Silverlight].You can download the trail here. The image below, is a prototype of an application made with SketchFlow. A bit sketching, playing with colors real designers work... :-)
Smashing Magazine had a nice overview of sketch techniques last week “35 Excellent Wireframing Resources” and I made some several weeks ago for this post Storyboard: Architectural Inspections - VSTA2010 – AppArchGuid.
Now, the interesting piece is that SketchFlow, Blend solutions have the same structure as Visual Studio solutions. So, we can open or sketch in Visual Studio. as you can see in the image below, it’s just a normal Silverlight 3.0 project. [installing Expression Studio gives VSTS the ability to open Silverlight 3 projects].
From this point it’s very easy to add the ‘XAML’ screens as an artifact link to our Use Case Diagrams.
The small challenge at this point is that double clicking on the artifact opens the XAML file of your prototype in ‘your preferred XAML viewer’ your internet browser, showing nothing. A small tweak [replace the full path property value with a batch file with one command “devenv.exe /edit filetoopen.xaml”, the /edit opens the file in the current open environment] makes it possible to open the XAML file in the currently open Visual Studio edition.
Finally the result is a Use Case Diagram with several artifacts referring to user interface screens. Which gives the user interface designer, the system specialist, the customer actually everybody who is involved in this software project an overview of the solution, which results in better understanding and the user interface designer still can work in SketchFlow.
final note: there are still a few integration problems, but I do think this is a valuable scenario….
TMap Process Template for VSTS2010 – Short Version
Got way too much comments on the length of the TMap process template ‘overview’ video, I know 38 minutes is long for listing to me, my wife even can hold it for 38 seconds, wen I start talking about my work ;-). So, I made a ‘community cut’, a shorter version with only the highlights of the extended version…
I’ll keep the YouTube constrains for other video’s, max 10 minutes. [post a comment if that's even too long]
just saw that the end is a bit strange/ abrupt, don’t know what went wrong, will change it on a latter time
TMap Process Template for VSTS2010 - Overview Video
This is an update of the work we have been doing regarding TMap [a widely adopted test approach] and VSTS2010. With the release of Beta1 of VSTS2010 we’ve started to build a TMap test process template. This 38 minutes video recording [silverlight] is an overview of this work in progress. Feel free to give us any kind of feedback, by using the comment form or by sending a mail directly at Clemens dot Reijnen at Sogeti dot nl and introduction story can be found here.