Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Material Type: Project; Professor: Marchese; Class: Software Engineering Seminar II; Subject: Computer Science; University: Pace University-New York; Term: Spring 2007;
Typology: Study Guides, Projects, Research
1 / 20
This page cannot be seen from the preview
Don't miss anything!
In the traditional waterfall model software development approach, the whole project is divided into a number of stages: gathering user requirements , design and documentation , development , testing and deployment. In this approach, it assumes that each stage is 100% complete before the next stage starts. One of the main weaknesses of this approach is that design errors are often not discovered until deployment time. At this time the project is almost complete and the errors are often expensive to recover from_. “Observe that it is perhaps 100 times as costly to make a change to the requirements during system testing as it is to make the change during requirements definition_ .” (Fairley, R., 1985).
Agile methods try to avoid this weakness of “waterfall” by doing iterative development. Each iteration is meant to be short (1-3 weeks) and includes all of the above steps. This guarantees that design errors are discovered at the early stages of development. Feature Driven Development (FDD) is one of the agile software development methodologies that emerged in the last 10 years as an alternative to traditional “waterfall” development.
Jeff De Luca and Peter Coad introduced FDD in 1997. It so happened in 1997 that Jeff De Luca was the project Manager of a large software development project in Singapore. The problem domain was so complex that Jeff realized that that the task in hand could not be completed in time, with the available resources using traditional strategies of software development. He therefore with the help of Peter Coad and others discovered the modeling in color technique and the concept of feature driven development. In print this was first published in the book “ Java Modeling in Color with UML” written by Peter Coad (Peter, et al., 1999).
FDD is an agile, highly adaptive software development process that is
Highly and short iterative. Emphasizes quality at all steps Delivers frequent, tangible working results at all steps Provides accurate and meaningful progress and status information, with the minimum of overhead and disruption for the developers. Is liked by client, managers and developers
In a software development process, communication is taking place constantly at every level. In fact, no process (work) can occur without it. If we consider developers as nodes in a communication network, all potentially linked to each other by communication channels, then the number of potential communication channels increase dramatically as more number of developers are added.
As the size of a software system grows, the complexity of that software system grows “ at least as fast the square of the size of the program” [Weinberg, G., 1992] and quickly outstrips the relatively fixed capacity of a human brain. Gerald Weinberg calls this law of software development “the size / complexity dynamic”.
FDD decomposes the entire problem domain into tiny problems, which can be solved in a small period of time, usually 2 weeks Î decomposed problems independent to each other reduces the need of communication.
“Observe that it is perhaps 100 times more costly to make a change to the requirements during system testing as it is to make the change during requirements definition “ (Fairley, R., 1985).
FDD splits the project into iterations so that the distance in time between analysis and test is reduced Î early discovery of errors reduces the cost of fixing the errors.
Different persons have different perception of software quality. A user talking about the quality of a system discusses the user interface, the response time, the reliability and the ease of the use of the system. A developer talking about quality discusses elements of design; ease of maintenance and enhancement; and compliance to standards, patterns, and conventions. Software managers will look at quality in terms of ease of maintenance and enhancement, compliance to standards and conventions, and ability to deliver it on time. Project Sponsors will look at how well the system meets their business requirements. Does it allow them to meet a constantly changing business requirement and be proactive in meeting the challenges that are ever present in the marketplace? This makes necessary to view quality as a spectrum, with internal quality at one end and external quality at other end.
A Language Guru is a person who is responsible for knowing a programming language or a specific technology inside out. In projects where a programming language or technology is used for the first time, then this role is special.
The Build Engineer is responsible for setting up, maintaining, and running the regular build process.
The Toolsmith creates small development tools for the development team, test team, and data conversion team_._
The System Administrator configures, manages, and troubleshoots any servers and network of workstations specific to the project team.
Testers are responsible for independently verifying that the system’s functions meet the users’ requirements and that the system performs those functions correctly.
Deployers convert existing data to the new formats required by the new system and work on the physical deployment of new releases of the system.
Technical Writers write and prepare online and printed user documentation.
FDD blends a number of Industry-recognized best practices into a coherent whole. The best practices used in FDD are:
It consists of building class diagrams depicting the significant types of objects within a problem domain and the relationships between them. It is a form of object decomposition. The problem is broken down into the significant objects involved. The design and implementation of each object or class identified in the model is a smaller problem to solve. When the completed classes are combined, they form the solution to the larger problem. ”Modeling in Color” is the best technique for Domain Object Modeling.
Colored UML is regular UML with color-encoded classes. The use of color allows quick understanding of the problem domain’s dynamics. All the classes are divided into different
categories; each category has its own color. The auxiliary classes and interfaces are colorless. Figure 1 shows a fragment of a colored UML diagram.
Yellow : a role being played, usually by a person or an organization. For example, the user of an
online auction site may play different roles: it can be a buyer, a seller or a system administrator.
Blue : a catalogue-like description. For example, an online store may have descriptions of the CD players that it sells. The description gives all the characteristics of the player, but it is not the player itself.
Green : a party, place or thing. In the previous example, the actual CD player in stock would be modeled as green. The green class usually has some identifying attributes, such as serial number, person’s name etc.
Pink : a moment in time or an interval of time usually associated with some business process. For example, the fact of purchase may be shown a pink class, since it has a time of sale, which is tracked by the online store.
Figure 1 Example of color UML. This figure displays part of the problem domain for Feature Driven Development for a garage. The purpose of above model is to track cars in a garage. Service and Regular service class have dates , therefore they are represented by pink interval. Car is a thing so it has green color. The Model belongs to the description archetype so blue in color. A person may be car owner or a mechanic hence these classes are yellow in color. (Source: Palmer, SR., Felsing , JM.2002,p.124)
As the feature team owns all the code it needs to change for that feature, there is no waiting for members of other teams to change code. So we have code ownership and a sense of collective ownership too.
Each member of a feature team contributes to the design and implementation of a feature under the guidance of a skilled, experience developer. This reduces the risk of reliance on key developers or owners of specific classes.
Class Owners may find themselves members of multiple feature teams at the same time.
Chief Programmers are also Class Owners and take part in feature teams led by other Chief Programmers.
Figure 2 Feature teams: Feature teams are formed from class owners as needed. (Source: Palmer, SR., Felsing , JM.2002,p.47)
The mix of feature team and inspection adds a new dimension to FDD. As a feature team comprises more than one member, so the fear of humiliation for a particular person is no more.Applying best known defect detection techniques and leveraging the opportunities it provides to propagate good practice, conventions, and development culture.
At regular intervals all the source code for the features completed is taken is taken, and the libraries and components on which it depends and the complete system is build. This ensures that there is always a demonstrable system available.
This serves to identify the latest versions of completed source code files and provides historical tracking of all information artifacts in the project.
Throughout the project frequent, appropriate, and accurate progress reporting at all levels, inside and outside the project, based on completed work is done.
FDD starts with the creation of a domain object model in collaboration with Domain Experts. Using information from the modeling activity and from any other requirement activities that have taken place, the developers go on to create a features list. Then a rough plan is drawn up and responsibilities are assigned. Small groups of features feature that lasts no longer than two weeks for each group and is often much shorter are taken up. FDD consists of five processes.
Figure 3 The five processes of FDD with their outputs (Source: Palmer, SR., Felsing , JM.2002,p.57).
Domain and development team members work together under the guiding hand of an experienced Object modeller (Chief Architect). Domain Members perform an initial high-level walkthrough of the scope of the system and its context. Then the domain members perform more detailed walkthroughs of each area of the problem domain. After each walkthrough, the domain and development members work in small groups to produce object models for that area of the domain. Each small group composes its own model in support of the domain walkthrough and presents its results for peer review and discussion. One of the proposed models or a merge of the models is selected by consensus and becomes the model for that domain area. The domain area model is merged into the overall model, adjusting the model shape as required. The object model is then updated iteratively with content by process IV, Design by Feature (see figure 3).
Figure 6 Sample feature list
The project Manager, Development Manager, and Chief Programmers plan the order that the features are to be implemented, based on feature dependencies, load across the development team, and the complexity of the features to be implemented. The main tasks in this process are not a strict sequence. Like many planning activities, they are considered together, with refinements made from one or more tasks, then the others are considered again. A typical scenario is to consider the development sequence, then consider the assignment of features sets to Chief Programmers, and in doing so, consider which of the key classes are assigned to which of the developers. When this balance is achieved and the development sequence and assignment of business activities to Chief Programmers is essentially completed, the class ownership is completed.
Figure 7 Flow diagram for planning by feature (Source: Palmer, SR., Felsing , JM.2002,p.146).
A number of features are scheduled for development by assigning them to a Chief Programmer. The Chief Programmer selects features for development from his or her “inbox” of assigned features. Operationally, it is often the case that the Chief Programmer schedules small group of features at a time for development. He or she may choose multiple features that happen to use the same class (hence developers). Such a group of features forms a Chief Programmer work Package. The Chief Programmer then forms a feature team by identifying the owners of the classes (developers) likely to be involved in the development of the selected feature(s). The chief Programmer then refines the object model based on the content of the sequence diagram(s). The developers write class and method prologues. A design inspection is held.
Figure 8 Flow diagram for designing by feature (Source: Palmer, SR., Felsing , JM.2002,p.160)
Working from the design package produced during the Design by Feature process, the class
owners implement the items necessary for their class to support the design for the feature(s) in
the work package. The code developed is then unit tested and code inspected, the order of which
is determined by the Chief Programmer. After a successful code inspection, the code is permitted
to build.
Figure 10 The six milestones of feature development. (Source: Palmer, SR., Felsing , JM.2002,p.77).
A percentage weighting is assigned to each milestone. So we can say that a feature that has reached the coding stage is 44% complete. The weighting percentages assigned to each milestone varies from situation to situation, depending upon the level of effort put into it.
Figure 11 Percentage Weighting Assigned to Milestones (Source: Palmer, SR., Felsing , JM.2002,p.80).
Now the percentage of completeness for every feature in the feature list is calculated. Doing this for all the features in a Feature Set, gives us the completion percentage of the Feature Set. This is done for each major Feature Set and then for the whole project. In this way we can count the number of features not started, the number in progress, and the number completed for the project.
Feature Set No^ of
Features
No not started
No in Progress
No Completed
Percentage Completed
Scheduling a
Service
Performing a
Service
Billing a Service 6 5 0 1 16.6%
Booking in a
Repair
Total 53 24 17 12 38.7%
Table 1 Workshop Management Area (Source: Palmer, SR., Felsing , JM.2002,p.82)
Every week, the rate of progress is shown by plotting a graph for the number of features completed each week.
Figure 12 A graph plotted for features completed vs. Weeks elapsed
In Figure 13 each feature set is represented by a rectangle divided into 3 bands: top, middle and lower. The top band is the biggest compartment and contains the name of the feature set, followed by the number of features in the feature set, followed by the percentage completed for that feature set. The middle band shows a progress bar graphically representing the percentage of completeness. The progress bar is green; the completed color. The lower band contains the planned completion date estimated in process 3 and remains white until completed, whereupon it turns green to match the other two bands.
In Figure 14, Feature Sets are arranged horizontally inside larger rectangles representing the major feature sets of the system. Each page of paper contains a number of major feature sets so that the final report consists of a few pages of colored rectangles.
Feature set No of Features
No. not started
No. in Progress
No. Completed
No. Behind % complete
Scheduling a Service
Performing a Service
Billing a Service
Booking in a Repair
Total 53 24 16 12 1 38.7%
Table 2 Tracking progress of features (behind schedule) (Source: Palmer, SR., Felsing , JM.2002,p.88).
FDD can be implemented with up to 500 developers
More critical projects Bigger projects More novice developers Environments that demand Waterfall
Feature-driven development is a process for helping teams produce frequent, tangible working results. It uses very small blocks of client valued functionality, called features. It organizes those little blocks into business-related feature sets. FDD focuses developers on producing working results every two weeks. FDD is better prepared to work with team where developers’ experience
varies. It offers progress tracking and reporting capabilities. This comforts managers and makes it more attractive for big companies.
11. References & Links
Coad, Peter, et al. Java modeling in Color with UML.Upper Saddle River, NJ:Prentice Hall PTR,
Fairely, R. Software Engineering Concepts. New York: McGraw Hill, 1985.
Weinberg, G. Quality Software Management vols. 1-4. New York: Dorset House, 1992-1997.
Freedman, D.P., and Weinberg, GM. “Software Inspections:“An Effective Verification Process.“
IEEE Software. May 31-36(1982)
Palmer, SR., Felsing, JM. “A Practical Guide to Feature Driven Development”, Prentice Hall,
Internet sites
http://www.nebulon.com/
http://www.petercoad.com/
http://www.featuredrivendevelopment.com/
http://www.featuredrivendevelopment.com/certification/list
http://en.wikipedia.org/wiki/Feature_Driven_Development
