Thursday, July 22, 2010

Class Notes 7-22-10

Analysis is the process of fully understanding the constraints

Design = goal oriented choices made under constraint

Analysis = understanding the constraints - get as much clarity as you can get

Analysis = an investment - invest time/money


The later in a project you have to make a change the more expensive it is to make


Front End Analysis

    Gap Analysis = difference question - what is? What should be? - what is the difference from where people are and where we want them to be eg pre-test (academic)
        Cooperate - test, interview, survey, training, meeting, = time that they are not doing their job - real cost associated
            Taking a sample (all / partial) -
            ROI argument - return on investment
           
    Performance Analysis Quadrant
   
       
        • Quadrant A (Motivation): If the employee has sufficient job knowledge, but has an improper attitude, this may be classed as motivational problem. The consequences (rewards) of the person's behavior will have to be adjusted. This is not always bad as the employee just might not realize the consequence of his or her actions.
        • Quadrant B (Resource/Process/Environment): If the employee has both job knowledge and a favorable attitude, but performance is unsatisfactory, then the problem may be out of control of the employee. i.e. lack of resources or time, task needs process improvement, the work station is not ergonomically designed, etc.
        • Quadrant C (Selection): If the employee lacks both job knowledge and a favorable attitude, that person may be improperly placed in the position. This may imply a problem with employee selection or promotion, and suggest that a transfer or discharge be considered.
        • Quadrant D (Training): If the employee desires to perform, but lacks the requisite job knowledge or skills, then additional training or coaching may be the answer.
       
        Pasted from
       
       
    Audience - Prior knowledge - past experience- socio-cultural - demography
   
    Content (academic analysis of the domain)- Knowledge, learning, skills
   
    Task (cooperate - what do they do, mapping out jobs-) - Performance, behavior
   
    Pragmatic (contract negotiations) - budget, timeline, resources available to you, access to SME (subject matter expert) - make sure that they understand the connection with the SME and the timeline
   

Development

    Avoid analysis paralysis
   
    Instructional design usually follows software design a decade later
   
        Agile development
            • Customer satisfaction by rapid, continuous delivery of useful software
            • Working software is delivered frequently (weeks rather than months)
            • Working software is the principal measure of progress - the most important
            • Even late changes in requirements are welcomed
            • Close, daily cooperation between business people and developers
            • Face-to-face conversation is the best form of communication (co-location)
            • Projects are built around motivated individuals, who should be trusted
            • Continuous attention to technical excellence and good design
            • Simplicity
            • Self-organizing teams
            • Regular adaptation to changing circumstances
           
            Have the user involved throughout the whole process
           
        The Open Source Way
        (Selections from The Cathedral and the Bazaar)
        1. Every good work of software starts by scratching a developer's personal itch.
        2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
        3. "Plan to throw one away; you will, anyhow." (Fred Brooks, The Mythical Man-Month, Chapter 11)
        4. If you have the right attitude, interesting problems will find you.
        5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
        6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
        7. Release early. Release often. And listen to your customers.
        8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, "Given enough eyeballs, all bugs are shallow." I dub this: "Linus's Law".
        10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
        11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
        12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
        13. "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away." Antoine de Saint-ExupĂ©ry
        14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
        18. To solve an interesting problem, start by finding a problem that is interesting to you.
        19: Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
       
        Pasted from
       
        Getting the users involved as soon as possible and get their ideas - not a democracy but get their input
       
        Alison Carr-Chellman (Penn state) - user design
       
       
The List

    Interesting things that happened during the design process - reflective on the design process - the most important things that we learned thought the process
   
    Write up of the reasoning behind why you used or not used the list items
   
    Like a designer roadmap
       
    Be sure to indicate what we are intending to teach

0 comments:

Post a Comment