CSC/ECE 517 Fall 2010/ch6 6d ub

From Expertiza_Wiki
Jump to navigation Jump to search

Agile vs. other software-development methods

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.1

Developing a fairly large or a small software project involves some planning. Though there are proponents of the sit on the computer, code and be done with it approach, it hardly works for projects as their complexity, both in terms of deliverable and resources increases. There are numerous ways in which a software project is planned and executed. From the more classic and orthodox models like the waterfall model to the newer XP philosophies such as Agile and Scrum, these methodologies are different ways of achieving the same goal, each with its pros and cons.

Agile is an iterative method of software development wherein the software development is done in terms of multiple stages which may/may not build upon each other. At the outset of the project, the various user requirements are gathered and split up into various such relevant stages which are completed one after the other a reviews done. Due to its iterative nature, agile allows for dynamic project scope and development with a high degree of user interaction. In comparison to more orthodox and classical methodologies, Agile can be looked upon as a combination of spiral module with a waterfall module which is executed in each spiral of software development.

As mentioned in the description of this wiki, the paper by Hoda et al 'Agility in Context' 2, though Agile looks as a excellent method to carry forward and execute various real world software development problems, there are many limitations and modification that are needed to its methodology for use in real world scenarios in many cases.

Agile and its strengths

Agile due to its iterative nature is based on a system where each iteration takes into account some of the user requirements and code is developed based on those requirements. Based on user feedback, any changes if necessary are made to the code in subsequent iterations. This makes Agile projects highly adaptive to change in specifications as compared to more classical models.3 Agile also is very customer centric, where client feedback at the end of each stage is essential in work on next iteration. Also, a high degree of involvement from the customers is needed to create specifications that can be rightly mapped to the priorities and split up into iterations at each stage of the agile project. Agile is also a proponent of highly integrated and synched teams. This is due to the highly dynamic and iterative methodologies used in Agile. It is these strengths which are a limiting factor in many of the projects which do not implement on one of the above features by the book, and hence need software development to be carried out by some modified Agile methodologies which take features from some classical development models.

Strengths of More classical Approaches in Software Development

There are certain basic characteristics of Classical Software Approaches which go in their favor while executing projects with those specific characteristics.7

  • Predictive Approach towards project development and execution.
  • Comprehensive documentation.
  • Process Oriented.
  • Tool Oriented, where specific tools are needed to be needed in development.

Hence, classical approaches are beneficial in specific situations as below.6

Waterfall Model

A waterfall model is better in case of more classical projects where all the requirements are made clear beforehand. The whole development process in this case is highly documented and planned with little or no need for modifications. In such a project, the developers have assumed to have worked on such projects before and have a clear idea of what the development process should be consisted of.

Spiral Model

The spiral model is beneficial in cases where there needs to be various stages in the project, still predefined, and there needs to be a delivery at pre specified stages in the project as per pre defined guidelines. This allows for a better structure for software delivery in specific cases. At each spiral stage, the user or customer is taken into account to get his feedback on the features developed during that stage.

Iterative Models

Certain iterative processes are used by development teams to arrive to a final shape of a software when the customer is not sure of the requirements of the software. In this case, the software developers take an incremental approach wherein at each stage, some specific needs of the customer are met and delivered and the customer asked for further requirements as needed.

Top Down or Bottom up Models

These kinds of models value the concepts of modularity and integration for development. In a top down model, the basic skeleton containing modules is developed first and subsequent detailed modules developed after that. The case is different in bottom up approach where the individual modules are developed first and then integrated to get final system.

Rapid Prototyping

Rapid prototyping uses the iterative approach wherein with high level understanding of the users requirements, a basic prototype is created, which is then refined with each subsequent phase to impart more and more functionality as per fined grained requirements of the user.

Conventional Agile Methods

The iterative and customer involvement centric philosophy of Agile has been used to create more specific software development methods. Each of these methods have specific flavors of Agile while the basic philosophy remains the same. 8

XP

XP (Extreme Programming)9 involves the use of short bursts of development, or iterations. In this approach, a working release is first priority, based on customer feedback related to such a release, further changes are made in the next release. The release cycles/iterations are continued till the customer dosent have any more requirements/modifications related to the system.

Scrum

