What is Agile Unified Process (AUP) ?

Rational Unified Process, when simplified, gives rise to AUP or Agile Unified Process. Its developer – Scott Ambler, describes it as a simple and very easy to understand methodology for development of application software for business. The agile unified process makes use of agile concepts and techniques but remains true to its origin i.e., the Rational Unified Process. Various agile techniques are employed by Agile Unified Process for developing software:
> Test driven development (TDD)
> Agile modelling (AM)
> Agile change management
> Database refactoring

All these techniques help AUP in delivering its 100 percent productivity. In 2011 the AUP was considered to be 1 percent of the whole agile methodology. In 2012 DAD or Disciplined Agile Delivery Framework superseded the AUP. Since then most people have stopped working on Agile Unified Process. AUP is different from RUP in the sense that it works only on 7 principles:
> Modelling: Involves understanding about how the business is organized around the software and the problem domain of the project, and then identifying a feasible solution for addressing the problem.
> Implementation: The model is transformed in to executable code and basic testing i.e., unit testing is performed on this code.
> Testing: An objective evaluation is carried out for ensuring that the artefact is of high quality. Testing is done for rooting out the defects and validating whether the system works as desired or not. It also includes verification of the requirements met.
> Deployment: The delivery plan for the system is laid out and executed so that the product reaches the customers.
> Configuration management: Managing the access to various artifacts of the system includes tracking the various versions at regular intervals of time, managing and controlling the changes in them.
> Project management: It includes directing the activities of the project to the right track. These activities include risk management, assigning tasks to people, tracking their progress, coordinating with people for ensuring that the system is delivered on time. This is also for making sure that the project is completed within budget.
> Environment: Involves providing continuous guidance i.e., standards and guidelines and tools for ensuring process is going on right track.

The agile unified process follows certain philosophies as mentioned below:
> The team knows what it is doing: People don’t find it convenience to read highly detailed documentation. Timely training and good guidance is accepted by all. An AUP provides links to a number of details if you want, but it does not force you.
> Simplicity: The documentation is kept as simple as possible without going into too much of detail.
> Agility: For maintaining agility, the AUP should conform to the principles and values mentioned in the agile manifesto and agile alliance.
> Emphasizing on high – value activities: Only the activities that affect the project are actually considered. Rest of the activities are not counted.
> Choice of tools: In Agile Unified Process any toolset can be used. However agile experts often recommend using simple tools appropriate for the project.
> The agile unified process can be tailored specific to the needs of your project.

There are two types of iterations in agile unified process as mentioned below:
> Development release iteration: For deployment of the project to demo – area or quality assurance.
> Production release iteration: For deployment of the project to production unit.

These two iterations are a result of refinement of RUP. The RUP’s modelling, requirement and analysis disciplines re encompassed by the disciplines of agile unified process. Even though modelling constitutes an important part of agile process, it is not the dominating factor. 

What are user stories? Are they similar to use cases? Where is user stories used?

You must have heard about the term “user stories” and “use cases” when it comes to the discussion regarding the issues of the software development! In this article we have taken up 3 important questions to discuss as mentioned below:

1. What are user stories?
2. Are they similar to use cases?
3. Where are the user stories used?

What are User Stories?

- User story is a common term that is quite involved with everything that happens in the field of software development and the product management. 

- A user story is more like the business or every day language of the end user (end user is the one who uses the software system or application) which indicates about the activities of the user and what things he/ she needs to do to perform his part of function well.

- User stories have become quite famous.

- User stories are commonly used with the agile software development methodologies when compared its use with the other software development methodologies. 

- Actually, the user stories when used with the agile software development methodologies, serve as a basis or criteria for defining the business functions that a business system is ought to provide. 

- The facilitation of the requirements management is also done with the help of the user stories.

- There are 3 aspects of the requirements that are captured by a typical user story in a way that is quite simple and concise and with a limited description:

1. Who?
2. What?
3. Why?

Who is responsible for writing user stories?

- They are written by the business users as their means to have an influence on the functionalities and features of the software system or application that is being developed. 

- They may also be written by the system developers and programmers as a way to express the non functional requirements like the performance, quality and security. 

- But overall, the task of managing the user stories is taken up by the product manager and thus it is his/ her responsibility for ensuring that the user stories are captured properly. 

"Are user stories similar to use cases?”

Both these are similar to a certain extent. We shall state how! 

- The documentation of the requirements is created with the help of both the user stories and the use cases so that the documentation has a perspective of the user. 

- Since both of them are used in the documentation of the requirements, they both indeed help in capturing the features and functionality of the system. 

- Together they help the development to come with the best solution to the problem. 

