"A complex (information) system that evolves from a simple system that works via rapid prototyping and software evolution."
Rapid Evolutionary Development -- Requirements, Prototyping and Software Creation. Lowell Jay Arthur, John Wiley (1992)
One of the goals of this course is for you to create a successful project that produces an electronic publishing product or service.
Understanding what makes a successful project is as important as knowing what makes a successful product.
Our 3 V's: Vision, Viability and Value
A project needs a clear and compelling vision of what to do.
A project needs a champion, a person who is willing to represent, interpret and defend the vision.
Must be able to address the key creative, business and technical issues that are crucial for a project to face.
- What is essential to this project's success?
- What business model makes this project viable?
- What technology makes this project viable?
- What people and expertise make this project viable?
Can you convince the people who fund this project that you will create new value for them?
Can you identify and reach a unique group of people who will find the results of the project valuable?
Can you convey the vision, viability and value of your project in 50 words or less?
Everybody seems to agree that you start by figuring out what the customer wants. Then you design, build and test it.
Requirements -- a formal assessment of the customer's needs and priorities.
Design -- a detailed specification of how those needs will be met, establishing that the customer will be happy if the resulting product follows the design spec.
Build -- the actual development of code and documentation.
Test -- the process of determining if the product works and revise requirements, design and code.
This is an iterative model.
A typical metaphor for development of large systems is the construction model, which leads to long lists of requirements and long development cycles.
Arthur: "This paradigm insists that we have complete knowledge of requirements and technology, that we have fixed stages and no unresolved issues."
"System construction models work well if the requirements are both well known and static, neither of which is true of information systems." (Arthur, p. 4)
"Focus on creating the 20 percent of the system that will provide 80 percent of the value." (Arthur, p. 23)
The object of prototyping is to "shorten the time between the customer's expression of a need and the developer's demonstration of the capability."
A learning process. Make continuous adjustments to the system as you build it.
(Arthur p. 61)
Act to Improve
Understanding requirements, through user interviews and prototyping.
Defining the architecture and designing the modules
Converting uncertainty into certainty
Occurs through the development process.
McConnell, Software Project Survival Guide, Microsoft Press (1998), p. 52
You have to explore to find the right requirements. You can't just ask and get the answer.
"Often, until you can demonstrate something to a customer, he or she won't be able to clearly articulate what they need." (Arthur, p. 23)
Prototyping is a way to provoke a reaction. (It's difficult to get good feedback.)
Applies to project development team as well as customers.
"Prototyping projects are explorations."
"Rapid prototyping relies on speed, simplicity and a shared vision to create a desired product." (Arthur, p. 55)
(Arthur, p. xv)
These are not "throw-away" prototypes. This is the first "generation" of a product, which will grow and change through many iterations. It should demonstrate the fundamental assumptions of the vision.
McConnell talks of "staged delivery", producing a plan with specific deliverables at successive stages. (p. 53).
Arthur cites Drucker's "do's" and "don'ts" of innovations in relation to prototypes, adapted below (Arthur, p. 97)
"Prototyping focuses on the vital 20 percent of the system that will provide 80 percent of the benefit."
(Arthur, p. 103)
Also, a too general conception of the audience is as harmful as a too general conception of the product.
Perhaps the hardest part is understanding how your project fits in with all the other people, processes and tools that already exist. This is the ecology, the set of relationships or connections that impact a project. This needs to be part of the project vision.
Things change all around you and you can't ignore that.