This Web Design methodology was introduced to me by my case study adviser before we conduct a case study. Si like my meister, I want to share it with you as an introduction to the study These steps serve us as main frame of the study in which to need to take it step by step.
Process 1: Develop an Overall Model
This is an initial project-wide activity with domain and development members under the guidance of an experienced object modeler in the role of Chief Architect.
Process 1 involves the project team creating an object model of the business domain -- a model that's more shape than content. The model is not fully defined with all attributes and methods, as this step is more about capturing correctly the shape of the business domain in an object model -- not capturing every detail.
This is a highly collaborative process in which everyone has to work together to create an overall model. It takes an iterative approach. First, the domain expert explains a part of the business domain. The project team is broken up into groups (preferably 3 per group) to model that part of the domain. The groups then present their models and consensus is reached on which to use. This process is then repeated for each part of the domain until everything has been covered. The end result is an overall model of the entire domain.
Process 2: Build a Features List
This is an initial project-wide activity to identify all the features required to support the project requirements. Creating the feature list is the task of the Chief Programmers involved in the modeling process. The client and stakeholders don't need to be a part of this process, as they have made their contribution in Process 1. Now is the time to capture the project in a list of features. This does not require collaboration: getting a group of people involved at this stage would not be productive or constructive.
The key to this process lies in defining the project using the language of the business domain. This means that the client will be able to understand and value each feature, but it also enforces a common language across the project team and reduces the risk of miscommunication or assumptions.
Poor communication is the basis of most problems in software and Web development. The language we choose has a significant impact on how effectively we communicate. There are many techniques in FDD that help to provide meaningful communication. The most powerful of these is encapsulated in Process 2: defining the entire project in features using the language of the domain, i.e. using the client's language. This might sound simple and obvious, but it should not be underestimated. The focus that this step brings is incredible and affects the project in many ways.
Defining everything as a feature avoids the problems that occur whenever the client refers to a concept in one way, the programmer refers to it in another, and the Project Manager has to continually interpret the two. If the Project Manager doesn't get the interpretation exactly right, mistakes occur: the programmers think they're building one thing, the client expects another. Using the same language doesn't mean the problem disappears, but it reduces the risk of confusion considerably.
Process 3: Planning
Process 3 is an initial project-wide activity to produce the development plan.
This process extends the benefits provided by Process 2. It provides the Project Manager with a means of planning the development phase in a meaningful way for both the client and the programmers. It is completed in conjunction with the Development Manager and Chief Programmers, who look, in particular, at the order in which features will be built, balancing load within the team and providing strategies for delivering early results to keep the client happy.
Process 4: Design by Feature
Process 4 involves a per-feature activity to produce the feature design package. This process is broken down into three steps: walkthrough, design and inspection.
In the walkthrough, programmers familiarize themselves with what they're about to build before starting on a detailed design, which is inspected before they start the build. The inspection of the design allows defects to be found and removed before a single line of code is written for that feature.
It might seem like commonsense to design, and inspect that design, before building, but this step is often ignored. In many other industries, the idea of building something before it has been fully defined, designed and planned would be considered negligent, yet it happens all the time in Web development. The first reaction of many programmers, especially those in Web development, is to open their favorite editor and start coding. The amount of risk to which this approach exposes any project is enormous. However, the converse can also be problematic: attempting to design everything up-front can often result in "analysis paralysis".
Exactly how much design should occur up-front is a hotly debated topic amongst advocates of agile methodologies. The approach taken by FDD is clear in the difference between Process 1 and Process 4. As we have seen, Process 1 includes design early in the lifecycle, but it's not a detailed design. The detail is left to Process 4. Putting the detailed design in this later stage ensures that it is considered at the right time: before the code is written. It also breaks the design down into meaningful chunks, feature by feature. This means programmers don't feel like they're spending all their time designing and no time coding; immediately after the design has been completed and inspected, the programmer can start to code.
Process 5: Build by Feature
Process 5 involves a per-feature activity to produce a completed client-valued function (feature).Process 5 is also broken down into three steps: code, code inspection, and promote to build. As with Process 4, the idea of collaboration and benefits inspections is enforced. What makes Process 5 unique is the final step, "promote to build".
For code to be "promoted to build" it must be finished. The key to this is the definition of "finished". A feature is not finished until there is nothing else to be done. The way a Project Manager can test if a feature is truly finished is simply by asking if the work is finished. If the programmer answers "yes", the Project Manager then asks, "There's nothing else to be done?". This question often elicits a different response. It's not that the programmer is being difficult or misleading; it's just that, given the chance, many programmers will continue to work on code, tweaking, optimizing or trying to improve it ad infinitum. If there's time to do this, it's not a problem, but if there's a tight deadline, the Project Manager needs to focus programmers on getting the project completed. This process is a great way to ensure that focus.
The other benefit of this process is that helps the Project Manager see clearly how much of the project has been completed, and how productive each programmer is. According to Gerald Weinberg (Quality Software Management Vol.1), the productivity difference between programmers can be as much as 20 to 1. The issue is how to assess that productivity. Even though features might range in size from 2 hours to 2 weeks of work, it doesn't take long for the Project Manager to assess how much work each programmer is actually producing once the variances in feature size are taken into account.