- Another advantage of these two is that both can be used to organize the requirements of the system under different categories. 

- They also serve as a reference during the testing phase which ensures that the requirements have been met. 

But there are many other substantial ways in which they differ. 

- Without user stories the developers would have to create formalized requirements documents and perform many tasks to manage them. 

- The user stories are intended to make the response of the developers faster to the rapidly changing requirements of the users and so cutting down the overhead.

- User stories are accompanied by acceptance tests whereas use cases can be delivered as a stand alone document.

- User stories contain little detail whereas use cases include detailed description.

Where are user stories used?

- User stories are an important part of agile development methodologies.

- They give a reason what should be built in a software project.

Explain Extreme Programming XP life cycle?

XP or extreme programming is one of the best agile software development practices ever known since the advent of the agile software development concept. This agile software development methodology was developed with the intention of making improvements in the quality of the software product and responsiveness to the ever changing requirements of the customer. 

Being an agile software development methodology, it involves the frequent releases of the software product in short development cycles (this methodology is called time boxing). This type of methodology is intended to improve the overall productivity and also helps in introducing the check points where new customer requirements can be carefully adopted. 

Elements of Extreme Programming

There are certain elements of the extreme programming few of which are as mentioned below:

1. Programming in pairs.
2. Extensive code review.
3. Unit testing of the whole software code.
4. Avoid programming of the functionality and features until there is an actual need of them.
5. Provides a flat management structure.
6. Maintains simplicity.
7. Maintains the clarity of the code.
8. Expects the changes in the requirements of the customers with the passage of time for the better understanding of the problem.
9. Maintains frequent and effective communication with the programmers, developers and customers.

This article discusses the life cycle of the extreme programming. In the nineteen’s there was a lot of fuss regarding the extreme programming since the environments being adopted for it were quite different from those that were used earlier. 

All the practices of the extreme programming require high discipline making the observers think that the practices are too rigid and should be left unfinished or reduced on the individual sites. 

Extreme Programming Life Cycle

- Simplest example would be of reducing the practice of integration tests to some mutually agreed dates. 

- This helps greatly in coping with the rush of generation of the artificial stubs converting the whole hard process in to a relaxing schedule.

- In this way it will be easy to develop the complex features over a period of certain number of days. 

- Such an approach also helps in investing the development process checking whether or not it is following the right track or not. 

- This development methodology is evolving further till date acquiring an assimilation of various experiences in the field of software engineering. 

- First step in this process is setting up the goals.

- The primary goal is to organize people to produce software productively and with higher quality. 

- Another goal is to minimize the budget of both the money and the time by making use of multiple short development cycles.  

- After goals come the activities. There are four main activities have been defined:

1. Coding: It has been argued over and over that the code forms the most important part of the software development process since no code means no working project.

2. Testing: In testing phase also the XP follows the same philosophy i.e., “if a little can do this much good! More can do much better!” Two types of tests are carried out namely unit and acceptance tests.

3. Listening: This stage involves listening to the customer’s needs and understand what business logic is required.

4. Designing: It involves creating a design structure so that the dependencies withing the program can be avoided.

What are basic practices of iterative development?

So many software development processes have come up with the specifications and benefits of their own. The iterative development is one such development strategy which has been identified as an agile software development process. 

The basic practices of the iterative development have been discussed here. But, before moving on to the approaches will have brief discussion regarding the iterative development.The iterative part forms the first half of the heart of the cyclic software development process with the other half being formed by the incremental development. 

The iterative development strategy was the resultant of the response to the weaknesses spotted in the water fall model of the software development and testing. Like any other cyclic software development process, the iterative development process also has its starting with an initial planning and ends up with deployment and it has so many cyclic interactions happening in between the ned points. 

The iterative development process forms an important and non neglect-able part of the following processes;

1. Rational unified process or RUP
2. Extreme programming or XP and
3. Various other agile software development methods

The idea of a simple business process improvement has been implemented in the iterative development which has its flow like as shown below:

Plan à DO à Check à Act

What is meant by Iterative Development?

- Iterative development is itself an agile software development strategy which has its basic idea revolving around the use of the iterations in smaller intervals of time called the incremental.

- This agile software development strategy helps the testers and the developers to exercise their past experience of the learning in to the current testing scenario.

- With every new iteration, the design of the software system or application is modified and is incorporated with some new functionalities or features. 

- The procedure for the iterative development process consists of the following steps:

1. The Initialization step
2. The iteration step and
3. Project control list

- The first step i.e., in the initialization step involves the building up of the foundation or the base version of the proposed software system or application.

