What are some of the limitations / challenges of Adaptive Software Development (ASD)?

The Adaptive Software Development (ASD) culture is the result of efforts of Sam Bayer and Jim Highsmith in the field of rapid application development. The methodology aims at developing software that is capable of adapting continuously to the changes in the working environment. In ASD, in place of the waterfall approach, we have cycles of speculating, collaborating and learning. It is because of this dynamic cycle that the software is able to adapt to changing state of the requirements and learn through it. The cycle is very much tolerant to changes, driven by the risk, timeboxed and works in iterations.
Throughout the process the ASD life cycle remains focussed on the mission. Since adaptive software uses the information available from the environment for improving its working pattern, with the increasing complexities it becomes difficult for it to gather usable information. The effectiveness of the adaptive software development is reduced by the complexities of the environment. Today we expect more from the software and in such critical situations in which we never expected earlier. Thus complex environments pose a great challenge. There are three dimensions that contribute to this complexity:
> Increasing number of users: Now not only professionals, everyone uses software.
> Increasing number of systems: More number of systems means more number of interactions between them. Most of the system networks that we have now are heterogeneous. Maintaining homogeneous networks is easy.
> Increasing number of resources and goals: The most common trade off that programmers make is between time and space. Now there are several other things to worry about including security, bandwidth, money, quality, resolution and so on.

These three dimensions make it even hard for the designers to design a system. It is impossible to predict about these factors and therefore always right decisions can’t be made. This results in a product with a short lifetime. Every now and then upgrades will be required for modifying the software. Other factors related to complex environment that pose a challenge for adaptive software are:
> uncertainty
> hidden inputs
> non – deterministic
> unique
> continuity
> real world

Other things that put limitations on adaptive software development are following 4 myths:
> The traditional belief is that the specifications must be determined first. But this is not the case always. One specification can be taken at a time and refined in later stages. The aim should be combining several components together successfully and not developing a single app.
> People usually believe by maintenance that program code has degraded. The truth is that it remains the same while its environment changes. So maintenance involves evolution of the code to satisfy these changing needs. When programmers view this through a maintenance perspective, they tend to preserve the old program structure.
> It is undeniable that abstraction has an important role to play in the development process. But when we treat a process as a black box object we are actually ignoring the practical problem it faces of resource usage. In adaptive software development we take a new approach called open implementation. Here the modules have two interfaces – one for input/ output and the other checking performance. These two interfaces are perpendicular to each other. ADS also adds a feedback mechanism to this orthogonal interface system making it much better.
> While designing software we consider all the possible alternatives. The desired one is kept and the others are rejected. This means that once a requirement changes, we again have to see what alternatives are available and which one can be implemented. This might require changing all of the program structure. The best thing here to be done is programming the system such that it reconfigures itself.

How is Adaptive Software Development (ASD) different from Scrum? Part 2

Read the First Part (Adaptive Software Development being different from Scrum - Part 1)

For understanding the further differences between the two, it is important that we know what Agile Development is. The Agile manifest defines the agile methodology. There are 7 agile methodologies; namely XP, Crystal orange, Scrum, Adaptive Software Development, DSDM, Pragmatic programming and Feature – driven development. All these methods differ in their mechanisms and the parameters they take. All these methods have a different agile life cycle. For ASD, it depends on what techniques we are going to use. Generally speaking it doesn’t have a life cycle of its own. In contrast to this, scrum has an abstract lifecycle which packs certain activities in to its schedule.

However here we discuss differences based up on a lifecycle having some general phases.
- Project initiation: This step includes justification of the project and determining the requirements.
- Planning: Laying out an elaborate plan for development and leaving some gap for contingency actions. Scrum doesn’t have choice for including optional phases. It must work within predefined options, whereas the adaptive software development can have many options because it does not limits itself to few techniques.
- Elaboration of requirements: This stage is optional. The requirements are explained in great detail. Scrum does not implement this stage separately, but, it may be done in Adaptive Software development. Since the requirements are still in high level, they need to be broken down in to simpler specifications. The requirements are collated in to requirements document after classification. This document also contains use cases apart from the requirements.
- Architecture: Both scrum and ASD are based on agile principle of, design today and refactor tomorrow. Software developed using ASD can be modified to suit the changing environment just by adjusting their software capabilities and leaving the hardware unchanged. Software developed through scrum has to be modified through manual intervention and may even require to change hardware. A system architecture document is prepared in this phase.
- Release: The software is released to the customer. It has one timebox at least. Scrum can have many releases depending upon the development span of the project. Adaptive software usually delivers product in one go.

