aspose file tools*
The moose likes Agile and Other Processes and the fly likes functional point analysis Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "functional point analysis" Watch "functional point analysis" New topic
Author

functional point analysis

rabia abdur rab
Greenhorn

Joined: Jul 04, 2005
Posts: 1
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
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
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


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Don Stadler
Ranch Hand

Joined: Feb 10, 2004
Posts: 451
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
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
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
Ranch Hand

Joined: Oct 12, 2000
Posts: 1874
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
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
Ranch Hand

Joined: Feb 10, 2004
Posts: 451
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
Ranch Hand

Joined: Oct 12, 2000
Posts: 1874
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
Greenhorn

Joined: Jun 13, 2005
Posts: 10
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
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
>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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
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
Greenhorn

Joined: Jun 13, 2005
Posts: 10
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
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608

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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: functional point analysis