Agile Methods in Software Development Priyanka Walke

Agile Methods in Software Development Priyanka Walke

Key Points Waterfall model Agile model Agile vs Waterfall Agile methods: XP & Scrum Method Configuration Process for the Agile Methods Basic Concepts The Agile Method Engineering Process Case Study

Waterfall Model: The first software development methodologies were hardly methodologies, but free-for-all, the organizations struggled to profit from new computer related technologies. As the industry learned more about software development, certain techniques for managing and developing software came into use. One such was the Waterfall model that has dominated the Software development projects for decades.

Waterfall Model: Adoption of waterfall model helped in reducing the failure rate of Software development projects, but even with rigorous management, almost 70% projects using this methodology failed. Organizations tried to cut the failure rate by insisting on more detail in the requirements and design phases.

Waterfall Model Manifesto

Agile Methods Phrase to describe methodologies for incremental software development. Alternative to traditional project management: - Emphasis on empowering people to collaborate. - Make team decisions in addition to continuous planning. - Subset of iterative & evolutionary methods based on iterative and opportunistic development processes.

Generic agile development process

Agile Manifesto

Waterfall Waterfall features distinct phases with checkpoints and deliverables at each phase. vs Agile Agile has iterations rather than phases. Assumes that it is possible to have perfect Small teams work with stakeholders to define quick understanding of the requirements from the start. But, prototypes, POC’s or other visual means to describe often the stakeholders don’t know what they want & the problem. This team defines the requirements of hence can’t articulate the requirements to the fullest. the problem, develops the code, defines test cases and the user verifies the results. Verification occurs at a very later phase of development. Verification occurs at every iteration.

Agile methodologies XP Scrum Dynamic Systems Development Method (DSDM) Crystal Feature-Driven Development (FDD) Lean and Kanban Software Development

XP XP :- Extreme Programming. Concentrates on development over the managerial aspects of the projects. It was designed so that the organizations would be free to adopt all or any part of the methodology. Development: Starts with a release planning phase, followed by a user planning phase, each of which concludes with the user acceptance testing. When the product has enough features to satisfy the users, the team terminates the iteration & releases the software. “User-stories” to describe “what” needs the software should fulfill. Help the user to estimate the time & resources required for that iteration. Next phase of the iteration deals with acceptance test from the users & the bugs found are fixed in the next phase of the iteration. Iterative user acceptance testing can result in release of the software. If the users feel that enough user stories have been delivered, then the team can choose to terminate the project before all the originally planned “User-Stories” have been completed.

Method Configuration Process for Agile Methods Agile methods for software development emerged in the 90’s. Intend to improve the software quality & responsiveness to changing customer requirements. Twelve principles - defined in the Agile Alliance meeting in 2001, which provide support for software development. However, there is no guidance on how to configure these methods for the current organizational situation. Extends the need to develop a configuration process for agile methods that supports to select some practices of different agile methods for the current organizational requirements. Method Engineering (ME) been focused on tailoring of software development methods to the actual need of development context. Focuses to introduce a Agile Method Engineering(AME) process to form situation specific agile method, the method thus formed is a blend of more than one configured method assembled together to form the desired method that fulfils the current organizational requirement.

Motivation for the proposed agile ME process Introduction of Agile methods is definitely an improvement over the traditional development methods. But since requirements of organization vary, there is no single agile method that fulfils the entire set of requirements. This motivates to create a blend of different agile methods based on the rich knowledge of the past usage of these methods under different requirement sets. The applicability of the method thus formed will be significantly improved than the existing methods because the assembled method thus formed contains the essentials of each constituent method.

Basic Concepts Defined Requirement: Present ME approaches have several assumptions, majorly: It is possible for project members to explicitly specify the required situational method upfront & successfully communicate these requirements to the method engineer and these requirements do not change over the lifetime of a project. However, the requirements are often ‘evolutionary’ in nature. Also, the requirements are often vague in nature. To handle them, a support system is provided that converts the elicited vague requirements into a specific format that can be easily input to any tool support designed for the method configuration. The entire set of converted requirements is termed as ‘Defined Requirements’ for the process.