One of the important questions to be asked during project initiation phase is that whether to invest more or not? Not all methods answer this question. However addressing this question is an important part of the adaptive software development. Scrum doesn’t address this question explicitly. Next step is choosing the appropriate method. Scrum claims that it can be used for any project. Adaptive software development creates a list of all alternatives that can be used and chooses the best one.
The level of formality to be maintained in scrum is given by documents such as running code and backlog. In adaptive software development there are many too many choices to choose from. It makes use of vision statements for clearing out the confusion. Scrum defines a sprint goal which is a kind of timebox vision i.e., it follows one choice for some time and then can change if required.
Scrum avoids elaboration phase for speeding up the delivery. It uses product backlog maintained by the product owner.
Since adaptive software development may have an elaboration phase, it may also have a draft plan initially which may turn into a complete plan after determination of requirements. Scrum plans based on timeboxes.
Both methodologies help you work faster creating products with better quality. The agile customer too is an important role in the agile process. The customers are responsible for providing input during prototyping sessions. The organizing and controlling of user testing is the responsibility of the user. 

How is Adaptive Software Development (ASD) different from Scrum? Part 1

Adaptive software development and scrum both come under the overall heading of agile software development, but are two different beasts with differences between them. These are two different approaches with the same aim i.e., agile development. Below, we will write more on what differentiates the two.
It is necessary to know the differences between these two approaches since Scrum, as a part of agile software development is already a very famous methodology, whereas the adaptive software development is relatively new, but also a strong upcoming methodology ready to take the software development market by storm. Agile methods are always preferred over traditional development approaches to incorporate major factors such as increased levels of customer participation and satisfaction, project delivery flexibility, and acceptance of ongoing requirements or design changes at any level in the development process. This is the usual development scenario and that is why agile development methods are used mostly.  Most commonly used agile methods include:
-  Adaptive software development
- Scrum
- Feature driven development
- Extreme programming

Even though all these strategies aim at the same set of objectives (well almost), they do take somewhat different paths (having some items common, and yet others are different). It is important to know the differences between them. Otherwise how you are going to maintain agility in your development structure? Comparison between different agile methodologies, their common points and differences lets the managers choose the most appropriate agile method for their software characteristics.
There are many traditional techniques for drawing comparisons between 2 software development techniques. In this post, Scrum and ADS have been compared on basis of 2 areas, namely software construction and software requirements.
First difference between adaptive software development and the scrum approach is that in the former, there is no predefined technique to be followed. In scrum there are certain predefined techniques to be followed. On the other hand the focus of adaptive software development is on the end result rather on the steps. Adaptive software development methodology implements a particular technique only if it is required.
Since the last two years agile principles have encompassed methods such as extreme programming, feature driven development, adaptive software development and so on.  So far companies using scrum or adaptive software development have been able to deliver successful products. Scrum is described as a process for management and control used for cutting down the complexity. This is used by the organizations who want to deliver products faster. This approach to software development has been used on advanced development methods including software; it usually works well in the object – oriented development environment.
On the other hand adaptive software development is described as methodology for developing reliable and re – adaptive software. It is used by the organizations who want their products to function in a wide range of changing conditions. Software built with this approach are capable of reconfiguring themselves to better suit to the environment. It can be used under any kind of environment. Any technique can be applied here to make software as much flexible as possible. The owners are responsible for estimating backlog items in scrum. In adaptive software development it is mainly the task of the developers.
Scrum follows time-boxing method for speedy delivery. At the start of each timebox, a sprint planning meeting is held. A backlog that can be achieved is picked up by the team members and they decide how it can be achieved.
Scrum may have 1 to 4 teams with 5 – 9 members and adaptive software development may have even more number of teams dedicated to each phase of development process. Agile developers play a number of roles – analysing, estimating, designing, coding and testing. Even though the typing burden is less, there is a lot of stress because of the short frames. But you get to see your progress through user reviews and daily meetings.

Read next part  (Adaptive Software Development being different from Scrum - Part 2)

What is meant by time boxed iterative development?

The iterative type of the agile software development has always been the favourite choice of the developers and testers when it comes to adopting a time and effort efficient and effective agile software development process. 

Till now three approaches to the iterative development have been developed namely:

      1. Risk based iterative development

      2. Client based iterative development

      3. Time boxed iterative development

This article is here to focus up on the time boxed iterative development. But before we move on to the time boxed iterative development, let us brief up ourselves with the concepts of the iterative and incremental development so that it will be easy for us to understand the time boxed iterative development better.  

What is Iterative Development?

