Using FDD for Small Project: An Empirical Case Study

Abstract

Empirical analysis evaluates the proposed system via practical experience and reveals its pros and cons. Such type of evaluation is one of the widely used validation approach in software engineering. Conventional software process models performed well till mid of 1990s, but then gradually replaced by agile methodologies. This happened due to the various features, the agile family offered, which the conventional models failed to provide. However besides the advantages, agile models lacked at some areas as well. To get the extreme benefits from any agile model, it is necessary to eliminate the weaknesses of that model by customizing its development structure. Feature Driven Development (FDD) is one of the widely used agile models in software industry particularly for large scale projects. This model has been criticized by many researchers due to its weaknesses such as explicit dependency on experienced staff, little or no guidance for requirement gathering, rigid nature to accommodate requirement changes and heavy development structure. All these weaknesses make the FDD model suitable only for large scale projects where the requirements are less likely to change. This paper deals with the empirical evaluation of FDD during the development of a small scale web project so that the areas and practices of this model can be identified with empirical proof, which made this model suitable only for large projects. For effective evaluation, the results of FDD case study are compared with a published case study of Extreme Programing (XP), which is widely used for the development of small scale projects.

Systematic Literature Review of Trend and Characteristic Agile Model

“…Feature Driven Development Peter Coad and colleagues created the concept of feature driven development in 1999, and Palmer and colleagues improved it in 2002 [29]. Large and complicated projects frequently adopt the agile paradigm known as "Feature Driven Development" (FDD) [2]. The five stages of FDD are: developing the overall model; building the feature; planning and designing by feature; and building by feature.…”

“…It is not surprising that numerous researchers have raised research on agile approaches given the dependability they offer. According to studies by Aftab et al [2] between Extreme Programming (XP) and the Feature Driven Development (FDD) approach. This study examines a number of indicators, including productivity, actual work effort, and design classes.…”

Presenting and Evaluating Scaled Extreme Programming Process Model

“…The reason of choosing the XP case study for comparison with the case study of proposed SXP is to critically analyze the performance of SXP with empirical data, so that any gap or deficiency can further be identified for further improvement. This study compares the proposed SXP with XP process by providing detailed empirical results of all of the iterations as per the guidelines provided by [10]. Both of the case studies (SXP and XP) are empirically compared in Table II.…”

“…Maintenance phase deals with the addition of any new functionally (if required) by keeping the old ones intact and finally death phase deals with the completion of software as per client's requirement and ends with the release of software product. All of these phases are backed by twelve best practices of software engineering, including: "planning game, small releases, metaphor, simple design, continuous testing, refactoring, pair programming, collective ownership, continuous integration, 40-hour work per week, on-site customer and particular coding standards [8], [9], [10]. The structure of XP process model along with the umbrella of these 12 practices is best suited for small scale project and also can handle frequently changing requirements very 163 | P a g e www.ijacsa.thesai.org effectively [4], [39], [40], [44].…”

Extreme Programming vs Scrum: A Comparison of Agile Models

“…To produce good quality product, agile frameworks deliver the software considerably fast [11]. Agile frameworks are iterative and incremental in nature hence user's requirements are fulfilled by constantly delivering fragmentary and partly done software [12][13] [14]. Any change in client's requirements is also easily handled during any phase of development.…”