Method Configuration: Since projects differ in various dimensions, e.g., w.r.t development context, situation, complexity and granularity. Different proposals for creating a situational method that fits the unique project have been put forth, ranging from formalized meta-methods to architectural based and further extended to more formal guidelines Present research reveals an Agile Method Engineering(AME) approach that uses method configuration process to configure individual agile methods, these configured agile methods assemble to satisfy the current organizational requirement definition. AME process supports an Essentiality attribute for agile methods. This essentiality attribute can take two values either “Essential” or “Variable”.

Situated Agile Method Formed The heavily weighed (most suitable) configured Methods are assembled to form the situated method. Comprises of Method Part and Method Extension Part. Method part primarily contains the essentials of the first configured method, and may also contain the essentials of the other configured method (s). The length of the method part is obtained by the MAX function applied on all the configured methods. The appended part that is, method extension part contains all the remnant essentials of the configured methods.

Agile Method Engineering Process Defined as a two part process (two sub-processes), in order to make the process more understandable and less complex. Former is to obtain suitable methods for the situation-in-hand and later is to configure them by finding the essential practices for the most-suitable or highly weighed configured methods. The configured methods are put together to form the situated method.

Sub Process 1 The first sub-process deals with finding the suitable methods and assigning weights to them Sub Process 1

Sub Process 1 Begins with gathering of the method requirements - often vague & difficult to understand. To handle this ‘vagueness’, requirements are converted into a Definite Format, specified by the framework. The formatted requirements are fed into the Database that serves two purposes: It creates a repository of requirements for future use. For generating the associative discovery clustering rules to find the cluster of suitable methods using some data mining tool like WEKA. Format for specifying the requirements: Requirements are represented in a format for further processing, which then act as a keywords for method search or cluster operation. The format specifies that every keyword should have at least 2 words or should be split into 2 words where the first word should be an adjective and next one will be noun. Like: Small followed by team : small team Complex followed by technology: complex technology

Sub Process 1 Finding suitable methods: Associative Clustering for method retrieval: Based on associative discovery rules that discover the presence of an object with respect to another object. Association rules are if/then statements that help uncover relationships between seemingly unrelated data in a relational database or other information repository. An association rule has two parts, an antecedent (if) and a consequent (then). An antecedent is an item found in the data. A consequent is an item that is found in combination with the antecedent. A special set of database is designed for the process that contains the set of keywords and the methods that suit the combination of those keywords. Database Schema Database 1: Keywords: Permutations and combinations of the keywords Cluster of Methods: The method names suitable for the combination of the keywords.

Method Selection-selecting suitable methods The Fuzzy Logic Controller is used to assign membership to each of these methods depicting the degree of perfectness of the particular method for the defined requirements. It takes the defined requirements & the methods found above, as its input and assigns the weight to the method. Rule Base here will be in the form of IF-Then Rules. Say if the set of keywords is “X” and method for this is “Y”, and then Value is “High”. Value tells the suitability of the respective method for the given set of defined requirements. The value will be one of the Keywords: Low, Average, and High. The Range for keywords has been decided by the experts. Input will be given in the fuzzified form. The rule base is applied to the fuzzified terms that fall under the work of inference engine. The output of the inference engine will be defuzzified to assign the crisp value. It is not necessary that every time the same value is assigned to a method & further to its practices. As there is a range that is being fed into the fuzzy inference system, so for the same set of defined requirements value may vary in the specified range.

Sub Process 2 The next sub-process describes the procedure for assigning the weights to the practices of the highly weighted methods. Specifically it categorises the essential practices for the current organizational requirement.

