This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Agile and Other Processes and the fly likes to the auther: MMF, IFM? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "to the auther: MMF, IFM?" Watch "to the auther: MMF, IFM?" New topic
Author

to the auther: MMF, IFM?

Hanna Habashy
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
Can you describe briefly what is MMF and IFM.
thanks


SCJD 1.4<br />SCJP 1.4<br />-----------------------------------<br />"With regard to excellence, it is not enough to know, but we must try to have and use it.<br />" Aristotle
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

See the opening post in this thread.


[Jess in Action][AskingGoodQuestions]
Jane Cleland-Huang
Author
Ranch Hand

Joined: Feb 28, 2004
Posts: 32
Sure.
MMF stands for Minimal Marketable Feature. It is best described as a "chunk of functionality" or an incremental delivery of part of the product you are building. An MMF is characterized by its ability to return value to the customer, where value can be measured in terms of cost savings, revenue generation, or a number of less tangible factors such as increased brand recognition, increased customer loyalty etc. We therefore deconstruct a product that is to be developed into these MMFs.
A related term that we haven't mentioned much in this forum is an Architectural Element or AE. An AE is similar to an MMF except that it is cost incurring but NOT revenue generating. Typically an AE is an element of the architecture that needs to be delivered in order to support the functionality of an MMF.
Finally, IFM stands for the Incremental Funding Method. IFM is a process and related concepts and heuristics that we use to sequence MMFs and AEs in order to optimize the value of the software project, where value is measured in terms of the financial metric known as Net Present Value (NPV). The idea is to identify the delivery sequence (which can be linear or concurrent) that meets the needs of your organization.
THe primary goal is to optimize project level NPV, but we may also be interested in manipulating other metrics such as the initial funding investment, time to reach self-funding (ie when the income from earlier MMFs funds ongoing development), and break-even time (ie when the income from earlier MMFs has paid back earlier investments).
In Software by Numbers we provide an introduction to this type of financial analysis and describe how to apply the IFM approach.


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>
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jane Cleland-Huang:
A related term that we haven't mentioned much in this forum is an Architectural Element or AE. An AE is similar to an MMF except that it is cost incurring but NOT revenue generating. Typically an AE is an element of the architecture that needs to be delivered in order to support the functionality of an MMF.

Interesting. Wouldn't it be appropriate to see that AE as a part of the MMF? Why did you decide to handle it explicitely?


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
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
Jane, could you please mention an example about what concretely could be a AE and an MMF so that we can see why a distinction was made in the first place and why an AE is cost incurring while an MMF is revenue generating. To the same extent, which aspect(s) of the AE makes it being cost incurring?


SCJP 5, SCJD, SCBCD, SCWCD, SCDJWS, IBM XML
[Blog] [Blogroll] [My Reviews] My Linked In
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Ilja Preuss:
Interesting. Wouldn't it be appropriate to see that AE as a part of the MMF? Why did you decide to handle it explicitely?

Ah, I see that you already answered that question in this thread.
[ April 28, 2004: Message edited by: Ilja Preuss ]
Jane Cleland-Huang
Author
Ranch Hand

Joined: Feb 28, 2004
Posts: 32
Initially we only had the concept of MMFs. We thought we could decompose a system entirely into MMFs. An MMF obviously costs money to construct but also returns value - so it has both costs and returns.
However then we discovered that sometimes two or more MMFs both need the services of something that we can consider a physical implementation of the architecture (ie an AE) - such as a secure messaging system. So this created an analysis problem. Which MMF should we attach these AE costs to? Obviously they belonged to whichever MMF we ended up sequencing first.
From a process perspective it therefore makes sense to recognize AEs as valid elements to be built and sequenced. Our IFM heuristic works in such a way that an AE would NEVER get scheduled until it is needed by at least one of the MMFs because an AE doesn't provide any useful functionality on its own. It is useful ONLY because it supports the user requested functionality of the MMF. In other words secure messaging is ONLY important as it supports functionality such as an ATM user requesting information about their account balance or to support the user in transferring funds. Because an AE doesn't return value on its own - we see it as a cost incurring element, drawn into the sequence as and when it is needed by an MMF.
Tina Coleman
Ranch Hand

Joined: Dec 12, 2001
Posts: 150
Do you handle interrelated Architectural Elements? E.g., AE1 is dependent upon AE2. MMF1 needs AE1 but doesn't explicitly care about AE2. I'd assume AE2 would just tag along for the ride in AE1?
Jane Cleland-Huang
Author
Ranch Hand

