Download Feature Driven Development & Empirical Modelling and more Lecture notes Software Development in PDF only on Docsity!
Feature Driven Development & Empirical Modelling
Abstract
Feature Driven Development is a new software development methodology and its appeal lies in its natural applicability. This paper is an introduction of Feature Driven Development (FDD), with in- corporated analysis of its likeness to Empirical Modelling. Out of this analysis, specific challenges for EM have been highlighted. Further, a teaching model, which describes the formation of features in FDD, has been produced using LSD principles. Suggestions for further work have also been detailed.
1 Introduction
Software development is a primary bond be- tween industry and computation. If Empirical Modelling is to succeed as a foundation for computation, it must situate itself around soft- ware development such that it appeals to the industry as an alternative or a complementary framework.
Feature Driven Development is a fairly new methodology but its appeal lies in its natural applicability, as claimed by the founders of the methodology (Palmer, 2002). This is inline with the purpose of Empirical Modelling to make computation more appealing to the natural human disposition of computation through experimentation.
2 Feature Driven Development
Feature Driven Development (FDD) is a model- driven, iterative software development meth- odology. It begins by establishing an overall model. It then continues with a series of two- week "design by feature, build by feature" it- erations. The features are small, client-valued
functions and outputs. There are 5 Process Steps within FDD (Figure 1).
2.1 FDD Activities
In the first step, the client and the development team work together to develop an overall model of the clientās domain. The client pre- sents walkthroughs of the context and required system. While the development team produce models from this information. A process of ad- justing the model shape results in a final agreed-upon model. It can be seen that this step is essentially interactive situational require- ment gathering, with results that express knowledge about the required system, which is very much inline with Empirical modelling thinking.
The second step allows the team to formulise the information gathered in the first step through the production of a feature list. As mentioned above a feature is a small, client- valued function or output. It is small because a key concept in FDD is to generate results every two weeks. Therefore a given feature must take less than two weeks to implement. The team creates a feature list by identifying features,
Figure 1: The 5 Process Steps within FDD (Palmer, 2002)
prioritising them in accordance with client sat- isfaction and weighing them to ensure they can be completed in less than two weeks (or else dividing them into smaller features). Features are also grouped together into feature sets to reflect dependencies and associations between features.
The third step involves using features to plan the development and organise the team in preparation for implementation. In planning for development, features from the features list are ordered to reflect the development se- quence and transformed into milestones. In terms of team arrangements, a chief program- mer for each feature set is selected to lead each two-week cycle involving that feature set. The chief programmer then forms a feature team by selecting a group of developers to work with, on assigned feature sets. Team management is an essential concept in software development and it determines the scalability of a methodol- ogy to large projects.
The last two steps are iterative and each itera- tion lasts 2 weeks. A chief programmer takes the next feature and identifies associated classes. The feature team work together on se- quence diagrams and general design of fea- tures. Coding, testing, integrating and inspect- ing takes place in the final step of FDD. By this point, there is little room within FDD for ex- perimentation and a more structured approach is adopted. A key benefit of this is that it en- sures the project is completed within a reason- able time frame.
2.2 Key Principles in FDD
FDD is based on the idea that results reflect success and not the steps used to achieve those results. The founders of FDD have attempted to achieve this through making FDD a naturally applicable methodology. One of the main con- cepts used to accomplish this aim is to avoid process over-specification. In other words, a reduction in the amount of process description provided to team members. For this, a process description notation is has been provided in the
form of a template named ETVX: Entry, Task, Verification, and eXit (Coad, 1999). The idea being that for each process step within FDD, the entry criteria is given, followed by a list of tasks and then methods to verify that the task has been completed and finally an exit crite- rion.
Process description within FDD in general is based on similar thinking to Definitive Nota- tion, in the sense that scripts are never com- pletely closed and definition only stabilise as meanings are negotiated. This is reflected in the observation that many specific details in proc- ess description of the later steps in FDD have been left ambiguous and open. For example, integration testing is left at developerās discre- tion in that there is no mention of integration testing within the process description; although there is a separate discussion about it and it has been considered by the founders of the meth- odology (Palmer, 2002).
Further, FDD was founded in 1997 and as of yet, there have been two different definitions provided by the founders for the specific de- scriptions of process steps; one definition is the original and the other is a ānew and improvedā version. This reflects the idea that new insight and experience can give rise to new definitions, or even removal of old definitions.
Another key principle within FDD is accom- modation for shorter and shorter business cy- cles. The racing nature of technology requires shorter iterative business cycles. To explain further, consider a project with a 2-years lifecy- cle. This project may perhaps be unsuccessful if design is completed before any implementation is started because technology advancements will quickly outdate the output to this project. EM does not have concerns about outdating models because programming is done while modelling.
Scalability of FDD to large projects is a key strength. FDD provides just enough process to ensure this. By process, the indication is to- wards short design and implementation cycles,
ture using the standard template, ensuring the feature will take less than two weeks to imple- ment and prioritising it before adding it to a Feature List. Second, the sequencing of features in preparation for development is done in ac- cordance with client satisfaction and practical concerns. Third and last, features are grouped into feature sets and assigned to chief pro- grammers. Having considered this, another possibility was to model simply one of the three stages in a feature lifecycle.
Further stimulus for the decision was provided while reading Meurigās analysis of software development and empirical modelling (Bey- non, 2006). There is mention in the analysis of a dishwasher model (Wong, 2002), with particu- lar attention drawn to UML depiction in the model.
During research for FDD, there was mention of a UML reporting component that particularly captures Feature Progress during FDD (Coad, 1999). The component, as shown in Figure 2, is a rectangle with a set of inner rectangles that are representative of different observables re- lated to a particular feature set. There is use of colour to identify state-changing events. Agency is also depicted in how one of these rectangles sits in a āMajor Feature Setā with many others (as shown in Figure 3). This was another possibility for the construction of a model that captured the progress of features and reflected observables, dependencies and agencies of FDD in one place. Further, experi- mental interactions could be created to allow an agent to change feature set progress.
However, additional motivation came from the dishwasher model itself. Having seen the model, it seemed like an obvious basis for the depiction of one of the 3 stages in a feature life- cycle (mentioned above). In particular, it was suitable for the first stage of forming a feature because that is the most elaborate stage and requires the most explanation.
In deciding between, a reporting model and a feature-forming model, it was decided that the feature-forming model was more appropriate at this stage because FDD is a new methodol- ogy and knowledge about how it works is more significant knowledge than the reporting of progress in FDD.
3.2 Model Description
The model is a visualisation of and an executa- ble model of the process of forming a feature and adding it to a feature list. The model is called the Feature-list model. There are 3 win- dows (Figure 4); the first window (top left) al- lows a user to start and pause and re-start the simulation and it also provides the user with descriptions of process steps and progress while the simulation is running. The second window (bottom left) is a state-changing state chart. The third window (right) is the feature space that provides a visual abstract represen- tation of the process of forming a feature.
The model has been created with 3 main agents in mind: ļ· First, it acts as a simulator for the activities of a feature-list team during the 'Build a Feature List' step in FDD.
Figure 2: UML Reporting Component that depicts Feature Set Progress (Coad, 1999)
Figure 3: UML Reporting Component that depicts a Major Feature Set containing 3 Fea- ture Sets (Coad, 1999)
ļ· Second, it provides space for a modeller to express an abstract interpretation of the ac- tivities of the feature-list team. For instance, a feature is represented by a circle.
ļ· Third, it acts as a teaching tool for anyone wishing to learn about the activities that take place during the 'Build a Feature List' step in FDD (the term student is used for this agent in the model).
Other agents include a programmer and a user interface designer, who implements and con- ceptualises the student's desired interaction. There is also a Process Manager who expresses the process that the Feature-list team follows as a state chart.
3.2 Empirical Modelling Principles in
the Model
The Feature-list model works in a Multi-agent modelling environment. Through using this approach, the potential use of LSD as an alter- native approach to software development was explored and it also captured the relationship between the agents. This made it easier to for- malise how different agents observe the system and therefore results in producing a more full system that does justice to all involved agents as appose to the normal ādo what is necessary for the system to workā approach.
The modelling and simulation of this artefact was constructed with a view to imitate a physi- cal experiment and observation of a āstudentā viewing the process of forming a feature. This was successfully done, although it was difficult to capture the discussions of a feature-list team while the feature is being identified, named and prioritised.
One of the main focuses of the Feature-List Model is to be a teaching tool. This makes it open to exploration and experimentation. The variables defined within the script can be ma- nipulated to depict more useful states or com- plete nonsense states. For example, if the user felt the simulation was too fast, it is possible to increase the endtime variable to make the simulation slower. As another example, the x and y coordinates of the feature can be changed to make it appear anywhere on the feature space or even off the feature space.
Different views of the problem domain have been provided to increase comprehensibility of the referent being modelled. Colour is used to create dependency between the current activity and another construal of that activity in a dif- ferent window. For instance, the progress bar and state chart show the same information about the current activity but in different ways. They are indivisibly linked in change.
The user is able to start and pause the process while itās running at any point and explore what is happening at that stage at their own pace. This makes the model interactive as well as representative of knowledge.
The power of definitive notation is also ex- plored in this model. A simple and small script is able to store state information about the en- tire process of forming a feature. If an alterna- tive object-orientated approach was used, then much more effort would have been required. If an alternative, UML approach was used then it would not have been as expressive and com- prehendible as this model.
Figure 4: A screen shot of the Feature-List Model.
