Why do we use software prototypes?
As software engineers it is possible to use prototypes in order to be able to investigate concepts, visualize design options and help research alternative solutions for the problem on hand. A software prototype helps in many ways:

1. Having a prototype helps the elicitation of further system requirements. When customer stakeholders actually see a prototype, from experience, most of the times say that something is missing. This process is very helpful in validating system requirements.
2. User interface design is a key factor for the success of the software under developement. Presenting and collaborationg wirth end users using a UI prototype is a very nice way of producing widley accepted interfaces.
3. A prototype can be used in the testing process comparing it with the system to be delivered to the customer. That means, entering in both systems (prototype and application) the same data and compare the output results. If the results are identical then there is no fault detected. (Sommerville, 2006, p.409-410)

Although prototypes have great benefits for the software project, they hide some dangers. One major danger is to use a prototype and develop it further to a product. The prototype is for experiments and proof of concept. It has no “depth” or quality build in it.

Using a prototype can be viewed as a risk reduction process. This process may introduce new risks to the project if not handle carefully. Except the risk mentioned above there are also other risks involving the software prototype. The risks are:

1. The customer gets a wrong impression on the stage of development. Seeing a working prototype is confusing to him and thinks that the software is almost ready. It is of paramount importance not to let stakeholders to think of the prototype as an early version of the software system.
2. Users may confuse the hows of the user interface and not focus on what’s of the prototype. The prototype will be used to validate the requirements of the system and not how the system will look and how it will operate.
3. Users may believe that the prototype performance will be the end software product performance. It must made clear to customers that in the prototype are not any security features or optimized algorithms. A good habit is to use a delay timer to simulate the actual system response time.
   (Wiegers, 2003)

From personal experience I know that stakeholders confuse the prototype as an early version of the system. I was building hotel management software to handle the front office jobs of a hotel. I delivered a prototype to the customer soon after we had finalized the description of the software requirements. The prototype was to test what the menu navigation would be, what critical functions (reservations) the software will perform. After the demonstration of the prototype the customer refused to believe that it will take several months of development to finish the product. It took me several meetings with the customer to convince her that it was a prototype and not an early version of the software. Sometimes managing customer expectations can be very difficult.

As a conclusion software prototyping can reduce the ambiguity of functional requirements and shorten development schedules. We must include time in the project schedules for building several prototypes and state why we want to build them. (Wiegers, 2003)

From my experience even early prototyping screen mock-up on paper can help describe the requirements of a software project.

What software can be used to create prototypes?
I have used pencil sketching for Mozilla Firefox, I know that Adobe’s Dreamweaver can be used for fast prototyping. An idea is also to use Iron Speed designer. There are many more tools listed in Cunningham & Cunningham wiki.

References

Sommerville, I (2006). Software Engineering. Addison Wesley / Pearson 8th Edition. ISBN: 0321313798

Wiegers, Karl E. (2003). Software Requirements, Second Edition. Microsoft Press. ISBN: 9780735618794

1. known risks and
2. unknown risks.

For a project to be successful risk management should be done early in the project planning. The plan risk management should identify the risks, perform qualitative risk analysis, perform quantitative risk analysis and plan risk responses. Defining a Risk Breakdown Structure helps to identify project risks. Typical categories where risk might occur in a project are technical, external, organizational and project management.

Shenhar (3) discusses the technological uncertainty for four types of projects: Low-Tech (ex. road building), Medium-Tech (ex. Existing product improvement), High-Tech (ex. New systems) and Super High Tech (ex. the Hubble telescope). Ways to reduce uncertainty involved design cycles and design freeze.

There are mainly three categories of risks relating to software projects:

Project Risks which affect the availability of resources or the time constrains of the project. From experience I know that usually developers are very optimistic when setting deadlines. They do not anticipate difficulties that may occur in the development phase of the project. This easily creates a problem with time and completion of the project. It has also implications with the total cost of the project.

Product Risks which affect the performance, scalability or the quality of the software under development. Again, from experience I know that is totally different a design that supports a few hundred users to one that supports simultaneously thousands of users. Creating multithreaded code and introducing locks into the system to avoid race situations involving shared resources increases the complexity of the code and complicates the testing of software components. I have more than 20 years of programming experience and I have seen good and bad quality code. I have also seen code that was fully commented, not well documented having no bugs but it was unnecessary complicated. This type of code can be spotted only from experience and the cause of it is job protection. Programmers thought that by writing code the way they did they were protecting their jobs because no one else would be able to deeply understand the code. In my opinion quality of the code cannot be counted by bugs and bug fixes as many organizations practice but with internal and external (if possible by an independent consulting firm) code reviews.

