Advertisements

Where does the acronym ALM (Application Lifecycle Management) come from?


I became interested today in where this ALM term comes from.  It is involved a lot with what Microsoft does on the Team Foundation Server (TFS) front and frankly, I’ve thought it to be just another marketing term for Software Engineering.  BUT, I wanted to investigate and dig deeper….

The best I can tell, the acronym ALM comes from PLM or Product Lifecycle Management.  The Wikipedia article on PLM has a good history of the term and how it came to be used at Chrysler in the mid 1980’s.  They basically started centralizing all designs, documentation, etc. of the Jeep Cherokee into one database to manage its creation.  Sounds a lot like ALM to me today.

It also makes sense that the term would come from manufacturing.  This article from 2002 talks about the transition in the manufacturing industry from Computer-Aided Design (CAD) tools to a more holistic approach of PLM.  There was also a boon of Computer Aided Software Engineering (CASE) tools in the 1980’s.  CAD leads to PLM.  CASE leads to ALM.  We both went from individual tools that did design, requirements, etc. and integrated them into one tool or system.  That seems to be the evolution.

The borrowing from manufacturing also makes sense as so much of Software Process comes from that industry. Kanban, Lean, CMMI, and on and on.  Deming, one of the greats in manufacturing process, is cited often in software process literature.

So there it is, ALM comes from PLM which all originated in the auto industry with the Jeep Cherokee.  Who would of thunk it? 🙂

Advertisements

Another example UML class diagram: The United States Congress


I did this recently with Visual Studio’s UML tools!  They’re not too shabby!  Enjoy!

Class Diagram of the US Congress

New User Voice Site for TFS and Visual Studio!!!!


Microsoft just created a new site for suggesting new features for TFS and Visual Studio at:

http://visualstudio.uservoice.com/forums/121579-visual-studio

This is great and seems to be much better than the Connect site.  I’ve already voted for upgrading the usability in Microsoft Test Manager, centralizing permissioning, and so much more!!!!

http://visualstudio.uservoice.com/users/21614007-woody

Lovin’ it.

.vdproj Setup Projects and TFS Build 2010


So you’re using .vdproj setup projects are you?  And you want to automate them with TFS 2010?  Well, you’re in the right place, although I would recommend you start moving those setup projects to a msdeploy  solution.

First, to automate the building of .vdproj project, you’re going to need to write your own msbuild file because they are not in msbuild format and therefore TFS Build does not know what to do with them.  I found some good examples on the net on how to do this, but I updated mine a little for 2010.  Here it is:

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
  <Target Name="Build">
    <PropertyGroup>
            <DevEnv>$(ProgramFiles)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.com</DevEnv>
            <SolutionFile>$(MSBuildProjectDirectory)\MySolution.sln</SolutionFile>
            <ProjectFile>$(MSBuildProjectDirectory)\MySetupProject\MySetup.vdproj</ProjectFile>
            <Configuration>Release</Configuration>
    </PropertyGroup>
    <Exec
          Command="&quot;$(DevEnv)&quot; &quot;$(SolutionFile)&quot; /Rebuild &quot;$(Configuration)&quot;
          /Project &quot;$(ProjectFile)&quot; /ProjectConfig &quot;$(Configuration)&quot; /Log"
          ContinueOnError="false"
         IgnoreExitCode="false"
         WorkingDirectory="$(MSBuildProjectDirectory)" />
  </Target>
</Project>

After you’ve done that save the msbuild file as, for example, AutomatedSetupBuild.proj and add it to source control at the same level as the solution file you intend to build.  Then select it when you are creating your build definition.

One last thing on drops.  If you intend to create a drop, there is a twist.  TFS Build usually overwrites the “OutputPath” property in msbuild files to the “Binaries” folder on the build agent at build time.  Since the “OutputPath” property does not apply here, you will need to overwrite it in the .vdproj file.  Simply open the .vdproj file in a text editor and find the word “Release”.  Change the “OutputFilename” to “..\\..\\..\\Binaries\\*.msi”.  My .vdproj file had an “8:” prefixing the path which I simply left.

You’re done now.  Enjoy!