Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I understand this site is for programmers, and i have to ask specific coding question.

I am doing a software engineering degree and i have been asked to reference at-least 7 books in my definition of prototyping.

The best place to ask is here because most of you have probably read books on this and would be able to recommend books to me.

I dont mind buying them from Amazon so if you could some books for me that define prototyping or a prototype i would really appreciate it.

share|improve this question

migrated from stackoverflow.com Nov 20 '11 at 12:06

This question came from our site for professional and enthusiast programmers.

    
I think they want you go to your University Library and do some research for yourself. Asking for references on SO etc doesn't count as research. –  Stephen C Nov 20 '11 at 12:17
2  
What's the difference between asking a librarian and asking in a Q&A forum? –  Bryan Oakley Nov 20 '11 at 12:25
4  
@BryanOakley I'll tell you the difference - you're going to get more than one opinion, and get a chance for less bias. So indeed it might even be better to ask this question here. –  Yam Marcovic Nov 20 '11 at 12:51
    
@Stack Stock: what's the real question? Your title asks what is a prototype, but in the body you are simply asking for references to books. Which is the real question? If it's the latter, you might want to change the title to something more relevant. –  Bryan Oakley Nov 20 '11 at 14:27
    
Another note: if you want names of books then just go to Amazon.com and search for software prototype. :) –  Yam Marcovic Nov 20 '11 at 15:26
show 3 more comments

5 Answers

The Guide to the Software Engineering Body of Knowledge describes prototyping as a method of requirements validation as well as requirements elicitation in Chapter 2, Section 6, Subsection 2:

Prototyping is commonly a means for validating the software engineer's interpretation of the software requirements, as well as for eliciting new requirements. As with elicitation, there is a range of prototyping techniques and a number of points in the process where prototype validation may be appropriate. The advantage of prototypes is that they can make it easier to interpret the software engineer's assumptions and, where needed, give useful feedback on why they are wrong.

This passage cites Software Requirements: Objects, Functions, and States, Requirements Engineering: Processes and Techniques, and Software Requirements Engineering.

From Object-Oriented Software Engineering: Practical Software Development using UML and Java, 2nd Edition, which was the textbook used when I took my undergraduate Introduction to Software Engineering course provides this definition in Chapter 4 (Developing Requirements):

A prototype is a program that is rapidly implemented and contains only a small part of the anticipated functionality of a complete system. Its purpose is to gather requirements by allowing software engineers to obtain early feedback about their ideas.

The book then goes on to describe paper prototypes and rapid prototypes.


Ian Sommerville's Software Engineering (8th edition) provides this high-level definition of prototyping in Chapter 7.3:

In this approach to validation, an executable model of the system is demonstrated to end-users and customers. They can experiment with this model to see if it meets their real needs.

In Chapter 17.4, Sommerville discusses the use of prototyping during requirements engineering to elicit and validate requirements, in system design to explore particular solutions, and in testing to run tests with the system that will be delivered. He cites a study by V.S. Gordon and J.M. Bieman, published in 1995, titled "Rapid prototyping: lessons learned", which was published in IEEE Software, which found that prototyping leads to improved usability, a closer match to user needs, improved design quality, improved maintainability, and reduced development effort.


In Software Requirements, Karl Wiegers defines prototyping as:

A partial, preliminary, or possible implementation of a program. Used to explore and validate requirements and design approaches. Types of prototypes include evolutionary, throwaway, paper, horizontal, and vertical. These can be combined, as in an evolutionary vertical prototype.

Chapter 13 is dedicated to reducing the risk of a software project through the use of prototyping and discusses horizontal, vertical, throwaway, evolutionary, paper, and electronic prototyping methods. He also discusses how to evaluate prototypes and the risks that could be incurred because of the use of prototyping. One of the largest traps of using a prototype that he identifies is a stakeholder who thinks that a prototype is an early version of production software.


