Evaluation for Feature Driven Development Paradigm in Context of Architecture Design Augmentation and Perspective Implications

Agile is a light weight software development methodology that is useful for rapid application development which is the need of current software industry. Since the focus of agile software development is the customer but it does not provide the detailed information about the application’s architecture and documentation, so software architecture has its own benefits and use of it has many positive effects. The focus of this paper is to provide a systematic mapping of emerging issues in feature driven development that arises due to lack of architecture support in agile methodology and proposed solution’s model. Results of this mapping provides a guideline for researcher to improve the agile methodology by achieving the benefits employed by having an architecture in place that is aligned with agile values and principles. Following research addresses to implement the SEI architecture centric methods in FDD methodology in an adapted form, such that the burden of architecture doesn’t affect the agility of FDD. And the researcher found the de-motivators of agile which helps to understand the internal cycle and reduces the issues to implement the architecture. This study helps to understand the difference between architecture and FDD. This researcher mapping creates awareness about the process improvement with the combination of architecture and FDD. Keywords—Software architecture; agile; architecture and agile; integration of architecture and agile; agile architecting practices


INTRODUCTION
Agile practices have gained popularity among various organizations due to its feature of reducing cost and encouraging change during the development cycle.In modern software development environment, changes to any software product are inevitable [39].Agile methodology provides answer for this issue.Feature driven development lies under the umbrella of Agile.FDD is a process for assisting teams in producing features incrementally that are useful for the end user.It is extremely iterative and collaborative in nature [5].The FDD process has extensive guidelines for identifying issues in the system.It also supports in providing builds to the end user on daily or weekly to add more features to the existing software.FDD process requires configuration management for its proper execution because features are being developed in parallel.In this way, integration of the features is made easy while executing the process.Feature Driven Development provides activity tracking support.Activities can include coding, design or testing.Details of this process are reflected in Fig. 1.Feature tracking is implemented by assigning the value ranging from 0 to 1 to the feature.0 shows that this feature has not yet been developed and 1 depicts the completed feature [1].
Literature defines the software architecture as "The architecture of a software-intensive system is the structure or structures of the system, which comprises software elements, the externally visible properties of those elements, and the relationships among them" [3].Software architecture defined by IEEE 1471 standard is "The fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution" [7].www.ijacsa.thesai.orgFig. 1.Hybrid FDD with architecture evaluation methods [16].

A. FDD (Feature Driven Development)
Feature driven Development is a procedure for helping groups deliver visit, substantial working outcomes.It utilizes little squares of customer esteemed usefulness called highlights.It sorts out those little pieces into business-related capabilities.Fig. 1 demonstrates the half and half FDD with an engineering assessment.FDD centers engineers around creating working outcomes at regular intervals.FDD is better arranged to work with group where engineers' experience shifts.It offers advance following and announcing abilities.This solaces supervisors and makes it more alluring for enormous organizations [3].Fig. 2. Feature driven development [8].

 Process # 1: Develop an overall model
The first step of the FDD procedure is to make a detailed model of the system.The clue is for both field and progress members of the team to increase a worthy, shared understanding of the tricky domain.Fig. 2 shows all the phases flow of FDD.
 Process # 2: Build a feature list The initial step of the FDD procedure is to manufacture an itemized model of the framework to be produced, which catches the partners" suspicions and necessities.The sign is for both field and advance individuals from the group to build a commendable, shared comprehension of the precarious space.Fig. 2 demonstrates every one of the stages stream of FDD [3].
 Process # 3: Plan by feature Manager of project, Development Manager, and Chief Programmers design the request that the highlights are to be executed, in light of highlight conditions, stack over the improvement group, and the intricacy of the highlights to be actualized [3].
 Process # 4: Design by feature Highlights different features are planned for improvement by doling out them to a Chief Programmer.Boss Programmer plans little gathering of high spot at once for enhancement.Such a gathering of highlights shapes a Chief Programmer"s work Package.The Chief Programmer at that topic an element group by distinguishing the proprietors of the classes (designers) liable to be associated with the improvement of the chose feature(s).The central Programmer at that point refines the protest demonstrate in view of the substance of the succession diagram(s).The engineers compose class and technique prefaces [3].
 Process # 5: Build by feature Working of the design plan bundle delivered amid the Design by Feature process, the class proprietors execute the things fundamental for their class to help the outline for the feature(s) in the work bundle.The code created is then unit tried and code examined, the request of which is controlled by the Chief Programmer.After an effective code assessment, the code is allowed to build [3].

B. Architecturecentric methods
IEEE 1471 standard [6] explains software architecture as "The fundamental organization of a system exemplified in its components [40], their relationships to each other and to the environment, and the principles managing its design and evolution".
The software architecture serves as the outline or skeleton of a software system to be built [8], [9].The benefits of software architecture include a tool for stakeholder communication [7], designing decision documents, identifying design decision risks, reusing [10] scalability [2], allows to program, saving time, the cost of correction or reprocessing is recorded and above all, it helps to avoid software catastrophes [4].

