TFS

Team System 2010: Static Code Analysis, easier to set rules

terje — Sun, 12 Jul 2009 16:41:01 GMT

In Visual Studio the settings for static analysis is done on the project property page, a tab called Code Analysis. You can set which code analysis rules you want to be active. The default in Visual Studio 2008 is to use all. If you run with this default setting you will generate a lot of "noise", since there are a large set of rules. You need to create a set containing the rules you and your team find are suitable for your organization and project. This set you have to apply to every C# project in your solution. In Visual Studio 2008 there is no easy way to do this. At Osiris we made an Addin to Visual Studio to ease this. We defined the set in a separate file, and used the Addin to apply that to all projects in a solution.

With Visual Studio 2010 this will be more easy, because in 2010 you can define sets of rules. It comes with a default list of sets. You can also define your own sets, based on any of the others.

To make your own rule set, just open any of the default ones, make any changes you like to it, and save it under a suitable name. A rule set file is created, which can be checked in together with the other files of the project. This file [rule set] can now be used by any other project you have. So you only need to define it once.

You still have to select it for all the projects in the solution, but this has been made easier by having solution properties, where Code Analysis is one of these setting pages:

It's then easy to select the rule set you want for all projects within your solution.

Mapping use cases to code

terje — Wed, 08 Jul 2009 19:30:24 GMT

There has always been a controversy between modeling and coding. All from the point where models are to be turned into code automatically, through the state where models are written and then forgotten after coding has started, to the point where one generates models from the code.

To me, code and model is representations of the same thing - the problem to be solved, or the solution to the problem. And when the solution matches the problem, which sometimes happens, all is well.

So the artifacts one make in a model IMHO it should be possible to map to code. I do believe that should be a strong guideline for which artifacts one uses in a model. If that holds, one can always reverse engineer a model from code, at least to a certain degree.

In order to make the picture more complete when one uses Use Cases for specifications is to add navigation diagrams to the suite. The term is coined by Manassis I think, and it shows how the different GUI pages are navigated. This takes form of a set of classes (one for each GUI page or independent part of a page) which depends on each other, where the dependency is named based on how you access the dependency. Ex.: “Button: Create New”. Although they say a use case diagram should be independent of the realization in form of GUI’s, I normally take a more pragmatic viewpoint, and connects these things together. One is to make a software program after all – not a theoretical thesis. I often connects a use case with a graphical page, or in some cases a page may encompass multiple use cases. Anyway, by using tracing from the use cases to the GUI pages, those relationships are taken care of, and a relationship matrix can show which use cases and which GUI’s are not connected, thus revealing missing specifications.

So, the use cases links to user interfaces (or messages for a message based system). Since the logic for the use case is not to be engraved into the user interface it has to be the Controller (or presenter or service component) that orchestrates the use case steps, hopefully most of it delegated down to the domain model. See Controller pattern within the GRASP patterns (Craig Larman).

Very often one uses the Use Case as the main work item for realizing a certain set of functionality, which encompass code on several layers, from the GUI layer, the controller layer, and on the domain layer, possibly also on the database layer. This duality, the use case both representing the code for the logic of the use case, and representing the whole work package for that behavior, is something I believe one just should accept, and not try to mitigate. It really poses no big problems, and mitigation of this would probably only cause over-complexity in the work item tracking or model.

Team System 2010 introduces the Layer Model, which can be used to enforce a more strict layering model in an application, making sure code is not placed inadvertently at the wrong layer, or crossing layer boundaries inappropriately. When one starts to take layering more seriously one also needs to be clear on which artifacts relates to which code-layer. The navigation diagram classes maps to GUI pages or GUI control classes. The Use cases maps to Controller classes. The domain model classes maps firstly to business class domain classes in code, and then, through some O/R mapping into a database model. Having a layering model, together with the necessary model elements, it should be possible to maintain a consistent relationship between model and code. One can then use whatever view one chooses and finds most convenient, and be sure that code and model is in sync. If the model then represents the specifications, the problem to be solved and the solution is also kept in sync.

