Software Development Methodology
At IP Details, we follow the Agile Software Development methodology, which refers to a group of software development methodologies that are based on similar principles. As part of Agile, we promote:
- a project management process that encourages frequent inspection and adaptation
- a leadership philosophy that encourages teamwork, self-organization, and accountability
- a set of engineering best practices that allow for rapid delivery of high-quality software
- a business approach that aligns development with customer needs and company goals.
There are many agile methods available, of which we find that Extreme Programming and Scrum are the two methods that are best suited for us to provide you the maximum benefits. Any one of these methods alone has inherent drawbacks. So we have adopted a hybrid method by blending the benefits of both.
Among the different agile practices, we have adopted Test Driven Development and Continuous Integration. Again, any one of these practices alone limits the flexibility in some solution development situations. So we have gone in for the concoction that is difficult for our competitors to beat.
Extreme Programming (or XP) is an agile methodology that aims to reduce the cost of changes that are an inevitable aspect of all software projects. Your requirements are bound to change a bit even as we are in the process of building the solution for you. Extreme Programming prescribes the set of practices to be followed to tackle and incorporate ongoing changes smoothly without upsetting the rhythm of the development process. By adopting the good aspects of Extreme Programming, we stress that we understand that changes in your requirements at any stage of solution development are very important to meet your business goals. This methodology ensures that your changes get incorporated with the lowest possible cost impact.
Scrum is the other agile software development method that we use in combination with Extreme Programming for our hybrid agile software development method. It is an iterative incremental process with clear guidelines, practices to be followed, and predefined roles. The main roles in Scrum are:
- ScrumMaster – similar to a project manager and responsible for maintaining the processes
- Product Owner – represents the stakeholders
- Team – all the developers
The method has incremental completion periods called sprints, the periodicity of which is decided by the team. Each sprint creates an increment of usable software. The Product Owner tells the team of the items in the product backlog during the sprint planning meeting. The team analyzes and decides how much of this backlog can be committed for the next sprint. Once the sprint is completed, we get a usable increment of software which is demonstrated to the client.
We find Scrum a beneficial method for you because of its empirical approach – accepting that the entire solution you need cannot be fully and accurately defined at the start of the project itself. Instead, the focus is on maximizing our team’s ability to deliver fast and respond quickly to your changing requirements. As the project completes, you get exactly what you want now, instead of what you thought you wanted at the start of the project.
Test-Driven Development, also known as TDD, uses short development iterations based on pre-written test cases. The test cases define desired improvements or new functions. Each iteration results in code needed to pass that iteration’s tests. Preparing tests before coding aids rapid feedback changes.
A typical cycle development cycle is as shown in the chart.
- Write a test: The programmer clearly understands the feature through use cases and user stories. Thus the test is written based on the understanding of the requirements as opposed to the usual practice of writing unit tests after the code is written.
- Check whether the new test fails: The new test should fail because code has not yet been written to pass it. This step is therefore a test for the new test itself.
- Write some code: Now some code is written for the new test to pass. The programmer focuses on writing only the code needed to pass the test, which helps to keep the code clean and simple.
- Run the automated tests and see if they succeed: Run all test cases. If all of them pass, it is a good stage from which the programmer can begin the final step of the development cycle.
- Refactor code: This is the final step (not in the chart) where the code is cleaned up if necessary. Removing duplication of code is an important action in this step. The test cases should be re-run to ensure that refactoring has not upset any existing functionality.
Better software can be built faster by using TDD. The reason is the ability to take small steps and also ensures that all written code is covered by a test. Large numbers of tests help to limit the number of defects in the code and also to catch them early in the development cycle. This obviates the need for tedious debugging at a later stage.
Continuous Integration, or CI, is a software development practice in which the stress is on frequent integrations – usually, each person in the team integrates at least daily, leading to multiple integrations per day. This is in contrast to the traditional method of integration happening only at the end stages of a project.
Verification of each integration is done by an automated build (including test) to detect and rectify integration errors as quickly as possible. We reap the full benefits of CI through keeping the builds fast, automating them, maintaining a code repository, etc.
Continuous integration has many advantages:
- When a bug is discovered or when unit tests fail, instead of time-consuming debugs, developers can revert the codebase back to a bug-free state.
- Integration problems are detected and fixed continuously – no fixing on the eve of the delivery date
- Bad/incompatible code get detected early on
- Conflicting changes are detected early on
- Immediate unit testing of all changes
- For testing, demo, or release purposes, always a “current” build is available
- Developers get to see the impact of broken code immediately. This helps them learn to work in incremental steps with short feedback cycles.