C. Need of Systematic Mapping
In this paper, systematic mapping was explored to find problems that are faced during measurement of individual"s performance.PSP quality principles were explored during systematic mapping which can be used for individual"s performance measurement in agile team.Main purpose of study is to calculate architecture support provided in feature driven development that resides under the umbrella of agile [12], and how researcher can achieve benefits of architecture using agile methodologies without compromising the agile values [32].This paper also describes how to cumulate the knowledge by performing systematic mapping study, there are few steps such as "planning", "conduct the research" and "selection of primary study".www.ijacsa.thesai.orgII.LITERATURE AND BACKGROUND STUDY Architecture-centric approaches feature early suspicion, arranging and documentation of programming engineering.This infers a specific accentuation on quality traits and outline choices, exercises depend on across the board correspondence and joint effort among partners [13].
In Agile procedures clients or individuals are focal point of focus [35].Touching delivery of working programming is need over weighted documentation and reports.Testing obliges the conveyance of each little working programming units and successive customer criticism on these product units enables keeping the product to extend on right track and lined up with objectives of the client.XP, Scrum, Feature Driven development are few examples of agile methodologies.
Since agile approaches have important influence on software development practices from industry perspective.However, there is also a prominent impact regarding issues that arises due to lack of SA, which is considered most important artifacts in traditional software development.Many industry professionals who are involved in using agile approaches view software architecture from the perspective of the plan-driven development paradigm [38].According to them, software architecture design and evaluations requires too much effort which has very little impact to customer"s needs from the system [37].Hence, they view architectural activity as a part of highly formal processes.On the other hand, practitioners of software architecture believe that solid architectural practices cannot be followed using agile methods [36].However, recently there is an increased appreciation related to the importance of incorporating architectural practices in agile methods.Hence, there is a growing interest and research in this perspective of integrating these two different cultures [11].Researcher trust that a decent comprehension of current industry practices and issues identified with software architecture is a most important for building strategies to incorporate architecture in agile methodologies [31].Literature has additionally highlighted a Hybrid Software Architecture Evaluation Method for FDD [33], [34].Utility trees, affectability focuses and tradeoffs are the characteristic highlights of ATAM [18], [19].

A. Rational
Researcher undertake the study to improve/evaluate the tailored feature driven development methodology by integrating software architecture support that was originally part of traditional software development so that organizations using FDD can also achieve benefits that are provided by Software architecture.Since software architecture is a very heavy activity which is against the agile core principles so a light weight version of software architecture has been proposed and evaluation will be made on this tailored FDD process as against with traditional FDD process.There is limited published research that validates and measures the impact of integrating architecture in FDD without compromising agile values, and this case study sought to contribute to the body of research in this area.

B. Objective of the Study
The objective of this study is to evaluate the impact of integrating architecture in FDD methodology with respect to reusability, cost, effort, requirement traceability and project failure risks due to unknown domain and untried solutions.Researcher proposed the solution model in proposed solution section.

C. Factors Analysis Method
Researcher used the Minitab static tool [49] for finding and analyzing the results of factors of Agile.Minitab tool helps to create the different types of graphs which help to understand the scenario of factors.Researcher provided the complete results of all factors in Appendix "A" part and factor analysis result table.Moreover, Appendix "B" section show result in different graphs [49].

D. Planing of Mapping
In this mapping, issues have been gathered that arises due to lack of architecture in agile methodology with reference to feature driven development (FDD).This mapping will help us to evaluate the benefits [49] that can be achieved if architecture support is provided in agile development.

F. Search Strategy
Computing databases become the basis for searching primary studies.Following search strings and keywords are used in these databases.

A. Search Engine
Search strings are put in advanced search of following software engineering databases: IEEE, ACM, Science direct, Springer and Google Scholar.Fig. 3 shows all the digital libraries.

B. Inclusion Criteria
Research papers are selected based on their titles and abstracts.Following criteria will be used to select the papers.
 Research papers discussing the integration of agile and architecture at any level.
 Research papers that highlights project failure using agile methodology.
 Research papers relevant to agile values will be included.
 Research papers that discusses the architecture impact on reusability, cost, effort and requirement traceability.

C. Exclusion Criteria
These papers were excluded.
 Books and slides, etc. were excluded.
 Papers other than primary and irrelevant studies.

V. CONDUCTING MAPPING
Search results from different digital libraries are mentioned in Table I.These digital libraries were selected because they were highly known for having empirical studies and literature surveys and are most relevant to software engineering field [27].Digital libraries search was made to include all the papers that identify agile issues, architecture benefits, or any other paper that discusses integration of both of them.After this initial search, papers were selected from the digital libraries based on the inclusion and exclusion criteria mentioned in Section IV.With further investigation of selected papers, researcher has filtered studies that are most appropriate to the problem in hand.Table I shows all the found publications.These filtered papers are shown in Table II.Relevant studies are shown below in Table III.The combined OPN and UML method for developing an agile manufacturing control system 6 [26] Building Software Solutions in an Industrial Information System: The 5+1 Software Architecture Model 7 [27] The necessary nature of product traceability and its relation to Agile approaches 8 [1] Agile software development methods review and analysis The total of primary and relevant study count that was included in this mapping is 23.These are the strong evidence that shows conflicting as in Fig. 4. Study source distribution on IEEE, Google Scholar, ACM, Springer, Science Direct and Scopus is displayed in the graph on the right side Fig. 3.