Use Cases, User Stories and Scenarios - what are they - and how do they relate to TFS 2010

terje — Wed, 08 Jul 2009 12:07:09 GMT

All these three terms are used to describe the behavior of an application. They come from different process methodologies, and have different meanings, characteristics and are intended to be used differently.

Larry Guger also discuss these aspects and several others in his blog entries http://continuouslyintegrating.blogspot.com/2009/07/use-cases-and-visual-studio-2010-part-1.html and http://continuouslyintegrating.blogspot.com/2009/07/beginning-use-cases-identifying-actors.html.

The Use Case is the term used in UML and in the different Unified Process based methodologies. See http://en.wikipedia.org/wiki/Use_case for a good overall description. A use case is often looked upon as a more formal way of describing behavior, and which has to be accompanied by a detailed description following certain rules. However, a Use case can in fact be as light weight or as formal as one wants it to be. I find that this depends more on the process methodology one uses more than characteristics of the use case itself.

The User Story comes from the Scrum based processes, and is meant as a short concise way of capturing a users need for a certain behavior. See http://en.wikipedia.org/wiki/User_story for a useful description.

Scenarios comes as two different meanings, one is as a separate term used in agile modeling, see http://en.wikipedia.org/wiki/Scenario_(computing) for a description. It is very equal to a User Story, but I tend to see it as a more general term. The other meaning is as a certain path of actions for a use case. One talks of a "happy path" scenario, or an alternate scenario.

One can argue that a User Story can be converted into a Use Case, and there is a point in this. A Use Case is meant to describe an application behavior, whereas a User Story is used more freely to catch behavior "as is" from the product owner. This may lead to the case where multiple User Stories matches up to one Use Case, possibly as an Use Case with multiple scenarios, each scenario matching a User Story.

In the TFS 2010 these terms are used at different places in the suite. In the architect diagrams one can draw up a Use Case diagram, and in the Work Item store you can create User Stories. You can even create a User Story item from the Use Case artifact in the Use Case diagram. So these items can be related in TFS 2010. However, since they are not coming from the same methodologies, the mixing of these can be confusing.

