Address: | PDS Enterprise Inc. 1650 West Artesia Blvd, Suite 278 Gardena, CA90248 |
Phone: | 1-843-408-0142 |
Email: | pdsenterprise@gmail.com sales@coolprototyping.com |
290. Guidelines for rapid prototype Iterative Development Life Cycle
The rapid prototyping 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.
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.
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.
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.
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.
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.