- Actually, a base version is created so that the user can react with the software product and also to have a key sample of the problems of the software system or application and also possible solutions that are easy to understand and implement.

- The control list contains all the tasks that have to be performed in order to complete the software development process. 

- As the analyzation phase progresses, the project control is also revised timely and frequently as and when any change in the requirements is wanted.

- With every iteration, a task from the project control list is accomplished or redesigned. 

- The below mentioned are some of the goals of the iterative development process:

1. Simplicity
2. Straight forward
3. Modular
4. Redesigning supportive at that particular stage etc.

- Every iteration is analysed on the basis of the below mentioned factors:

1. Structure of the iteration
2. Modularity
3. Usability
4. Reliability
5. Achievement of goals and
6. Efficiency

Based on the results of the above factors, the project control list is modified accordingly.

Phases of Iterative Development

 The whole iterative development consists of the following 4 phases:

1. Inception phase: It involves identification of the project scope, risks and both the functional as well the non functional requirements.
2. Elaboration phase: It involves the delivery of a working architecture fulfilling all the requirements and mitigation of the top risks.
3. Construction phase: It involves implementing the production ready code in to the architecture.
4. Transition phase: It involves delivery of the project in to the production environment.

What is meant by client-driven iterative planning?

Iterative planning is one of the important planning strategies categorized under the agile software development processes. Iterative and incremental cannot be neglected if we want a cost and time efficient software development plan. Iterative planning is a must! However so far only 3 types of iterative planning have been designed as mentioned below:

Types of Iterative Planning

1          -  Risk driven iterative planning

2          -  Client driven iterative planning and lastly

3                     - Time boxed iterative development planning

This article is focused up on the 2^nd type i.e., the client driven iterative planning. But, before moving on to that we’ll discuss something about the iterative development so that understanding the concept of the client based iterative development becomes easy for you.

What is Iterative Planning?

- An iterative planning is required before starting of any iteration for the production of the plan of the programming tasks. 

- Each iteration may take up from 1 to 3 weeks depending up on the complexity of the program. 

- For every iteration some user stories are chosen that are most valuable to the customer.

- Iterative planning is an extremely important part of the below mentioned processes:

1. Extreme programming
2. Rational unified process and
3. Many other agile software development frame works

- Any iterative planning, be it risk driven, client driven or time boxed iterative planning are based up on one agile principle which is to develop a software system or application through several small iterations or repeated cycles rather than drawing out the whole software system or application in just one development process. 

- Dividing down the development process in to small iterations give a chance to the developers to experience their learning of the development process in the past. 

- Firstly the sub set of the system requirements is implemented in a very simple way and later the evolving versions of the software system or application are enhanced making use of the iterations.

- This process of enhancing through the iterations continues till the whole software system or application has been implemented. 

- Every iteration seeks the modifications in the design and also the addition of new functionality.

- The following steps are 3 main important steps of any iterative planning be it risk driven, client driven or time boxed:

1. The initialization step
2. The iteration step and
3. The project control list

- The first step deals with the creation of the base version of the software system or application so that it can be reviewed by the customers or the clients. 

- This base version acts as a sample for reviewing and feedback purposes. 

- The second step deals with the redesigning and implementation of tasks in order as they are mentioned in the project control list.

- The purpose of this project control list is to serve as a guide to the iteration development process. 

- This project control list is meant to be revised continually as in many of the cases the requirements of the software system or application keep on changing. 

- Certain guidelines have been stated for the implementation process called the implementation guidelines. 

About Client Driven Iterative Planning

- The basic difference between the client driven iterative planning and other types of planning is that the choice of features for the iterations are taken from the customers or more appropriately if we say from clients.

- These set of features is often decided by the clients based on how much valuable is that feature to them when it comes to business. 

- This development methodology allows the client to steer or drive the whole development as they want iteration by iteration requesting the features that are of the utmost importance to them. 

- The features for the next iteration are planned by the client “adaptively”. 

How to define a practice for agile testing ?

Practice for agile testing should encompass the following features:
Conversational Test Creation
- Test case writing should be a collaborative activity including majority of the entire team. As the customers will be busy, we should have someone representing the customer.
- Defining tests is a key activity that should include programmers and customer representatives.
- It should not be done alone.

Coaching Tests
- It is a way to think about acceptance tests.
- It turns user stories into tests.
- Tests should provide goals and guidance, instant feedback and progress measurement.
- Tests should be in specified in a format that is clear enough that users or customers can understand and that is specific enough that it can be executed.
- Specification should be done by example.

Providing Test Interfaces
- Developers are responsible for providing the fixtures that automate coaching tests.
- In most cases, extreme programming teams are adding test interfaces to their products, rather than using external test tools.

