Rosario – Project Estimating with Team Architect Diagrams

An idea [and early implementation ] of our “Enable ALM by Automation” vision within Rosario.

alm

While VSTS with TFS is great in measuring, time tracking, project planning and other project management kind of tasks it misses the early phase where the project team needs to estimates the project. With Rosario Team Architect this important missing piece in Application Lifecycle Management can be realized, by making an “connected” viewpoint for business estimation and measurement.

Project Estimation.
I think, I don’t have to talk about why there is a need for project estimation [it would be a very long post], how it’s done and what needs to be in place to do it “right” [is an estimation ever right??] is more interesting.
The classic estimation book 'Software Estimation: Demystifying the Black Art', a must read anybody interested in software estimation, is a good start in capturing the needs for a good enough software estimation implementation. The next “deadly sins” are distilled out of this presentation “10 Deadly Sins of Software Estimation” from the author “Steve McConnell”.

  • Confusing targets with estimates
  • Saying “yes” when you really mean “no”
  • Committing to estimates too early in the cone of uncertainty
  • Assuming underestimation has a neutral impact on project results
  • Estimating in the “impossible zone”
  • Overestimating savings from new tools or methods
  • Using only one estimation technique
  • Not using estimation software
  • Not including risk impacts in estimates
  • Providing off-the-cuff estimates

Before we can use this list and look at Rosario Team Architect and what the diagrams can mean for software estimation we have to dive in to the different estimation methodologies. Lucky me somebody already did that in this paper “An Effort Estimation by UML Points in the Early Stage of Software Development”, and the writers also point to the pain point of these methodologies:

Common problems with these approaches are lack of early estimation, over-dependence on expert decision, and subjective measurement of each metric. A new approach is required to overcome these existing difficulties. We move upstream in the software development process to requirement analysis and design.

pros and cons of software estimation practicess

The missing estimation style in this table is the most interesting one for us, Use Case Points. [it’s the topic of the report, so that’s the reason it’s missing]. Use Case Points is an estimation method based on UML Use Cases. From UML Distilled:

Use Cases are a technique for capturing the functional requirements of a system.

And requirements is exactly what we need as bases for an estimation.

uc

Use-Case-Points [UCP].
So, Use Case Points is based on Use-Cases with al it’s pros and cons. But, the way it works is pretty easy. When you have your Use-Case in place you can start counting “points” the same way as with for example Function Points. Some cases are harder to implement than others so those will have more points… easy going.

To be more precise Use-Case Points exists of:

  • the number and complexity of the use cases in the system
  • the number and complexity of the actors on the system
  • various non-functional requirements (such as portability, performance, maintainability) that are not written as use cases
  • the environment in which the project will be developed

and ranking:

  • Rank Actors as simple (1 point), average (2 points), or complex (3 points):
    • Simple: a machine with a programmable API
    • Average: either a human with a command line interface or a machine via some protocol (no API written)
    • Complex: a human with a GUI
  • Rank use cases as simple (5 points), average (10 points), or complex (15 points):
    • Simple: fewer than 4 key scenarios or execution paths in the UC
    • Average: 4 or more key scenarios, but fewer than 8
    • Complex: 8 or more key scenarios

Readings about Use-Case Points:

Automation.
From a Rosario Team Architect point of view this is an interesting estimation method… because it can be automated! Not that we only should use UCP just because it can be automated, put automation of the estimation process will give us a big benefit in making estimation more mature within the organization.

Looking at Steve McConnell’s deadly sins we can imaging that one of the important capabilities we need from estimation tooling is historical data, “Providing off-the-cuff estimates”. Without historical data estimation is useless, error prone and unpredictable, with automated estimations this can be realized. Another important pro with automation is that we are reproducible, running the estimation again will result in the same numbers, which give the historical data some more value ;-)

TFS is a databasesystem so capturing historical data shouldn’t be a big problem.

boeing
[Process Improvement Journey (From level 1 to Level 5) The Boeing Company]

Deadly sins tackled:

  • Saying “yes” when you really mean “no”
  • Not using estimation software
  • Providing off-the-cuff estimates

