This Course has been replaced by CSE557


    Choosing Projects


      Your career as a computer professional will rise and fall along with the success of the projects you work on, lead, propose, and manage. These notes are about the first critical steps to successful projects: (1) A clear vision, (2) a project aligned with the organization's needs and (3) a project that is feasible.

      The Systems Development Life Cycle is expressed as:

    1. SDLC::= Analysis; Design; Implement; Operate; Obsolescence.

      Design starts when we choose the changes that need to be done. In class and in an ideal world we complete analyzing the situation before we start to choose the projects. In practice, we usually discover the need for more information (Analysis) about the enterprise and its systems as we choose our project.

      1. Analysis: Systems and Fact Finding [ a1.html ] , Organizational Context of Systems Work [ a2.html ] , Systems Architecture [ a3.html ] , Modeling Data [ a4.html ] , System Modeling using Text [ a5.html ]

      2. Design: Choosing Projects [ c1.html ] , Strategic Thinking [ c2.html ] , Project Planning and Management [ c3.html ]

      3. Data...

      4. Requirements...

      Envisioning a Project

        Before we start a journey we need to know where we are going and why. In systems terms we say a project needs some kind of vision to guide it. This needs to be expressed in business language. Projects are started because they do something for the enterprise. Technology is a servant of the enterprise. It shouldn't form a large part of the vision. A vision also needs to simply stated: a paragraph.

        Here is a definition of vision and an example from a project.

      1. vision::="a statement of what the enterprise will achieve if a project is carried out".

        For example

          mOrder-Server table service offers Point of Sale functionality in a restaurant. It helps waitresses and waiters to make orders easily. Also, its management functions intuitively help the manager to manage the restaurant. The manager can easily edit the menu, check the sales report, discover the top sales, and so on. An intuitive touch screen puts the user in control with the touch of a finger, allows the manager to decrease training time and increase employee productivity.

        From Chieh-Chou Chou's project presentation in 2004.

      . . . . . . . . . ( end of section Envisioning a Project) <<Contents | End>>

      Selecting a Project

        Pattern -- Involve People in Selecting Projects

        Find out who has a stake in the success (or failure) of a project and get them (or their representatives) involved in discussing possible solutions. People tend to prefer systems that give them something... They also like system that they have helped to develop. So getting stakeholders involved will improve the project. They will also improve the chances of its environment accepting it.

        Story -- Diagnose problems and propose solutions thoughtfully

        Once there was a tall office building with a set of elevators. People always were complaining that they were too slow. They would have to wait when they entered the building before the elevator came.

        Exercise in class: What are the problems? Propose solutions. Moral: TBA in class.

        Principle -- Twelve Leverage Points in Changing Systems

        These are a little abstract but might help you come up with an innovative proposal to fix a broken (or bent) system: [ Twelve_leverage_points ] (Wikipedia).

        Story -- Design for the Future -- calculate data volumes

        Study this [ world-us-canada-11491937 ] news item.

        Moral: always be careful to work out how much data a system can handle and make sure this is more than the projected amount.

        Typical Process

        1. Situation->-THINK* ->-Ideas* ->-Business Case->-Preliminary report . . .
        2. * Involve stakeholders.
          1. Senior Managers
          2. Your Boss
          3. Your users. -- involve opinion leaders and users who are expert in the area, for preference.
          4. Customers
          5. Other Developers
          6. ...

        3. Notice that the process is iterative. You may have to make several proposals until you can proceed to detailed design and implementation.

        The Business Case

        The Business case for a project explains the Business Reasons for carrying out the project. Funcdamentally all businesses have two reasons to carry out a project:
        • Increase Revenue
        • Decrease Costs
        Luckily some objectives tend to do both: improving reliability, improving efficiency, reducing energy use, ... But there is often some up-front costs that have to be met before the project starts to pay off. There is a standard approch for handling the tradeoff between development costs and ultimate benefits... it is call "Cost Benefit Analysis" and will be described later.

        By the way -- increasing revenue is the real selling point for a project -- see [Armour11] for example.

        Technique -- Thinking

        First you need to understand the situation -- and the previous activities and notes are all about gathering and organizing the information that you need to come up with good ideas.

        It helps if you train your brain to follow some workable patterns below

        Pattern -- TEC

        A good pattern for thinking is TEC from the British Cognitive Research Trust. TEC is the acronym for: Target Expand Contract.
      1. TEC::CoRT=following,
        1. Pick a specific Target.
        2. Expand about this target -- say everything you can.
        3. Contract to a selection, summary, solution, conclusion, action, or ....

        (After the Cognitive Research Trust "THINKING -- ACTION" booklet, UK, 1975?)

        Pattern -- PMIU

        Here is another useful pattern. When evauating an idea start by looking for the positive points and end by looking for things you don't know.
      2. Evaluating_an_idea::=following
        1. + Good points
        2. - Bad Points
        3. ! Interesting points.
        4. ? Unknowns

        Principle -- Avoid Problems

        The best way to solve a problem is to avoid having it in the first place. Be aware that an important job when analyzing and designing systems is to avoid problems rather than to create and then solve them. Choosing your battles is a significant part of successful systems work.

        Principle -- First Define the Problem

        In many cases, the correct description of the problem contains the solution to the problem In other cases explaining what the problem is -- verbally -- or better on paper -- helps you create or discover the solution. For example see [ rubber-duck-problem-solving.html ] Also see Problem_solving and Polya below.

        Technique -- Personal Problem Solving

        Sometimes our task is to solve a problem that exists in the current system. Problem solving is a skill that you can learn. It pays to practice it. I've put a set of online resources that you can refer to later at the end of this section.

        Here is a procedure I've used for many decades

      3. Problem_solving::=following
        1. Clarify what you really want -- the goal or purpose.
        2. Review the given data and unknowns.
        3. Get data to reduce the unknowns.
        4. Generate at least three solutions
          1. Do nothing
          2. The obvious solution
          3. If X was the solution then ...
          4. Shift your goal a little...
          5. Factorize the problem into subproblems, solve them ( Problem_solving (recursive)), and assemble combinations.
          6. Use a random thought to stimulate an idea. Example open a dictionary at random and pick a random word, now try to find a connection between the word and the problem.
          7. Re-express the problem in a different media or mode. Typically this means drawing a different kind of diagram, but writing a poem on the topic can also generate insight and so solutions. Check out Visual Thinking [ ] [ ] (advert).
          8. ...
          9. Improve any of the solutions that you've got

        5. Evaluate the solutions. Since each solution should be evaluated on several criteria it is beset to draw up a table. I use rows for the criteria and columns for the solution. For example with personal projects I use:
          fit with Goals???
          Best case???
          Worst case???
          How handle worst???

          (Close Table)
          In an enterprise use a table something like this:

          (Close Table)
        6. Choose a solution. Why that solution?
        7. Make a plan of action including: NOW! Development, and Support...

        Pattern -- All problems have three solutions

        A colleague of mine with a lot of experience said that every problem in an organization needed three solutions. Here I've translated them into a medical analogy:
        1. Emergency first aid -- a fast patch to stop the bleeding and keep the system breathing... Also called the band-aid solution.
        2. Curing the underlying disease or repairing the damaged body.
        3. Installing healthy habits to stop the disease re-occurring.

        Example of three solutions

        If the problem was a buffer overflow letting people take over the server.... then the band aid is to shutdown and clean the system. The cure is to find the buffer overrun in the code and fix it. The healthy habit is to give up 'fgets' and C.

        Pattern -- Mathematical Problem Solving

          Introduction to Polya

          Some problems can be expressed in terms of Givens, Goals, and Operations that relate them. These can often be solved using the mathematical method as described by George Polya. The following may also help you in mathematics classes.

          Polya - how to solve it

          1. Princeton 1988 2nd edn isbn0-691-02356-5 QA11P6 1988 [Polya88]
            1. Understand, 2. Plan, 3. Carry_out_the_plan, 4. Looking_Back.

            1. What is the unknown? -- goal/output/conclusion?
            2. What are the data/givens? -- given/input/parameters/hypothesis
            3. What are the conditions? -- operations/relations/premises connecting the given to goal.
            4. Check conditions: possible & sufficient ~ redundant ~ contradictory ~ separate.
            5. Draw a diagram.
            6. Introduce a suitable notation.
            7. Separate the various parts of the condition. Can you write them down?
            8. Use plausible, reversed, and lateral thinking to invent a way to solve the problem. Avoid rigor and details.
            9. Look at the goal/end point first!
            10. Have you seen a similar problem before?
              • Look for similar goal/given/...
              • Look for more general/specific.
              • Look at any previously solved problem/theorem... can you make use of it?
            11. Can you restate/reverse this problem?
            12. Review
              1. Did you use all the data/givens?
              2. did you use the whole condition?
              3. Have you allowed all the notions in the problem... if not revise your plan.

            13. Carry out your plan step by rigorous step.
            14. Fill in the details in steps top-down by refinement.
            15. At each step look for signs of progress,
            16. Check each step for correctness.
              • Can you see that it is correct(intuitive)?
              • Use formal techniques that fill in the details in your plan.
              • Can you prove that it is correct?
            17. Can you check the result?
            18. Can you check the steps?
            19. Did you use all the givens?
            20. Can you improve the steps?
            21. Can you see the whole at a glance?
            22. Can you use the result or the method in some other problem?
            23. How can you share/present/publish the result?

            . . . . . . . . . ( end of section Polya) <<Contents | End>>

        Finding a Feasible set of changes

          How to spot something that might be worth changing.
        1. Requests for changes(RFCs). Does your enterprise have a form for systems requests? Should it? Does a committee prioritize them? Map out the request handling system as a DFD!
        2. Look at the Strategic plan -- if it exists.
        3. Who is responsible for deciding on projects. Some enterprises have a special Steering Committee for IT projects.
        4. List the stakeholders:
          • People who have something to lose if the project or system fails.
          • stake_holders::="people who have a stake in the success of the system".
          • stake_holder::="person who has a stake in the success of the system".
        5. Look at Possible Futures: Best, most likely, and worst. What can you do about the worst case scenarios?
        6. Look for the forces and barriers in the situation.
        7. The 4 Reasons for change: PORT
          1. Problems -- where does it hurt? (just like medical diagnosis)
          2. Opportunities
          3. Risks -- from inside and boundaries.
          4. Threats -- From outside

        8. Some Reasons for Systems Requests
          1. to improve service
          2. to support new products/services
          3. to deliver new or better information
          4. to strengthen control and security of data
          5. to reduce cost
          6. etc.

        9. Costs and Benefits: Before a project can proceed you will need to convince people that it is worth doing. This often means you need to prove that it will either save money or generate more money. Note that most businesses aim to optimize profit: (minimize costs and maximize income). However some enterprises (CSUSB and non-profits for instant) treat money as a constraint and have some other objective. You need to know what the organization's vision, mission, goals, etc. are before proposing a problem to tackle. We will return to formal Cost-Benefit-Analysis later in this course.

        10. Half-a-dozen factors that effect projects
          1. Internal
            1. Existing systems
            2. Strategic planning
            3. Top management (stake_holder)
            4. users (stake_holder)
            5. People in the IT Department (stake_holder)

          2. External
            1. Technology (Opportunity / Threat)
            2. Suppliers (stake_holder?)
            3. Customers (stake_holder?)
            4. Competitors (Threat / opportunity)
            5. The Economy (Threat / opportunity)
            6. Governments (Threat / opportunity)

        Process -- Field of Dreams -- Technology adoption

        This pattern is named for a movie where the central character is told that "If he builds it, they will come". This is a plan that is most often used with commercial and mass marketed software. You develop the new system so that you think it has clear advantages over the old (rival) system and then encourage people to use the new one in place of the old. Given that the new system is attractive enough to make people change then the numbers of people switching over follows a bell shaped curve with small numbers of people at each end:
        1. innovators
        2. early adopters
        3. early majority
        4. late majority
        5. laggards

        Conclusion: if you build it some people come to it slowly...

        Moving from the "early adopters" to the "early majority" is difficult -- it is known as bridging the chasm. If your solution doesn't cross the chasm then it does not enter the mainstream and will vanish from sight.

        Pattern -- The Inventor's Dilemma

        Clayton M Christensen wrote a very good book ( "The Innovator's Dilemma: When new Technologies cause Great Firms to Fail", Harvard Business School Press Boston MA 1997 ISBN 0-87584-585-1 CR9802-0061 ). He documented the way that a new technology enters a market and then comes to dominate it. Paradoxically, initially the old system is more effective than the new one. Only evolution through usage makes the new system better. Thus new technology is rarely introduced by companies that already have a dominant product. The technology comes from a start-up with nothing to loose. Some large companies handle this by creating separate parts charged with coming up with a new product which must then compete with the old internally. Examples are the Java language developed inside Sun and The PC developed inside IBM. You may find this branch of the organization called the "Skunk Works".

        Notice that this also means that technological innovations tend to start with a backward step. It takes several iterations to get a better system that people are happy to adopt. For this reason you would be wise to always develop projects as a series of iterations with time to test ideas with the stakeholders well before the deadline.

        Phase vs Iteration

        (phase): a section of time when a particular part of a method is followed.
        (iteration): a cycle through a series of steps that moves something closer to its ideal state.

        Principle -- Network Effects

        You will often find that a piece of software's value depends on how many people are using it -- the more the better. This effect was first noted by economists with respect to telephones: the value of owning a telephone depends, critically, on there being people you can talk to using the phone. Hence the name: Network Effect or Network Externality.

        In software, for example, it pays to have a the same word processor as everybody else. The value of your word processor is higher if lots of other people also use it. So, as a rule, a better connected product does better. An example is Apple's Newton that did not interface with their Macintosh series -- and failed. On the other hand, Palm Pilots have always have HotSynched with PC's -- and are still with us. And of course now Apple has the iPhone, iPods, and iTunes that connect with PCs and Mac's.

        A wise designer will design a new system to communicate well with the old systems so that people using the new system are not isolated. This might be called

      4. Forsters_law::="Only Connect", from a famous novel.

        Exception: in the presence of malicious and infective software it can pay to be different. Diversity slows the spread of viruses.

        Principle -- There are many ways to skin a cat

        Never forget that software doesn't have to be developed internally. You can
        • Get it free from Open Source projects. But it may be without support and documentation. [ open_source_ado.html ]
        • You can buy it.
        • You can buy it and customize it.
        • You can reuse existing software with new software wrapped around it.
        • You can outsource development: next door vs off shore. NearSource vs FarSource.

        Document -- Statement of Work

          Some organizations require you to prepare a "statement of work" as part of developing a project proposal.
        1. statement_of_work::document=following
          1. It defines: name, manager, client/customer, sponsor.
          2. It gives dates.
          3. Staffing: How many people doing what.
          4. Vision, goal, objectives, phases or iterations.

        . . . . . . . . . ( end of section Document -- Statement of Work) <<Contents | End>>

        Document -- Project scope

          Some organizations require a description of the project in more detail -- a
        1. project_scope::=following
          1. Who? What? When?
          2. General information.
          3. Problem or Opportunity.
          4. Objectives.
          5. Description.
          6. Benefits to business.
          7. Deliverables.
          8. How Long will it take?

        . . . . . . . . . ( end of section Document -- Project scope) <<Contents | End>>

        Technique -- Assessing Feasibility

        1. Is this project worth doing -- This is Feasibility.
        2. Classify constraints: external vs internal, mandatory vs desirable, present vs future.
        3. Learn the kinds of feasibility
          1. Operational -- Can it work?
          2. Technical -- Can we make it? The key part of technical feasibility is whether we have (or can get) the necessary data that the project will use.
          3. Economic -- Will benefits outweigh costs? If so when does this happen? What is the Return On Investment?
          4. Schedule -- Can we do it in time?
          5. Legal (AMOW)
          6. Political (AMOW) -- who inside the enterprise will oppose this?
          7. Ethical (AMOW)

          All of these can make a project fail. The most important one varies from project to project: the critical one is the one that will kill the project.

          (AMOW): I added three kinds of feasibility (Legal, Political, and Ethical) that are not found in most texts. They are based on my experience of projects.

        Pattern -- Trade off

        Commonly you will find several solutions. But a solution that is good for one criteria is bad for another and vice versa. For example one solution is cheap to develop but inefficient to operate, whereas another solution will be expensive to develop but cheaper to operate. We talk about this as a Trade-off. In computing for example we can nearly always speed up a program by giving it more space to run in. This called a space-time trade-off. In these cases you can often developed a mixed strategy which combines the alternatives. Another strategy is to think about the relative importance of the two opposed benefits and set priorities.

        Pattern -- The Bathtub Law of Costs and Reliability

        Costs of a system tend to start high and then slowly decline, and then stay low for a long time, until the system starts to need extra maintenance and ultimately replacement. We call such a pattern a Bathtub curve. Bathtub curves were first observed for failure rates.... but the same curve fits the costs of a system.

        [Costs a high at first and at the end of life]

        [Reliability stays low between unreliable start and finish]


          What are the double colons for

          I use them in definitions:
          so that I can extract them into a data file "dictionary" that my search engine's uses to find things on my web site. The notation (Bachus Naur Form or BNF) has been used since the 1960's to define computer languages. In the 1970's it was extended(EBNF)... and through the 1980s onward I experimented with stretching it to the limit -- eXtreme Backus Naur Form (XBNF).

          What is schedule feasibility

          This is checking to see if we can complete the project within the deadline with the available resources.

          What do you do if there is no documentation

          You may have to do it yourself! Or at least go into the source code and use that to answer questions.

          What is the commonest root cause of a problem in an organization

          The people. And typically today's problem was yesterday's solution!

        Architectural Choices

          Many architectures can support a set of functions. The best architectural choice depend on the non-functional requirements like: usability, reliability, security, cost, performance, speed, latency, time to develop, TCO, ...

        1. TCO::=Total Cost of Ownership.
        2. Initial cost is a lot less than the TCO!

        3. Check the following things about your architecture:
          1. OPTIONS: choose the best of three architectures. Or present three to the stakeholders with a range of costs and let them pick the best one.
          2. Scalability -- choose an architecture that will work with more data and usage than you need. Choose one that can expand as the need grows.
          3. Performance -- details below.
          4. Training,
          5. Reliability -- Mean time to failure, ...
          6. Life time,
          7. Fit with Legacy Systems,
          8. Security,
          9. Maintenance,
          10. Security,
          11. System Management and Support
          12. Help Desk
          13. Maintenance and Faults,
          14. Backups,
          15. Disaster recovery.
          16. Obselescence -- cost of recylcing and cleaning up.
            1. Amip Shah & Tom Christian & Chandrakant Patel & Cullen Bash & Ratnesh Sharma
            2. Assessing ICT's Environmental impact
            3. IEEE Computer Magazine V42n7(Jul 2009)pp91-93
            4. Evaluate the impact of your system over the complete life cycle from manufacture to recycling or the dump.

          17. Security.

        4. Classic Processing options: Online (OLTP) vs Batch, mixed .
        5. OLTP::="Online Transaction Processing".
        6. Classic mix: Provide a mostly automatic system for every day work that gathers performance data for executives and managers to analyze -- OLAP, data ware house, data mining.
        7. OLAP::="Online Analytical Processing".

        8. Classic architectures: a client server architecture

          Fat and thin clients + Server

          Multi-tier architectures

        9. Systems Design Completion: Report, sign off, presentation.


            There are three things that effect performance: Location, Limits, and Load. This complicates choosing the best systems architecture. Study the three sets of notes below.
            Performance depends on the location of the data
              We met this in [ a3.html#The Principle of Locality ] which covered to facts of systems life. First the place where the data is stored determines the speed at which you can access it. The technology chosen for each data store will control the possible speed of the processes that use it. Second, if the data is a long way away, on a network, then the latency will be larger. Finally, the position of the data inside a device interacts with the sequence in which a process accesses the data.

              So, choosing the right technology for data stores, choosing the right places on the network, and making processes access data in the optimal sequence all add up to a winning architecture.

            . . . . . . . . . ( end of section Performance depends on the location of the data) <<Contents | End>>

            Performance is Limited by the minimum resource available
              A common mistake is to by a faster CPU when the system is actually slowed down by the disk. It is important to understand what limits a system's performance. Further new technology changes the rules.

              Read this article [ 001304.html ] (Coding Horror).

            . . . . . . . . . ( end of section Performance is Limited by the minimum resource available) <<Contents | End>>

            Performance depends on load
            1. Performance degrades for high loads. There is a lot of theory worked out for the behavior of systems under various loads [Queuing Theory]. A useful rule of thumb predicting performance is that
            2. (eq1): time = constant /(limit - load), for some unknown constant and limit.


            3. Given some low load measurements it is not difficult to estimate what the limit is. If we rearrange eq1 above as follows
            4. limit-load = constant/time,
            5. load = limit - constant/time,
            6. Now we can see that plotting load vs 1/time we should get a straight line that touches the x-axes at the limit. Better we can use statistics to fit the line and make estimates of the expected value of the limit and 90% confidence intervals for it. To learn more -- take MATH262!

              [Plotting load vs speed]

            How do you measure scalability
            By how much growth the system can take before it suddenly becomes more expensive. Typically a small increase in volume or size is handled easily and inexpensively, but there comes a point when the added demand makes the system hard to use/unreliable/slow...

            Scalable systems respond linearly to growth -- costs go up on a straight line not a curve.

          . . . . . . . . . ( end of section Performance depends on load) <<Contents | End>>

          Designing for Performance
            Most effective processes for getting data in the right place etc. are iterative and based on complex spreadsheet based models. We don't have time to do any of this in this course, sadly. You may find it described as "Physical Design Control" in some enterprise methodologies.

          . . . . . . . . . ( end of section Designing for Performance) <<Contents | End>>

        . . . . . . . . . ( end of section Performance) <<Contents | End>>

        How far in advance should you plan

        Your design should be a good design for the whole life time of the system. This is an arbitrary time and if the system works well the life time will be longer than you would ever believe possible. But in planning: look at how long it is before a system will be replaced. For planning activities within a project follow these guidelines
        1. Precise estimates and plans are only good for a short time. You can plan a day of work precisely but you will be wrong about six-months.
        2. Divide a long time period into milestones. Divide these into "inch" "pebble" pieces. Revise the total plan as you go.

        We will cover the classic techniques for detailed planning later.

        What is the most important non-functional requirement when making architectural choices

        I call this the most critical quality of the system. Sadly, it varies from project to project. The prime skill you need to learn is to spot the most critical quality -- the one property that is most likely to make the stakeholders reject your system.

        For example, if you are producing a piece of software for the mass market the most critical quality is time to market and just about all the others (reliability, usability, completeness, ...) have been sacrificed to beat a rival company to the market. For NASA however reliability tops the list... but they also have hard deadlines (launch windows). For many businesses the most critical non-functional requirement is maintainability: being able to cheaply make changes in running software.

      . . . . . . . . . ( end of section Architectural Choices) <<Contents | End>>

    . . . . . . . . . ( end of section Selecting a Project) <<Contents | End>>

    Document -- Systems Design Specification -- SDS

    The target of all this activity is to know what needs to be done to make the systems run better. Typically a project needs to define a "Systems Design Specification" or SDS. A typical one looks like this
  1. Specification::report=following,
    1. Executive Summary: Name, who, what, why, how...
    2. System Components: Interfaces, Networks, Data, Flows, etc etc
    3. System Environment: Constraints on system including operations, hardware, software, security, ... Response times, deadlines, processing schedules,...
    4. Implementation Plans: start up, initial data, user training, test plans
    5. Time and Cost Estimates
    6. Optional(Appendices)

    Note: your final project report will be a Systems Design Specification. You will develop it during this course. You will be given extra time to perfect it before your final presentation in the 20th class meeting.



      Always know what you will giving to people -- the deliverable. Precisely.

      Skill -- Communications

      Practice your communication skills: face-to-face, Email, phone, meetings, and presentations.

      Presentation Tools

      Use anything and anybody in the room , plus anything/body you can bring with you! Chalk board, sticky Notes, cards, walls+posters, sticky walls, OHP+view-foils, screen, projectors, flip-charts, DVD players, people, . . . , even computers and the Internet.

      Plan Presentations

      Start by visualizing the audience and the room. Think about your preferred styles and techniques. What about the equipment? Focus on your objectives. Present: opportunities, strengths, resources, weaknesses, and threats Present ideas that will appeal to the audience whenever possible.

      Slides and PowerPoint

        DO NOT do the slides first. Do slides LAST. First Plan the presentation, then write the deliverable, then illustrate it, then edit without mercy, then convert the facts and simplified key illustrations into slides and think up the spoken stuff: stories, analogies, and metaphors.

        Movement: Don't animate -- unless it is special, meaningful, or to get attention.

        A Good Structure for a presentation:

        1. Who are you, anyway?
        2. Why is this worth listening to?
        3. tell them what you a going to tell them,
        4. tell them,
        5. tell them what you told them.
        6. Any questions?
        7. Quick summary of questions and answers.
        8. Thank you

        Design: Choose the right layout, line, scale, color, movement, and timing.


        Good Layouts: Heading and simple diagram, Heading + 4 or 5 bullets... Empty space. NO PARAGRAPHS. Bullet points: aim for sentences rather than keywords. Paragraph? Long Text? Make a handout. Share the reading. Mix layouts. Avoid "machine gun" bullets.

        Scale and Color

        Big is seen as most important. Minimum font 16pt, San Serif. Big text is better than small. Big hall->big text. Color: moods and style rather than content -- many color-blind people. Careful: foreground must contrast background. Check lighting in room.

        Put your name in lights

      . . . . . . . . . ( end of section Slides) <<Contents | End>>

      The Twenty Minute Law

      If you don't change pace, style, or process every 20 minutes your audience will be asleep.

      The twenty-twenty meeting

      Each person is give time to present 20 PowerPoint slides with only 20 seconds per slide.


      In your slides and handouts check for
      • Jargon. Spelling. Grammar.

      Technology. Check room out before hand: systems and visibility.

      Laser pointers

      Avoid laser pointer: program a red circle cursor on computer. Use a pen on the OHP. Rest your hand on something to avoid shaking. Laser is only good when you are a long way from the projector system... or you can loan it to the audience.


      Lighting? When you project reduce the lighting. Make sure that every one is happy with the lighting -- note: deaf people need light to read lips.


      Things go wrong. Make a list and think up some work a rounds.

      Practice to be spontaneous

      Do NOT read your slides. Tell stories about the facts on the slides. Share metaphors, stories, & analogies verbally. Show Facts visually. Notes? Put key words on cards and "palm them".

      Prepare. Test. Dress.

      Dress to fit audience and topic. In OOPSLA, jeans but in IBM: shirt/blouse and tie. Don't forget to switch any PC doing AVs to Presentation mode. Take a few deep breaths.

      Audience Involvement

      Eye contact: Look at the audience. Talk to them. SMILE.

      Invent ways to find out audience experiences/needs and link to them. Invent ways to allow/encourage thinking about the data, making plans, doing things. Ask for ideas and display them as they happen -- honestly. Distribute cards and ask people to put questions or ideas on them -- collect. Circulate ideas on cards and rate them for importance to the people in the audience.


      If you handout notes.... do it last! Otherwise people can go to sleep. You can give out an outline first with space for the audience to write notes. If you are presenting a long document ... hand out at the best time and try to involve the audience in presenting parts of it.

      Walkthoughs and Inspections find errors

      You need a document that people have had a chance to see, a way to project the document, and a way to take notes. Lead people through the document/artifact and ask what is wrong with it. Don't defend it or try to persuade people. Don't fix it: take note, thank, and promise to fix later.

    . . . . . . . . . ( end of section Presentations) <<Contents | End>>

    Review Questions

    1. Are problems solved for ever?
    2. Describe two useful frameworks for thinking.
    3. Take any topic -- a boring one is best -- and practice TEC.
    4. What is a stakeholder?
    5. List for 4 reasons for change.
    6. List 5 reasons people request changes in an existing system.
    7. What is a statement of work?
    8. What is a project scope?
    9. List some factors that effect projects.
    10. Name 6 kinds of feasibility.
    11. How does the cost and/or reliability change through the life time of a system.
    12. What information should you prepare to sell a project to management in a typical for-profit enterprise.
    13. The five types of components in a system are named by words that start(alphabetically): D,H,P,R,S. What do they stand for? For each one describe how it plays a part in systems analysis and systems design.

    Are there any limits on project topics

    Your project should be clean and legal! We will check out feasibility during this course.

    Project Kickoff

    [ project1.html ]

    Online Resources

      Resources for Thinking

      Here are some resources for thinking on the web:

      Georges Polya was a mathematician who wrote a book "How to Solve it" about solving mathematical problems. It is worth reading... I borrowed his ideas and prepared a page "polya.html" based on his work. [ ../samples/polya.html ]

      Here [ ] is a relevant Dilbert cartoon on the dark side of organizations choosing what projects to do.

      Wikipedia: [ Brain-storming ] (with Activity Diagrams) [ Lateral_thinking ] [ How_to_Solve_It ] [ Cognitive_Research_Trust ] [ Dr_Edward_De_Bono ]

      Patterns of Technology Adoption

      You can find a good summary at [ Technology_adoption_lifecycle ] in the Wikipedia. That article lead me to [ pencil.htm ] which you will (1) enjoy, and (2) learn something about changing technology.

      An Example in the history of the computerized spreadsheet:


      1. David Alan Grier
      2. Annie and the boys
      3. IEEE Computer Magazine V40n8(Aug 2007)pp6-9

      The Inventors Dilemma


      Trade offs online

      [ Tradeoff ]

      Many possible charts

      [ periodic_table.html ]

      Also See -- Rock The Podium From Wired

      [ index.cgi?page_name=rock_the_podium;action=display;category=Work ]

      Includes Advice from Desrochers & Cheal CSUN

      [ 1146_Desrochers_Cheal.html ]

    . . . . . . . . . ( end of section Online Resources) <<Contents | End>>

. . . . . . . . . ( end of section Choosing Projects) <<Contents | End>>


  • TBA::="To Be Announced".
  • TBD::="To Be Done".


    Notes -- Analysis [ a1.html ] [ a2.html ] [ a3.html ] [ a4.html ] [ a5.html ] -- Choices [ c1.html ] [ c2.html ] [ c3.html ] -- Data [ d1.html ] [ d2.html ] [ d3.html ] [ d4.html ] -- Rules [ r1.html ] [ r2.html ] [ r3.html ]

    Projects [ project1.html ] [ project2.html ] [ project3.html ] [ project4.html ] [ project5.html ] [ projects.html ]

    Field Trips [ F1.html ] [ F2.html ] [ F3.html ]

    [ about.html ] [ index.html ] [ schedule.html ] [ syllabus.html ] [ readings.html ] [ review.html ] [ glossary.html ] [ contact.html ] [ grading/ ]