Sub Process 2 Assigning weights to practices: The lower level of FLC assigns weights to the practices of the methods that have been obtained from the above step. It filters out the unwanted methods by selecting only the highly weighed processes for this filtering. These methods with highest weights are fed as input with the set of requirements to find the membership degree of the practices of the method. The outcome is then fed into the Database 2. This repository can be used in future if the similar set of defined requirements came across and these databases will be updated periodically. Database Schema: Database 2: Keywords: Permutations and combinations of the keywords. Weighed Methods: Retrieved Agile methods with their respective weights. Weighed Practices: weighted practices of the highly-weighted agile methods for the situation in hand.

Finding essentiality in the method for the set of defined requirements Describes the operations performed on the weighted practices to find the essentiality pattern. For each highly weighted method, the mean of weight for all the practices is calculated separately. This is executed in order to find the essentiality pattern for the practices. Essentials are those that are mandatory to consider for the situated agile method. Assign ‘1’to those practices, whose weights are greater than the nominal value, these are termed as Essentials, ‘0’to remnant practices whose weights are lesser than the nominal value these are termed as Variable.

Assigning the colour scheme In order to differentiate between the highly weighted configured methods, a different color is assigned to each method. Say ‘red’ color to method 1 and ‘green’ color to method 2 and so on.

Assembling the individual highly weighed configured methods This process requires to perform logical OR operation but with an exception that if there are two 1’s of different color both will be considered and will be appended to the result. If the numbers of practices are not same a ‘don’t care condition(X)’ is applied. The obtained outcome is the final situated method formed by assembling the individual configured method. Consider ‘1’ as representation for essential practices of method 1 and ‘1’ for essential practices of method 2. A ‘0’ represents the variable practice of either method. There may arise 4 cases during the OR operation: 1. 1 OR 0: output will be 1 in method part. 2. 0 OR 1: output will be 1 in method part. 3. 0 OR 0: output will be 0 in method part. 4. 1 OR 1: output will be 1 in the method part and 1 in the method extension part.

Method Representation Final output of the above step is represented into two parts: Method part and Method extended part. Method part includes the actual part that comes out of the OR operation whose length is the length of the maximum of the two method representations M1 and M2 and rest of the appended part which is called method extension part that falls under the 4th case of OR operation discussed in later sections, where it is required to keep the essential practices of both the methods, so this part contains the essentials of the second practice as essentials of the first method had already been included in the method part.

Case Study It is a project that involves the upgrading of the existing code and it a large software project. It was being developed for a University which has many colleges located at various different places and each college administration used the software for the academy management placement management of the students. It involved the iterative and incremental development of the software, but on the other side it was a rapid development project. The project had seen an active user involvement during the development of the project because of the ever changing requirements of the customer. Since it was needed by colleges at different locations so teams were also spread at different locations for the software development so it was a distributed development project.

Sub Process 1 Extracting and converting the requirements into a specified format: Two best method are selected out of the 9.

Sub Process 2 Weighted method practices for the current situation-in-hand.

Sub Process 2

Identification of essential practices For DSDM: Mean 1.0 0.9 0.8 0.7 1.0 0.5 0.4 0.3 0.9 6.5/9 0.72 rounded off to 0.7 For FDD: Mean 0.8 0.9 0.4 0.4 0.5 0.9 0.4 0.8 5.1/8 0.635 rounded off to0.6 Method representation after all the calculations is Method M1 (DSDM) Method 2 (FDD) Performing OR on the 2 methods: Output:

Conclusion An agile method engineering approach has been developed to find the degree of veracity of agile methods for the specified set of requirements. Such a method can be used under the circumstances when a single agile method does not fulfils the complete set of requirements of the customer, so there is a need for the blend of parts of more than one agile method, which the introduced method process helps to achieve. Supports to specify the requirements in laymen language and finds the suitable agile methods for the same with the practices that need to be followed. The aim is to deliver situation specific agile method for the current organizational requirement. There is a dependency on the sequencing of the practices and if there is any change in their sequencing, the situated method formed will turn out to be useless. It can be improved to remove this dependency in the future and make this method more flexible to work upon.

Thank You