Extreme Programming Agile Model

Here is my notes on Extreme programming and Agile process. Agile process model works on action based software development, the practitioners of agile prefer face-to-face communication, daily meeting and active software development approach. They want to build software that is useful and have required components rather than all the fancy unwanted features.

Agile Principles 

Agile Principles
Agile Principles

Extreme Programming Philosophy

  1. Extreme programming starts with user stories, which are scenarios that customer and user would like in the system. Detailed requirements are not mentioned in User Stories.
  2. XP Team then estimates how long it will take to implement the user scenario.
  3. Based on the User Stories and Estimates, the release planning is done in advance. That define the user stories built in which release and release dates of this release.
  4. Frequent release of iteration is employed.
  5. An acceptance test is also built from these stories bugs found in the iteration, becomes work item for next iteration.

XP and Agile Process

An iteration starts with iteration planning, user stories to implemented in selected high values and high risk are of high priority.

Agile Programming Philosophy
Agile Programming Philosophy
If an iteration failed the acceptance test, then it is included in the next iteration.
An Iteration of XP Model
An Iteration of XP Model

Some unique practices of XP programming

  • Programming is done in a pair , not individually.
  • A unit test is written first and then actual software code written to pass the test.
  • Changes are not made to the obsolete codes, instead, focus on refactoring the codes. All unused functionality is eliminated and what is necessary is built first.
  • Keep everything simple.
  • At a time, only one pair can integrate into the Base unit.
Overall XP Model
Overall XP Model

Other Rules

  1. Rights of customers and programmer.
  2. Communication between Team Members, every morning they do a small meeting.
  3. Decide how meetings should be conducted?
  4. Spike solutions to resolve technical or architectural problems.

Rapid Development Model – The Big Picture

Rapid Development Model (RAD) is an incremental software development process model which focus on developing a software in short development cycle say 60-90 days.
When the software development is that intense and the duration is short, then two things happen.
  1. RAD model uses component-based development of software, ready-made software components are used for building the software product, otherwise writing code within a short span requires a huge effort.
  2. The customer also becomes part of the development team at the beginning, but not beyond the certain time limit.

 

Rapid Development Model (RAD)
Rapid Development Model (RAD)

Limitations of RAD process model

 
There are a few limitations of Rapid Development model.
  1. Requires sufficient human resource.
  2. A large project needs lot of people because of the need to finish the product in 60 – 90 days.
  3. Need commitment and efficient customer and developers who could deliver.
  4. Does not fit for all kind of development, because modular development and component-based development is a must.
  5. Even we cannot develop a product that needs to give a good performance.
  6. Not a good model when a project has a high technical risk.
 

Concurrent Process Model – The Big Picture

Concurrent Process model is an evolutionary process model in software engineering. The term concurrent mean “done at the same time”.

If we take waterfall model as an example, you will not know the activities going on in each phase, only after the phase is over, you get a work product or a document.

Suppose we want to know the state of activities of the design phase and at the same time we want to know about testing phase activities. Which ones are complete and which are not?

The concurrent process model shows the current state of activities, tasks and their associated states that remain in different phases.

Concurrent Process Model
Concurrent Process Model

For example,

‘Design Phase’ may be at an ‘awaiting state’ and ‘customer communication’ is in ‘under revision’ state. The customer wants some changes to the design, then ‘communication’ goes to ‘awaiting changes’ and ‘design’ goes to the under-development stage again.

The benefit of this model is that project managers know each phase is what state and why.

Main Point –  Maintain information about each phase at the activity level.

Incremental Model – Big Picture

An evolutionary process model is that which deliver some product at the end of each iteration of software development.

In the Incremental process model , classical waterfall model is applied repeatedly because the drawback of waterfall model is that it cannot rectify any major change at the later stage of the software development.The incremental process model focus on delivering a working product at each iteration and each iteration pass through

  1. Requirements
  2. Design
  3. Implementation
  4. Testing Phase
Incremental Process Model
Incremental Process Model

Phases of Incremental Process Model

These are the main stages of incremental process model.

  1. Inception
  2. Elaboration
  3. Construction
  4. Transition

Prototype Process Model – The Big Picture

Prototyping process model in software engineering is required when customer requirements changes frequently. It means the customer is not clear about the product that need to be built. Also, sometimes the software engineers have never worked on some of the product where the technical challenge is high.
Prototype Process Model
Prototype Process Model

A working prototype of the product is built and later enhanced by the software developers.

