Originally posted by shailesh sonavadekar:
hi there , scott. thanks for the input. even though it is a view at 50000 meter , there is any other way for estimating the size of the software , developemtn effort in caledar month , which is independent of language & functionality ? what is your take ? which is the best method ? or there is some improvement over FP ?
the projects involving agile methodologies , what is the best way to estimate to estimate size & effort ? or it should not be done at all ? just go one delivering in increments ?
with warm regards
[ July 13, 2005: Message edited by: shailesh sonavadekar ]
Originally posted by Don Stadler:
Shailesh, one could do much worse than read
this book for probably the most detailed treatment of the gentle science of estimating ever written. It's overkill for a Struts project, though.
[ July 14, 2005: Message edited by: Don Stadler ]
>Estimation is a black art (still is!)
>Estimation is an empirical science
>Estimation is in the eyes of the beholder
>Estimation figures are not sacrosanct (most times - planned and actual values may differ)
>No two methods are likely to yield identical values
>No two entities (individuals or companies) may come up with the same set of estimation figures
Having said all this, one must still estimate. Even when using the best tools, best methodology, and the best individuals who are using it, there is pressure from management, from sales and marketing to clinch the deal at any cost (which may require shaving off a fair amount from original estimates)
FPA - by its very name, one needs to be a functional expert to carry out this estimation - i.e. understand the functionality (Business Rules/Workflow/etc) in order to arrive at estimates
Barry Boehm's SLOC-driven estimates resulting in COCOMO II have been arrived at empirically. However, changing technologies, new fads, shortage of time to deliver, competition, management focus, and a myriad other issues all have impact on estimation. SLOC's will now need to be revised for .NET, web services and SOA - the big companies are swearing by the last two-named!
Another option is to estimate using Use Case Points. If one were using UML, functionality is captured using Use Cases - from which are derived the Analysis and Design models, Implementation Model, Deployment Model, and Test Model - In fact a disucssion on Use Case Points (which doesnt seem to have much visibility) would be useful
As an aside, Use Cases don't have much to do with UML. UML is a language for diagrams, Use Cases are textual (don't confuse them with Use Case diagrams).
Originally posted by Scott Ambler:
Unfortunately, the RUP marketing rhetoric tries to connect itself to the UML via the names (both have Unified in them), and the fact that they each sort of originated from Rational (now a subsidiary of IBM). The RUP claims to be "use case driven", although you really want to be requirements driven (see The EUP Best Practices for a discussion). So, there's some pretty good reasons why people seem to comingle use cases into the UML.
Aren't Requirements - functionality, business processes, workflow, org structure, user hierarchy, etc. captured in Business Modeling? It speaks of business use cases and business entities and concepts such as Activity Based Costing, Business Architecture, etc.
My personal viewpoint - RUP by itself is a behemoth; a lone individual trying to conquer RUP may well be trampled underfoot. Since any process needs to be tailored specifically towards a project, an understanding of RUP is required before one can have the confidence to tailor - just as RUP was not built in a day, undestanding RUP cannot happen in a day - it's going to take time and concerted effort of some dedicated folks