Agile methodology

What Is Agile?

Agile methodology is driven by face to face communication than written documents. It is an alternative to waterfall model but in incremental manner. The daily tasks are divided into small increments called sprints with minimum planning that don’t include long term planning. The collection of sprints is called product backlog. These are iteration which last from one to four weeks. Each iteration would include planning, requirement analysis, design, coding  and testing. So, at the end of each iteration, a working product will be in a position to be demonstrated to the stake holders. The face to face meetings will be held in the first hour of the day before the team starts their work. These meetings are termed as Scrum meetings and will not last more than 15 minutes. These are also termed as stand up meetings.

Burn down charts are drawn and will display the progress.

Scrum team has only three roles: Product Owner, Team, and Scrum Master.

Product Owner: The Product Owner represents the stakeholders and are accountable for team deliverables.

Development Team: The development team is the core team that develops the planned sprints from the product backlog.

Scrum Master: Scrum is facilitated by a ScrumMaster. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster enforces all rules that would be followed by the team.

Advantages:

1.    Agile Methodology helps in saving Time and Money.
2.    Great transparency as whole team will be involved on regular basis
3.    Less documentation that will help in concentrating on the product than the documentation
4.    Issues can be quickly tracked and closed due to daily meetings
5.    Change requests can be implemented as the feedback will be collected for every sprint

V Model

According to the IEEE Standard Glossary of Software Engineering Terminology V&V is defined as the process of determining whether:

• Requirements for a system or component are complete and correct.
• Products of each development phase fulfill the requirements or conditions imposed by the previous phase.
• Final systems or components comply with specified requirements.

V-Model evolved from waterfall Model. Every phase must be completed before the next phase begins. Testing is done in all the phases. It is a structured approach to testing and brings high quality into the development of our products.

Stage containment:

The goal of stage containment is to identify defects in the system during development before they are passed to the next stage. This helps build quality into the system. Finding problems or errors in the stage they occur in is important because problems become more expensive and difficult to fix later in the project life cycle.

Requirement Analysis:

Business Analysts collect requirements from the customer and prepare a Business requirement specification (BRS) documents. Reviews are conducted to make sure that the requirements collected are accurate.

System Design:

Based on the BRS document, System engineers analyze and understand the business of the proposed system.Feasibility study is done on whether the requirements cab be implemented and is informed to the customer. System Requirements document containing the general system organization, menu structures, data structures, business scenarios, sample windows, reports for the better understanding and Other technical documentation like entity diagrams, data dictionary will be produced in this phase which serves as a blue print for the development phase. System testing documents are prepared in this phase

High Level Design:

A high level design document containing the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration test plan is developed in this phase.

Module Level Design:

A Low Level design document containing detailed functional logic of the module, in pseudo code - database tables, with all elements, including their type and size - all interface details with complete API references- all dependency issues- error message listings- complete input and outputs for a module. The unit test plan is developed in this stage.

Unit testing

Unit testing is done based on Module level design document. A unit is the smallest testable software component. Units are tested in isolation to ensure it is working according to the detailed design/build specifications of the module. This testing is also known as component, module, or program testing. This is done by the developers.

Integration Testing

Testing of more than one (tested) unit together to determine if they function correctly is called Integration testing. This testing focuses on assembling incrementally a whole system to ensure the communication between modules and data flow from the first through the final component. This is also called interface testing or assembly testing. Integration testing is done based on High-level design document. This is done by the developers.

System Testing

Testing the complete system to determine if its working correctly as per the system design. Testers perform different types of functional, Non-functional and usability testing to ensure the functionality. System testing is done based on the system design document.

Acceptance testing

Testing to determine whether a system satisfies its acceptance criteria and business requirements or not. Testing is done the real users of the system.

Sprial Model

Spiral Model includes the best features of both the prototyping and waterfall model Software is developed in a series of incremental releases in the spiral model. At the early stage/iteration, the incremental release might be a paper model or prototype. Each iteration consists of Planning, Risk Analysis, Engineering, Construction & Release & Customer Evaluation

These regions include

Customer Communication task - Tasks required to establish effective communication between developer and customer

Planning task -Tasks required to define resources, timeliness, and other project related information.

Risk Analysis task - Tasks required to assess both technical and management risks.

Engineering task - Tasks required for building one or more representatives of the application.

Construction & Release task - (Tasks required to construct, test, install and provide user support e.g., documentation and training)

Customer Evaluation task - Tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation state

The steps in the spiral model can be generalized as follows:

• New system requirements collected by interviewing a number of external or internal users and considering other aspects of the existing system are clearly defined 

• An initial design is created for the new system.
 

• Based on the initial design a first prototype of the new system is constructed
• Second prototype is evolved by a fourfold procedure:
 

