Guidelines for rapid prototype Iterative Development Life Cycle
The rapid prototype iterative prototyping approach, on the other hand, will facilitate functionally scoped, yet completely deployable versions of the software to be delivered to users incrementally. Functionality is enhanced through new iterations until the final version is cut out. Thus, the system will be developed as executable software components in an evolving manner, each iteration growing in functionality and ultimately encompassing the requirements of the complete production system.
Each iteration consists of one or more of the following development cycle process steps:
Requirements capture
Analysis
Design
Implementation
Testing
Change is anticipated throughout all stages of the development. Technical risks are assessed and prioritised early in the life-cycle and are revised for each iteration. The risks associated with each iteration are alleviated with the successful completion of the iteration.
Iterative prototyping will ensure rapid prototype development, measurable progress and the best acceptability among users.
Stage I – Starting a Project and Analysing Requirements
Defining requirements for software development is the responsibility of the customer. Customer provides the problem statement along with the business requirement specification. Sometimes, the business requirements specification is generated through various interactions with the customer.
The project team would identify the functional phases in which the system will be developed and delivered. Functions within each phase would follow an iterative development approach.
As a part of analysing requirements, the project team may undertake visual modelling of the requirements along with the logical grouping of scenarios and suggested options for implementation.
This would typically include:
Use Case diagram(s) for the proposed system.
Preliminary Class Diagram showing suggested new classes and other already existing classes.
Analysis of requirement scenarios and any other information needed to give an overview of the business process.
Stage II – The First Iteration
Scenarios of analysis are the main inputs to this stage.
The primary objective of the first iteration would be to focus on the class diagram and determine the data elements. This is aimed at addressing the database risk.
Activities of this stage include:
Building the data model
Deploying the database
Identifying the application and operations on classes. This will determine logical units of code that would be enhanced and re-used over iterations.
Identification of a user interface that can address presentation issues in relation to functionality.
Prototyping the design
Preliminary user documentation (operational instructions)
Either of the following two strategies can be agreed upon for prototyping:
Develop a single prototype that aims at crystallizing the base functional elements without finer details of presentation.
Develop multiple prototype options with the same base functionality coverage for different presentation styles. This may give users a better feel of the final system. Also, presentation issues in relation to functionality usually get identified earlier rather than during the final stages of iteration.
The strategy to be followed will be determined by feedback from the customer and the criticality of the presentation interface in relation to the business process as suggested by the requirement scenarios of Stage I.
Stage III – Planning the Iteration Process
User feedback from the first iteration will enable the project team to plan subsequent iterations.
Iterations would be planned based on the following issues:
Highest risks are tackled first. This necessarily guarantees convergence towards desired functionality as the project progresses through the iterations and also ensures less risk coupled with minimum investment.
Determining the anticipated number of iterations before the software can be shifted out of the iterative stage into final development. These are the intermediate iterations. The number of intermediate iterations would be determined by grouping scenarios (as defined in Stage I) to collectively provide a meaningful chunk of system functionality. For most projects, about five (plus or minus two) such intermediate iterations suffice.
The iteration rolling into final development may or may not match presentation GUI needs of users. This will depend on the strategy used in Stage II.
The final development would be conducted as penultimate iterations(s). The focus of these iterations would be to incorporate finer details into the software, viz. presentation, error messages, print options, multi-lingual support and so on. The maximum number of such penultimate iterations must also be planned and defined – typically, two rounds would suffice.
Once the functionality has been crystallized, test planning can be initiated.
Focus of Iterations
Focus of iterations would change as functional depth is added to each iteration.
The data model and application design must necessarily be validated and finalized in iteration II. Thus, class diagrams are finalized early in the iterative development cycle. At this time, it would also be possible to define the operations on classes.
Subsequent iterations would concentrate on the business rules (event handling, procedural logic). That is, implementing method bodies.
Presentation GUI would be considered once the functionality (including business rules) has been approved. This also provides the go-ahead for test planning.
Every iteration would be released with minimal testing. Testing focus will be put into the penultimate iteration(s); that is, in the final development stage.
Feedback is vital to an iterative process; without such feedback, there are no further iterations.
Team Profile
The focus of iterations determines the composition of the team.
The first two iterations are the primary responsibility of analyst/designers. Valuable contribution from programmers in this stage is not expected.
Subsequent iterations are carried out effectively by programmers with minimal interference by analyst/designers.
Test planning is the primary responsibility of the business analysts.
Presentation GUI and system testing stages in the penultimate iterations are also best done by business analysts.
Since there is a clear distinction between analysts and programmers, it would be possible to define involvement levels of individuals for each iteration based on the focus of the iteration. This would enable the team to take up new functional phases in parallel, well before a final delivery. That is, analyst/designers could move onto a new functional phase while the programmers see the current functions through final iterations.
Stage III – Penultimate Iteration(s)
This marks the end of the user feedback stage. The functionality along with business rules and presentation is now finalized. Focus changes to finer details, presentation GUI and system testing.
Other activities include:
System Documentation
Finalization of class, sequence, state-transition and component diagrams
User Documentation
Depth to the operational instructions as determined by the document format standardized
Quality Assurance
Code walkthrough, QA testing and correction
Stage IV – Software Packaging and Delivery
The software will be packaged, appropriately versioned and delivered. The “readme” file will list salient features of the functionality, any special areas of consideration and installation instructions. All user and system documentation will be part of the release.
Processing your request, Please wait....
