CSc 332: Multimedia Design and Development Life Cycle

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

• 
  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!
  

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

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

• 
  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;
  

• 
  http://www.cse.lehigh.edu/~glennb/oose/figs/pfleeger/waterfallPrototyping.jpg:
  

• 
  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
  
  • 
    http://www.cse.lehigh.edu/~cimel/Graphics/CimelPrototype.jpg
    
  • 
    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:
    
  • 
    http://www.cse.lehigh.edu/~cimel/Graphics/CimelAlpha.jpg
    

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

• 
  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
  

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.