Business Risks which affect the business itself. For example a change in technology that a system assumed.

To have a plan ready to respond to risks that might occur, can save the project depending on the severity of the risk. The risks that are worst are the ones that are unknown and have an unknown outcome. There are several strategies available to reduce or control the risks:

• Avoidance. Taking proactive actions to avoid the occurrence of that risk.
• Transference. Insurance or subcontracting.
• Mitigation. Reducing the risk to an acceptable level for the organization
• Acceptance. Identifying the risk but making no plans to mitigate or avoid the risk.
• Contingency planning. Having an alternative plan to follow if a risk occurs.
• Independent verification and validation. A third-party oversees the project.

As a conclusion the most certain thing about projects is that risk factors will occur in one form or the other. Reducing or controlling the risk is a task that is performed by a team.

From experience I know that is also important to take under consideration the external environment when devising risk plans. This post is an introduction to possible risks associated with software development projects. I will continue with more in depth postings on the subject.

References

1. Heldman, Kim (2005). Project Manager’s Spotlight on Risk Management. SYBEX
2. PMBOK(2008) A guide to the project management body of knowledge. PMI 4th edition.
3. Aaron J. Shenhar (2001) “One Size does not Fit All Projects: Exploring Classical Contingency Domains” Management Science, Vol. 47, No. 3 (Mar., 2001), pp. 394-414 INFORMS
4. Sommerville, I (2006). Software Engineering. Addison Wesley / Pearson 8th Edition.

• the system to be build
• its functions
• its purpose

Requirements are used to define these constraints and articulate beyond any misinterpretation the software system to be build.
The term “requirement” is used very broadly in software systems. It includes:

• the Functional Requirements,
• the non-Functional requirements
• the domain requirements.

The Functional requirements state what the system should do and what the system should not do. Meaning how the system will handle input and what output to produce.
The non-Functional requirements describe attributes of the system as a whole. To give an example, a non-Functional requirement may be the response time of the system to user requests.
Domain requirements are derived from the application domain. This means that the software system might comply with some international standards.

I think that it is important to use a categorizing schema in order to be sure that all requirements are covered and to reduce the risk of not considering some important aspects of the system.
FURPS+ is used in Unified Process to categorize requirements. FURPS stands for Functional,Usability, Reliability, Performance and Supportability. The + stands for Implementation, Interface, Operations, Packaging and Legal.

It is very important to validate requirements after defining them. Correcting requirements during a requirements review has a small cost for the project. If errors to the requirements are found in later stages of software developement the cost to correct them is much bigger.

Stakeholders of the system may have different needs from the system and sometimes these needs may be conflicting. Thus, it is important to perform validity and consistency checks to the requirements. The customer and the software development team should review the requirements to ensure that the requirements correctly describe the system to be build. All the requirements of the system should be verifiable and comprehensive. It must be clearly stated who enforced a requirement in order to be able to trace back to the originator in case of a requirement change. For each requirement is good practise to state the adaptability of the requirement, meaning what the effect on the system will be if the particular requirement is changed.

After the requirements are reviewed and the proper use cases are written along with all the documentation to describe the system a requirements management system must be activated in order to:

• Control changes to the requirements in a systematic way
• Keep in synchronization project plan with requirements
• Track the status of the requirements
• Ensure that all team members have correct latest version of the requirements.

It is very important to have a conflict resolution procedure to detect and reolve conflicts. Stakeholders must have active involvement in change requirements interaction. Monitoring change and active stakeholder involvement greatly reduces system errors and increases stakeholder satisfaction and system effectiveness.

As a coclusion it is important to walkthrough the customer through the system using use cases and scenarios discussing all requirements. It is also important to insist that domain experts be present to correclty identify the requirements of the system.

References

Larman Greg(2002). Applying UML and Patterns:an introduction to object oriented analysis and design and the Unified Process. Prentice Hall 2nd ed.

Robinson,W.N, Pawlowski, S.D, and Wolkov, V(2003). Requirements interaction management. ACM comput. Surv. 35,2 pp. 132-190. DOI=http://doi.acm.org/10.1145/857076.857079

Sommerville,I (2006). Software Engineering. Addison Weasly/ Pearson 8th edition.

Wiegers, Karl E.(2003). Software Requirements, Second Edition. Microsoft Press