File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes Software by numbers: Chapter 2 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Software by numbers: Chapter 2" Watch "Software by numbers: Chapter 2" New topic
Author

Software by numbers: Chapter 2

Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
I'm reading through Chapter 2 - The new ROI of the book available on Amazon. Given that we can make numbers say pretty much anything, I'm really curious to know where all the figures in the example (p. 19) come from. Are they based on a real project that took place in the past or are they purely speculative and imaginary?
Just asking...
[ April 29, 2004: Message edited by: Valentin Crettaz ]

SCJP 5, SCJD, SCBCD, SCWCD, SCDJWS, IBM XML
[Blog] [Blogroll] [My Reviews] My Linked In
Jane Cleland-Huang
Author
Ranch Hand

Joined: Feb 28, 2004
Posts: 32
First of all THANKS for buying our book. I hope you enjoy reading it.
Just to provide some context for others reading this post - in Chapter 2 we create two spreadsheets to illustrate the benefits of incremental delivery vs. big bang delivery.
So the question is 'where do the numbers come from?'
First I should say that all of the numbers of the book are derived from our actual experience but due to non disclosure agreements cannot be actual numbers from projects. As we said in the book, the original ideas for IFM originated from a real project in which Mark won the bid for a contract - just because he presented the numbers to the client showing incremental delivery in exactly this way.
Having said that - the numbers reflect very meaningful and realistic values for a large project.
A second thought is also that to convince yourself you should take numbers from any project you may be familiar with and plug them into this type of spreadsheet. You will find that as long as the project can be decomposed into increments that have the ability to deliver functionality early, it is very likely that the returns on your project will be superior if delivered incrementally. I say "likely" because as we show in the two spreadsheets, there are obviously additional costs associated with incremental delivery and these must be taken into consideration. Usually the benefits of early returns far exceed the penalty of additional costs.
btw we have a spreadsheet posted at our website http://www.softwarebynumbers.org under Tools. As a STRONG DISCLAIMER, this spreadsheet has many limitations and is NOT robust (primarily because all the macros etc push the limits of Excel). We only posted it after many requests. It will be replace by Mid June with a more robust java based tool. Also I strongly recommend NOT trying to use the spreadsheet unless you have read the book - because we assume complete knowledge of IFM
Just because each project is different, it really pays to do the analysis for your particular project, in order to determine the best approach and the best way to decompose it and sequence the MMFs.


Jane Cleland-Huang PhD<br />DePaul University<br />jhuang@cs.depaul.edu<br /><a href="http://facweb.cs.depaul.edu/jhuang" target="_blank" rel="nofollow">http://facweb.cs.depaul.edu/jhuang</a>
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
First of all THANKS for buying our book.
Well, I have just read chapter 2 available from Amazon.com in order to get a feeling, so I haven't bought the book yet.
I hope you enjoy reading it.
All I can say is that I enjoyed chapter 2 so far
Having said that - the numbers reflect very meaningful and realistic values for a large project.
That's what I wanted to hear and, to be honest, I didn't expect less than that from a high-quality book
Usually the benefits of early returns far exceed the penalty of additional costs.
True, but the case may arise where you might not have enough cash to invest even though you are convinced that incremental delivery is the way to go.
Thank you very much for your advice
[ April 29, 2004: Message edited by: Valentin Crettaz ]
Jane Cleland-Huang
Author
Ranch Hand

Joined: Feb 28, 2004
Posts: 32
Usually the benefits of early returns far exceed the penalty of additional costs.
True, but the case may arise where you might not have enough cash to invest even though you are convinced that incremental delivery is the way to go.

However, one of the benefits of incremental development is that it generally requires less upfront cash than a non-incremental approach. The reason being that you only have to fund part of the project and then revenue from early deliverables start to kick-in to offset costs.
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
In addition to cost, will we consider any returns from the software?
If so, how we recongize the returns? in accural basis or what?
Also, does the returns be consider iteratively as well?
Nick


SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
Mark Denne
Author
Greenhorn

Joined: Feb 19, 2004
Posts: 11
In IFM, returns are ascribed to each and every MMF. The returns can take many forms ... revenue, cost savings etc. The returns are presented as a cash flow. This is discounted and summed in the usual way to calculate a net present value (NPV). Because the returns are time sensitive, the net present value of an MMF varies according to where in the development sequence it is developed/delivered. For this reason, IFM calls these values "sequence-adjusted net present values" or SANPVs. By default, IFM uses these metrics (or more precisely a weighted version of these metrics) to optimize the overall development process for maximum net present value.


Author - Software By Numbers<br /><a href="http://www.softwarebynumbers.org" target="_blank" rel="nofollow">http://www.softwarebynumbers.org</a>
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
Hi Mark,

Because the returns are time sensitive, the net present value of an MMF varies according to where in the development sequence it is developed/delivered.

In this sense, when should we carry out the process iteratively?
Whenever there is a revenue generated? or we do it in a regular time basis?
Nick
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
Originally posted by Jane Cleland-Huang:

However, one of the benefits of incremental development is that it generally requires less upfront cash than a non-incremental approach. The reason being that you only have to fund part of the project and then revenue from early deliverables start to kick-in to offset costs.

I understand your point very well. Let me rephrase.
Let's admit I'm totally convinced (and I really am) that incremental delivery is the way to go. No doubt about it... Actually, I'm convinced of the IFM approach since ever (even before I got to know your book).
In my planification (real past case!!), I have identified two MMFs which needed approximately there months to complete. They could more or less be done in parallel but this isn't an option since I had only one developer working for me and I couldn't allow myself to hire another one. So, I have decided to develop one MMF and then the other one. Obviously, I chose the one MMF whose ROI was bigger, makes sense. The problem is that my budget was so tight that I couldn't even start the work on this first MMF unless I had found other financial solutions.
Agreed, this is a worst-case scenario, but s**t happens and you have to deal with it. All this to say, that sometimes even great ideas like IFM may not be the proper answer to certain problems.
[ April 30, 2004: Message edited by: Valentin Crettaz ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Valentin Crettaz:
In my planification (real past case!!), I have identified two MMFs which needed approximately there months to complete. They could more or less be done in parallel but this isn't an option since I had only one developer working for me and I couldn't allow myself to hire another one. So, I have decided to develop one MMF and then the other one. Obviously, I chose the one MMF whose ROI was bigger, makes sense. The problem is that my budget was so tight that I couldn't even start the work on this first MMF unless I had found other financial solutions.

What might sometimes help is to think about wether the MMF *really* is minimal. For example, sometimes you might simply be able to get more funding by being able to show stakeholders a partially working system.


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
Mark Denne
Author
Greenhorn

Joined: Feb 19, 2004
Posts: 11
A great point! Identifying MMFs is both a science and an art. We've included a whole chapter in book on this subject. In addition to being Marketable, and a Feature, it also has to be Minimum
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
Ilja and Mark,
Thank you for your pertinent comments about the *minimal* (and often overlooked)aspect of MMF
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Denne:
A great point! Identifying MMFs is both a science and an art. We've included a whole chapter in book on this subject. In addition to being Marketable, and a Feature, it also has to be Minimum

I think what is critical here is the definition of "Marketable". Defining it as "Marketable to the end users" might just be too limiting. How do you define it in the book?
Jane Cleland-Huang
Author
Ranch Hand

Joined: Feb 28, 2004
Posts: 32
Actually we define the term "Marketable" is something with intrinsic value to the user in terms of revenue generation, cost savings etc. This term captures the "value" part of the equation.
In retrospection I think that in some organizations another term might capture this better. ie some organizations aren't 'marketing' services but are focused entirely on different types of value. A Minimal Valuable Feature perhaps, but of course this doesn't sound as good as MMF
[ May 03, 2004: Message edited by: Jane Cleland-Huang ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Software by numbers: Chapter 2