CSc 332: Multimedia Design and Development Life Cycle

Download 21.69 Kb.
Size21.69 Kb.
CSc 332: Multimedia Design and Development

Life Cycle
What is the relationship between the size of a program & the time it takes to develop it?

  • Would you say the size to time relation is linear, polynomial, or exponential? Why?

Real world software projects involve teams of programmers

  • Software engineering is “multi-person construction of multi-version software”

  • If you program for a living, you’re more than likely going to be working on a team

  • Therein lies much of the complexity….

  • What’s the relationship between program size and number of people involved? Why?

  • Therein lies much of the complexity

    • getting machines to understand humans is hard enough,

    • let alone getting people to understand each other!

  • How does multimedia affect the life cycle, especially multimedia e-learning?

    • Think about the different roles involved: graphics designers, instructional designers, subject matter experts, ….

    • Software development involves a lot of communication between various human stakeholders with different perspectives on a problem.

    • BTW, make sure you have key role(s) filled for your projects!

    • OTOH, Multimedia development benefits from use of high level authoring tools

Software engineers recognize stages in the history or lifetime of a software product

Development is analogous to conception and childhood

operation and maintenance to adolescence and adulthood,

and retirement--to mix metaphors--is the sunset of a program’s life

[Show first few screens of UM’s Software Life Cycle.]

Stages of the traditional “waterfall” software life cycle:

Requirements Analysis-->Design-->Coding-->Testing-->Delivery-->Maintenance

  • Progresses from one stage to the next only after previous stage is complete

  • Gravity only allows the waterfall to go down; it’s very hard to swim upstream

  • At least, this is the ideal!

Why would corporate manager types like this development model?

  • It certainly would be simpler and cheaper to minimize the possibility of change!

  • Many software shops associate different people with different stages:

    • a systems analyst does analysis (and possibly design),

    • programmers do the coding and testing, etc.

Is something like this more realistic?

  • The reality is that not only does software change, but change happens during the process

The life cycle process is not strictly linear, but allows for cycles: iterative and incremental

  • Bear in mind, however, that more cycles mean more costs.

  • The reality is that not only does software change, but change happens during the process

  • A user may want to change the requirements (just a little!)

  • A realistic life cycle process is not strictly linear, but allows for cycles;

A modern software life cycle develops rapid prototypes early in process


  • This variation of the waterfall model adds with prototyping as sub-processes

  • A prototype is a partially developed product that enables customers and developers to examine some aspect of a proposed system and decide if it is suitable for a finished product.

  • E.g., for the CIMEL project, we developed a prototype user interface


    • We asked potential users and domain experts to review the prototype

    • A review panel then summarized their findings and made recommendations

    • We now have an alpha version of the interface, which I hope is better:


Multimedia changes the life cycle or timeline somewhat

  • Vaughan gives lots of practical advice about planning and costing a project

  • Lopuck’s timeline (p. 8) refines design and development stages for multimedia

  • What’s different? Why brainstorming instead of analysis?

  • Why build in prototyping & user testing?

  • What’s different during development? (media production)

  • How might e-learning further change the life cycle? (See Driscoll’s ADDIE model.)

Analysis: What is the problem or requirements? Instructional designers call this needs assessment.

  • Emphasis on what the problem is rather than how to solve it.

  • Lopuck calls this stage “brainstorming”: figure out who, what, why, where, when and how?

  • In addition to needs assessment and content analysis, determine what resources are needed

  • Both Vaughan and Lopuck point out that marketing and distribution plans need to begin here

Design: How to solve the problem? What’s the difference between analysis and design?

The design stage shifts to how to solve the problem,

though not in terms of implementation details or a particular programming language

` storyboards develop first thoughts about a title’s content and structure--see Lopuck, 10-12

scripts, flowcharts and paper design--see Lopuck, 12-16

flesh out storyboards by describing all the content and interactivity in detail

Instead of scripts, Lopuck talks about flowcharts--see pp. 12-13.

Development: Implement a solution

Lopuck’s timeline advocates developing an early, rapid prototype

Why would a rapid prototype be a good idea for a multimedia project? (user testing)

Why might a rapid prototype be easier for multimedia than for, say, systems software?

Activities of multimedia development:

media production: creating or acquiring graphics, video, sounds, animations.

Why is media production a separate activity from programming?

programming in an authoring environment or conventional programming language

Testing and debugging:

debugging: progressing from alpha to beta stage

final debugging and deployment
Delivery and maintenance:

How does delivery via CD-ROM vs. Web change this activity somewhat?

The life cycle of a student’s program typically ends at this point, but...

The life time of a program for a for real world application, however, is just getting started

Maintenance of software involves four different kinds of activities:

  • corrective maintenance--fixing errors found by users after delivery;

e.g., web pages not linking correctly, Authorware’s pattern transition bug on some machines

  • adaptive maintenance--adapting to environmental changes, such as a new OS;

e.g., should we port UM to MacIntosh, possibly using Shockwave?

  • perfective maintenance--improving the behavior or performance of a system;

e.g., shortening initial load time of UM by breaking up the program; adding more web page links in the content;

  • preventive maintenance--increasing a system’s future maintainability.

e.g., adopting standards in a published manual of programmers’ guidelines

standardizing fonts, use of sounds, common elements in libraries, etc.

All of these are issues for multimedia projects such as the UM

and our new NSF-sponsored project

Maintenance makes a software development process truly cyclic--revisiting earlier stages
More about analysis or brainstorming (see Questions for Preliminary Requirements Analysis)

See analydoc.doc and AudienceAnalysisOOSE.doc on the web site.

Assignment: hand in a preliminary analysis, answering some of these questions in two weeks.

Then hand in a more fleshed out analysis, revisiting these questions, in about a month.

I’ve organized these questions in terms of questions: who, what, why, where, when and how?

Who: who is your audience? Age, gender, background, experience, attitudes.

In an educational title, what background does this audience already know coming in?

What limitations might some of your audience have that needs to be overcome?

What: what is the problem? What are the goals of your project?

In an educational title, what are the key concepts/skills that the learner will master?

Why: why multimedia? (See prospect.txt on our web page)

Needs assessment: Why will multimedia provide a better solution to the problem?

E.g., we envisioned animation helping students visualize algorithms and processes.

Can you convince someone with dollars to invest in a multimedia solution?

Here’s where lots of brainstorming comes in, envisioning a successful product.

Where: where will it be deployed? Via CD-ROM or via the Web or both?

How: how will it be done?

What resources will you need? Talent, hardware, software, money to pay for it.

Who will work on your project? What roles will each project member have?

Who is the domain expert for teaching your content?

How will he/she work with your team?

What do you already have available? What else do you need? How will you get it?

When: when will it be done?

Be prepared for people in the back seat to start asking, are we there yet?

Begin to develop a timeline, budget and marketing plans

Don’t under-estimate the resources you will need! (Remember the Greek Chorus!)

See prospect.txt and timeline.txt on my web page

These documents were developed as the output of our preliminary analysis for the UM

These are by no means perfect documents, but they give you a chance to learn from

our experience (and mistakes!)

Download 21.69 Kb.

Share with your friends:

The database is protected by copyright © 2020
send message

    Main page