About 10 years ago, web projects for the most part were static, and the process is sometimes simple to disgrace. Now the line between web applications and desktop applications is erased, the functional complexity of web projects is growing. This dictates new web development requirements. The usual situation today, in the era of “surprise me 2.0”, is when the project is long-term, it involves a lot of specialists (and not specialists as well), generously irrigating the long-suffering product backlog with new ideas and goals, both before and after development. As you know, goals and stories mutate, and with them, tasks. A preliminary estimate of time loses its usefulness. Etc. etc. Obviously, we need a special development methodology. You can try joining the Rational Unified Process (RUP) orProcess Mentor . However, not worth it. Among the currently popular Agile techniques is what we need - Feature Driven Development (FDD).

In general terms, the approach can be described by the following sequence:

• General model development
• Creating a property list
• Property Planning
• For each property - technical design and implementation.

Ideally, at the exit we get a platform, gradually acquiring properties. It sounds somehow suspiciously simple. Let’s see what it is.

Develop an overall model

As Jeff Deluca, the author of the methodology, put it (Jeff Deluca - http://www.jeffdeluca.com ), the general model is more of a sketch or outline than a detailed content. However, to get this model, project requirements are not enough. A model is a project vision based on preliminary research. Thanks to Louis Rosenfeld (Louis Rosenfeld - http://louisrosenfeld.com ) - we know how important the role of information architecture is in web development. At the stage of the general model, we should have - analysis of the target audience, analysis of the content and context of its use, content structure, including metadata and thesaurus. There should be a document describing the principles of the user interface, a list of the UX components used, a description of their properties and behavior.


Fig. 1. The pyramid of information architecture
In this approach, it is understood that we are starting to develop, having only outline of the system, which, as the development develops, overgrows with details. In this way, detailed wireframes will be developed in the input creating the corresponding features (features) or, in other words, parts of the project. However, at the stage of the general model, “raw” frameworks of the main interfaces and a preliminary site map will be required.
All of the above are related documents. The main result of the stage is a domain model . This is a static UML diagram, which includes all the logical objects of the project that are currently defined and their interaction (the object is part of another object, the object extends another object, etc.).

Build a Feature List

I don’t think that I should go into details here. Most of you use the SCRUM methodology, and the list of properties in FDD is the same as the product backlog in SCRUM. Is it worth recalling once again: when creating the list, it is necessary to operate with goals and subgoals, but not tasks.

Planning by Properties (Plan by Feature)

Everything would be fine, but how can we estimate the development time of the project properties when the details are foggy. The related tasks for developers will be extremely clear only when all the preliminary work on this property is completed. How to plan? And here comes the Story Point Estimation to the rescue. We evaluate properties not in man-days, but in abstract points as the complexity of the property. From the entire list it is proposed to choose a property of minimal complexity and assign it 2 points of difficulty. It is recommended to use an exponential scale, for example: 1, 2, 3, 5, 8. Then the question is asked why we did not assign 1 to the most trifling property. Just in case. The list of properties is huge and at first glance it is unlikely that you will be as accurate as possible in the assessment.
All members of the team participate in the assessment. That is, each property is discussed from the point of view of all stages of development until the team comes to a single assessment of complexity. Tiring enough, I'll tell you, but - productively.

Technical Design Feature (Design by Feature)

So, the priorities are determined, the property for implementation is selected. It's time to describe the requirements. To do this, a Use Cases model is created relative to the selected property. It would be good to provide this document with an Activity Diagram for visualizing the logic of conjugate usage scenarios. Use cases can be reflected in the corresponding UML diagram (Use Case diagram). During the review of the document, again, all team members participate.


Fig. 2. The use-case model brings details to the documents of the general model.

Further work can be carried out in parallel: part of the group is engaged in technical design, part is working on wireframes (or on the detailing of wireframes, if they have already been prepared at the stage of the general model).
Technical design involves a UML diagram with domain model entities, a list and class diagram (where appropriate) that are associated with the property of models, DAOs, controllers, services, decorators (possibly helpers). The database architecture covering the property in the form of an entity-relationship model ( ER Diagram ) is also presented there . If the property affects any external systems (for example, the user preferences profiler), this should also be reflected in the technical design, say, in the form of a sequence diagram ( Sequence diagram ).
Among other things, you should prepare test cases ( Test Cases ), which will allow QA-specialists to fully assess the quality of the implementation of the property.
When the domain model entity diagram for the selected property is finished, details that are not taken into account in the general model appear. It should be so: you simply reflect new details on the general model as they appear.
At the end of the stage, the entire development team takes part in the review of technical design. In addition to “polishing” all aspects of the document, this provides a deep insight into the architectural ideas of all project developers.

Property implementation (Build by Feature)

While the visual designer will work on the user interface, programmers can create the prototypes described in the technical design. Thus, after a review of the visual design and the prototype of the property, xHTML-layout and modification of the decorators (views) are performed. Surely the creative genius of a visual designer will require you to also do additional programming on the client side (JS). When the property is ready, it is transferred to the QA department for testing.
After the property has been tested and gone into the product, we take the next priority property, repeat the design / implementation cycle.