We at ITR have been using Use Case Point Estimation now for about 18 months and we are finding it to be very accurate and that it fits our business model nicely too. We use this technique to provide clients with indicative first up estimates (even though we work to time and materials), enabling them to come to some conclusion as to what features to build into their product at a particular juncture in time.
I have found this technique to work so well in fact and to blend so nicely with our agile practices, that I am going to move the estimation formula into an ASP.Net application and make it available from our Web Site when it goes online shortly. The application will include the ability to upload user stories (with attached Use Cases in XMI format).
I will post again soon when it’s available.
Well there he sits, Mr Average Joe Developer, reading up and trying to get ahead of the curve by playing with and testing the new PFX API, whilst he tier splits with Volta, tries to REST a little with ADO.Net Data Services, jump a cloud with the ISB under the illumination of some Silverlight and then it comes, the inevitable question: 
how do I fit Asp.Net Dynamic Data into my latest CTP scratch pad code. Ooops, I forgot to put on my polyglot cap and ask, should I be writing this in C# (with a dash of Spec#), F#, IronPython or IronRuby?
Ok, so for the duration of the last stanza I did have my tongue squarely in my cheek but the latest new tech (that I have cast my eye on), namely the ADO.Net Data Services, proposes some interesting questions. If your like me and you are a separation of concerns believer, then you will probably get the feeling in the first instance that this tech is not for you. Beware, looks can be deceiving and lets wait till we explore that API and bang out some proof of concept code and who knows, if the guys in that team can pull off the integration with the MVC (still in CTP) Framework from Gu and co, then maybe this blip on the tech radar is worth following for a bit longer.
From the onset it seems pretty clear though, this API is going to be well received and be of a lot of value to the smaller organisation’s that typically embody a project based 
business model and where slapping short lived applications together for a smallish number of users is a common requirement and fits the whole business alignment strategy in that context. Horses for courses my friends and definitely no dogma on this page.
As far as it working in my next architecture where I plan to implement Domain Driven Design; this API sounds as though it wont play in that space, that much seems clear at this juncture. The basic premise of this tech is that it will model Asp.Net pages in your project around your data model via entities of the LINQ to SQL or the Entity Framework variety and will use templates to dynamically represent CRUD(ish) pages based on that data model. No doubt the demo will look great and I can see the value proposition in segments of business, so this may fit the bill somewhere and sometime but generally speaking I don’t model my applications this way (even at the UI layer) and I don’t want to have to give up my maintainable, clean, separation of concerns and highly testable TDD / DDD / MV(P or C) environment just yet.
More investigation required.
I recently moved my blog and will reside here now for a great deal of time (all things being equal). Wilkommen (extent of my German these days)!
