.Net 1.1, Visual Studio 2003, and TFS 2010

So, you have some old .Net 1.1 apps that you don’t want to upgrade, BUT you want to use TFS 2010 for your source control.  Well you are in for a treat! (kidding)

First, you’re condemned to using VS 2003, because VS 2005, 2008, and 2010 only deal with .Net 2.0 and higher.

Second, because of this, you’re condemned to using the TFS 2010 MSSCCI provider; which is a not very well documented, unsupported by MS free tool. 🙂 (Have fun)

This guy has a great post with screenshots to lead you through the gauntlet!

Third, heaven help you if you’re migrating your source from another source control provider like SourceSafe or PVCS.  You’ll need to unbind the code from the old source ccontrol provider and then re-bind it to TFS 2010.  A treachous course that shouldn’t be taken lightly.

But otherwise, have fun!


Great article on distinction between Software Engineering and Software Development

Even though this article is five years old, it is just as salient and relevant today as then.  The author’s main argument is that software development is applied software engineering.  What a great way to think about the two concepts!!!  I think he’s exactly spot on, but it’s hard to get to this idea because of our experience of engineering is applied physics and physics is applied math.  I’ve never thought about applied engineering!  I always thought it should be applied computer science, but I was never comfortable with that idea.  I rarely use concepts from CS.  Maybe algorithms, but that’s about it.  This really fits!!  I encourage you to read this article if you’re interested in how our field is shaping up in this century!


An example UML class diagram

I made this in my graduate class for an airline ticketing system.  Enjoy!!

Class Diagram

CMMI version 1.3 and Agile

Well, the Software Engineering Institute (SEI) just published the newest version of the venerated CMMI and there are many side notes in the CMMI-DEV version that touch on using an Agile methodology with CMMI.  I’ve always thought this was possible and I’m glad to see the SEI has taken the lead.

For example, here is the “Agile note” in the configuration management section:

In Agile environments, configuration management (CM) is important because of the need to support frequent change, frequent builds (typically daily), multiple baselines, and multiple CM supported workspaces (e.g., for individuals, teams, and even for pair-programming). Agile teams may get bogged down if the organization doesn’t: 1) automate CM (e.g., build scripts, status accounting, integrity checking) and 2) implement CM as a single set of standard services. At its start, an Agile team should identify the individual who will be responsible to ensure CM is implemented correctly. At the start of each iteration, CM support needs are re-confirmed. CM is carefully integrated into the rhythms of each team with a focus on minimizing team distraction to get the job done.

I especially like this one from the Requirements Development section:

In Agile environments, customer needs and ideas are iteratively elicited, elaborated, analyzed, and validated. Requirements are documented in forms such as user stories, scenarios, use cases, product backlogs, and the results of iterations (working code in the case of software). Which requirements will be addressed in a given iteration is driven by an assessment of risk and by the priorities associated with what is left on the product backlog. What details of requirements (and other artifacts) to document is driven by the need for coordination (among team members, teams, and later iterations) and the risk of losing what was learned. When the customer is on the team, there can still be a need for separate customer and product documentation to allow multiple solutions to be explored. As the solution emerges, responsibilities for derived requirements are allocated to the appropriate teams. (See ―Interpreting CMMI When Using Agile Approaches‖ in Part I.)

Download the latest CMMI-DEV and enjoy!