Exploratory Learning
- Plan to explore, learn and understand the product with each iteration.
- Look for bugs, missing features and opportunities for improvement.
- We do not understand software until we have used it.

What are the basic components of Extreme Programming (XP) ?

The basic components of Extreme Programming (XP) are:

Test-First Programming
- Developers write unit tests before coding. It has been noted that this kind of approach motivates the coding, speeds coding and also improves design results in better designs.
- It supports a practice called re-factoring.
- Agile practitioners prefer tests to text for describing system behavior. Tests are more precise than human language and they are also a lot more likely to be updated when the design changes. How many times have you seen design documents that no longer accurately described the current workings of the software? Out-of-date design documents look pretty much like up-to-date documents. Out-of-date tests fall.
- Many open source tools like xUnit have been developed to support this methodology.

Refactoring
- It is the practice changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.
- Traditional development tries to understand how all the code will work together in advance. This is the design. With agile methods, this difficult process of imagining what code might look like before it is written is avoided. Instead, the code is restructured as needed to maintain a coherent design.Frequent refactoring allows less up-front planning of design.
- Agile methods replace high level design with frequent re-design. It also requires a way of ensuring whether the behavior was not changed inadvertently. That's where the tests come in.
- Make the simplest design that will work and add completely only when needed and re-factor as necessary.
- Re-factoring requires unit tests to ensure that design changes do not break existing code.

Acceptance Testing
- Make up the user experiences or user stories which are short descriptions of the features to be coded.
- Acceptance tests verify the completion of user stories.
- Ideally, they are written before coding.

How much testing is relevant in an agile scenario?

Testing is as relevant in an agile scenario if not more than a traditional software development scenario. Testing is the headlight of the agile project showing where the project is standing now and the direction it is headed. Testing provides the required and relevant information to the teams to take informed and precise decisions. The testers in agile frameworks get involved in much more than finding software bugs, anything that can bug the potential user is a issue for them but testers do not make the final call, it is the entire team that discusses over it and takes a decision over a potential issues.
A firm belief of agile practitioners is that any testing approach does not assure quality, it's the team that does or does not do it, so there is a heavy emphasis on the skill and attitude of the people involved.
Agile testing is not a game of gotcha, it's about finding ways to set goals rather than focus on mistakes.
Among the agile methodologies, XP i.e. Extreme Programming components are:
- Test First Programming
- Pair Programming
- Short iterations and release.
- Re-factoring
- User Stories
- Acceptance Testing

Test-First Programming

- Developers write unit tests before coding. It has been noted that this kind of approach motivates the coding, speeds coding and also improves design results in better designs.
- It supports a practice called re-factoring.
- Agile practitioners prefer tests to text for describing system behavior. Tests are more precise than human language and they are also a lot more likely to be updated when the design changes. How many times have you seen design documents that no longer accurately described the current workings of the software? Out-of-date design documents look pretty much like up-to-date documents. Out-of-date tests fall.
- Many open source tools like xUnit have been developed to support this methodology.

Overview of User Acceptance testing - what does it mean and what are its forms.

User Acceptance Testing is often the final step before rolling out the application. Usually the end users who will be using the applications test the application before ‘accepting’ the application.
A formal product evaluation performed by a customer as a condition of purchase. The testing can be based upon the User Requirements Specification to which the system should conform. Use Acceptance testing is black box testing.

USER : System developers cannot do it, as although they are expert in writing software, they are unlikely to know anything about the realities of running the organisation, other then what they have acquired from requirements specifications, and similar documents.

Acceptance : The acceptance of a system means you are confident it will give benefit to the organisation. It does not mean that it only meets the original specification as requested.

Testing : Whenever people are asked what testing is, many of them say it is to prove the system works.
The point of UAT is for business users to try and make a system fail, taking into account the real organisation it will be working in.

User Acceptance testing can be in the form of :
Alpha Testing - Tests are conducted at the development site by the end users. Environment can be controlled a little bit in this case.
Beta Testing - Tests are conducted at customer site and development team do not have any control on the test environment.

Think aloud Protocol - popular technique used during usability testing

The Think Aloud Method consists of asking people to think aloud while solving a
problem and analyzing the resulting verbal protocols.
Think Aloud (TA) studies provide rich verbal data about reasoning during a problem solving task. Using TA and protocol analysis, investigators can identify the information that is concentrated on during problem solving and how that information is used to facilitate problem resolution. From this, inferences can be made about the reasoning processes that were used during the problem-solving task. In the past, the validity of data obtained from TA studies has been suspect because of inconsistencies in data collection and the inability to verify findings obtained from the slow, laborious process of protocol analysis.