Joined: Feb 28, 2004
Posts: 32
Well if AE1 is dependent upon AE2, and MMF A upon AE1 then it implies that MMFA also needs AE1. If that is not the case then it would probably indicate that you didn't do a sufficiently fine-grained decomposition of the AEs. The idea is to decompose them sufficiently so that you only invest effort developing those parts of the architecture that you need for the current MMFs.
There are two approaches you can take - depending on whether you are in an agile or a non-agile project. For agile projects you can create AEs as you go! (ie no big upfront design). For other projects (and certainly this can also be done in agile projects too), you can design your architecture upfront according to the MMFs that you plan to build in the near future, but you can then decompose the architecture into AEs.
In either case, if you want to optimize the value of your project you should only build AEs as they are needed.
Mark Denne
Author
Greenhorn

Joined: Feb 19, 2004
Posts: 11
Part of the elegance of IFM is that it treats AEs and MMFs equally. In other words, it's just as sceptical of doing the work associated with an AE as it is of an MMF. Whether it's an MMF or an AE, it has to emerge as the most compelling thing to do now (in comparison with everything else that could be done) in order to be the action recommended by the IFM heuristic.
This means that to a large extent we've transcended the traditional religious arguments about Architecture (should we do it all up front, or should we just do bits of it as and when needed?) that often characterize the debates between adherents to traditional and Agile processes.
By applying the same rules to AEs as we apply to MMFs we've ensured the same financial analysis and justification is demanded of Architecture as all other aspects of the project. At the end of the day, it allows us to answer the question "should we do all the architecture up front?" with a dollar figure - a monetary gain or loss against doing it "just in time".


Author - Software By Numbers<br /><a href="http://www.softwarebynumbers.org" target="_blank" rel="nofollow">http://www.softwarebynumbers.org</a>
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mark Denne:
By applying the same rules to AEs as we apply to MMFs we've ensured the same financial analysis and justification is demanded of Architecture as all other aspects of the project. At the end of the day, it allows us to answer the question "should we do all the architecture up front?" with a dollar figure - a monetary gain or loss against doing it "just in time".

That's quite interesting!
Do you already have any experience on how often the analysis tends to suggest upfront development of architecture in contrast to just in time development?
Jane Cleland-Huang
Author
Ranch Hand

Joined: Feb 28, 2004
Posts: 32
Do you already have any experience on how often the analysis tends to suggest upfront development of architecture in contrast to just in time development?

I think we would have a hard time quantifying that. We can observe specific types of project in which upfront development makes sense. For example if the requirements are relatively stable it may make sense to build a slightly more extensive architecture upfront to save refactoring costs later. However this is VERY different from building the entire architecture up front.
We actually advocate upfront architectural design, but incremental development and delivery.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jane Cleland-Huang:
We can observe specific types of project in which upfront development makes sense. For example if the requirements are relatively stable it may make sense to build a slightly more extensive architecture upfront to save refactoring costs later.

Mhh, I'd think that there needed to be more requirements:
- our *understanding* of the requirements had to be relatively stable,
- our understanding of the desirable solution to the requirements had to be relatively stable, and
- the saved refactoring costs had to make up for delayed ROI because of the delayed delivery of the first features (if we deliver incrementally, of course).
Would you agree?

However this is VERY different from building the entire architecture up front.
We actually advocate upfront architectural design, but incremental development and delivery.

Which begs the question: what do we actually mean by "architecture"? XP, for example, advocates to develop a System Metaphor early in the project, a very high level description of a few sentences about how the system will work internally. Would that suffice for you, or would you want to go into more detail?
vasu maj
Ranch Hand

Joined: Jul 12, 2001
Posts: 395
Are these terms (MMF and IMF) standardized ? Are they your own terminology that you are advocating that the industry should start using?
Just curious.
Thanks,
vasu


What a wonderful world!
Jane Cleland-Huang
Author
Ranch Hand

Joined: Feb 28, 2004
Posts: 32
The terms MMF and IFM are both new - although of course Mark and I are both pleased to find that they are starting to be adopted as terms in peoples' conversations.
In writing our book, we felt that the new focus on software development as a value-creating activity was best expressed through the introduction of some new terms.
 
wood burning stoves
 
subject: to the auther: MMF, IFM?
 
Similar Threads
Software by numbers: Chapter 2
To the authors: An overview
MMF == Story?
Software by Numbers (not-wide)
managers book