(1) evaluating the first prototype in terms of its strengths, weaknesses, and risks;
(2) defining the requirements of the second prototype;
(3) planning and designing the second prototype;
(4) constructing and testing the second prototype.
 

• Entire project can be aborted at customer’s opinion if the risk is too high. Risk factors include development cost overruns, operating-cost miscalculation, or any other factor that could result in a less-than-satisfactory final product.
 

• The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
 

• The above steps are iterated until the customer is satisfied. The final system is constructed, based on the refined prototype.
 

• The final system is thoroughly evaluated and tested. Regular maintenance is carried out on a continuing basis to prevent large-scale failures and to reduce downtime.

Advantages:

• Provide better risk management
• Requirements are better defined

Disadvantages:

• Requires considerable risk assessment expertise
• Increases development costs and schedule

RAD Model

RAD is incremental software development process model that allows usable systems to be built in extremely short development cycle using a component based construction approach. If the requirements are well understood and defined, and the project scope is constraint, the RAD process enables a development team to create a fully functional system with in very short time period.

The RAD model contains the following phases:

1. Business Modeling:
The information flow among business functions is modeled in a way that answers questions like what information drives the business process, what information is generated, who generates it, where does the information go, who process it and so on.

2. Data Modeling:
The information defined as part of the business modeling phase is refined into a set of data objects (entities) that are needed to support the business. The characters of each entity (called attributes) are identified and the relation between these data objects (entities) are defined.

3. Process Modeling:
The data object defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting or retrieving a data object.

4. Application Generation:
RAD assumes the use of RAD tools like VB, VC++, Delphi etc rather than creating software using conventional third 3G programming languages. RAD works to reuse the existing program, components or create reusable components.

5. Testing and Turn over:
As RAD process emphasizes reuse, many of the programs components have already been tested. This reduces overall testing time. But new components must be tested and all interfaces must be completely exercised.

Advantages

• Increased Speed - RAD reduces the development time as reusability of components help to speed up development. Modularized functions that makes easy to work with.

Disadvantages

• Reduced Scalability - As RAD focuses on development of a prototype that is iteratively developed into a full system, the delivered resolution may lack the scalability of a resolution that was designed as a full application from the start.
• Reduced Features - As RAD focuses on delivery of application in short time some of the features may be moved to later versions which results in incomplete application development.

Prototype Model

A prototype is toy implementation of the system. There are many reasons for developing a prototype. The main purpose is to illustrate the input data formats, messages, reports and the interactive dialogs to the customer. This is a valuable mechanism for gaining better understanding of the customer’s needs. Another main use of the prototyping model is that it helps critically examine the technical issues associated with the product development

In this model, once the requirement analysis is done and the quick design for a prototype is made, the development process gets started. Once the prototype is built it is given to the customer for evaluation. The customer tests the package and gives his feedback to the developer who then refines the product according to the customer’s exact expectation. After a finite number of iterations, the final software package is given to the customer. In this methodology, the software is evolved as a result of periodic shuttling of information between the customer and developer.

Advantages:

• Provides a toy model of the original system.
• Users have an idea of what the final system looks like
• Encourages active participation among customers and developers
• Efficiently identify problems
• Faster feedback from the customer

Disadvantages:

• Damage in the structure of the system because of many changes
• Difficult to document as the requirements keep on changing
• Excessive time and cost for developing a prototype.

Waterfall model

This is also called as Linear Sequential model. The stages in this model include

Requirements Analysis:

Requirements are gathered from the end-user and feasibility analysis is done on possibility of incorporating the requirements. The output of this phase is a Requirement Specification document which serves the purpose of guideline for the next phase of the model.

System and Software Design:

In this stage the requirements flowing from the first stage are identified as software or hardware requirements. The software requirements are then translated in such a way that they can be readily transformed into computer programs.

Coding:

This is the stage where the programs are created. Each program is called a unit and unit testing is the verification that every unit meets its specification.

Testing:

All the units are combined and now the whole is tested. When the combined programs are successfully tested the software product is finished.

Maintenance:

Most software products include this stage of the development. It involves correcting the errors that have gone undetected before, improvement and other forms of support. This stage is part of the life cycle of software product

Advantages:

• Best suited if the requirements are constant
• Allows for departmentalization and managerial control

Disadvantages:

• Waterfall model requires well defined and frozen requirements but it is often difficult for the customer to state all requirements explicitly.
• Application will not be available until late in the project time-span
• Although the waterfall model can accommodate iteration, it does so indirectly. As a result, change can cause confusion as the project team proceeds.
• Each phase should be completed before starting the next phase
• It’s difficult to go back to the earlier phase if any problem is occurred.