One other important advantage you get from automation the estimation process with Rosario and UCP is collaboration, collaboration in the early phase of the project lifecycle between business and development. Estimation is important for the business to get budget and for the project lead for the planning, while working together on the Use-Cases business can immediately see what the impacts are in terms of budget, so there will be less unnecessary and incomplete requirements.

Drawbacks and points to look at:

1. Use Case Granularity and Complexity…
There is no standard in writing Use Cases. You can define very high-level cases and very low-level detailed use-cases, nobody will stop you from doing that. This is one major challenge in estimation with Use-Cases. When writing to high level cases you are in the neighbourhood of the deadly sin “Estimating in the “impossible zone” and “Committing to estimates too early in the cone of uncertainty”.

Cone01
[ The Cone of Uncertainty from http://www.construx.com/Page.aspx?hid=1648]

For sure it’s possible to estimate with use-cases in a more early stage of the project using more higher level use cases, the “initial state”, but keep in mind that the uncertainty will be bigger in this stage. When the project evolves and more information comes available, more detailed use-cases are made, you can tune the estimation and with version control of previous estimations and use-cases you will have an mechanism to assess your previous estimation. With this assessment you can make this process of early estimation in the lifecycle more mature. Actually this learning process must be in place during the whole lifecycle, for estimation and for all the other things. [see the Boeing story]

This problem of differences in granularity and complexity of use-cases is recognized by the industry and many people and organizations have a solution for it. For example Capgemini use Smart Use Cases which are generic use case types.

ADP

I really like this approach of a kind of repository of UseCase stereotypes, although you must be aware that a use case is technology independent adding technology in to use cases will make the world more fuzzier.

2. Technology/ platform independence…
Use Case is document which describes “WHAT” our system will do at high-level and from user perspective. Use Case does not capture “HOW” the system will do. It’s impossible to make an “platform independence” estimation. Platforms, technologies, tools and languages all have impact on the speed of development. While Use-Cases, actually UML in its whole, is platform independent, estimation can’t be, so there needs to be a place in the Use-Case-Points methodology for differences in platforms, technologies, tools and languages . With UCP this is minimal done by the identification of actors.

Actor identification need technical details: In order that the actor is classified we need to know technical details like which protocol the actor will use. So estimation can be done by technical guys.
[How to Prepare Software Quotation]

independence-signing
[ almost 4th of July :-) The signing of the Declaration of Independence 4th July 1776 ]

Actually, you don’t want technology in Use Cases, it’s mend to be independent so we need to keep it that way. Another way to put technological knowledge in the estimation is add this information to the complete estimation. For example, most organizations already have chosen their platforms, technologies, tools and languages and Enterprise Architecture will monitor it that every project uses their guidelines. So adding a reference to these guidelines while estimating will bring technology in the estimation. Historical data will need to have this information and projects can base their estimation on this, guideline referenced, data. These Enterprise Architectural guidelines can be measured up-front and will get fine-tuned with every project. With that identifying risks when using new technologies in an early stage.

when capturing this in with automation, you have Deadly sins tackled:

  • Committing to estimates too early in the cone of uncertainty
  • Estimating in the “impossible zone”
  • Overestimating savings from new tools or methods
  • Not including risk impacts in estimates

Deadly sins not tackled:

  • Confusing targets with estimates [for sure don’t put the estimation in TFs as workitems, maybe something like a workitem where the project lead can upgrade them to workitems. But that’s already very very tricky ]
  • Assuming underestimation has a neutral impact on project results [don’t assume that]
  • Using only one estimation technique [with one technique automated there is time left for the other…]

Summary.

So, there has to be many capabilities in place before we can make an mature automated estimation process with Rosario Team Architect.
But, we can start small… extend the Use-Case Diagram with additional “complexity” information [also granularity information], add an command which captures the Use-Cases and collect the points. The very near next step would be historical data with the possibility of referencing guidelines. In the future we could make a repository of Use-Case stereotypes like the smart use cases from Capgemini.

[next post an early implementation]

Comments (1) -

hey..

i've read in the above article as "Not using estimation software "Not using estimation software" is a deadly sin.

In this regards, help me with the tools that you recommend, towards using the Estimation Software. What methods are wise and are there any good articles that are in your view point to study (or) give a look at..

Thanks for reading

Add comment


Şarkı Sozleri