I have a long history in developing business systems of various sorts. I have worked in organizations and on projects with "heavy" process and some with no process. I have gone through the Yourdon SDLC, the RAD methodologies, and on and on. The Agile methods, particularly FDD, seem to support the work of software development in the real world, the way it has always happened regardless of (and often in spite of) the process we have tried to wrap around it over the years. I have found FDD to be a good match for me, the way I think, and the projects I typically work on. Wonderful! I have found the books and material on the topic to be informative and useful, and generally tailored to busines systems. But....
I now find myself doing a process review for a company that develops SCADA systems - generally, the product suite is described as an "open, secure, substation communications architecture that connects new and existing Intelligent Electronic Devices (IEDs) to control center and enterprise applications over public and private networks." That may or may not help you in any way. I am NOT an expert is SCADA systems. However, it does seem to me that FDD might be a good fit. This is a small company, in need of process that supports creativity, flexibility, adaptability, and responsiveness. Their competitive edge is greatly wrapped up in those characteristics. They are growing, and have wisely chosen to look at process improvement now, before things get seriously chaotic and out of hand. This is good, but I will not advocate process for the sake of process. I believe the product suite can be readily described as a set of features, such as a communication protocol as a feature set with subsequent FBS. I'm contemplating taking an example and doing a proof of concept exercise here. But I would like a little higher comfort level before I recommend that.
Having said all that, I could use some advice, which is what brings me here to the FDD site....
Has anyone any experience using FDD on technical development (SCADA systems) rather than business applications? Any advice or recommended reading material you can direct me to will be greatly appreciated.
Thanks,
Tammie
Model the domain - express the Features in domain terms
I did once run across a startup in the SCADA area - but that was before I met Jeff and before FDD as we know it. Anyway...
I do have experience using FDD on some pretty esoteric pieces of telephone network infrastructure. For example, if your business is in the USA and uses the Sprint single voicemail service to offer a single voicemail box for wired and wireless phone numbers then part of that software was written using FDD. If you own a T-Mobile phone and service plan in the USA and you ever downloaded a game to play on it, then that all happened via software written using FDD.
My experience is that if you can model the domain - preferably in color but any old modeling technique will do, doesn't even have to be OO, ERDs will do just fine - and if the terms used on that domain model have meaning to the business owners who are paying for the system then the process will work just fine.
The absolute key to FDD is to write Features using domain language so that Features truly express client-valued functionality. Then you simply track the flow of that value using the tracking and reporting techniques described in the FDD books.
Good luck!
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Yes
Well said David - that's good advice. I'll go even further and say that you also don't have to model (not something I often recommend) as long as you can substitute an informational/analytical activity for the Develop An Overall Model process that will allow you to Develop the Features List and Plan By Feature with accuracy (having said that, I know of no better way to do this than to follw the Develop an Overall Model process).
The descriptions of FDD certainly are biased towards line of business systems because that's where the authors primarily work (but not always). However, FDD has been used in product development, embedded systems and SCADA.
There really is nothing different about the application of FDD in these different domains. As David says, you produce a features list that describes all the functions required and you plan and track accordingly. When we do this, of course, we also do the Develop an Overall Model process and produce a model. Models are different for different domains as they are for embedded and SCADA type systems. If using color modeling, we do see a different preponderence of colors than in line of business (LOB) systems. In LOB pinks tend to dominate whereas in a SCADA system greens tend to dominate and the pinks are the messages or data sends across them. There is even a SCADA model in the JMCU book.
I know Gavin from this site is currently doing just such a system for a major fruit company. They have cameras that film the fruit as it moves along the main belt, the software determines the quality of the fruit from the imagery and diverts the fruit to different downstream belts which are for different types of product lines, etc. I don't know many of the details, hopefully Gavin can talk about this some more, but I did review some of the models and the features list for this project.
Jeff
thanks
Thanks so much David and Jeff for the great feedback. And I must say, I am very pleased because you have comfirmed what I was thinking and the direction I have been taking.
The key, as I have tried to say often but not so well and succinctly as David did, is to write features that express client-valued functionality, no matter what the domain.
Tammie