|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells
|News||Real Insights into Architecture Come Only From Actual Programming||Recommended Links||Scripting Languages||Software Life Cycle Models||KISS Principle|
|Literate Programming||Unix Component Model||Featuritis||Humor||Etc|
Software prototyping, refers to the activity of creating "disposable", threw-away version of software applications to test the key ideas of the architecture .
A prototype typically simulates only a key aspects of the system, avoiding bells and whistles and as such can use different, higher level implementation language then the final product. It also can be a virtual machine, not a software implementation in traditional sense (see below).
As Wikipedia article states
Prototyping has several benefits: The software designer and implementer can get valuable feedback from the users early in the project. The client and the contractor can compare if the software made matches the software specification, according to which the software program is built. It also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met. The degree of completeness and the techniques used in the prototyping have been in development and debate since its proposal in the early 1970s.
The monolithic "waterfall" approach to software development has been dubbed the "Slaying the (software) Dragon" technique, since it assumes that the software designer and developer is a single hero who has to slay the entire dragon alone. Prototyping can help in avoiding the great expense and difficulty of changing an almost finished software product due to changes in specification or understanding of the problem (and understanding of the problem often comes too late in the "prototype-less" development of software).
The process of prototyping involves the following steps
Approaches to prototyping
There are several appaches to prototyping. Among them there are two more or less realistic:
Also called close-ended prototyping. Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the final delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.
- Rapid Prototyping involved creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The method used in building it is usually quite informal, the most important factor being the speed with which the model is provided. The model then becomes the starting point from which users can re-examine their expectations and clarify their requirements. When this has been achieved, the prototype model is 'thrown away', and the system is formally developed based on the identified requirements.
The most obvious reason for using Throwaway Prototyping is that it can be done quickly. If the users can get quick feedback on their requirements, they may be able to refine them early in the development of the software. Making changes early in the development lifecycle is extremely cost effective since there is nothing at that point to redo. If a project is changed after a considerable work has been done then small changes could require large efforts to implement since software systems have many dependencies. Speed is crucial in implementing a throwaway prototype, since with a limited budget of time and money little can be expended on a prototype that will be discarded.
Another strength of Throwaway Prototyping is its ability to construct interfaces that the users can test. The user interface is what the user sees as the system, and by seeing it in front of them, it is much easier to grasp how the system will work.
- …it is asserted that revolutionary rapid prototyping is a more effective manner in which to deal with user requirements-related issues, and therefore a greater enhancement to software productivity overall. Requirements can be identified, simulated, and tested far more quickly and cheaply when issues of evolvability, maintainability, and software structure are ignored. This, in turn, leads to the accurate specification of requirements, and the subsequent construction of a valid and usable system from the user's perspective via conventional software development models. 
Prototypes can be classified according to the fidelity with which they resemble the actual product in terms of appearance, interaction and timing. One method of creating a low fidelity Throwaway Prototype is Paper Prototyping. The prototype is implemented using paper and pencil, and thus mimics the function of the actual product, but does not look at all like it. Another method to easily build high fidelity Throwaway Prototypes is to use a GUI Builder and create a click dummy, a prototype that looks like the goal system, but does not provide any functionality.
Not exactly the same as Throwaway Prototyping, but certainly in the same family, is the usage of storyboards, animatics or drawings. These are non-functional implementations but show how the system will look.
SUMMARY:-In this approach the prototype is constructed with the idea that it will be discarded and the final system will be built from scratch. The steps in this approach are:
- Write preliminary requirements
- Design the prototype
- User experiences/uses the prototype, specifies new requirements
- Repeat if necessary
- Write the final requirements
- Develop the real products
The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. "The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built.
When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt.
- "…evolutionary prototyping acknowledges that we do not understand all the requirements and builds only those that are well understood."
This technique allows the development team to add features, or make changes that couldn't be conceived during the requirements and design phase.
- For a system to be useful, it must evolve through use in its intended operational environment. A product is never "done;" it is always maturing as the usage environment changes…we often try to define a system using our most familiar frame of reference---where we are now. We make assumptions about the way business will be conducted and the technology base on which the business will be implemented. A plan is enacted to develop the capability, and, sooner or later, something resembling the envisioned system is delivered.
Evolutionary Prototypes have an advantage over Throwaway Prototypes in that they are functional systems. Although they may not have all the features the users have planned, they may be used on an interim basis until the final system is delivered.
- "It is not unusual within a prototyping environment for the user to put an initial prototype to practical use while waiting for a more developed version…The user may decide that a 'flawed' system is better than no system at all."
In Evolutionary Prototyping, developers can focus themselves to develop parts of the system that they understand instead of working on developing a whole system.
- To minimize risk, the developer does not implement poorly understood features. The partial system is sent to customer sites. As users work with the system, they detect opportunities for new features and give requests for these features to developers. Developers then take these enhancement requests along with their own and use sound configuration-management practices to change the software-requirements specification, update the design, recode and retest.
Scripting language are ideal for software prototyping. Included among these benefits is the ability to address rapidly changing software requirements. In addition, the efficiency gained from user-centered design, which consists of constant user feedback impacting the software design, has received significant attention recently [Landauer95]. Fast compile-debug-test cycles, and high programming flexibility make dynamically typed languages such as Perl, Python, PHP and Tcl ideal for the rapid creation of prototypes both on compoment and system levels
Ousterhout was the first to argue that a two language approach is both feasible and practical for software development [Ousterhout97] and created the scripting language (TCL) that has a transparent interface with C and can be extended using C modules. Python also provide consistent interface to C to allow developers to move performance critical methods and procedures into C without modification of the calling code.
Supporting prototyping requires a language which can support transformation of components previously written in cscritping langue into low level statically typed compiled language (C or C++) and vise versa. Currently, few scripting languages allow for this type of flexibility.
If developers choose to use a statically typed language (for example Java) they often encounter problems in the early prototyping and development phases.
These limitations often make it difficult to use statically typed languages for rapid prototyping of all or part of an application.
On the other hand, if developers choose to use a single dynamically typed language they often encounter problems in the latter phases of development when performance, scalability, and maintainability become critical issues. They often encounter performance problems when writing computationally intensive code and tend to spend an unordinary amount of time optimizing code. They may also suffer scalability problems related to CPU and memory usage typical for scripting languages. The detection of all coding errors is delayed until the actual line of code containing the error is executed meaning that complex tests must be written in order to check the validity of code. Despite the benefits of a scripting languages, these limitations increase the cost of maintaining a large codebase.
Modern software development demands the use of Rapid Application Prototyping. Professor Luqi at the Naval Postgraduate School coined the term "Computer Aided Prototyping" to describe this work. Her leadership showed its effectiveness in gaining understanding of the requirements, reducing the complexity of the problem and providing an early validation of the system design. For every dollar invested in prototyping, one can expect a $1.40 return within the life cycle of the system development.
Dr. Barry Boehm's experiments showed that prototyping reduces program size and programmer effort by 40%. It is the technology that is the foundation for his Spiral development method. Prototyping is being used successfully to gain an early understanding of system requirements, to simplify software designs, to evaluate user interfaces and to test complex algorithms. It is a best-in-class software approach.
Fully 30 to 40% of system requirements will change without prototyping. Rapid Application Prototyping provides a look at the dynamic states of the system before we build it, whereas most other software engineering focuses on the source code. The special problems of reliability, throughput and response time as well as system features are addressed in the best prototypes. A new field of study, Software Dynamics, will emerge once Rapid Application Prototyping is widely practiced. It will focus on quantitative analysis of how software performs under various loads and include a set of design constraints that will make it possible for us to build components that can be hooked together without exhaustive coverage testing.
Software is hard because it has a weak theoretical foundation. Most of the theory that does exist focuses on the static behavior of the software, analysis of the source listing. There is little theory on its dynamic behavior, how it performs under load. To avoid serious network problems software systems are over-engineered with plenty of bandwidth for two or three times the expected load. Without analysis of the dynamic behavior, application designers have no idea of the resources they will need once their software is operational. Software has the awful propensity to fail with no warning. Even after we find and fix a bug, how do we restore the software to a known state, one where we have tested its operation? For most systems, this is impossible except with lots of custom design that is itself error-prone. Software prototyping has proven its mettle in helping designers avoid these problems in their production systems.
Much has been written about the best way to develop software applications. But there is no "best way." Both prototyping and requirements are necessary. The tried and true process of synthesis and analysis is used to solve Software Engineering problems. Bottom-up is synthesis. Top-down is analysis. Bottom-up is prototyping. Top-down is developing requirements. Prototyping is the best way to encourage synthesis. Prototyping also eases communication with the customer and with the designer. Formal written requirements are needed to establish a clear definition of the job, to control changes and to communicate the system capabilities between the customer and the developer.
So where does this leave us?
Start with an English language written statement of a problem and broadly outline its solution. Now build a prototype for the elements where you need insight. Analyze the prototype using computer aided prototyping technology and synthesize a new solution either by refining the prototype or building a new one. Once you and the customer agree on the workings of the prototype, write requirements that include features, performance goals, product costs, product quality, development costs and schedule estimates.
What do I mean by prototype?
Prototyping is the use of approximately 30% of the ultimate staff to build one or two working versions of various aspects of a system. It is not production code but it may eventually become pre-production code or it may be completely discarded. In the prototyping effort, we are not concerned with the maintainability of the code nor are we concerned with formally documenting it. Code resulting from prototyping is often used to train the programmers. Only after we have written specifications resulting from the experience with the prototype should we start the formal development process. If we are fortunate enough that some of the code that was developed for the prototypes can be carried forward, that's great, if not, there is no loss.
A prototype produces "running" software and the production development produces "working" software.
Recent project experience has led to the widespread acceptance of the concept that early prototyping is fundamental to the success of operations supporting software products.The reasons why prototyping is fundamental include:
- The prototype provides a vehicle for systems engineers to better understand the environment and the requirements problem being addressed.
- A prototype is a demonstration of what's actually feasible with existing technology, and where the technical weak spots still exist.
- A prototype is an efficient mechanism for the transfer of design intent from system engineer to the developer.
- A prototype lets the developer meet earlier schedules for the production version.
- A prototype allows for early customer interaction.
- A prototype demonstrates to the customers what is functionally feasible and stretches their imagination, leading to more creative inputs and a more forward-looking system.
- The prototype provides an analysis test bed and a vehicle to validate and evolve system requirements.
About the Author
Mr. Bernstein is president of the Center of National Software Studies and is a recognized expert in Software Technology. He provides consulting through his firm Have Laptop - Will Travel and is the Executive Technologist with Network Programs, Inc. building software systems for managing telephone services.
Mr. Bernstein was an Executive Director of AT&T Bell Laboratories where he worked for 35 years.
Google matched content
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: September 12, 2017