Wednesday, February 21, 2007
BetterEstimate: the (simple) math behind
The paper describes the mathematical approach behind the BetterEstimate tool, together with some interesting insights on the relationship between times and probabilities in the input data.
Note: the paper is referencing version 1.2 of my other paper, Realistic and Useful: Towards Better Estimates, which is not online yet (only version 1.0 is available). I hope it will be finished quite soon, but meanwhile, the paper on the math side can be easily read on its own.
As usual, your feedback is welcome :-).
Thursday, February 15, 2007
Process Query Systems
Software is not generally known for being user-friendly in face of faults. Even mass-market software will often fail with mysterious error boxes. When a complex system, build upon mechanical parts, optical devices, electronic board (not to mention cables and junction boxes) and software fails, providing sensible diagnostics can be rather hard.
An interesting approach has been recently presented in IEEE Computer, January 2007 (Process Query Systems, by George Cybenko and Vincent H. Berk). The underlying idea makes a lot of sense: for complex systems, situational awareness can't be a function of the current state only; you need a track, or a sequence of model states. A track can be explained by one or more hypotheses, as a sequence of events can be associated to different transitions among internal states. A longer track usually reduces the set of reasonable hypotheses.
If you like the idea, you can find more details on the PQS net. Needless to say, the concept is not limited to system diagnostics, but it has also been applied to other complex problems, like motion detection.
Curiously enough, when the underlying model is based on a nondeterministic finite state machine, once you define a reference model for most system failures the problems looks a lot like strong bisimulation in CCS. Old stuff keeps coming back :-).
Monday, February 05, 2007
Value and Priorities
I've used the same idea (with a different terminology) for a few years, to handle conflicting viewpoints in several large projects. Indeed, it must have been inspired from some paper on viewpoints (unfortunately, I can't remember exactly which one).
The idea is quite simple: instead of struggling over each requirement, take the time to agree on a set of core values (as they are called in the paper above; I usually call them "concerns", by gathering from the viewpoints literature). Core values could include non-functional concepts like "security", "dependability" or "efficiency", business concepts like "innovation", "customer retention" or "new sales", and so on.
Then give values (or concerns) a weight (for instance, on a 0-9 scale). Values, and weights, should be set only once and should be agreed upon by all the stakeholders, as they should reflect the company's appreciation of those values (if you can't even get past this point, you're in serious troubles :-).
After that, each requirement is simply given an importance (or weight as it's called on the paper above) relative to each core value. You then multiply and sum to get the final requirement weight, after which it's easy to prioritize (just sort on final weight).
Simple, effective, and requires no more than a spreadsheet. There is also no need to quantify value in monetary terms, which may help in many cases where the economic impact of having (or not having a feature) can't be easily determined.
Of course, the company may grow, the focus can change, and so on, so we should periodically revisit the set of core values and their relative weights.