From a project management perspective, Steve McConnell discusses prototyping in Rapid Development: Taming Wild Software Schedules. A few key points are the use of evolutionary prototyping as a lifecycle model, useful for situations with rapidly changing requirements or for systems that are not well understood. He also discusses evolutionary delivery, which is a blend of techniques from the evolutionary prototyping and staged delivery lifecycle models.

Some of McConnell's best practices include evolutionary prototyping, throwaway prototyping, and user interface prototyping. For each, he identifies the impacts of these techniques on schedule, visibility, risk, and project success, the major risks and trade-offs, and when using these techniques is appropriate and when it is not appropriate.

share|improve this answer
    
+1. You not only gave a reference of the books - you read them for the OP as well! –  Dipan Mehta Jan 16 '12 at 17:58
add comment
share|improve this answer
add comment

I fail to understand the rationale for telling students to reference 7 books about something like prototyping, but whatever. I can't reference any books, except maybe for "The Pragmatic Programmer" and "The Mythical Man-Month" which talk about prototyping in a slightly different way.

First of all, they call it "Tracer bullets" and what they mean by that (what most people mean when they talk about prototyping software solutions) is that.. well, let me start a bit earlier:

When you're developing a new project (of any size), it's like a box of chocolate. You never know what you're gonna get. Specifically, you don't know if your initial plan is going to lead you to a dead end, or to some ugly counter-design patches.

So what good programmers do is they take an idea they have about the future project, and start developing something like a proof-of-concept. Usually, their ideas would turn out imperfect even for what they knew they had to achieve. That's why they don't spend too much time and thought on prototyping. They take the shortest possible route to get to the solution.

Once they're there, they have a much better understanding about the project and possible pitfalls. Now they can start over reinforced with the knowledge they gained by prototyping; and they can even give better estimations to their managers.

Again, this is also called "shooting tracer bullets".

share|improve this answer
    
"I fail to understand the rationale for telling students to reference 7 books about something like prototyping...". Why? It's perfectly reasonable to ask for references when the assignment is a research project. –  Bryan Oakley Nov 20 '11 at 14:28
    
I'd expect the professor who gave the assignment to have the ability to judge whether the definition is correct or not. What's the point in referencing books? It's only done for credibility. There's no need for it here. –  Yam Marcovic Nov 20 '11 at 14:36
1  
I disagree with the notion that programmers don't spend too much time on prototyping. I think that's an over-generalization. Some prototypes are throwaways, but some have a lot of thought behind them. For example, I'm willing to bet that many iPhone UI prototypes had a lot of thought behind them. Sometimes prototypes are the result of some very hard thinking. –  Bryan Oakley Nov 20 '11 at 14:37
    
I didn't say prototypes didn't require time and thought, bud. But any prototype that takes (even nearly) as much thought and time as the whole project defeats its purpose. –  Yam Marcovic Nov 20 '11 at 14:40
    
@BryanOakley By the way, the iPhone UI example doesn't quite apply here, since it's a UX prototype. The iPhone API however might have been prototyped the way I mentioned. And again - everything requires thought, I really didn't suggest it didn't; quite the opposite. However, the question is why are you prototyping? To test your ideas before committing to them - and wasting lots of time on them is considered committing. You want to waste less time. Do you understand what I mean? –  Yam Marcovic Nov 20 '11 at 14:57
show 1 more comment

If you're writing about UI prototyping which is a sub-genre of the general topic of software prototypes, you can reference Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. The link is to a website dedicated to that book.

share|improve this answer
add comment

A software prototype is some code that you claim is not ready enough for production use. But sadly, a lot of software is released without being ready for that. So the notion of prototype is more "marketing" than technical.

share|improve this answer
2  
I down-voted because a) I think you're wrong -- prototyping isn't just "marketing", and b) even if you're right, I don't think the answer is useful to the person asking the question. The answer doesn't recommend any books and doesn't really define prototyping other than to say it doesn't really exist. –  Bryan Oakley Nov 20 '11 at 12:28
1  
In addition to Bryan's statements, a prototype can also be something which is never intended to make it to production. E.G.: throw away prototyping. –  Jonathan Hobbs Nov 20 '11 at 15:43
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.