Electronic Publishing -- SIMS 290

Project Development Concepts

"A complex (information) system that evolves from a simple system that works via rapid prototyping and software evolution."

Source:
Rapid Evolutionary Development -- Requirements, Prototyping and Software Creation. Lowell Jay Arthur, John Wiley (1992)

Creating Successful Projects

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

Vision

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.

Viability

Must be able to address the key creative, business and technical issues that are crucial for a project to face.

  1. What is essential to this project's success?
  2. What business model makes this project viable?
  3. What technology makes this project viable?
  4. What people and expertise make this project viable?

Value

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?

"The Pitch"

Can you convey the vision, viability and value of your project in 50 words or less?

Development Models

Everybody seems to agree that you start by figuring out what the customer wants. Then you design, build and test it.

Traditional Development Cycle

"waterfall" model.

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.

 

 

 

 

System Construction 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)

Rapid Prototyping

"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.

Life Cycle of Lifecycles

PDCA Model

(Arthur p. 61)

Plan

Analyze the customer's needs

  • People, tools, environment
  • Processes

Do

Create a demonstrable prototype

Check

Closeness of fit

Act to Improve

 

Key points:

  1. PCDA not fundamentally different from waterfall model, except in use of prototypes and the shorter "cycle time."
  2. Could apply PDCA to each phase of the waterfall model as well.
  3. Should be applied to the development process itself.
  4. The preference for prototypes over written specifications to establish essential requirements.

Conceptual Phases

McConnell's Three Phases

Discovery

Understanding requirements, through user interviews and prototyping.

Invention

Defining the architecture and designing the modules

Implementation

Converting uncertainty into certainty

Occurs through the development process.

McConnell, Software Project Survival Guide, Microsoft Press (1998), p. 52

Tell Me What You Want, What You Really, Really Want?

Customers Don't Really Know What They Want Until They See It

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.)

Prototyping Leads to Better Communication

Applies to project development team as well as customers.

Advantages of Prototyping

"Prototyping projects are explorations."

"Rapid prototyping relies on speed, simplicity and a shared vision to create a desired product." (Arthur, p. 55)

Advantages:

(Arthur, p. xv)

Working Prototypes

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).

Innovation and Prototyping

Arthur cites Drucker's "do's" and "don'ts" of innovations in relation to prototypes, adapted below (Arthur, p. 97)

Do's

  1. Innovation begins by choosing a strategic opportunity, a project with upside.
  2. "Go out to look, to ask, to listen. "What does this innovation have to reflect so that the people who have to use it will want to use it and see in it their opportunity?" "
  3. An innovation is focused on the most important part of the problem, not every aspect of it. Do one thing well.

    "Prototyping focuses on the vital 20 percent of the system that will provide 80 percent of the benefit."

  4. "Effective innovations start small. ... They move most quickly when they have few people..."
  5. One of my own: trust your creative impulse that says your own work is original and valuable.

Pitfalls of Prototyping

  1. Failure to manage expectations of customers and team members and keep them informed.
  2. Attempt to meet all the needs of the customer instead of focusing on most important ones. (Lack of focus, changing the scope to increase complexity.)
  3. Omitting key players or involving too many, politicizing the process.

(Arthur, p. 103)

Also, a too general conception of the audience is as harmful as a too general conception of the product.

Ecology

The Context of a Project

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.

Beginning a Project

Get Started By Defining a Clear Vision

  1. Identify the Project Lead
  2. Create a Vision Statement