Software Prototypes

Training for any new technologies or tools used. The training referred to is in-house training, not vendor training

The above list is not meant to be a complete menu of goals and objectives and you probably won’t need to meet every one of these in every project.

Choose the best set of screens to include in your prototype so that you get the maximum benefit from user testing. For example, where logging in is required across a wide selection of screens, include at least one with that function. The goal here is to produce a system with the fewest surprises for your user community. You may also want to choose screens that implement the most complex concepts.

Decide on whether you need to prove build methods or performance, or both, in your prototype. Proof that the new system can handle the transaction volume required and perform at the required speeds may be a priority, in which case the functions you choose need to demonstrate this. Choose the most commonly used functions in this case. Choose the simplest, least complex functions when you need to determine the best development approach and tool set. This is particularly important if you are dealing with a team with no practical experience working with a new platform. Choose the most complex and difficult functions for the prototype in the case where you are looking to learn the best practices for development and have an experienced team.

The prototype must be carefully chosen to fit the system architecture where that prototype will be used in the final product. This may mean that the prototype must deliver the core functionality upon which the rest will be built (e.g. transaction processing, messaging, etc.). Consult with the architect for the new system on the decision. They should be able to direct you to a core set of functionality that can stand alone, meet the goals and objectives set for the prototype, and be re-usable.

Building the Prototype

Start by choosing the right software development methodology for building the prototype. If your prototype will only consist of a few screens without functionality it won’t matter what methodology you choose because the build time and effort will be negligible. Choosing the right methodology becomes important when the build will require significant time and effort. Building the prototype will be a different activity from building the production system so doesn’t necessarily have to use the same methodology as that chosen for building the production system. There are 2 methodologies that lend themselves to developing prototypes because of their focus on rapid delivery and learning from the build: Srum and RAD (Rapid Application Development).

Scrum relies on an iterative approach to development, where the iterations are called "sprints”. Scrum also has no place for a project manager so you can hand the responsibility off to a senior developer or analyst who is called the Scrum master.

RAD is particularly suited to developing prototypes because the methodology is based on using a prototype. RAD is based on prototyping and modeling replacing an intensive requirements gathering phase. RAD works best where the development teams are relatively small. Since you won’t have the entire development team on board at this point, RAD is particularly well suited for the purpose.

Quality Assurance should be a part of the prototype build. Building a prototype which cannot be manipulated by the user community will add unnecessary time and effort to the project, frustrate the user community, and end up prejudicing the stakeholders against the project. Developer testing and system testing should utilize the tools and techniques established for the project. You may acquire a testing resource or two from your QA group or assign the QA function to a developer on the prototype team. Test cases should simulate the way the user community uses the system and exercise all the screens, fields, and functions in the prototype.

The prototype should be delivered to schedule. If building the prototype exceeds the schedule a root cause analysis should be performed to determine the reasons for the delay. Reasons may indicate a different approach to development, or that original estimates for the effort are inadequate. The reasons will trigger changes to the project plan in either case.

There are companies that specialize in building prototypes to order. Prototyping is a core competency for these companies so you may want to investigate outsourcing the build of the prototype to a company that specializes in building prototypes on the software platform you are using for your project. Your "build or buy” decision should be made using the best Procurement Management processes described in the PMBOK® Fourth Edition. Learn about these best practices by taking a PMP® Course or other PMP® Exam Prep training, then passing your PMP® Exam for your certification.

Prototype Delivery

The prototype should be subjected to User Acceptance Testing, or QA testing, or both. QA testing should precede User Acceptance Testing where both are indicated. User Acceptance Testing should provide a feedback vehicle and narrative type feedback, including suggestions for improvement, likes and dislikes. QA testing should be done using the test suites and test cases designed for the prototype during the build phase. These tests should include performance tests which will measure the prototypes ability to perform at the benchmarks established for it. This testing may require special tools or environments to be available for load, stress, and performance testing.

User feedback should be collated by screen and function (where a screen is shared by more than one functional group) to help with analysis. Systems analysts should exam the feedback and make changes to the screens as appropriate. The feedback should also be evaluated for its implications for screens not in the prototype. Common functions such as the login feature may need to be altered on other screens as the result of user feedback on the prototype. You may want to conduct a second iteration of testing to prove the changes. Don’t plan for more than 2 iterations of UAT.

Use the projects issue tracking/bug reporting system to capture test results from the QA team. A failure of a test exercising prototype functionality should be corrected and the test re-executed. A failure of a test for performance, stress, or load should be analyzed for its implications. The fix to correct the failure may be simple, in which case it should be made and the fix tested. On the other hand, the fix may be very complex, or even impossible. There are companies that offer UAT services for prototypes. You may wish to outsource UAT to a company specializing in that area if you have difficulty rounding up actual users or you are prototyping a commercial web site.

The implications should be examined in this case. Can the fix be implemented in the prototype and still allow the project to finish on budget? Is there another way of building the system which would avoid the problem? Does the problem have any implications for the functionality not delivered by the prototype? The answers to these questions will have a bearing on whether the project is to proceed to the next phase.

The issues, problems, and learning derived from building the prototype should be gathered and analyzed by your systems analysts for their impact on the development phase. The results of the analysis should be an input into the planning process for the implementation phase of the project. Look for indications that additional tools need to be purchased or existing ones replaced. Examine the results for their impact on effort estimates for the rest of the development and testing tasks in the project. Learning from the prototype may indicate that building the system is indeed feasible but the cost will now exceed the benefits so rewrite the business case based on any implications for project costs.

Your prototype has gone through QA testing and may have also gone through UAT. You need to ensure that work isn’t duplicated so will need to indicate the software has been tested before archiving it, if your prototype will now become part of the new system. You’re now ready for your "go/no go” decision on whether to proceed to the implementation phase of your software development project.