Think-aloud protocols are of particular value because they focus on the problems a user has; when the user is working without difficulty, direct observation is of very limited use. Use this technique in any stage of development. Thinking aloud is a cheap way of getting a lot of good qualitative feedback during testing.
Main advantages of this method are :
- High degree of flexibility.
- Presence of two people allows meaningful, direct dialog.
- Rapid, high-quality, qualitative user feedback.

How do I do Thinking aloud Protocol?
Provide your participant with the product to be tested (or a prototype of its interface) and a scenario of tasks to perform. Ask participants to perform the tasks using the product, and explain what they're thinking about while working with the product's interface.
Thinking aloud allows you to understand how the user approaches the interface and what considerations the user keeps in mind when using the interface. If the user expresses that the sequence of steps dictated by the product to accomplish their task goal is different from what they expected, perhaps the interface is convoluted.

Although the main benefit of the thinking aloud protocol is a better understanding of the user's mental model and interaction with the product, you can gain other benefits as well. For example, the terminology the user uses to express an idea or function should be incorporated into the product design or at least its documentation.

Introduction to Feature Driven Development (FDD) - Type of Agile Software Development

Feature Driven Development (FDD)was originally developed and articulated by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results. FDD designs the rest of the development process around feature delivery using the following eight practices:

1. Domain Object Modeling
2. Developing by Feature
3. Component/Class Ownership
4. Feature Teams
5. Inspections
6. Configuration Management
7. Regular Builds
8. Visibility of progress and results

Feature Driven Development asserts that:
- A system for building systems is necessary in order to scale to larger projects.
- A simple, but well-define process will work best.
- Process steps should be logical and their worth immediately obvious to each team member.
- "Process pride" can keep the real work from happening.
- Good processes move to the background so team members can focus on results.
- Short, iterative, feature-driven life cycles are best.

FDD recommends specific programmer practices such as "Regular Builds" and "Component/Class Ownership". FDD's proponents claim that it scales more straightforwardly than other approaches, and is better suited to larger teams. Unlike other Agile approaches, FDD describes specific, very short phases of work which are to be accomplished separately per feature. These include Domain Walkthrough, Design, Design Inspection, Code, Code Inspection, and Promote to Build.

Quick Overview of Crystal Methods - Type of Agile Software Development

The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of methodologies (Crystal Clear, Crystal Yellow, Crystal Orange, etc.) whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project’s unique characteristics.

The use of the word "crystal" refers to the various facets of a gemstone — each a different face on an underlying core. The underlying core represents values and principles, while each facet represents a specific set of elements such as techniques, roles, tools, and standards. Cockburn also differentiates between methodology, techniques, and policies. A methodology is a set of elements (practices, tools); techniques are skill areas such as developing use cases; and policies dictate organizational "musts".

Introduction To Scrum - Type of Agile Software Development

Scrum is an agile method for project management developed by Ken Schwaber. Its goal is to dramatically improve productivity in teams previously paralyzed by heavier, process-laden methodologies. Its intended use is for management of software development projects as well as a wrapper to other software development methodologies such as Extreme Programming.Scrum is a lightweight management framework with broad applicability for managing and controlling iterative and incremental projects of all types. With Scrum, projects progress via a series of iterations called sprints. Each sprint is typically 2-4 weeks long. Scrum is ideally suited for projects with rapidly changing or highly emergent requirements.

A scrum team is typically made up of between five and nine people, but Scrum projects can easily scale into the hundreds. The team does not include any of the traditional software engineering roles such as programmer, designer, tester, or architect.
- The product owner is the project’s key stakeholder and represents users, customers and others in the process.
- The ScrumMaster is responsible for making sure the team is as productive as possible.
- The product backlog is a prioritized features list containing every desired feature or change to the product.
- At the start of each sprint, a sprint planning meeting is held during which the product owner prioritizes the product backlog, and the scrum team selects the work they can complete during the coming sprint. That work is then moved from the product backlog to the sprint backlog, which is the list of tasks needed to complete the product backlog items the team has committed to complete in the sprint.
- Each day during the sprint, a brief meeting called the daily scrum is conducted. This meeting helps set the context for each day’s work and helps the team stay on track.
- At the end of each sprint, the team demonstrates the completed functionality at a sprint review meeting, during which, the team shows what they accomplished during the sprint.

Scrum enables the creation of self-organizing teams by encouraging verbal communication across all team members and across all disciplines that are involved in the project. A key principle of scrum is its recognition that fundamentally empirical challenges cannot be addressed successfully in a traditional "process control" manner.