At Shivamtech we plan our work and work our plan using mature and well-honed quality processes and systems.
The most important question to answer before starting product development is: Why is this product needed in the marketplace? The answer to this question constitute the business objectives of the product that should drive its entire lifecycle.
A software product's development lifecycle is comprised of four facets:
- Requirements: What features will the product have?
- Design: How will the product offer these features?
- Coding:How will the features be coded and unit tested?
- Testing and delivery: How will the product be tested and delivered to customers?
- Quick feedback loop from business stakeholders to engineering back to business stakeholders
- Rapid software product conceptualization and materialization through prototyping
- Ability to refine requirements and design, and handle changes in both in the early phases of a product lifecycle
- Focus on getting the highest priority features and the highest risk features implemented as fast as possible
- Ability to validate pieces of design incrementally, providing continuous analysis and mitigating the risks
These four facets are managed by a project plan that determines when the software product will offer the required features.
In a traditional Waterfall lifecycle model, the project plan organizes the four phases in a strict serial order. A lot of time is spent up front to define and analyze requirements and to complete the design of the target system before a line of code is written. This model does not handle changes in requirements or design well. In addition, it creates an artificial separation between business analysts, architects, designers, and programmers, leading to the risk of miscommunication and divergence between the business objectives and vision of a software product and its implementation.
Using an Iterative lifecycle model, the four facets of a software product are integrated so that business objectives drive the entire process, and the requirements and design are continuously refined while the code evolves. The project plan arranges the development into small releases, and mandates continuing integration of all coded components, incremental builds, and periodic validation of refined requirements and design. By doing so, it encourages a shared ownership of the product among business analysts, software architects, designer, programmers, and testers; this shared ownership reduces the risk of miscommunication and divergence. It also enables continuing refinement and integration to avoid any unpleasant surprises just before the delivery date.