I’m very pragmatic (even if I’m a theoretical guy), and I’ve noticed people have problems with these terms. I often just say that it’s more important to catch the behavior aspect of the requirements, regardless of whether you call it Use Case, User Story or Scenario. Scott Ambler has an interesting article on Agile Maturity (http://www.ibm.com/developerworks/blogs/page/ambler?entry=apmm_overview). I’ve noticed the same thing, that dependent upon the maturity of the product owners, the developers (really all involved), one uses the process differently. Also, dependent upon the size of the project, the maturity of the organization, the clarity of what is to be developed, and who’s the client and how is the contract specified, the need for formalized specifications vary based on these factors. A use case specification is more formal, than a set of user stories. Although as you so nicely shows, use stories can be converted into use cases. I fully agree. But I feel there is a one-to-many relationship between use case and user story. And then I’m not quite sure if I want that within the TFS's work item system. It just becomes too much.

I tend to take a pragmatic approach to things like this, and just say that you could argue that these terms are "equal enough" to be used interchangeably. In a real setting I would tend to try to catch as much as possible from a client (product owner) in terms of user stories, and during analysis convert these to Use Cases. After having made my set of use cases, and made sure I had captured enough to start working with code, I would convert these into work items to start the show. In order to make the terms less confusing, I would rename the User Story work item types into Use Case work item types. No other changes really required. And then I would simply use the actual User Stories as yellow notes in a customer meetings.

It is said that a Use Case need a more thorough specification, detailing the action steps it should take. One thing I’ve started to recognize is that a set of test cases is very similar to a set of use case action steps, and should never be less than these steps. So, to save on work to be done, one could simply skip the action steps, and just use the test cases with their steps as the specification. It might be that the Microsoft guys have been thinking in this route when they connected the User Story so directly with the Test Cases. It makes sense, and gives a leaner specification. But, it makes the User Story look even more like a Use Case.

TFS Workitems : On the fields, their namespaces and in which workitem types they are used

terje — Sun, 14 Dec 2008 22:06:34 GMT

At the moment there are five different popular process templates, three from Microsoft official, one on Codeplex (by some Microsoft guys afaik), and one from Conchango. The fields defined in the workitemtypes found in these templates belongs to a set of namespaces. The System namespace is a predefined Microsoft namespace, with special behavior. The other ones are in reality free text. However, since some effort has been placed on defining these namespaces, and some of these fields are used in several reports, in mappings to Microsoft Project etc., it is wise to adhere to these definitions. It will at least reduce the work you have to do if you're modifying them, or defining your own types. It is also wise to keep the fields named as equally as possible between types, and even processes, because it also simplifies querying across types. See http://teamfoundation.blogspot.com/2008/05/work-item-customization-tidbits-part-1.html for a great tutorial on how-to-do-it.

I have listed out the different namespaces, and linked the fields up to whatever workitem type is using them. I've only included the Microsoft'ish templates - the Conchango template only use the System namespace in addition to its own defined namespace fields.

The Process templates described are:

Microsoft CMMI 4.2 CMMI Download

Microsoft Agile 4.2 Agile Download

Microsoft eScrum 1.1 eScrum Download

Codeplex VSTS Scrum 2.1 VSTS Scrum Download

Even if a workitem type has the field defined, it doesn't mean it really uses the field, that is, fills it with useful information.

The different namespaces used in these processes are listed below, and their details below that again:

Namespace	No of defined fields	Comment
System	26	These fields have special behavior. Even if they are not present in a WIT, they can still be filled with information which can be read from the API or a query. See details http://msdn.microsoft.com/en-us/library/ms194971.aspx.
Microsoft.VSTS.Common	18	Here they've packed in the most common fields, which is used across several processes and types.
Microsoft.VSTS.Build	2	Used by the build system. See details here
Microsoft.VSTS.Scheduling	7	Used in Microsoft Project mappings. See f.e. http://msdn.microsoft.com/en-us/library/ms364081.aspx and http://www.devx.com/dotnet/Article/30187/1954
Microsoft.VSTS.Test	3	Used by the test system See http://msdn.microsoft.com/en-us/library/ms194965.aspx
Microsoft.VSTS.CMMI	40
Microsoft.eScrum.Common	4
Microsoft.eScrum.Product	2
Microsoft.eScrum.Sprint	3
Microsoft.eScrum.Retrospective	4
Microsoft.eTools.Bug	18	Probably a leftover from older days, guess it also should have been eScrum, not eTools
Microsoft.eScrum.Task	2
Scrum	4

System Namespace: (This is the only namespace which is also documented on MSDN)

	Used in CMMI	Used in Agile	Used in eScrum	Used in VSTS Scrum
AreaId			Bug
AreaPath	Risk,Review,Req,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	PBI,PD,Bug,Task	Backlog,UserStory,Defect,Impediment,Release,Review
AssignedTo	Risk,Review,Req,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	PBI,PD,SD,SR,Bug,Task	Backlog,UserStory,Defect,Impediment,Release,Review
AttachedFileCount			Bug
AuthorizedAs			Bug
ChangedBy	Risk,Review,Req,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	PD,SD	Backlog,UserStory,Defect,Impediment,Release,Review
ChangedDate	Risk,Review,Req,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	PD,SD,Bug	Backlog,UserStory,Defect,Impediment,Release,Review
CreatedBy	Risk,Review,Req,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	PD,SD,Bug	Backlog,UserStory,Defect,Impediment,Release,Review
CreatedDate	Risk,Review,Req,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	PD,SD,Bug	Backlog,UserStory,Defect,Impediment,Release,Review
Description	Risk,Review,Req,Issue,CR,Task	Scenario,Risk,QoS,Bug,Task	PBI,PD,SD,SR,Bug,Task	Backlog,UserStory,Defect,Impediment,Release
ExternalLinkCount			Bug
History	Risk,Review,Req,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	(PBI),PD,SD,SR,Bug,(Task)	Backlog,UserStory,Defect,Impediment,Release,Review
HyperLinkCount			Bug
Id	Risk,Review,Req,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	PBI,PD,SD,SR,Bug,Task	Backlog,UserStory,Defect,Impediment,Release,Review
IterationId			Bug
IterationPath	Risk,Review,Req,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	SD,SR,Bug,Task	Backlog,UserStory,Defect,Impediment,Release,Review
NodeName			Bug
Reason	Risk,Review,Req,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	Bug	Backlog,UserStory,Defect,Impediment,Release,Review
RelatedLinkCount			Bug
Rev			Bug
RevisedDate			Bug
State	Risk,Review,Req,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	PBI,PD,SD,SR,Bug,Task	Backlog,UserStory,Defect,Impediment,Release,Review
TeamProject			Bug
TeamProject
Title	Risk,Review,Req,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	PBI,Bug,Task	Backlog,UserStory,Defect,Impediment,Release,Review
WorkItemType			Bug

For CMMI: CR = Change Request, QoS = QualityOfService requirement, Req = Requirement

For eScrum: PD = ProductDetails, SD = SprintDetails, SR = SprintRetrospective, Task = SprintTask, PBI = ProductBacklogItem

Microsoft.VSTS.Common namespace

Name	Used in CMMI	Used in Agile	Used in eScrum	Used in VSTS Scrum
ActivatedBy	Risk,Review,Requirement,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	Bug	Backlog,UserStory,Defect,Impediment,Release,Review
ActivatedDate	Risk,Review,Requirement,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	Bug	Backlog,UserStory,Defect,Impediment,Release,Review
ClosedBy	Risk,Review,RRequirementeq,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	Bug	Backlog,UserStory,Defect,Impediment,Release,Review
ClosedDate	Risk,Review,Requirement,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	Bug	Backlog,UserStory,Defect,Impediment,Release,Review
Discipline	Task	Task		Backlog,UserStory
Exit Criteria	Risk,Requirement,Task	Scenario,Risk,QoS,Task		Backlog,UserStory,Release
Issue	Risk,Requirement,Issue,Bug,Task	Scenario,Risk,QoS,Bug,Task		Backlog,UserStory,Defect,Impediment,Release
IssueType			Bug
Priority	Risk,Requirement,Issue,CR,Bug,Task	Bug	Bug,Task	Backlog,UserStory,Defect,Impediment,Release
QualityOfServiceType		QoS
Rank	Risk,Requirement,Task	Scenario,Risk,QoS,Bug,Task	Bug	Backlog,UserStory,Release
Regression			Bug
ResolvedBy	Risk,Review,Requirement,Issue,CR,Bug,Task	Scenario,QoS,Bug	Bug	Backlog,UserStory,Defect,Impediment,Release,Review
ResolvedDate	Risk,Review,Requirement,Issue,CR,Bug,Task	Scenario,QoS,Bug	Bug	Backlog,UserStory,Defect,Impediment,Release,Review
ResolvedReason		Bug	Bug	Defect
RoughOrderOfMagnitude		Scenario,QoS
Severity	Risk,Bug,Task	Risk	Bug
StateChangeDate	Risk,Review,Requirement,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	Bug	Backlog,UserStory,Defect,Impediment,Release,Review
Triage	Requirement,Issue,CR,Bug,Task	Bug	Bug	Defect,Impediment

Microsoft.VSTS.Build namespace

Name	Used in CMMI :	Used in Agile :	Used in eScrum	Used in VSTS Scrum:
FoundIn	Risk,Bug	Risk,Bug	Bug	Defect
IntegrationBuild	Risk,Review,Req,Issue,CR,Bug,Task	Scenario,Risk,QoS,Bug,Task	Bug	Backlog,UserStory,Defect,Impediment,Release,Review

CR = Change Request, QoS = QualityOfService requirement, Req = Requirement

Microsoft.VSTS.Scheduling namespace

Name	Used in CMMI	Used in Agile	Used in eScrum	Used in VSTS Scrum
RemainingWork	Risk,Req,CR,Bug,Task	Task	Task	Backlog,UserStory,Release
CompletedWork	Risk,Req,CR,Bug,Task	Task	Task	Backlog,UserStory,Release
BaselineWork	Risk,Req,CR,Bug,Task	Task	PBI,Task	Backlog,UserStory,Release
StartDate	Task	Scenario,QoS,Task		Backlog,UserStory,Release
FinishDate	Task	Scenario,QoS,Task		Backlog,UserStory,Release
TaskHierarchy	Task	Task	Task	Backlog,UserStory,Release

CR = Change Request, QoS = QualityOfService requirement, Req = Requirement

Microsoft.VSTS.Test namespace

Name	Used in CMMI	Used in Agile	Used in eScrum types	Used in VSTS Scrum

TestName	Bug,Task	Risk,Bug	Bug	Defect
TestId	Bug,Task	Risk,Bug	Bug	Defect
TestPath	Bug,Task	Risk,Bug	Bug	Defect

Microsoft.VSTS.CMMI namespace (Not used in Agile or eScrum)

Name	Used in CMMI	Used in VSTS Scrum
ActualAttendee[1-8]	Review
Analysis	Issue	Impediment
Blocked	Risk,Requirement,CR,Bug,Task	Backlog,UserStory,Defect,Release
CalledBy	Review	Review
CalledDate	Review	Review
Comments	Review	Review
Committed	Requirement
CorrectiveActionActualResolution	Issue	Impediment
CorrectiveActionPlan	Issue	Impediment
Escalate	Issue	Impediment
Estimate	Risk,Requirement,CR,Bug,Task
FoundInEnvironment	Bug
HowFound	Bug
ImpactAssessment	Requirement
ImpactOnArchitecture	Change Request
ImpactOnDevelopment	Change Request
ImpactOnProjectPromise	Issue	Impediment
ImpactOnTechnicalPublications	Change Request
ImpactOnTest	Change Request
ImpactOnUserExperience	Change Request
Justification	Change Request
MeetingType	Review	Review
Minutes	Review	Review
MitigationPlan	Risk
MitigationTriggers	Risk
OptionalAttendee[1-8]	Review
Probability	Risk
ProposedFix	Bug
Purpose	Review	Review
RequiredAttendee[1-8]	Review
RequirementType	Requirement
RequiresReview	Task
RequiresTest	Task
RootCause	Bug
StepsToReproduce	Bug
SubjectMatterExpert[1-3]	Requirement
Symptom	Bug
TargetResolveDate	Issue	Impediment
TaskType	Task
UserAcceptanceTest	Requirement	UserStory

And then some special namespaces which are only used by one process

Microsoft.eScrum.Common namespace

Name	Used in eScrum
Category	ProductBacklogItem,SprintTask
Order	ProductBacklogItem,SprintTask
Goals	ProductBacklogItem,SprintDetails
Source	ProductBacklogItem

Microsoft.eScrum.Product namespace

Name	Used in eScrum
MembersXml	ProductDetails
BugDatabasesXml	ProductDetails

Microsoft.eScrum.Sprint namespace

Name	Used in eScrum
StartDate	SprintDetails
EndDate	SprintDetails
MembersXml

Microsoft.eScrum.SprintRetrospective

Name	Used in eScrum
Date	SprintRetrospective
WhatWentWell	SprintRetrospective
WhatDidNotGoWell	SprintRetrospective
Improvements	SprintRetrospective

Microsoft.eTools.Bug namespace

Name	Used in eScrum
ReproSteps	Bug
DevEstimate	Bug
TestEstimate	Bug
PMEstimate	Bug
Environment	Bug
Accessibility	Bug
Source	Bug
HowFound	Bug
Market	Bug
OSPlatform	Bug
Browsers	Bug
SourceID	Bug
Cause	Bug
Change	Bug
KBNeeded	Bug
Product	Bug
Release	Bug
Milestone	Bug

Microsoft.eScrum.Task namespace

Name	Used in eScrum
ProductBacklogItemId	Task
Discovered	Task

Scrum namespace

Name	Used in VSTS Scrum
Complexity	Backlog,UserStory,Release
Acceptance	UserStory
Owner	UserStory
BuildInstructions	Release