Scrum 10 is a Agile method tailored to smaller teams with each increment or 'Sprint' that is time bound, instead of being based upon a stage. In this kind of model, a backlog list is compiled at start of each sprint, and development undertaken to take items off such a backlog list. Here, the team has more say in deciding which features can be handled in a specific sprint.

Feature Driven Development

In FDD 11, an initial list of features is taken into account, and a basic overall view of the system created for further development. Going forward from this initial requirement gathering and analysis phase, either the features are implemented incrementally, or in parallel by many teams if they dont depend on each other. After each feature is developed, its tested and then integrated to the main system for more incremental development (features based on current feature) or acceptance tests by users.

Dynamic System Development Method

This is a combination of Rapid action development and Iterative methods. DSDM 12 involves the use of a analysis and prototyping phase where after learning of the business objectives, the developers create prototype and analysis modules which are used to further refine and make efficient implementation of user requirements. The fundamental idea behind DSDM is to fix time and resources, and then adjust the amount of functionality accordingly rather than fixing the amount of functionality in a product, and then adjusting time and resources to reach that functionality.

Adaptive Software Development

Adaptive Software Development 13 stresses the need for collaboration, and incorporation of some learning phases, which are used to learn about certain changes that may spring up during development or mistakes that may happen during development. This lessons learnt are used in further development upstream.


Unorthodox Agile Models

We would now see that for most of the basic project types which are better suited to a specific methodology, how can Agile be modified for providing a more efficient and productive software development process.


Customer 'Proxy' or 'Story Owner'

Agile requires a high degree of customer interaction both in getting specifications and also for validating development in an iteration. However, it is seen that in many cases, the customer expects software projects to deliver like more conventional projects wherein a high requirement overview is provided and the development team is expected to complete the project and give it in one go to the customer. This is not at all beneficial in Agile development methodologies where a more detailed specifications description is needed from the customer and also a feedback needed in every iteration. Where a customer is very not forthcoming, a customer 'Proxy' is made from within the development team who is responsible for being a liaison with the customer to get a more established way of communication. Also certain 'Story Owners' are designated for each iteration of the project. These members of the team who are 'Story Owners' who were responsible for the requirements gathering and feedback of a specific iteration by acting as a limited time liaison between customer and the development team. Such a story owner was responsible for a story in only a specific iteration or stage of the project. 4

Offering Iterations or Buffering in Fixed Bid Contracts

It is seen that the classic customer just gives a fixed bid contract with specifications and expects the development team to deliver a product within a quoted fixed time. A Agile development team in this case can make use of iterations to have a more balanced and co-ordinated development of project instead of having a solitary fixed deadline by allowing the customer to buy fixed iterations of a given project and continue with further iterations if they are happy. Also, some teams will provide a buffering period over estimated completion time to provide for Agile process iterations while negotiating such a contract. 14

Staggering iterations in case of Design/Architecture intensive projects

In case of projects which are design/architecture intensive, it has been seen that staggering iterations is better in case of team which do design viz a viz development. This is because there exists a pipeline structure in the project which actually makes one team a customer of the other, and a simple Agile methodology of requirements gathering and verification on each iteration follows for each of the individual teams.

Documentation intensive Agile projects

In some cases, it was seen that documentation was necessary as a part of requirements of the project, or in the case where it was necessary to have a single repository of terms familiar to the customer and their mapping to the terms essential to the developers. (Data Dictionary). this involves an undercover agile approach where the output in form of documentation is done in the classic waterfall way, while the development is still Agile. This however, needs careful mapping of the documentation goals to the Agile goals.

Agile Processes in outsourced projects

In outsourcing environments, Agile processes need to be modified to a great extent to suit highly decentralized nature of such projects. The major challenges seen in such projects are the disconnect between the locations of the customer and the development teams. Also, it is seen that there is a obvious difference between the managements of the client and the customer as both of them are different entities. Agile practices are modified in such situations by providing for certain specific teams both at the client and outsourcing ends whose main job is to communicate between both organizations. The client team in this case is responsible for overseeing the outsourced work at regular intervals besides communication. At the outsourcing end, the developer team responsible for communication is tasked with ensuring the definition of correct and specific goals to the development teams. Also, a specific documentation format needs to be developed to better translation of user requirements to developer specs. 5


References & External Links

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch6_6d_ub&oldid=41656"