A. Data Collection
Data obtained from each study was:  Source and full reference.
 Grouping of the study type (Agile architecture integration, Agile issues, Architecture benefits, Architecture agile conflict)  Summary of each study that includes main research questions.

B. Data Analysis
The data was collected to show:  Whether the study presents high level architecture support with evidence in feature driven development.
 Whether the study presents explained low level design support with evidence in feature driven development.
 Whether the study highlights any risks due to lack of architecture.
 Factors that are inherited by architecture but are against the agile values and vice versa.

VI. MAPPING OF AGILE DRAWBACKS RELATED TO ARCHITECTURE
The issues are described in the below table (Table IV).By adding an architecture support in agile process, researcher can remove these drawbacks.Design decisions" documentations addresses knowledge and design erosion, and rationale vaporization.[13][3] 3 In case of unidentified domain and novel solutions the Risk of failure [11] [14] and [13] provides an unambiguous study of architectural decisions and a clear classification of user stories as quality scenarios and should decrease these risks.

4
Extremely skilled domain developers mandatory for successful projects [11] [14] and [13] provides a step-by-step approach to architecture, which is also referred to as a plan-based approach, known for a person's exploration of the new domain.

5
Lack of requirements traceability [11] [13] The step-by-step approach to architecture classifies the requirements according to their importance and documents them in the development of software

A. Reference Architecture Development 1) Develop Sub-System Model
To develop sub-system model, engineering principles are used as an input to these models [28].The engineering principles include design principles and general guidelines for subsystem design.Overall system structure is defined by grouping functions into subsystems, which are, then allocated to different hardware the model created for them is called subsystem model.

2) Identify component reusability
Reusability of the components and their fitness for large architecture is determined from subsystem model. Important (influential, that is) stakeholder.

 budget overruns or client dissatisfaction
At the end of this activity, Researcher has a list of ASFs in hand to perform further processing based on this

2) Requirement Prioritization
Prioritization is done by ranking.Researcher gave each one a different numerical value based on its importance.For example, the number 1 can mean that the requirement is the most important and the number n can be assigned to the least important requirement, n being the total number of requirements based on the combined importance relevant to architecture and stakeholders.Researcher choose this method as it can be difficult to align different stakeholders" perspectives on what the priority of a requirement should be; taking an average can however, address the problem in this prioritization method.
3) Prioritized feature list Prioritization done in the previous activity will listed down to form a Prioritized Feature list along the rationale of prioritization and get it approved from the concerned stakeholders.
C. Architecture Refinement 1) Refine sub-system model Sub system model is refined in each iteration as the knowledge of stakeholder increases and issues they faced with the delivered iteration.
2) Rationale capturing www.ijacsa.thesai.org In refinement of sub-system model, every decision and change is documented in the specified template, so that back tracking is possible whenever needed.

VIII. CONCLUSION
In this paper, a systematic mapping of agile issues, the proposed model provides the detail to reduce these issues and architecture benefits have been presented so that researcher can addressed by integrating architecture in agile methodologies with reference to feature driven development.There are different types of architectural challenges reported in literature Table VI.Researcher has discussed in details about SA with FDD.Researcher discussed very clearly about drawbacks of agile related to architecture in Table IV.Researcher found the agile drawbacks and benefits of architecture in Table V. Fig. 5 shows the distribution of papers years wise.Fig. 6 shows the drawbacks in agile.Fig. 7 discusses the most important demotivators of agile.Fig. 8 is the main thing that is proposed solution model.Minitab static tool is used to analyze the factors of agile which are mentioned in Fig. 7 and produce the result in the form of quantitative values and different views that graphs are Scree plot which is the major graph (Fig. 6) of this analysis.Other graphs and results are shown in Appendix section which are: Fig. 9, 10, 11, and 12. Research questions have been discussed through table for data.This mapping acts as a foundation for further research to incorporate architecture in agile methodologies in a way that is aligned with agile principles.In this systematic mapping, researcher described the concepts of Software Architecture with FDD.

IX. FUTURE WORK
Researcher will experiment based on the proposed model an adapted architecture that will be light weighted and can be integrated with feature driven development without harming the agility of this process.Researcher evaluated the proposed method and it proved to be useful in increasing reusability, traceability and also cost effective for middle sized projects.Moreover, this proposed process also puts positive effect on agile values and principles.
B. Refinement of Feature List 1) Identify ASFsIndicators for architectural significance include: Extraordinary business value and/or technical risk.

Fig. 11
Fig. 11 tells the co-relationships in two ways amongst factors vertically and horizontally.These relationships are between two factors.

Fig. 12
Fig. 12 biplot shows by using the both points.

TABLE I .
PUBLICATION COUNT On the Responsibilities of Software Architects and Software Engineers in an Agile Environment: Who Should Do What?

TABLE IV .
MAPPING OF AGILE DRAWBACKS RELATED TO ARCHITECTURE