Sasha Kopriva
CS383 hw 4
Feature Driven Development
Of the five major agile development methods, Feature Driven Development would be
the most effective and productive method to use for gus development. Many of its chief
aspects are characteristics of gus that could be easily manipulated to fit the Feature Driven
Development model. Though other agile development models could be used with perhaps
some minor adjustments, Feature Driven Development is a very well suited model to how gus
should be implemented effectively.
Feature Driven Development is a software development process in which development
is influenced by the features of the software incrementally. This method is effective when the
customer does not need to be directly or frequently involved. Using this method, a model of
the software is created, and from that, a list of features is produced. Using the list of features,
programmers are assigned different features that will be treated as classes. Then, design and
building is done on a class by class basis. Because Feature Driven Development (FDD) is focused
on the client-valued functions of the software, it is well suited to the gus software model. Gus
would be very easy to split into feature classes, and would also allow classes (and their
associations) to be developed correctly and easily.
Pair Programming is a way of software development that involves pairs of programmers
working together on the same piece of code. This is usually done with one work station. This
method allows for shorter programs and better solutions, as compared to a single programmer.
However, for gus, this would require that the two people that were “paired” to be able to work
well together, have similar free time, and have evenly matched programming skills. It would
also require that the class be split into pairs, with each pair working on a specific part of gus,
which would slow development time. Although pair programming can be a very effective way
of producing software, it would be too difficult to implement in a small class size for gus.
Extreme Programming is a software development strategy that is best suited to
frequent customer interaction and feedback. It is especially useful when the customer is unsure
of what their software requirements are, or if their software requirements are subject to
change. Extreme Programming (XP) allows for continuous feedback and planning, which gives
the customer the ability to see progress and develop the software alongside the programmer.
However, because gus doesn’t have a single customer or customer “entity”, but instead has a
collection of users, it would be more difficult to obtain frequent feedback in a timely manner
with every code, test, and design iteration. Also, because gus was not created by our users, but
instead the programmers themselves, many of the software requirements have already been
decided on, with only minor changes or tweaks to be expected through the design and
implementation process.
The Scrum model is similar to extreme programming in that it is useful for software
development that requires feedback from the customer. The Scrum method consists of
frequent meetings with programmers, customers, the product owner, and the project team.
Also, work to be done for the project is constantly being reviewed and prioritized to meet
customer’s needs and deadlines. Although it would be helpful for the gus teams to meet and
discuss priorities, it would not be practical or realistic for the gus teams to meet as frequently
has the scrum model suggests. Also, because gus does not have a “customer” to get frequent
feedback from, meeting with customers would prove to be rather difficult, and would provide
little in the way of assessing backlogs, as in the scrum model.
The Test Driven Development model is not necessarily a software development model
(as compared to Scrum or XP), but a way of effectively producing code. Using this model, the
software is developed through a series of tests written for the software, before it is fully
developed. An initial test is created in which the software will inevitably fail, and then code is
written. Subsequent tests are created and the software is re-tested with the tests until it passes
all of them. Once it does, the code is perfected and the process starts over again. This method
is very useful because it builds upon working code, assuring progress in the development
process. This model would be easy to implement for gus development and would be useful, but
feature driven development is better suited to the gus software model. However, the Test
Driven Development model could be used in addition or conjunction with feature driven
development as a means of testing and producing usable code.
From five agile concepts discussed, the Feature Driven Development method is
well suited to our software and our situation. FDD involves developing an overall model,
building a feature list, planning by feature, designing by feature, and building by feature. These
five basic “activities” of the FDD fit very well with the software we are developing. Gus is made
up of many “features. In fact, we have already mostly completed two of the five FDD activities:
We have developed a preliminary overall model for gus (through class diagrams) and we have
build a feature list (through use cases and class diagrams). Because many of the main features
of gus functioned as classes (as shown in our class diagrams) it would be very easy to refine our
model and our feature list. According to the FDD, planning by feature involves assigning and
ordering features as classes to programmers. By designing gus a feature at a time, it will be
easier to test functionality because it will be by a per feature basis. Because features are small,
testing will take place more frequently, therefore ensuring that features are functioning
properly before moving on to a new feature, or set of features. After the design is complete,
building the features will involve actually coding the features. During this phase, TDD could be
implemented to ensure full functionality of the features. Once a feature passes the TDD “code
inspection”, the feature will be finished and set aside for the final product. Because FDD is done
in a very modular manner, it will be very easy to implement the software, test it, and make
changes, without the possibility of a complete re-write of the software. The other agile
software development methods are not as well suited to the gus software project as Feature
Driven Development is. Although some methods could be tweaked to work with gus, FDD relies
on many of characteristics that are already built into the gus model, making it very simple
model to follow for development.