functional point analysis

[rabia abdur rab]

hie all,
im working on functional point analysis for size estimation of a software.. need some guidance regarding how to select the data element types and fil types refrenced for transactions and more over how to select record element types for internal logical files and external interface files.

the documentation about the application that i have is a software functional specification document.

need help urgent.
kindly reply!

[Scott Ambler]

I googled the term "function point analysis" and the first page was http://www.ifpug.com/fpafund.htm.

Further down I found http://www.stsc.hill.af.mil/crosstalk/2001/02/dekkers.html .

In my opinion, FPA generally turns out to be pretty big waste of time. It looks good because it's scientific and detailed, but in the end the best estimates are produced via my estimating tips.

- Scott

[Don Stadler]

I agree with Scott here. FP's are one of those things which look great from the 50,000 meter level but don't make much sense on the ground.

[Scott Ambler]

A major problem with FPs is that they take a lot of effort to calculate, and in practice the answer you get is no better than simply talking with someone with some experience building what you're working on. Worse yet, because it's so much effort you fool yourself into thinking that you must have done it right.

- Scott

[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
Shailesh
[ July 13, 2005: Message edited by: shailesh sonavadekar ]

[Ilja Preuss]

Of course most often you need to have an idea of how long a project roughly will take before considering wether to actually tackle it.

One way to get that number is the XP Release Planning Game (which is strongly influenced by how the planning is done in Scrum). See http://extremeprogramming.org/rules/planninggame.html for an introduction.

[Scott Ambler]

Fundamentally estimates are really only good guesses, so you should treat them as such. The XP planning game works really well, but you need to be allowed by management to actually do it. Many organizations will force you into a reasonably inane estimating process because management actually believes it works (regardless of all evidence to the contrary). The longer out your estimate goes, the greater the range of uncertainty.

Fundamentally, the only true estimate is "how much are you actually willing to spend?"

- Scott

[Don Stadler]

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
Shailesh

[ July 13, 2005: Message edited by: shailesh sonavadekar ]

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 ]

[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 ]

don , thanks for the input. the method in Sir Barry Boehm books are toatally diffrent. they are based on kloc or sloc. so , it is dependent om programming language & customer who is not that technical is not interested in listening technical jargon from you. there FP scores as it is independent of language & you can talk in terms of Functionality of ther software. please correct me if i am wrong.

still , thanks for the input. cocomo is time tested method . there is no second opinion abt. the book & greatness of Sir Barry Boehm for his contributions to Software engineering field.

BR
Shailesh

[ranjit roy]

After going through all the posts, I am adding my thoughts:

>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!

"Fundamentally estimates are really only good guesses, so you should treat them as such" - Scott Ambler - I'd like to paraphase - educated guesses - education derived from experiences that relate to technology platforms, vertical expertise, expertise of available resources, and others

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

cheers
ranjit

[Scott Ambler]

>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)

Yes, one must still estimate for the reasons that you've given. Just as important, one must also educate these folks in the realities of estimating. It's incredibly common for people to do a complex estimating technique such as COCOMO or FPs and assume that the answer must be correct because of all the effort they put in. It's also incredibly common for people to follow simple techniques, such as I described at Agile Project Planning Tips -- Estimating, and assume that the estimate isn't very good even though it's likely to be better than the estimate produced by complex techniques.

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!

Yes, the technologies often change much faster than the bureaucrats can handle. Worse yet, the people doing the estimating with these techniques are often the people who aren't building the system -- they often don't have experience with the technologies at hand, nor are they committed to the estimate.

Both FPA and COCOMO are good techniques, when applied properly, but unfortunately they rarely seem to be applied appropriately from what I can tell.

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

There is nothing special about use case points, it's just one technique to develop an estimate based on some form of abstraction of the functionality. It's basically a less detailed form of FPA when you think about it.

- Scott

[Ilja Preuss]

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).

[Stan James]

We used to do estimates by use case (Small, Medium, Large, 2xLarge) on a spreadsheet that mapped sizes to numbers and translated the sum into person-months. We switched to estimating stories. There are many more small stories than large use cases. The estimates tend to be closer to reality and easier to adjust over time.

[Scott Ambler]

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).

Agreed.

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.

- Scott

[ranjit roy]

Originally posted by Scott Ambler:


Agreed.

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.

- Scott

One of the disciplines of RUP is Business Modeling:
The aim of business modeling is to establish a better understanding and communication channel between business engineering and software engineering. Understanding the business means that software engineers must understand the structure and the dynamics of the target organization (the client), the current problems in the organization and possible improvements. They must also ensure a common understanding of the target organization between customers, end users and developers.

The RUP's business modeling workflow explains how to describe a vision of the organization in which the system will be deployed and how to then use this vision as a basis to outline the process, roles and responsibilities.

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.

The Business Use Cases and other information gathered (org structure, users, workflow etc.) are all inputs to Use Case modeling (the essential/detailed/effective use cases) that provides detailed undestanding of the system to be developed

So when RUP/UP is Use-Case driven, wouldnt it include the entire Business Modeling discipline- Vision, Feasibility analysis, Business Use Case Model Business Architecture, Use Case Model, 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

[Scott Ambler]

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.

Exactly. I've been saying this for years: The BM discipline is really requirements elicitation, the Requirements discipline for the most part is Analysis, and the Analysis & Design discipline is mostly Architecture & Design. I suspect that in the transition of Objectory over to Rational, see History of the UP, that they got confused as to the purposes of each discipline (workflows at the time).

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

Exactly. You need to have RUP experience to successfully tailor RUP, but to be successful enough to get good experience you need to tailor it first. Many organizations fail with RUP because they don't get outside help.

- Scott