Understanding development of prototype helps building the actual system. The prototype is an overhead, but better than Classical Waterfall Model, but this model need lot of customer interaction.

Main Point : Prototyping is only required when the customer or the developer not clear about the product to be built.

Spiral Process Model – Big Picture

This process model look like a spiral with many loops. The number of loops in the spiral model is not fixed or limited, we can add as many as required. Each of the loop is a phase in spiral model(e.g., A loop can be feasibility study , another loop could be requirement analysis).

Each of these phases is divided into 4 quadrants: Determine objectives, Identify and resolve risks, Prototype evaluation and Develop next level of product.

Spiral Process Model
Spiral Process Model
 -Source : Software Engineering – IIT Kharagpur [M02L04]

Phases of Spiral Model

The phases of spiral model are the quadrants. Each quadrant has specific goals in the spiral model, given in point form below.

(A)  First Quadrant (Goal or Objective Settings)

  • First quadrant, objective of phase is set.
  • Then all the risk associated with the objective is identified.

(B) Second Quadrant ( Risk Assessment and Reduction)

  • Risks are analyzed  for each project.
  • Appropriate steps to resolve those risk is taken.
  • If risks are unclear a prototype is build to get clarity on the technical or functional issues.

(C) Third Quadrant (Development and Validation)

  • After removing all risks, develop the product and validate the next level of the product.

(D) Fourth Quadrant (Review and Planning)

  • Review results with customer and plan the next iteration.
  • In this way a more complete version of software is built.

When to use the SPIRAL Process Model ?

  1. Risk analysis is built into the model.
  2. Software product that complex in nature or carry more risk, then this process model is suitable.
  3. Project with high risk can also use this model.
  4. This process model not good for ordinary software projects.

WaterFall Process Model – The Big Picture

In software engineering waterfall model is well known, it covers all the phases of software development and each of these phase has a set of activities. Every other process model is derived directly or indirectly from the Classical Waterfall Process Model.This process model cannot be used directly in a real world software development project, hence, it is a theoretical process model. It is a software engineering process model to compare and contrast with other software process models.

What are the Phases of the Classical Waterfall Model?

It has many phases and input of a phase is work product [partially produced software product from a particular phase is called a work product] which is output of a previous phase. Hence, going back to a phase is difficult in this model during advanced stage of software development. Software engineers cannot start from scratch if a problem is found with design or implementation at a later stage of software development life-cycle.

Here, I have more than one diagram that shows the phases of this model. You could use any one of these to describe the phases of Classical Waterfall Model.

Waterfall Model
Waterfall Model

There is another diagram of waterfall model which is popularly known as the Classical Waterfall Process Model. The stages in classical waterfall process model uses different terms, but activities of each phase is more or less same.

Classical Waterfall Model
Classical Waterfall Model

Primary Activities of Each Phase of Classical Waterfall Model

  1. Feasibility study starts with Team Leaders or Project managers meet the customer and understand the problem and know ‘what to be built’ than, ‘how it is to be build’. They discuss many possible solution to the problem and at the end of the phase pick the ‘Best solution’ to develop the software that is feasible financially and technically.
  2. Requirement analysis and specification starts with data collection by interviewing users, customers and other stakeholders. Next specifications are documented correctly in SRS document.
  3. Start of Design Phase, Context Diagrams, DFDs  are made according to SRS document. At the end of this Phase , a Structure Chart is produced.
  4. During coding phase, each module is written and compiled individually and then tested and debugged. At the end of this phase, we have a set of fully tested modules.
  5. Implementation phase, now we integrate all the Modules in small increments and test the partial system. When all modules are integrated, a System Testing is carried out. Alpha and Beta testing are done first and then Acceptance testing. Then the final product is delivered.
  6. Maintenance is required all the time due to wear and tear in the software product. Maintenance is carried out when a defect in software is found or change or improvement in software is requested by the customer.
 Flow through Phases of Waterfall Model
Flow through Phases of Waterfall Model

Software Engineering

The IEEE definition of software engineering is “The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software”.

Software engineering uses the methodology and best practices to develop quality software and deals with all aspects of software development processes.

About Software Engineering Tutorial

This tutorial is for anyone willing to learn software engineering principles. There is absolutely no prerequisite to learn from the tutorial. You can learn at your own pace. Each section has one or more article which you can start reading.

Tutorial Topics

1. Software Process Models

2. Agile Process Models