- Iterative and incremental development is an essential part of the agile software development process and lies at the heart of it.

- The iterative came in to existence as a response to the weaknesses of the other agile software development models especially the waterfall model.

- Apart from just being an essential part of the agile software development, it is also necessary to the extreme programming, rational unified process and many other agile software development frame works. 

- It is based up on a similar process of the business process improvement. 

- The iterative development is a way to develop a whole software system or application in small steps via the repeated cycles at a time. 

- There are two approaches that can be followed for accomplishing a task:

   1. We can either work non stop to accomplish the goal or

   2. We can define a time limit for ourselves and achieve as how much we can in that time period. 

The second approach is called time boxing. 

What is a Time Boxed Approach?

- It is a simple one yet effective technique from the perspective of planning and over the years has been found effective in completing the jobs within a time limit. 

- If we look at this approach from the perspective of planning, it is found to be useful in the development processes which are involved with the development of a complex software system or application and the starting point is quite uncertain. 

- On the other hand if we look at it from the perspective of the personal development, it is extremely helpful in improving the effectiveness as well as the productivity.

- In fact this approach is quite easy to follow but requires maximum effort. 

- Using time boxing approach, you fix up a time period and try to achieve the maximum you can within that time frame. 

What is meant by Time Boxed Iterative Development

- Time boxing approach employed for the iterative development is termed as the time boxed iterative development. 

- In such an approach to iterative development the task is divided in to several small iterations and each iteration is provided with a time box.

- Each of these iterations has its own budget, deadline and the deliverable. 

- In some cases, time boxing iterative development is employed for managing the risk.

- Since it is important to meet deadlines, it is necessary that the deadlines are not changed without the prior permission of the project owner. 

- An inadequate breakdown of the task can lead to the underestimation of the time requirement of the project. 

- To avoid changing of the deadline following three points can be followed:

1. Reduction in the scope: requirements having lower impact can be dropped from the plan.
2. Keeping time as the fixed constraint throughout.
3. Increase in the cost: the resources and the over timing can be added in to the plan.

Many projects that have been developed with the time boxing technique have been reported to be successful. 

What are different shortcomings of test driven development?

The test driven development though touching a new high is not free of any drawbacks or short comings! It does have some short comings like any other software development process. 

The test driven development as we all know was considered to be somewhat similar to the test – first programming concepts of an agile software development process popularly known as the extreme programming or XP.

Because of all this, the test driven development methodology suffered a whole lot of criticism and so many of its short comings were discovered. 

Even after the test driven development process got its own individual standing in the line of the software development processes, the critics did not stop criticizing it! What were those short comings? 

Shortcomings of Test Driven Development

1. It is quite difficult to use the test driven development process in the situations and conditions where the success or failure of the software system, application or program is determined by the full functional tests. For example, it cannot be employed for developing the below mentioned things:

(a)    User interfaces

(b)   Programs that involve a data base in their working

(c)    Programs or applications depending up on some specific network configurations.

2. The software developers and programmers are encouraged to keep minimum possible amount of source code in to the software modules in the test driven development. On the other hand they are also encouraged to maximize the logic that lies in the library code which is testable. It encourages the use of the mock objects and fakes for the representation of the outside world.

3   3. The test driven development calls for an extensive need of the management support which is quite vital. The management may get a feeling of the wastage of the writing test cases since the entire organization is not in to the believing that the software product can be improved by the test driven development.

     

     4. The software developer who writes the code for the tests is the same one who is also assigned with the duty of the creation of the automated unit tests in the test driven development. Therefore a possibility that the same blind spot might be present in both the tests is induced which potentially endangers the stability of the software system or application. Both the produced test and code will be wrong!

    5. In test driven development process a false sense of security might be induced by a higher number of passing tests. This in turn will result in less number of additional software testing activities like compliance testing and integration testing.

     6. The tests created for the test driven development system themselves form a part of the maintenance over head of the software project. The tests which have been produced badly may include hard coded error strings which may make the whole test prone to failure are quite expensive when it comes to their maintenance. Such tests are typically fragile in nature.

    7. With the test driven development one risk is always there which comes from the ignorance of the regularly generated false failures. This causes the real failure also to be ignored and thus preventing its detection. Several methods have been developed to create tests which require low and easy maintenance. Creation of such test cases is considered to be a goal of the code refactoring phase of the development cycle.

     8. If you are following the test driven development, then it would be difficult for you to reproduce the level of coverage and testing detail achieved during the repeating test driven development cycles. Deleting those original tests can lead to undetectable holes in the test coverage.