I have been reading about the application of FDD for web development, but have noticed people mentioning that FDD doesn't cater to the following important parts of the SDLC,
* Requirements gathering
* Interface design
* Testing
* Deployment
- Is this true?
- What are others doing to cover these steps in FDD?
FDD is specially fit for Web!
What is a Web site/application, if not a set of features delivered to users, usually by incremental chunks?
As for the other SDLC disciplines, the Practical Guide for FDD is very clear: you must choose appropriate disciplines to complement your Software Engineering lifecycle.
FDD is an excelent methodology for building software, but it doesn't try to embrace everything! :)
Check these links for an interesting FDD extension:
http://www.cognizant.com/html/content/microsoft/techfddvsts.asp
http://download.microsoft.com/download/1/b/7/1b7cbbdc-50c9-4f53-8a82-5e583e5032dd/Cognizant%20FDD%20Implementation%20with%20VSTS.pdf
Cheers,
Adail Muniz Retamal
www.heptagon.com.br
Re: FDD and SDLC
FDD is one of the agile software development methodologies. One thing that is common among all agile methodologies is that they exclude/replace some common software practices that are not important for the success of the project. For example,
- XP replaces requirement gathering with user stories
- In FDD we often replaces requirement gathering with problem domain modeling.
Having said this, I want to point out that you can fit FDD into SDLC perfectly well. I work in a pharmaceutical company and compliance is a big issue here. We have to produce the huge amount of documentation: project initiation, user requirements, functional requirements, development testing protocol, system test protocol, operational qualification….. you name it.
So we fit FDD into the development part of the process:
1) User requirements, functional requirements
2) Problem domain modeling
3) FDD development and testing
4) everything else.
Development includes unit testing for each iteration, but we also have a formal testing after that.
I am not sure if it is the best model to fit FDD into SDLC, but it works for us.
Regards,
Serguei Khramtchenko
Re: FDD and web apps
I do not see any difference between web and non-web apps from FDD point of view.
Here is one example how web application was developed using FDD:
- the application: FDDPMA
- the design document here: http://fddpma.sourceforge.net/tutorials.html
- the deployed web app: http://www.fddpma.net
- login as guest to see FDDPMA development progress, its features, workpackages etc.
Best,
Serguei
FDD is versatile!
Good point, Sergei!
Indeed, it doesn't matter much what infrastructure the project will use, including programming language. Even the mindset used is not big deal (e.g. structured analysis, with its Data Flow Diagrams, Hierarchical Diagrams, Flow Charts, ERD's, etc.).
The FDD "Meta-Process" is basically the same: think a little bit before doing it, then detail it and do it a little bit at a time.
It works even for non-software projects! ;)
Cheers,
Adail Muniz Retamal
www.heptagon.com.br
It's Not Prescriptive
FDD does not try and prescribe all of the SDLC. In fact, the FDD processes end at the hand-off to system test. It is clearly targeted by its system purpose statement. Now this is not to say that system testing, or other SDLC activities, is not important; but that FDD is clearly targeted at repeatably delivering to system test on time and within budget and with agreed function - and that would be a good problem to have!
FDD, as all other Agile methods, does not try and prescribe every SDLC activity. It talks to areas and activities where there are pattenrs of play that lead to greater chances of success. The fact that it does not speak about some other activity simply means that you "do whatever work for you there" - not that it is ignored or excluded.
It is folly to even want every activity to be prescribed.
That said, FDD does do a LOT for requirements gathering and development (unit, string or integration) testing and does a LOT for the defect removal goal of testing. The FDD processes say nothing about deployment or system testing but FDD does enable a lot in those areas. The FDD processes say nothing specifically about interface design.
In all cases though, FDD says what other Agile methods say. Define the roles a project needs. Roles are defined by skills and tasks. Find people with the skills to perform those tasks (play those roles).
What do I do for interface design? I hire a good interface designer.
Jeff
FDD is not a silver bullet
Hi VP,
I've been using FDD for web development since I first learnt about it in 2001. Strictly speaking, it does not dictate how you manage requirements gathering, interface design, testing and deployment. What it does do is deal with fundamental aspects of development that cause significant problems in development, including web development. There is no one perfect methodology that covers everything from start to finish. I'm not sure that even if there was that it would be a good idea. Each environment is different, product development is quite different to bespoke development. At the moment, my work is based around the implementation of content management systems and I've had to adapt FDD for my needs. To think you can find a method off the shelf and apply it to web development is the wrong mindset. It's about finding what works and making it work for you for your projects.
When I made the decision to use FDD for web development, it was clear that it would have to be adapted to fit within our development approach. We already had a team of business analysts who would draft the requirements for the project, so FDD fitted in well. We also had a test team and had several deployment plans that we could adapt for each project. We couldn't necessarily dictate that we use the same deployment plan for each project as they would differ considerably, some had integration into existing systems, some were replacing existing system, some were completely new solutions. It wasn't practical to have a single approach for the entire lifecycle. But, we could consistently use FDD for the specification and development part of the lifecycle. That worked well.
Regarding interface design, in the web world, this has a number of layers, it's not just the look and feel. You need to consider content design, information design, information architect and then finally the visual design. There are ways that this can be handled in a repeatable manner, a good place to start is the work by Jesse James Garrett on User Centred Design (http://www.jjg.net/elements/) and in particular, his diagram on the elements of user experience (http://www.jjg.net/elements/pdf/elements.pdf).
So, my suggestion, based on what worked for me, is to use FDD as the core component of your lifecycle and supplement it with your own approach to requirements, testing & deployment. In the next couple of months I have a book coming out that covers a number of these elements (however it is specifically for content management projects) but will give you an idea of how you can manage these parts of the lifecycle.
Cheers,
M
Martin Bauer
Managing Director
http://www.designit.com.au
Development Process Management Patterns
Hi, I tend to divide what I've learned with FDD in two different layers:
* FDD - The whole thing.
* The FDD principles and techniques for project management. The Build Overall Domain Model with Class Diagrams, Feature Teams, Class Owner, Chief Programmer, Feature Description Templates, Worksheets, Parking Lot Reports, etc.
I've rarely managed to apply the whole thing but in very specific conditions:
1) Coding a business application
2) Coding the problem domain. Not the UI or even application integration interfaces.
3) Coding from scratch
I seldomly apply FDD principles and techniques on everything related to organization and project management. For workitem tracking and reporting, scheduling, division of labor, work queue management (feature lists etc), calculation of work completed etc etc. Rarely I use the concept of Class Owner, or even make the class diagrams central to my development. My experience is that this is rare in large organizations considering the rising of SOA and EAI tools.
For us, class diagrams are just one of the tools that we use to communicate. Central is the Feature List (The work queue). We use the principles of FDD when building it.
The underlying principles and techniques for me, form a process pattern that can applied in many different circunstances (WORK STREAMS). We can apply it to develop the UI layer, the business layer, the UI, the documentation, system integration, to manage tests, and even deployment.
But as Jeff somewhere pointed out, just becouse we use the underlying principles and tecchniques we learned with FDD, it doe not necessarly mean that we are applying the FDD process in a project. I belive that Jeff calls this FDD facets, correct me if I'm wrong.
So does FDD process fit into a Web project? IMHO yes and no. If your focus is not the Business Layer of the application neither you use Class Diagrams to devide and propagate application knowledge across your developers, well no it doesn't fit perfectly. But does this mean that I can't use the underlaying principles an techniques in the project? Oh yes you can and you should as they are the best I've seen to manage almost any project. But this requires you to think and to dive deeply into the FDD insights and not use it simply as a cook book.
For me, there is no such thing as a Web Project or FDD Project or Java Project, Swing Project or J2EE Project .... etc etc when it comes to project management and process. There is as Software Project and Work Streams mandated by deliverables, and each stream needs to managed collectively and individually towards to the objective of the project. In this view all the techniques you learn with FDD can be applied anywhere. Each stream use their tools of the trade, but when it comes to problem analysis and design, work tracking, work queues, division of labor, reporting, bottleneck detection etc, they all share a common process pattern. The bottom line is - Got a list of things to do? One can and should apply one way or another FDD techniques. Why? becouse they bring so many benefits that would requre several books to explain, but in one phrase, mantains everyone engaged and communicating with each other when lead properly. Furthermore mantains the all project under peoples eyesight so problems can't be ignored or forgotten, neither peoples responsibility and merit overlooked by the collective. A cancer in too many complex projects.
The next time someone asks, why is this not done yet? "This feature as been blocked for 2 weeks waiting for this questions to get answered or customer signoff on this particular theme". The solution - We need to be faster when it comes to answering questions, or we need to be faster in making them, or simply our queue is overloaded with too many change requests, or cosmetic bugs, or even testing rate show that the test team is reporting less then a bug per hour and we only in the first week of testing, we were expecting them to report 14 bugs per tester per hour. There is a bottleneck somewhere. This all can be detected with the tracking mechanisms proposed by FDD easily. Usually when the problem is detected the solutions is very, very simple.
FDD is much more, but at its core its a very simple, flexible and effective information system for managing any kind of software projects IMHO.
Nuno
PS: I just re-read my post, sorry if it looks too much like a brochure, I guess I just got carryed away.