In this section we will analyze the different software development methodologies that can be applied in an offshore scenario. We will also do a case study of a successful offshore methodology that KI has applied for a number of projects over the years.

Traditional waterfall model

In traditional waterfall model, requirements are collected and iterated till they are complete. A detailed design document is then produced for entire requirements document and reviewed. Once the review is complete, the development team gets hold of the document and gets to work on it. Only the senior level team members are involved up and until the development phase. The junior developers get involved only during the development and the testing phase. Traditionally the Quality Assurance (QA) and the development are separate and have little or no interaction. Once the software development is marked complete or near completion, the testing team works on the product to identify the bugs and produce a report for the development team to work on until there are relatively few/ no bugs left in the product. At that stage the product is deemed to be ready for release to the outside world.

Waterfall model suffers from inherent and severe crippling qualities of software like

• changing requirements
• inadequate requirements
• wrong design that results in enormous cost to repair
• testing being postponed up until a later stage and done by totally different team
• constant meetings that are a result of a lack of working system.

This model is also called as SSADM (Structured System Analysis and Design Method).

Agile development model

Agile development model defines itself as an adaptive model against the traditional model which it terms as predictive.

Communication - give developers a shared view of the system as experienced by the end users. Promote verbal communication and feedback.

Simplicity - start with the simplest implementation and then go to the more complex ones. In short, make things work.

Feedback - from system using unit tests, from customers using acceptance tests and feedback from the team about the changing requirements.

Courage - to refactor code whenever it is necessary and throw away code that is out of scope or causing problems no matter how much time was spent on developing it

Respect - programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their work by always striving for high quality and seeking for the best design for the solution at hand through refactoring.

• Dynamic Systems Development Method
• Rational Unified Process
• Feature Driven Development
• AUP (Agile Unified Process)
• SCRUM

Agile methodology thrives in a small environment with senior developers who can interact with the customer on a daily basis. Agile methodology takes pride in delivering small chunks of working software throughout the development life cycle as a measure of progress.

At KI we adopt the best of both agile and the traditional software development models. We follow the agile methodology in the sense that we deliver an application in a series of iterations. We follow the traditional development in the sense that each iteration is treated as complete working software and delivered. So the team goes through a number of deliverables and with each iteration, requirements are refined and the detailed design is worked upon and changes made as and when necessary. This is essential and helpful since our understanding of the system grows as we are developing a product.

• Requirement collection
• Architecture proposal and review
• Identifying components of development
• Iterations
• Requirement correction - identifying and correcting requirements as our understanding of the system increases
• Detailed design and review

• tie each requirement to design
• remove unnecessary features
• review the design d. correct errors

• Construction

• development
• unit test
• integration test on developer's machine
• review with peers
• corrections resulting from reviews
• unit and integration test with modified code
• merging the code and checking in

• Quality assurance - acceptance tests and load tests
• Handover - documentation

• Requirement collection
• Design and design review
• Split up the project into stages for deliverables
• Iterations for deliverables
• Construction
• Test
• Deployment
• Handover - documentation