Prototyping and the SDLC

Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Share on Reddit0

The Prototyping Model Applied to the SDLC

Embarking on any development project in a new supplier/customer relationship can be a daunting experience for all parties involved. There is a lot of trust to be built in what is usually a fairly short time and it is sensible to select an approach that improves the chances of the project startup succeeding and progressing as planned to the next phase.

Read More

In my experience, there is no, single, ‘correct’ method to do this, though clear dialogue and an experience with project management methodologies can help immensely. Depending on the school of thought, project type and customer requirements, any one of a number of project management methods can be employed and it usually falls to the project manager to select an approach that also best suits the needs of the business case.

One such approach that has worked well for me in the past is the ‘prototyping model’ approach to the software development lifecycle (SDLC). Software prototyping itself, of course, isn’t a new concept, but it is becoming more popular and should be seriously considered when starting-out on a new project where it is recognised that there are other risk factors involved, such as fresh partnership agreements, subjective designs and/or new technologies.

An obvious reason prototyping is becoming more popular is its relatively risk averse nature. In a short space of time, a customer has an opportunity to perform a comprehensive skills assessment on the supplier before deciding to move forward (or withdraw) with the main project. This substantially reduces cost and quality risks at the outset.

In-turn, a supplier can ascertain if the customer has a decent grasp of their product vision and an ability to specify a clear set of requirements, so the prototype partnership is usually a mutually beneficial one. If the conclusion to prototyping is that it has been a positive experience for both parties then there is good reason to remain confident in the project partnership going forward.

There are a number of benefits to prototyping which can suit either party, but one that is of particular benefit to the customer is using prototyping as a vehicle to choose between a number of suppliers who are all bidding for the same project. Again there is less risk, certainly to the customer and potentially to the supplier as well, since neither party would wish to continue with a project that has failed in its first initiative.

So really, what I am saying here is that prototyping is a cheap, powerful assessment tool, and depending on the approach could form the foundation of the main project. Code developed in the prototype phase could be reused, so the time taken to complete the prototype is not lost in the overall project timescale.

Additionally, prototyping is tool for building successful working relationships quickly and it can prove invaluable as a supplier capability yard stick. Generally speaking, a prototype SDLC model has an overriding advantage over other SDLC models since it doesn’t rely on what is supposed to happen, i.e. what has been written in technical design documentation. Instead it canvasses the users directly and asks them what they would really like to see from the product. Gradually, the product is developed through a number of iterations and addresses the needs of the users directly in that phase of the project.

The Prototyping SDLC Model

The prototyping model starts out with a initial phase of requirements gathering, pretty much like any other software development process, however, it quickly moves to development after an initial, simple design is produced. A first iteration is released and given to the customer for review and feedback and this in turn may elicit more requirements as well as alter the design and function of the application.

This process continues until the customer accepts the prototype as complete and the project moves to the next phase of development. At this point the prototype can become redundant, or it can be continued to be used as a tool for examining various design options and/or functional changes; or it can be incorporated into the project main, as it is.

Since the prototype is developed in what is largely an agile process, there is no reason that the main application cannot be developed in the same way, although purists may argue that this is an inherently waterfall approach, I would argue that any purist approach for the SDLC can cause issues and practically speaking one should adopt an approach that suits the customer and project, i.e. flexibility is key.

Prototyping – Pros and Cons

Prototyping offers a number of advantages:

1. Time-boxed development ensures a minimum viable product
2. Users are encouraged to participate in the design process
3. Changes can be accommodated quickly and easily
4. The application evolves as a consequence of a series iterations of corrective feedback loops. Generally, this leads to a much more widely accepted product
5. Defects can usually be detected and fixed early on, possibly saving resources later on
6. Areas of functionality that are missing and/or confusing to users can be easily identified and remedied

There are however a few disadvantages as follows:

1. Most models are never fully completed and may exhibit technical debt which is never fully addressed. This is especially important if the prototype is literally used as the basis for the real application
2. Documentation, if required, can be a bit of a nightmare since changes are usually frequent and can be substantial
3. There can be a reluctance within developers to change from the initial prototype design. Instilling a new design mindset can be difficult
4. If integration is required and the prototype is unstable, this can cause other issues
5. An over enthusiasm in the iterative stages can result in too much time being invested in this phase

Will it work for you?

Before you can answer that question, it will probably be a useful exercise to ask yourself what do you need to get out of the prototype and, what do you intend to do with it afterwards?

The prototype model can be exercised in a few different ways and this can have a substantial impact on the project as a whole. More often than not prototypes fall into 1, of about 4 different categories:

1. Prototypes that are meant to be thrown away after the prototype phase
2. The evolutionary prototype where iterations continue and the prototype evolves into bigger and more functional prototypes and ultimately, the final application
3. The incremental prototype which is a more modular approach. Each subsystem is prototyped and then all of the sub-systems are integrated to build the final application
4. A web-based technique known as extreme prototyping where only the web pages are developed initially and then the functional aspects are added in the final stage. An intermediate stage is used to simulate the data processing as the prototype evolves.

The technology used to develop the application could also have an impact on how development proceeds, for example with mobile apps, most IDEs have built-in simulators to help with rapid design and demonstration of the app, so prototyping is almost implicit in the overall build approach.

Whichever SDLC approach you chose, prototyping should be considered as a useful tool in application development. It can save time, cost and be an invaluable indicator as to the future success of your project. Priceless!