Methodology |
| Patni’s Application Development methodology corresponds to ISO, CMM, and CMMi frameworks and assimilates best practices in the industry. The salient features of our Application Development methodology are: |
 |
Integration of best of breed process and practices |
|
Flexibility in complying with customer specific or commercial AD framework |
|
A common Project Management framework for different project types / AD methods |
|
Robust process with suitable entry / exit criteria for full life cycle or phase level solutions. |
|
Automation of AD processes and usage of Metrics for process improvement. |
|
| |
| We adopt an elaborate Delivery Model for our Application Development projects. |
| |
Patni Delivery Model for Development Projects |
 |
| |
| Our Quality Management System maps the Software Development Life Cycle phases of its projects through two process methodologies, namely: |
|
Classical Waterfall Methodology
In the traditional Waterfall Methodology, first comes the analysis phase, then the design phase, followed by the implementation phase, with testing completing the process. Each of the phases have defined entry and exit criteria. Phase transition is triggered through management decision point by signing off phase-end deliverables. This methodology
is called the Waterfall Methodology because each phase flows naturally into the next phase like water over a series of falls.
This methodology is best suited when the requirements are frozen upfront and they are well-documented without any ambiguity. It is typically used for small projects. |
| |
|
|
Iterative and Incremental Development Methodology
Iterative and Incremental Development is a project development and management methodology, which allows for iterative project development and periodic progress measurement. This development methodology is derived from the well documented "helix / iterative" software engineering models.
The entire project cycle is sub-divided into vertical segments, called "slices" wherein each slice is a deliverable. Each slice is developed in isolation using the “waterfall model”. Developers will analyze, design, code and test in a tight loop.
Slice partitioning is done up-front, with the selection criteria being: |
| |
 |
The slices are vertical i.e. they are not sub-systems. Slices cut across as much of the functionality of the system as possible, being tangible sets of functionality that allow the user to get a look and feel. Slices represent features. In case of schedule slippages, certain functionality releases may be differed. |
|
Slices are executable and demonstrable. |
|
A slice typically will take a few weeks to complete. |
|
| |
|
| |
This allows a tangible part of the project to be complete at the end of a slice. Complete testing is carried out in each iteration. The deliverables for each of the slices include an executable that meets the functionality, associated analysis and design documentation and test results.
This methodology facilitates better risk management, better control on the project schedule through better monitoring and early corrective actions and better requirements management in an incremental mode.
This methodology facilitates requirement evolution during the development as well as helps in managing larger projects. |
|
