AGILE SOFTWARE DEVELOPMENT: A STUDY
Mrs. A. Hari Priya
Asst. Prof., ECE, Princeton Institute of Engg. and Technology for Womens, Hyderabad, Telangana, India
Mrs. K. Indumathi
Asst. Prof., Computer Science Engg., Princeton Institute of Engg. and Technology for Womens, Hyderabad, Telangana, India
Abstract- This paper provides a better understanding of the architecture related issues in agile development and proposes a model to guide and assist practitioners adopting agile requirements engineering. The methodology was motivated by the lack of structure to the agile requirements engineering process with minimal impact on agility. It describes in detail the phases of the agile requirements engineering process and suggests techniques that can be used to perform these phases.
Keywords: Architecture Challenges in Agile Environment.
1 INTRODUCTION
The conventional approach to the RE process focuses on gathering all the requirements and preparing the requirements specification document up front before proceeding to the design phase.
These upfront requirements gathering and specification efforts consume a long time and leave no room to accommodate changing requirements later in the development cycle. Some of the issues faced by organizations involved in upfront requirements gathering and specification efforts are [8]: Requirements change over a period of time due to changes in customer and user needs, technological advancement and schedule constraints. Identifying new requirements or changing existing requirements affects the other requirements as new
dependencies may surface. Also, changes to requirements involve modifying the architecture and in turn, the code. Accommodating changing requirements is an expensive activity. Hence, gathering all the requirements up front is expensive in the face of rapidly changing requirements.
Also, new requirements can be identified late in the development cycle. Requirements Management activities help plan for and control change. However, it is not always possible to avoid changes to requirements.
Rapidly changing business environments can cause requirements to become obsolete before project completion. On the other hand, the agile requirements engineering [8] welcomes changing requirements even late in the
development cycle. This is achieved by using the agile practice of evolutionary requirements which suggests that requirements evolve over the course of many iterations rather than being gathered and specified up front. Agile requirements engineering has the following issues: (i) Clear specification of activities in the agile requirements engineering process is missing and there is a lack of a set of techniques that practitioners can choose from, (ii)This approach toward requirements usually results in several architecture- related issues that can potentially have negative impact on architectural practices, artifacts or design decisions [8].
2 REQUIREMENTS ISSUES IN AGILE METHODS
Little is known about how agile projects conduct requirements engineering [1]. Recent studies have identified several problems that could result from the lack of
detailed requirements
specifications [2]. The following paragraphs describe the requirements issues when using agile approaches.
Missing Requirements Engineering Activities: clear specification of activities in the agile requirements engineering process is missing and there is a lack of a set of techniques that practitioners can choose from.
Missing Requirements Interface: agile methods assume that it is very hard to elicit all requirements from the user upfront. They also
assume that such
requirements evolve over time as the customer may change its mind [6]. So, nobody knows the entire requirements at the beginning of the project.
That leads to missing the
interface between
requirements. As a consequence, the impact on the next iterations may cause re-work as the requirements interfaces were not addressed.
Non-Functional
Requirements Elicitation:
agile methods do not provide any widely accepted technique for eliciting and managing non-functional requirements [3]. After every iteration, the product is released and the customer is able to test the product. If he identifies problems related to non- functional qualities, the team can adapt the system to meet such requirements in the subsequent iteration without affecting too much the schedule. Often, the customer does not perceive as high impact many non-functional requirements (e.g., scalability, security, etc.). This may affect deeply the release of the final version of the application.
This approach to non-
functional requirements may represent a major risk for agile methods since they lack specific techniques for their management.
2.1 Architecture Challenges in Agile Methods:
The agile requirements engineering approach toward requirements usually results in several architecture-related issues that can potentially have a negative impact on architectural practices, artifacts or design decisions [7].
Following paragraphs briefly, describe the most commonly observed architecture-related difficulties when using agile approaches.
Incomplete Requirements Elicitation: the “user stories” or the like are just the beginning points of both the requirements gathering and development processes in agile methods. Early requirements are simply a place to start. It is expected to add more requirements as more is known about the product. This attitude toward requirements makes software architecture development more difficult. The architecture that chosen by the team during the early cycles may become wrong, as laterof requirements become known [4].
Incorrect Prioritization of User Stories: one of the key architecture-related
challenges commonly
experienced by agile teams is that User Stories may beprioritized without taking the technical considerations in to account [7]. If critical interdependencies among User Stories are discovered later on, it usually requires significant re-factoring with consequences for the whole structure of the software.
Lack of Focus on Non Functional Requirements: as mentioned, handling of non- functional requirements in agile approaches is ill-defined [5]. Customers or users talking about what they want the system to do normally do
not think about
maintainability, portability, safety or performance. Some requirements concerning user interface or safety can be elicited during the development process and still be integrated. But most non- functional requirements should be known in development because they can affect thechoice of the database, programming language or operating system.
3 THE PROPOSED
METHODOLOGY
The Requirement Engineering framework attempts to structure the agile RE process with minimal impact on agility. It reflects the agile principles such as direct stakeholder involvement,
evolutionary requirements, refactoring, no BRUF, just-in-time gathering of details and minimal documentation. Verification and validation activities in the existing agile methods are predominantly validation efforts carried out implicitly.
Preparation Phase – The objective of this phase is to establish rapport among the various project stakeholders. The development team learns the business process of the customers. Also, a high-level mission statement for the project is created which serves as the input to the next phase of the model.
Requirements elicitation and analysis - In this activity, the software engineers work with the customers and end-users to find out the application domain, services that system should provide, the required performance of the system, and so on. There are some identified problems that make the requirements elicitation difficult. To overcome these problems, the requirements gathering activity should be approached in an organized manner.
Requirement Prioritization Phase - Large software systems have a few hundred to thousands of requirements. Neither are all requirements equal nor do the implementation teams have
resources to implement all the documented requirements. There are several constraints such as limited resources, budgetary constraints, time crunch, feasibility, etc., which brings in the need to prioritize requirements.
Most customers on their part have a reasonable idea of what they need and what they want. But during requirements elicitation, the customer provides the Business Analyst (BA) with all the requirements that he feels will make his work easier. The customer is not wrong on his part;
the BA needs to understand the needs of the business to prioritize the requirements.
Requirement Documentation Phase: Each identified requirement is decomposed into stories. The stories are brief descriptions of user- or customer- valued functionality. The stories are validated and the developers estimate the time required for their completion. The stories are implemented during the iterations.
Hence, the developers estimate the time required to implement each story in this phase. The stories are then prioritized and stored in a prioritized story stack. A subset of the prioritized stories is chosen for development during an iteration which lasts for about 2 to 4 weeks.
Prototype Modeling & validation:
This prototype is developed based on the currently known
requirements. Development of the prototype obviously undergoes design, coding, and testing, but each of these phases is not done very formally or thoroughly. By using this prototype, the client can get an actual feel of the system, because the interactions with the prototype can enable the client to better understand the requirements of the desired system. The focus of the previous steps is to provide a soft- structured approach to gathering requirements in the form of features, stories,and tasks.
However, for completeness, we have included a component for implementation of these requirements which is the prototype modeling & validation phase. Also, the model has been designed for small-scale, non- mission and life-critical systems.
This assumption requires viewing the model not only from a requirements engineering perspective but also from a development perspective. Hence, describing the development process is justified. The tasks created during the previous Phase are developed in this phase.
Review Meeting (feedback) & RE- prioritization: Acceptance tests ensure that the system developed meets the expectations of the customer. The customers create acceptance criteria for the stories and test the stories against the criteria. Developers create additional tests which augment
those written by the customers. It is possible that code produced during a previous iteration be broken during subsequent iterations. Hence, acceptance tests from all the previous iterations should be run in order to ensure that all pieces of code show expected behavior.
4 PROPOSED METHODOLOGY – AGILE
4.1 Manifesto
This section discusses how the proposed methodology is reflective of the values and principles stated in the Agile Manifesto. The following paragraphs discuss the focal valuesand principles of the Agile Manifesto and how the proposed methodology reflects the agile philosophy.
"Individuals and Interactions over Processes and Tools" and "Customer Collaboration over Contract Negotiation" are two of the focal values stated in the manifest to. The agile movement focuses on close team relationships, close working environments, and
direct stakeholder
involvement. Human aspects of the software development process are considered more important than the process itself. Relationships between the customers and the development team are given preference over strict contracts. Rather than
focusing on strict contracts, agile methods emphasize on collaborating with the customers to discuss the functionality expected of the system. These values are reflected in the proposed methodology in the following ways:
The methodology emphasizes direct customer involvement.
Customers and users are involved throughout the process.
The activities described in the inception, features identification, features
grouping, groups
prioritization, and nonfunctional requirements identification are essentially
meetings among
stakeholders to discuss, elicit and validate the customer and user needs.
Face-to-face communication among the members of the development team is encouraged especially during the features list identification.
"Working Software over Comprehensive
Documentation" is another value stated in the manifesto.
The main objective of the software development team is to produce working software at regular intervals. Agile methods focus on iterative and incremental development.
Working software is used to
measure progress and minimal documentation is produced. The proposed methodology emphasizes on delivering working software to the customers at the end of each iteration. Documentation produced during the phases is minimal and mostly consists of product concept statement, feature list, groups and their prioritization, NFRs, high-level architecture, and task list.
"Responding to change over following a Plan": The methodology accepts changes in the task list by adding, removing, or updating data requirements or changing business logic or business steps.
4 CONCLUSION
The conventional software development models try to define all essential requirements at the beginning of the software development phase by using huge effort.
Agile methods, on the other hand, do requirements engineering in iterations: the requirements are defined in detail only when they are implemented. Agile methods, however, have a lack of focus on certain parts of what is considered as important in requirements engineering. The customers don't usually cover nonfunctional requirements when they define requirements. Non-functional requirements are not precisely
handled in agile method and it would be good to concentrate more on these.
REFERENCES
1. J. Erickson, K. Lyytinen, and K.
Siau, “Agile Modeling, Agile Software Development, and Extreme Programming: The State of Research” J. Database Management, 2005, vol. 16, no. 4, pp. 88–99.
2. J. Nawrocki et al., “Extreme Programming Modified: Embrace Requirements Engineering Practices,” Proc. IEEEJoint Int’l Conf.
Requirements Eng. (RE 02), 2002, IEEE CS Press, pp. 303–310.
3. A. Eberlein, F. Maurer, F. Paetsch,
"Requirements Engineering and Agile Software Development", Proceedings of the Twelfth International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003.
4. J. Tomayko, “Engineering of Unstable Requirements Using Agile Methods”, International Conference on Time-Constrained Requirements Engineering, (2002), Essen, Germany, 9 September.
5. A. Eberlein, F. Maurer, F. Paetsch,
"Requirements Engineering and Agile Software Development", Proceedings of the Twelfth International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003.
6. K. Beck, "Extreme Programming Explained: Embrace Change", Addison- Wesley, 1999
7. M. Babar, "Going Agile? Beware of architecture-related changes and challenges", (2009b). Available at:
http://www.acubecommunity.org/w ikis/index.php/Architecturecentric_
Methods_ and_Agile_Approaches.
8. S.Ambler, “Agile Requirements Modeling”, 2012 available at:
http://www.agilemodeling.com/essa ys/agileRequirements.htm
.
