Overview of Agile Software Development - Term Paper Example

?A Report on Agile and OOAD By Table of Contents I. Introduction 3 II. Overview of Agile Software Development 3 III. History and Fundamentals of Agile Software Development 4 IV. Current Status of Agile Software Development 5 V. Benefits and Constraints 5 1. Accommodate changes at any stage 6 2. Customer Involvement 6 2.1. Availability 7 2.2. Complete Knowledge 7 3. Trust Factor 7 4. Effective for small projects 7 5. Documentation 8 6. Non-functional Requirements 8 7. Requirements Management 8 VI. Relationship between agile, RUP and OOAD 8 VII. Guidelines for Combining Agile with other approaches 9 VIII. Case Study 10 IX. Recommendations and Challenges 10 X. Bibliography 11 I. Introduction In the past few years, there have emerged a large number of software development practices and processes. In this scenario, agile software development methodologies have become a trend in quickly changing software industry. In the past, only the traditional software development methodology was the only method to develop software products. However, it was not supportive for late changes and iterations. In order to deal with the issues presented in traditional software development approaches there emerged a very attractive software development approach, known as agile software development. Soon it became a standard software development approach which received a great deal of support of all kinds of experts from the software industry. At the present, the majority of software development firms and software developers are aware of agile software development methodologies. They use it all the way through the software development lifecycle. Basically, agile software development approach is based on some principles which can be tailored according to varying requirements of software projects. This report will present a detailed analysis of agile software development. This paper will discuss some of the important aspects associated with agile and its relationship with other software development practices. This report also discusses a case study to demonstrate the usefulness of agile software development methodology. This report also presents some recommendations and challenges in the implementations of recommendations. II. Overview of Agile Software Development The basic goal of agile software development methodology is to let a firm become agile. In this scenario, the term “agile” is used to reveal number of meanings like that implement changes rapidly, deliver the completed product rapidly and accommodate change frequently. In view of the fact that there are a large number of software development approaches (for instance Scrum, XP and many more) which come under the umbrella of agile software development paradigm and they differ in emphasis and practices, however they all follow the same principles which come under agile agenda. In this scenario, many researchers present the common description of the agile manifesto. According to researchers agile methodology and its family members are based on the following principles (Kavitha & Thomas, 2011; Lucia & Qusef, 2010; Paetsch, 2003): Working software application or a product should be delivered as rapidly and regularly as possible (it should be delivered in days in place of weeks and in weeks in place of months) Working software application should give an insight into the progress of the overall project Improving the customer satisfaction by providing them rapid and regular release of implemented software application. Agile software development methodologies are aimed at supporting and accommodating late changes all the way through the software development lifecycle. In fact, late changes in requirements are effectively accommodated without having serious effects on the overall development or project. Agile software methodologies are designed to support effective collaboration, communication and close on a daily basis cooperation between business people and developers in fact among all the stakeholders Agile software development methodologies are highly based on daily meetings and face-to-face communication in order to support software development. Software projects are developed and maintained by motivated team members, who can be trusted Agile software development methodologies pay a great deal of attention to technical quality and good design. Agile software development methodologies are aimed at simplifying the software development process by providing ease and simplicity Agile software development methodologies are designed to support self-organizing teams Usual adaptation to varying situations There is no doubt that agile software development methodologies have been built in an attempt to address the issues of providing high quality software quickly under rapidly and incessantly changing business situations, environment and requirements. In actual fact, agile software development methodologies have an excellent reputation in the IT and software sector. The research has shown than more than 69% of IT firms are adapting one or more agile methodologies for use in common project management as well as organizational development (Lucia & Qusef, 2010). III. History and Fundamentals of Agile Software Development The history of agile software development approaches can be traced back to the mid-1990s, when a number of members of agile family began to emerge. In this scenario, some of the most important and commonly used members of agile family included: Extreme Programming (XP), Scrum, eXtreme testing, DSDM (Dynamic Systems Development Method), Crystal Family of Methodologies, Adaptive Software Development (ASD), and Feature-Driven Development (FDD). However, ideally, the roots of agile software development approach are connected to lean manufacturing which started in the 1940s along with agile manufacturing which was started in the early 1990s. Basically, lean manufacturing is based on similar concepts that have been promoted by the agile software development approaches. However, the lean development was not intended to use for software development purpose. Basic ideology behind the lean development is developing a product in short-cycle time, multi-skilling, reduced setup and flow being in position at the same time as pushing out waste in time, regularly, space and inventory. In this scenario, the need of the agile methodologies in manufacturing industry refers to .the potential of a firm to be successful in an atmosphere where changes are rapidly and unpredictably occurred. Though, a large number of researches are still being carried out to determine the definite differences between agile and lean development with respect to manufacturing sector. However, key attributes and characteristics of both are available in the methodologies and fundamentals of agile software approach. For instance, in case of lean software development the agile practices are combined with lean principles (Salo, 2006, pp. 24-28; Dyba & Dingsoyr, 2008; Larman & Basili, 2003). Historically, in the field of software development, the struggles and efforts in agile movement were started to emerge in 2001 after the meetings of a number of practitioners researchers and inventors of these approaches in an attempt to recognize the mutual features of these approaches that both these approaches integrated new and old attributes and ideologies, as well as evidently combined some specific attributes in common. As a result of these efforts and meetings the manifesto for agile software development was emerged and all these participants decided to choose the word "agile" to integrate the techniques, practices and methods that would collectively share the characteristics, principles and values of agile software development. In addition, the basic principles and values of agile software development approach are believed to be the essential characteristics that should be the important part of techniques of any software development approach that claims to be a member of agile family (Salo, 2006, pp. 24-28; Dyba & Dingsoyr, 2008; Larman & Basili, 2003). Additionally, some of the agile practices and features are believed to be new and modern however some of them are believed to be emerged from the old and iterative methodologies. In fact, the impact of stakeholder participation in project development as well as in working decisions and a higher level of concern for complete performance in high team motivation, devotion, and spirit have also previously been identified among production employees by a number of studies. It is believed that incremental and iterative approach of software development have not been emerged from only by agile advocates, however they have a long historical time span in software development (Salo, 2006, pp. 24-28; Dyba & Dingsoyr, 2008; Larman & Basili, 2003). IV. Current Status of Agile Software Development At the present, a large number of studies, researches and surveys are being carried out at each level in order to determine the positive and negative features of agile methodologies. In this scenario, the previous concepts of agile approaches, particularly, received lots of discouragement and criticism due to the absence of scientific proof, as well as their appropriateness and usefulness just for the management of those software development projects in which small-sized and co-located teams were attempting to develop non-safety critical software applications with always changing requirements (Salo, 2006, pp. 24-28; Dyba & Dingsoyr, 2008; Larman & Basili, 2003). In view of the fact that since the beginning and emergence of agile software methodology, both researchers and practitioners have paid a great deal of attention to agile approaches, as a result developing an increasing amount of experimental facts and data on the diverse features of agile software development methodologies. Despite the emergence of specific practices and methods of agile software development to deal with specific context of software applications, a variety of challenging issues have emerged, for instance the applicability of agile methodologies for huge, critical and multisite projects as well as the compatibility of agile approaches with available standards. In the past few years, the researchers and practitioners have started to pay attention to business and organizational features of agility. In the same way, the previously developed agile techniques and approaches have been continuously improving and further evolving in order to integrate various useful features for instance, XP, Scrum, Test-Driven Development (TDD), Crystal and DSDM. In view of the fact that at the present there is as much as experimental proofs are available on the agile practices and techniques, hence the discussion in the favor of or against the use of agile methodologies is currently not absolutely about their advantages, however, it is about the need to grow their scope and implement them within industries in conjunction with predefined and established plan-driven processes (Salo, 2006, pp. 24-28; Dyba & Dingsoyr, 2008; Larman & Basili, 2003). The research has shown that one critical challenge in implementing agile methodologies within organizations can be occurred while balancing the presently controlling engineering practices and approaches of practicable, anticipated and repeatable practices along with agile software development approaches, which again combine process adaptation, self-organization and continuous changes. It is suggested that an organization must balance the two practices with the intention of attaining the benefits from their strengths (Salo, 2006, pp. 24-28; Dyba & Dingsoyr, 2008; Larman & Basili, 2003). V. Benefits and Constraints Without a doubt, agile software development methodologies offer a large number of benefits over traditional software development approach that’s why the use of agile software development methodologies for the development of software development is increasing all over the world. Basically, agile software development methodologies were emerged to deal with the problems associated with traditional software development approaches. In traditional software development, the development of a software application moves in a sequential manner. In this scenario, second step is performed only after the successful completion of the first step and in the same way this sequence flows all the way through the software development life cycle as shown in figure1. Figure 1Traditional Software Development Approach In this scenario, if some changes occur at latest stages of the software development then it becomes difficult for the software development team to accommodate those changes. As shown in the figure2, the late changes will increase the cost and time of overall software development. In order to deal with this issue agile software development methodologies were emerged (Paetsch, et al., 2003). Figure 2 Cost of changes, Image Source: (Sillitti & Succi, 2006) However, there are many beneficial features of agile software development approaches which are also the drawbacks of agile software development. These features are discussed below: 1. Accommodate changes at any stage In view of the fact that agile software approach supports change accommodation all the way through software development process so the customer can ask for changes at any stage and this process continues until the completion of final product. However, it is a time-consuming process to accommodate changes throughout the development and it slows down the development process (Paetsch, 2003; Paetsch, et al., 2003). 2. Customer Involvement Without a doubt, a key goal of all agile software development methodologies is to have the customer available or ’on-site’ (XP). In this scenario, software development team gets fast feedback and communication is improved. Additionally, this close communication between both parties leads to a superior understanding of the development process (on customer side) and requirements (on developer side). In addition, the customer is able to make final commitments and decisions. In this scenario, acceptance of the features implemented, any changes in requirements, etc. can be decided straightforwardly by the customer, supporting a quick decision making practice (Sillitti & Succi, 2006; Paetsch, 2003; Paetsch, et al., 2003). In this scenario, agile software development methodologies engage the customer all the way through the entire software development process. However, engaging a customer throughout the software development process is also costly, as the customer is spending a lot of time. Though, agile software methodologies highly promote customer involvement throughout the software development process. However, in some cases this involvement becomes a challenge, such as practice (Sillitti & Succi, 2006; Paetsch, 2003; Paetsch, et al., 2003): 2.1. Availability In view of the fact that the agile software development methodologies require the customer to be always accessible to respond to any issues and questions raised by the software development team. On the other hand, any delay in the response will surely cause delay in the software development process. In addition, a large number of organizations reported that achieving on-site customer representation is difficult (Sillitti & Succi, 2006; Cao & Ramesh, 2008). In smaller projects where there is only one customer it can be feasible for the customer to be present or be the part of software development process. But in case of large size projects, where there are so many stakeholders, involving each stakeholder in the development process is not possible. 2.2. Complete Knowledge In some cases, there can be a representative of all the project stakeholders. For that reason, he cannot answer all questions, unless he is the domain expert and have knowledge of how the application should work and the input/output data required. This situation becomes more critical when the size of the project increases (Sillitti & Succi, 2006). Hence, agile software approach does not seem suitable for large size projects. 3. Trust Factor In view of the fact that the stakeholders have the knowledge about the system to be built hence stakeholder participation can play a significant role in the current software development work? In fact, in the previous studies, stakeholder participation was appeared to be the one of key reasons for project success, at the same time as the lack of stakeholder participation was the key reason given for projects that faced serious challenges or failed (Sillitti & Succi, 2006; Paetsch, 2003; Paetsch, et al., 2003). In many cases system stakeholders feel it difficult to know or trust the agile software development process. A number of researches have shown that building and maintaining trust between the customers and developer, which is necessary for agile software development, can be difficult. In addition, customers who are used to a traditional software development processes might not believe or trust the agile development process for the reason that there is no standard agile requirements process and its requirements engineering process varies from project to project. Hence the requirements will not be collected in an effective way (Cao & Ramesh, 2008). 4. Effective for small projects One of the major limitations of agile software approach is that it is not suitable for large size and critical projects. It is only suitable for small size projects with smaller team size. The reason of this limitation is its ineffective requirements engineering process. In an article, a professor of Carnegie Mellon University, John Vu discusses his thoughts about agile software development methodologies. According to their experience and research agile software development methodologies are suitable for small team of people working on small size software development project. Professor John Vu has managed a large number of projects using agile software development approaches however he had better success with Agile in small projects (with a team of less than 10 people) (Vu, 2013). 5. Documentation Agile software development methodologies hardly have complete and dependable requirements documentation. Though, some agile software development methodologies comprise a kind of documentation or suggest the adoption of a requirements document (such as Scrum, DSDM, and Crystal) however the decision of the key extend and contents is left to the development team and not discussed thoroughly. Hence, due to lack of documentation agile software development process face long-term problems however lack of documentation increases the speed of actual software development. The documentations can answer his questions if he simply read through the entire documents. Additionally, asking questions to other team members will surely delay work, due to the time required to clarify a large project. However, these long term problems are reduced as agile methods often generate compact and clean code (Paetsch, 2003; Paetsch, et al., 2003). 6. Non-functional Requirements Agile software development methodologies do not effectively deal with non-functional requirements. In this scenario, systems users describing the system requirements what they want the system to do usually do not take into consideration associated non-functional requirements such as maintainability, resources, safety, performance and portability. In fact, in some cases non-functional requirements can be related to functional requirements and are hard to explain. However, the majority of non-functional requirements should be identified in development for the reason that they can have an effect on the selection of programming language, database or operating system (Paetsch, 2003; Paetsch, et al., 2003). 7. Requirements Management Requirements management is the process of managing changes to the software requirements. Since agile software development methodologies do not focus on appropriate documentation hence it is difficult to keep track to changes in requirements. Requirements management should be a formal process but agile software development methodologies do not follow it formally (Paetsch, 2003; Paetsch, et al., 2003). VI. Relationship between agile, RUP and OOAD Basically, the Unified Process is a commonly used iterative software development approach for the development of object oriented software applications. In particular, the RUP (Rational Unified Process), is known as a comprehensive alteration or enhancement of the Unified Process, which has gained a wide popularity among the majority of software development firms. Unified process is believed to be a very bendable and open, as well as encourages comprising competent techniques from other iterative software development approaches, for instance from agile software development methodologies such as, XP’s test-driven development, continuous integration and refactoring techniques can be combined within a unified process based project. In addition, unified process is well-matched with the agile manifesto as it also encourages the communication between Individuals and interactions over tools and processes, the delivery of working software over comprehensive documentation, customer cooperation according to agreement negotiation and responding to change over following a plan (Larman, 2004, p. 19). It is believed that in order to make the adoption of agile software development successful an organization must form a culture that is open to the values, new ideas and concepts and principles of agile software development. In this scenario, the research has shown that unified process is sometimes followed by those firms that either indirectly or openly do not understand the values of agile software development (Ambler, 2012). In the field of software development, Object?Oriented Analysis and Design (OOAD) is a software development approach based on the idea that a software application should be developed using a set of recyclable elements known as objects. In this scenario, in place of dividing data and processes applied on data in the organized way, objects comprise the characteristics of both. Basically, the agile software development is an excellent response to the thought that it is nearly impossible to describe, font side, all the functionality of a software application. In view of the fact that functional requirements always change, as well as the application environment can also change, which can require further changes to the programming concepts and coding ideas. Without a doubt, in many software development projects the development of a database is also a part of overall software development which normally requires the implementation of refactoring for the database code (for instance mapping, schema and data) similar to other software code. The use of object oriented concepts in the database improves the efficiency of database development through re?programming its access layers, and moving the existing stored data to the new database schema regularly. In addition, the overall worth of agile software development is sensibly well implicit. On the other hand, it is problematic to found an ultimate worth of the investment through object determination and agile development. In this scenario, the execution of to some extent shortened techniques offer some standpoint on the possible worth of combining the development of a database into the agile development methodology (Versant Corporation, 2009). VII. Guidelines for Combining Agile with other approaches In order to be successful in the use of agile software approach, software developers and database administrators should be well aware with the basic terms and ideas associated with object-orientation. The research has shown that the developers commonly make a mistake as they believe that the object-oriented analysis and design paradigm seems identical to the structured software development approach however actually they are very different from each other. In this scenario, they make a mistake of thinking that they have to do objects all the way through the software development for the reason that they have been putting into practice the identical software-engineering concepts. Hence, in order to be successful they must identify that the structured approach is different than the object oriented approach (Ambysoft Inc. , 2012). In view of the fact that unified process is widely used all over the world for the development of software applications as well as it promotes extensively documented best practices, hence it is beneficial for industry professionals to become familiar with it, especially the students who are newly entering to software industry (Ambler, 2012). It is believed that the unified process and agile software development methodologies are compatible with each other however it heavily depends on the culture of an organization not so much on the unified process itself. A software development firm can simply make use of the agile methodologies to enhance its unified process modeling endeavors, however in order to be successful they need to address cultural issues and challenges existing in their organization. As it is clear from the above discussion that a software development firm can make changes to its existing unified process in order to tailor it according to agile practices. However, in order to achieve this goal, an organization’s environment must be completely supportive to both approaches. In this scenario, the basic intention of a firm that is going to adopt the unified process is frequently to instantiate it as a impartially inflexible as well as formal process while the software development firms that adopt agile software development approaches are normally intended to perform their tasks in a more fluid way. Happily the unified process is very flexible as it can be tailored according to varying needs and requirements with the intention of making it to be soundly agile. In view of the fact that both the unified process and agile approaches follow the principle that the software application is delivered quickly and in the iterations. Since the unified process openly comprise modeling practices it can be easily identified where agile principles should be followed to improve tailoring of the unified process. However, it can be achieved only if an organization and its stakeholders put some effort to make it work (Ambler, 2012). VIII. Case Study It is believed that agile software development methodologies are not suitable for large size and critical projects. The reason is that the large and critical projects involve the description of critical aspects which are difficult to express unless they are documented or conveyed using a proper language such as UML. In their paper (Paige, et al., 2003) performed an experiment where they have used agile software development methodology by combining it with unified modeling language for the development of a health information system. Basically, UML (unified modeling language) is a graphical tool widely used for describing, building, and documenting a wide variety of artifacts produced all the way through the software development life cycle. Without a doubt, functionalities and features of complex and large-scale software systems cannot be explained with text and words only unless they are explained through diagrams by making use of UML. In this scenario, system modeling provides various benefits to system developers such as visualization, unambiguous communication, easy understanding and clarification of requirements. In fact, UML can be used with all activities all the way through the software development lifecycle as well as across different development tools. It is an admitted fact that agile methodologies have been developed to support rapid development of high-quality code hence they ignore various other aspects such as documentation and system design. However, in their paper (Paige, Agarwal and Brooke) performed an experiment in which they have used UML and agile collectively to complete a project. This project involved the implementation of a health information system. The results of this experiment clearly demonstrated that modeling is essential, even though a project is being managed through agile software development methodologies. In this project, researchers have made use of UML for capturing object interactions, use cases and simple associations among classes. In addition, these models were proved to be very useful in describing the system to the customer. However, the remaining processes such as customer collaboration, team meetings and other aspects were taken from the agile manifesto. The overall implementation of this project proved to very successful because of the implementation of two approaches jointly (Paige, et al., 2003). IX. Recommendations and Challenges This paper has discussed a variety of concepts associated with agile software development methodologies. Without a doubt, agile software development methodologies have been proved to be successful for the completion of small size teams and limited size projects. However, these approaches are not effective for large size projects. In order to make them useful for large size projects it is recommended that some formal process of traditional software development such as documentation and requirements management are combined with agile software development. In this scenario, the requirements management and tracing will become easy. However, the challenge is that the agile methodologies are designed for delivering products quickly if the documentation is included in this approach it will become a time-consuming practice. In addition, if agile software development methodologies are used by combining with other development approaches then their effectiveness can be further improved. However, it will require changing the organizational environment and will require additional resources and knowledge. The management of two processes collectively will also be a challenge for the software development team. Moreover, software development organizations must encourage their staff members if they are bringing any new idea for the improvement of their existing software development process. They should launch education and training programs for their staff members. Through, it will require additional resources and cost but it will be useful for the betterment of an organization. X. Bibliography Ambler, S. W., 2012. Agile Modeling and the Rational Unified Process (RUP). [Online] Available at: http://www.agilemodeling.com/essays/agileModelingRUP.htm [Accessed 13 October 2013]. Ambysoft Inc. , 2012. Introduction to Object-Orientation and the UML. [Online] Available at: http://www.agiledata.org/essays/objectOrientation101.html [Accessed 14 October 2013]. Cao, L. & Ramesh, B., 2008. Agile Requirements Engineering Practices: An Empirical Study. IEEE Software, 25(1), pp. 60-67. Dyba, T. & Dingsoyr, T., 2008. Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9), pp. 833-859. Kavitha, C. R. & Thomas, S. M., 2011. Requirement Gathering for small Projects using Agile Methods. s.l., s.n., pp. 122-128. Larman, C., 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. 3rd ed. New York: Prentice Hall. Larman, C. & Basili, V. R., 2003. Iterative and Incremental Development: A Brief History. Computer, pp. 2-11. Lucia, A. D. & Qusef, A., 2010. Requirements Engineering in Agile Software Development. Journal of Emerging Technologies in Web Intelligence, 2(3), pp. 212-220. Paetsch, F., 2003. Requirements Engineering in Agile Software Development, Alberta, Canada: University of Calgary. Paetsch, F., Eberlein, A. & Maurer, F., 2003. Requirements Engineering and Agile Software Development. s.l., IEEE, pp. 1-6. Paige, R., Agarwal, P. & Brooke, P., 2003. Combining agile practices with UML and EJB: a case study in agile development. Berlin, Heidelberg, Springer-Verlag. Salo, O., 2006. Enabling Software Process Improvement in Agile Software Development Teams and Organisations. Finland: VTT Technical Research Centre. Sillitti, A. & Succi, G., 2006. 14 Requirements Engineering for Agile Methods. [Online] Available at: http://www.agile-itea.org/public/papers/sillitti-succiV2.pdf [Accessed 12 October 2013]. Versant Corporation, 2009. OBJECT PERSISTENCE AND AGILE SOFTWARE DEVELOPMENT, Redwood City, CA: Versant Corporation. Vu, J., 2013. Agile and project size. [Online] Available at: http://tuyensinh.vanlanguni.edu.vn/CMUEN/CMUENDetail/tabid/481/cate/128/id/429/language/vi-VN/Default.aspx [Accessed 12 October 2013]. Read More