This Course has been replaced by CSE557

Contents


    Project Planning and Management

      Online Reading

      Part of the reading on this topic is on the Wikipedia. Please study this [ PERT ] before studying the reading below.

      Introduction -- Planning is everything but the plan is nothing.

      The quote is from a successful general in the 2nd world war: Eisenhower.

      From planning how you get to work on time, to planning the next step in your team project, thru to sorting out a plan for a big project.... the same technique can be used. You can handle routine daily planning and small projects using pencil and paper. Large projects need a computerized tool. But the same ideas and algorithms are used for both small and large projects.

      You should already have met scenarios: lists of simple steps that are executed one after another. There is only one path through a scenario. There is only one way of executing it. In a typical planing situation you have a list of steps, but the order is not completely determined. Usually you can save time (and so money) by doing things in the optimal order. The Critical Path Method is a powerful tool for doing this. The critical path is a set of activities that have to be done on time or the whole project will be late. Every plan has one. These are the important activites to watch as the plan evolves.

      Masterly management of the unexpected

      This page also has notes on management. Managers have to plan things. But they have other things they must do. They must motivate and organize people. They make the tough decisions, set goals for subordinates, provide resources, and .... get out of the way. This set of notes has a some introductory thoughts, some procedures and artifacts needed when managing a development project, and a reading list that may help.

      Brookes's Law: Adding staff to a late software project makes it later.

      Software development is usually a learning experience. As the project progresses the team learns facts about their environment, their technology, the problem, etc. . More they create new facts: the software architecture, the project coding standards, what each person does, ... Now, if you add new people, the team has to stop developing the software and, instead, teach the new people the above information. This slows down (even stops) development. The project goes further behind schedule, and so more people are added... See MMM (The Mythical Man Month) below.

      So..... (1) get enough people first. (2) software development is more like research than manufacturing so some traditional planning techniques tend to make failure more likely. (3) First do things that provide the information to estimate the project -- you need to know if you need more people at the start of the project, not later.

      Levels of planning


      1. National Plans
      2. Enterprise Level Planning
      3. Department and Mid-level Planning
      4. Team Planning and Organization
      5. Individual level: see [ Personal Planning ] below

      The only real differences between the levels is the number of stakeholders involved. As more people are effected by the plans the more politics starts to play a part. So, most of the techniques that work at the personal level can be used with Teams, Departments, and even small enterprises. However, the scope and scale of the plans tends to increase with the level -- National plans may take years to be completed and have consequences that continue for years. A typical personal plan may be for the next 24 hours, and a team may work in terms of the coming week.

      Personal Planning

        Here are some points made in a recent article based on the authors experience. You would be wise to to take note of them.

        Rainsberger07

        1. J B Rainsberger
        2. Personal Planning
        3. IEEE Software Magazine V24n1(Jan/Feb 2007)pp16-17
        4. =IDEA PLANNING WORK BREAKDOWN CSCI372
        5. It pays for a programmer to organize their work day as a series of tasks.
        6. Publish the task list and check off items as they are completed.
        7. Define tasks in terms of completion -- what conditions determine that the task is complete -- tests, reviews, .....
        8. Keep tasks small enough to be done in 90 minutes.
        9. Small tasks help spot more things that have to be done.
        10. Consequence: less work done but more working software delivered.

      Estimating and Planning

      1. Time and cost of a project depend critically on the size and scope of the project, the resources you can win for it, the novelty of the project, and any unusual constraints put on the product or the team.
      2. Always break down a complex piece of work into simpler steps.
      3. Look for steps that are novel -- these are risky and should be done earlier rather than later.
      4. Work out what steps must be complete before other steps can start. "predecessors".
      5. The result is called a "Work Breakdown Structure" -- -- --(WBS)
      6. You can show a WBS as activity diagrams or other charts (below). Wise managers do this. I had a 5-year plan for the Computer Science Department on display in the department office when I was founding chair.

        Example -- Implementing my PICT system.

        During my Ph. D. I created a graphic package (PICT) and I worked out how long it would take a team of programmers to port it to a new platform. It had 8 distinct modules and I planned two levels of testing -- the machine code and the high level language code. I figured as a result that 2 programmers could do the work in less than 8 weeks. I could also show that adding a third programmer wouldn't speed up the process.

        Tools -- Software vs manual

        You can use pencil and paper, MS Project, Visio, and Dia. In a group it is fun to use a board. There are lots of piece of software that can be used -- see the online resources at the end of the reading.

        Introductory Example -- breakfast


          Three steps: boil, open, eat an egg.

          This is an example of a sequence. Note we can't eat a hard boiled egg without first cracking it or boiling it. This defines a single possible scenario. We add up the durations to figure the time to completion. In turn this means that if it takes longer to boil the egg then the whole sequence will either be delayed, or we have to do the later steps faster.

          Software development has lots of sequences: write code before compiling and make it compile before you you test it. Another example: find out the problem, before you start to solve it.

          Here is an example of a parallel structure.

          toast bread while egg boils

          In the parallel case we have two or more scenarios depending on which task we start first. There is no predefined sequence. We can choose the sequence. We can even try to multi-task the two parallel processes at the same time.

          The time to complete the above two tasks is the maximum of the two times not their sum. When we have two parallel tasks, like this, then if the longer process takes too long then the whole is delayed. And the other process can take a longer time without delaying the whole. We say the longer process is critical. The shorter process has float or slack and is not on the critical path.

          In software development this happens when you have several people coding and the work is broken into independent modules. For example: Designing screens and reports. Or preparing user manuals and help screens in parallel with coding and testing. It also happens when there is a single person but machines (the toaster above) can carry out the actions.


        The Critical Path

        In a general WBS, the time for the whole project depends on just a few processes that form a critical path through the WBS. The time to complete the critical path is equal to the time to complete the whole project. Delaying any process in the critical path delays completing the project. The other activities (not on the critical path) are said to have float or slack which determines how much can go wrong before they slow down the whole process. Finally processes on the critical path have a rigid schedule that has to be followed, while the non-critical processes can float -- they have a range of times when they can be started with out changing the completion time of the project.

        Example -- eXtreme Programming

      7. Here is an example for a one week iteration of eXtreme Programming (XP). This shows a WBS as a table. The durations are in hours.
        Table
        #Task DescriptionPredecessorDuration
        1Get new Requirements-2
        2Negotiate iteration functions14
        3Programmer writes Unit Tests23
        4User plans acceptance tests25
        5Modify code until all tests succeed35
        6Users do Acceptance tests5,42
        -Done6-

        (Close Table)
      8. I've found that tables like this are an easy way to document a WBS but they are error prone and are not easy to grasp. A diagram is needed to expose errors and smells. All planning methods use what mathematicians call "directed graphs" -- see Math272. Some tools will accept the WBS and draw the diagrams. All Critical Path Methods record and display what tasks (= activities) must be done and show, graphically the Predecessor-Successor links. All predecessor tasks must be done before all successor tasks. You get networks of tasks. So some people called this Network Planning.

        Above table as a diagram

        When expected durations are added you can calculate the earliest time the activities can start and so the shortest time for the project. The durations must be attached to their activities. From, this you can calculate how late tasks/activities can start with out delaying the project. From this you discover a path through the graph of "Critical" tasks -- the "Critical Path". These tasks must start and finish on time if the project is to finish according to schedule.

      9. I don't trust a table until I have drawn a diagram. It helps me find errors. When I show the diagram to other people more errors to appear.

        The Critical Path Algorithm

      10. The algorithm calculates four times for each task:
        Table
        TimeAbbreviationConstraint
        Earliest StartESImmediately after the last predecessor task finishes
        Earliest FinishEF= ES + duration
        Latest FinishLFImmediately before the first successor task starts
        Latest StartLS= LF - duration

        (Close Table)
        Algorithm:
        1. Initially: Tasks/activities with no predecessors start at time zero.
        2. Forward: earliest start is the maximum of predecessor's earliest finishes.
        3. Tasks/activities without successors determine time for the project: the maximum of all the Earliest Finishs.
        4. The time for the project is the latest start of all activities that have no successors. This is also called the project lead time.
        5. Backward: latest finish is the minimum of the following latest starts.
        6. When you get to the tasks/activities with no predecessors -- the latest start should be zero again.
        7. Slack::= earliest - latest.
        8. Note: Float = Slack.
        9. An activity is critical if and only if it's Slack is 0. This means it can not be held up without delaying all the successor activities. Shortening this process can save time for the whole project.
        10. Find the Critical Path -- a sequence of critical (slack=0) activities that starts from the first activity to the last activity. Thus a delay in these activities can delay the whole project.

      11. You can do the calculations on a diagram and record the results in a table. Here are the computed times (no slack yet) for the XP example:
        Table
        #Task DescriptionPredecessorDurationESEFLFLS
        1Get new Requirements-20220
        2Negotiate iteration functions142662
        3Programmer writes Unit Tests2361196
        4User plan acceptance tests256111411
        5Modify code until test all succeed3511141411
        6Users do Acceptance tests5,4214161614
        -Done6-16161616

        (Close Table)

        Special Notations

          Gantt charts

          There are examples in the Wikipedia reading on PERT of this notation. Plot time on the x axis and tasks down the y axes. They look good, so use as an audio-visual aid in presentations and as a figure in reports. Also good for posters in the project's team room. High light the finished work. I only use these when I can get them drawn for me.

          PERT

          There are example in the Wikipedia reading) of this notation. I don't like the PERT notation of arrows for activities and bubbles for events because activities often have many prerequisites etc. You have to add "dummy activities" (that take no time) to express multiple prerequisites. I was taught this in the 1960's but rapidly moved away from it.

          However PERT has a very useful approximation:

        1. Expected::= (Best+4*Most_Probable+Worst)/6.

          Use this formula to get the expected durations of activities in CPM. It can also be used in any estimating problem where we have best, worst, and most likely values.

          CPM Notation

          There were example in the Wikipedia reading [PERT] of this notation.

          Each node records the following data representing activities:

          • Task data: id and name, duration, earliest start(ES), earliest finish(EF), latest finish(LF), latest start(LS).
          • Slack and Critical Activities are calculated and added to the boxes.
            Table
            Earliest startDurationEarliest finish
            -Task Name-
            Latest StartSlackLatest Finish

            (Close Table)

          I have seen several layouts for the parts in an activity for the Critical Path Method. I like the critical path method and have used the common notation until recently. But it forces you to record most start and finish times twice because the Earliest Finish of a task will equal the Earliest Start of the next task.

          UML Activity Diagrams

          These are the best notations I have seen for doing Network Planning.
        2. Tasks are shown as UML Activities -- boxes with rounded corners.
        3. Durations are shown like this "{duration = 1 hour}" inside activities. Each activity needs a duration. Note -- when doing CPM by hande just write the number to save time in side the activity under the name.
        4. Arrows show precedence (control flow). You must show arow heads.
        5. You must introduce UML start and finish symbols.
        6. Paralellism is shown by a bar that runs across the flows showing where they synchronize.
        7. Matching traditional to the unified notation

          [Where to find durations, ES,LS, EF, LF in UML]

        8. Add a unique Start state (a black dot) as predecessors of task/activities that have no predecessors.
        9. Add a unique Terminal state (a black dot in a circle) as a successor of all tasks/activities that have no successor.
        10. Avoid decisions and ambiguous exits from activities. Use "forks" and "joins".

          [No choices but use vertical bars for parallelism]

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

      Use UML Activity Diagrams for planning

      You can do the Critical Path Method easily in the UML.

      Hints with planning diagrams

      1. Turn your paper sideways. Set your "Print Setup" to landscape before you start.
      2. Every project has a single start point and a single terminator.
      3. Watch out for branches that go nowhere.
      4. Watch out for events/predecessors that are redundant before you do the CPM.

      . . . . . . . . . ( end of section Hints with planning diagrams) <<Contents | End>>

      Can we face a critical path at the start of a project

      Yes -- the critical path starts with the first step. All WBS have a critical path and it always connects the start to the end of the project. It is a property of WBSs! However only one of the initial activities is usually on the critical path.

      Which do I prefer: Visio or Dia

      Somehow I like Dia better because it is free and not pretentious. I dislike paying for any program that does many things that I don't want.

      What is the purpose of the critical path method

      It tells you much time you will need to complete a project if you do things in the right order. It also tells you what steps/actions/tasks in the project that can be started late with out delaying the whole project. It also calculates, for each non-critical task, how much lateness is allowed on each task.

      Explain CPM

      Hmmmmm --- best thing is to try it. It is a quick and simple calculation that gives you some useful information about your project.

      How do you decide if an activity is critical

      Use the critical path method and the critical tasks will have zero slack. Slack is found by subtracting the earliest start from the latest start. Then look for a sequence of critical taks that runs from the start to the fish of the project. This is the critical path for the whole process.

      If one activity helps another but is not necessary -- is it a predecessor

      It depends. First the "helpful" activity can be split in two: part that helps so much that it must be done first plus a part that is irrelevant. Second you can choose to ignore the help provided in the hope that the shorter schedule will make up for the "helped" not going so well. Third you can choose to include the constraint and assume that the helped task will finish quicker and so the whole project finishes faster. In each case CPM will help to clarify what you need to do.

      Planning Smell -- Indecisiveness

      A plan that has a decision in it, can not be handled by CPM and is a risky plan. Take whatever actions you can to reduce the risk as early as you can. For example, include activities to gather data to make the decision and schedule them early. Then revise the plan. For example
      1. It is not clear what algorithm might solve a problem in a program.
        1. Negotiate with management for more time.
        2. Start a special project to research and develop several prototype algorithms.
        3. In parallel: research alternative designs to avoid problem entirely.


      Story -- My Final Year Project

      In my final year project, the CPM diagram had a decision box in it because the algorithm Was experimental -- I wouldn't know which path to follow until I did the experiment. I planned to use might not work. I expected it to but it was an untested idea of my adviser. In fact, it was still failing when I had to stop and write up the project. Moral: Forward planning must be mixed with the masterful management of the unexpected.
    This story taught me that you can do any amount of planning but you also have to be prepared to handle the surprises that are going to happen in any interesting project. The job of management is to be ready for them and to demonstrate "masterful" handling of them. Being ready, means including some "slack" in the plans.

    Further it shows that you should tackle the risky parts (unknowns, new things, ...) first. Early steps should be set up to resolve doubt.

Management

    Management is about controlling costs, schedule, quality and functionality. Management is all about people. Learn people skills!

    You always need management. In small projects you need self management. Management has many facets. Here I cover: Complexity, Meetings, Success vs failure, Control, Configuration Management, Lists, and Reading.

    Complexity

    1. As a team grows the problem of controlling it grows as the square of the number of people.
    2. Complexity: O(number_of_parts^2)
    3. Handling more than half-a-dozen people directly reporting to you is a crazy making role.
    4. So you start to make a hierarchy, reports, paper work, ...

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

  1. For parts of management:
  2. Management = plan + organize + lead + control.

    Meetings

    1. A meeting must have a purpose. If not -- cancel it.
    2. Invite just the people who fit the purpose.
    3. Make sure they know what to bring. -- -- --(the deliverables)
    4. Plan the agenda, handouts, food, drink,...
    5. Organize the room. Boards, walls, equipment, ...
    6. Finish when purpose is achieved.
    7. Don't forget to schedule the next meeting (if any) at the end.
    8. Finish by making sure people know the "deliverables" -- what they bring to the next meeting.

    Success or Failure

    1. Success: All projects succeed (say the people who did them).
    2. More large projects fail (say the clients).

    3. Common reasons for failure
      • Business issues
      • Budget issues
      • Schedule issues
      • Mismatch between business goals and project deliveries: The tail wagging the dog. When technology drags the enterprise away from what it needs to succeed.
      • When requirements change faster than you can handle them, projects fail.
    4. Aim to grow software rather than create it in a single "big bang". If at all possible, plan to deliver big projects in small increments. Each is a working and high quality piece of the whole.
      1. Less risk, better estimates, better results and morale.
      2. Easier to meet client's needs in small safe steps.
      3. Aim for faster stakeholder feedback and making course correction. You do not drive to work with your eyes closed...
      4. Requirements are going to change. Don't forget to keep control of the flow of requirement changes. Most organizations/projects set up a "Change Control Board" -- -- --(CCB)
        to make sure that the most critical changes get through. Again think of this as part of a DFD.
      5. Do the risky requirements first.

    5. Do not treat system development as a manufacturing process. It is nearly always a research and development process. The first task is discover the questions you need answered, and answer them.

    Control

    1. No control without communication, and no communication without control (Patricia Botting's explanation of Cybernetics)
    2. Quality is improved by reviews, inspections, walkthroughs, etc.
    3. How do you communicate the artifact and the quality review information: paper, face-2-face, or Electronic?
    4. Fast feedback makes a big difference. "Captain: there is a big iceberg ahead!".
    5. Status Meetings. Can get ugly! Often boring. Stand up scrum meetings every morning are a modern alternative.
    6. Written Status Reports may help managers but they delay real work. Make sure the value is obvious.
    7. In all my projects (senior, intern, ind. study, or graduate) I ask for a short informal report: email, phone call, or meeting every week or every other week.

    8. Draw a DFD of your development process and check for smells.

    Controlling access to Artifacts

    With more than 4 or 5 people in a team working on the same artifacts -- especially code -- you need a system that stops two people modifying the same file in parallel. Without a control system the last person to save the artifact destroys all the work done by the rest of team. With a Control system only one person can work on a file at a time. People check out the the artifact, work on it, and the check it in.

    Version Control and Software Configuration Management

    With complex projects it becomes difficult to keep track of different versions -- especially when different programmers are working on different components/modules/classes at the same time. The moment you have more than 3 or 4 people working on a set of documents you need to stop two people working on the same version of an artifact at one time. You also need to control the different versions and different modules in your software. There several tools to help control this. Currently (2007) Subversion is the system of choice. But in the past UNIX users used RVS, SCCS, etc.
  3. SCM::="Software Configuration Management",

    Notice: you don't need a complex "Heavy weight" SCM system for simple projects with few people and small scopes. You need it for medium to large projects.

    Configuration management ( CM ) is needed from day one in a project of any realistic size. Each document or artifact has many versions and you need to know which one to use... For programs you can easily get into "DLL Hell" just because the user is using the wrong version of a library. Even DFDs, manuals, standards, and other types of documents will need SCM.

    In all SCM systems a strict regime is enforced. To work on an artifact you must:

    1. Check the current version out. You may have to wait for another person to check it in before you can do this.
    2. Make changes and make sure they are good.
    3. Check the artifact back in again (letting some one else work on it).

    Some SCM systems allow you create branching versions and integrate them into different versions of a growing system. Good SCM systems keep a log of all the activity in the controlled artifacts.

    Useful Lists for Managers

    1. Four_phases_for_managing_a_project::=following
      1. initiation
      2. planning
      3. executing
      4. closedown

    2. initiation::procedure=establish the following
      1. Select and brief an initiation team.
      2. Set up good relationships with customer/client.
      3. Create an initiation plan.
      4. Set up management procedures.
      5. Create the environment (physical and electronic).
      6. Launch the project workbook.

    3. SSR::form="System Service Request".

    4. work_book::artifact=following
      1. Overview
      2. Initiation plan and SSR
      3. Scope and risks
      4. Management procedures
      5. Data descriptions
      6. Processing description
      7. Team correspondence
      8. Statement of work
      9. Project schedule
      10. Online copies of definitions and diagrams

    5. planning::=following
      1. Establish scope, alternatives, feasibility
      2. Divide into manageable tasks
      3. Resources: estimates and plans
      4. Preliminary schedule
      5. Set up communications
      6. Define standards and procedures
      7. Identify and assess risks
      8. Preliminary budget
      9. Baseline project plan

    6. executing::=repeat following
      • Carry out baseline plan
      • Monitor Progress vs plan
      • Make changes to plan
      • Maintain the workbook
      • Communicate project Status

    7. closedown::procedure=following
      1. Close down project
      2. Post mortem review
      3. Close customer contract

    . . . . . . . . . ( end of section Useful Lists for Managers) <<Contents | End>>

    Readings on Management

    You won't be managing a team straight out of college! This course just touches on the high points. CSCI455 and/or CS655 (Software Engineering) go further. But before you get promoted to management you will need to learn more. An enormous number of books have been written on management. Some of these are about managing software development. Before you start your first project as manager please read the list of readings below. Some of these are available on line... but most are books you might want to have on the bookshelf in your office when you get promoted.

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

Questions

    Is there a point where the accumulation of new requirements add up to a new project

    Yes. I use the data models to spot additional requirements could be best tackled as a new project. Another trigger is the obsolescence of a part of the platform for a project. For example, the aging of our mainframe made it inevitable that we needed a replacement for the applications that run on it.

    What is a Change Control Board for

    It is a group of people who decide whether a requested change in a system is carried out, or delayed, or put with others into a special project, or thrown out.

    What is the most common reason for project failure.

    Size. There is a clear pattern in the literature (and the news) that shows larger projects failing more often than small ones. There is also the related problem that a project may not be given the resources that it needs for its size. This also leads to failure in many cases.

    Does removing people from a project speed up its development

    It depends on the person removed:-) More seriously: no. Brookes' Law is based on the time to train people in the domain and the software so far developed. Getting rid people does not "untrain" them. It wins no time.

Discussion topics

  • In how many ways is developing software like gardening?
  • In how many ways is developing software like a medical operation?

    Exercises on Critical Path Methods

    1. (CPM Exercise): Do a CPM on a given network.
    2. (Planning exercise): Given project description(in handout) of tasks and durations do a CPM.

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

    Online Resources

      Story -- How Fast can you build a house?

      The record is one day. [ 1042 ]

      Moral: Careful planning can save a lot time doing.

      Joke

      [ Hofstadter%27s_law ]

      Coding Horror -- Big Projects are different

      [ 000960.html ]

      Example Diagrams online


      (Gantt charts): [ Gantt_chart ] [ search?cat=img&cs=utf8&q=gantt+chart&rys=0&itag=crv ]

      Critical Path Method Online

      Look at this excellent description: [ Critical_path ]

      Another Example

      [ cpmEx.html ]

      Tools for project management

      Also see: [ List_of_project_management_software ]

      Scrum Meetings on Wikipedia

      See [ Scrum_%28development%29#Scrum_meetings ] or [ Craig Larnman ] below for details.

      Software Configuration Management on Wikipedia

      [ SCM ]

      What is the best way to estimate the time to develop software

      There are some standard techniques that are covered in CSCI455 (Software Engineering) -- See [ COCOMO ] and [ Function_point ] for more, they are not part of this course.

      All good methods are based on relevant previous experience and data plus breaking down the project into the parts.

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

    Further Reading on Management

      Fred Brookes -- the Mythical Man Month


        (MMM): the classic software engineering book [ The_Mythical_Man-Month ]

      Here some other good books, they may be out of date by the time you need them.

      Joel Henry

      1. Software Project Management -- A real-world guide to success
      2. Pearson 2004

      George Stepanek

      1. Software Project Secrets -- Why software Projects Fail
      2. Apress 2005
      3. Why and how to be agile, some unique techniques

      Craig Larman

      1. Agile and Iterative Development -- A Manager's Guide
      2. Addison Wesley 2004
      3. A good survey of the new methods.

      Frank P Ginac

      1. Creating High Performance Software Development Teams
      2. Prentice Hall PTR 2000
      3. The people side.

      Susan Snedecar

      1. How to Cheat at IT Project Management
      2. Publisher: Syngress Pub Date: September 2005 Print ISBN-10: 1-59749-037-7 Print ISBN-13: 978-1-59-749037-5 Pages: 416
      3. On Safari at [ 1597490377 ]

      Managing Projects with GNU make, 3rd Edition by Robert Mecklenburg

      1. Publisher: O'Reilly Pub Date: November 2004 ISBN: 0-596-00610-1 Pages: 320
      2. On Safari [ 0596006101 ]

      Do the Readings on Management make me an OK manager

      They are better than nothing. They inject some experience and know-how that will help. The main blockage to you being an OK manager in the long term, is your own personality. There are roughly 4 managerial types and all are OK when things are going well, but under stress they all have weaknesses. For example a "Benevolent Dictator" becomes a plain "Dictator" and the "Executive" type becomes a "Compromiser". This is from an author called Redding...

      And this is something you must work on after this class.

    . . . . . . . . . ( end of section Further Reading on Management) <<Contents | End>>

    Review Questions

    1. Example for you: How do you make coffee? Draw up a WBS and a activity diagram.
    2. Define: activity, predecessor, critical path,
    3. What is Brooke's Law? Why is it important?
    4. Draw a sketch of a small Gantt chart.
    5. Draw a sketch of a small CPM graph using the UML activity diagram.

      Simple Example

      You and a colleague are working on a project that has a main program and two independent classes. Once the initial test program is written you can start on the two classes (A and B say) and develop them without tripping over each other. Once the two classes have passed unit test then you can start on the main program that depends on them.
      Table
      #DescriptionDuration(Days)Predecessors
      1Develop test1-
      2Develop A11
      3Develop B21
      4Develop Main12,3
      -Done-4

      (Close Table)

      A JAD Meeting

      Before you can start a Joint Application Development -- -- --(JAD)
      meeting you must Email the participants and prepare the Audio Visual aids -- -- --(AVs)
      and before you can send the Email you need to prepare the information in the Email and arrange the room. You can't prepare the information or the AVs without preparing the agenda for the meeting. Before you arrange the room and prepare the agenda you need to get approval for the JAD meeting from the participants. And before you can get approval you need to make contact with the participants.

      Here is a table of activities. What numbers do you put in the "Predecessors" column:
      Table
      #DescriptionDuration(Hours)Predecessors
      1Contact people1?
      2Get approval5?
      3Arrange Room4?
      4Prepare Agenda11?
      5Prepare Info4?
      6Prepare AVs8?
      7Email people1?
      8Hold JAD session5?
      -Done-8

      (Close Table)
      Draw an Activity Diagram of the above activities. Calculate the earliest times of each event. Calculate the latest times of each event. Calculate slack and highlight the critical path.

      My First PHP Page

      I wanted to allow students to search my CS372 pages. To do this I needed an HTML form and a PHP script. Problem: I didn't know any PHP. Here are my activities for the first 3 iterations.
      Table
      #DescriptionDuration(Hours)Predecessors
      1Design Search form1-
      2Learn some PHP2-
      3Draft PHP12
      4Alpha test11,3
      5Improve form14
      6Improve PHP24
      7Beta test15,6
      8Release 1.017
      9Learn PHP RegExs22
      10Update PHP28,9
      11Update form & test110
      -Release 2.0-11

      (Close Table)
      Use UML Activity diagrams and the critical path method to work out how much time this project will take and which activities are critical.

      Setting up a Seminar

      The seminar committee has a lot of activities it must do to prepare for a seminar. How much lead time and what activities are critical?
      Table
      #DescriptionDuration(Hours)Predecessors
      1Find time+place2-
      2Book room11
      3Get Snacks21
      4Get coffee11
      5Draft flier22
      6Put on Dept Events Board12
      7Check Fleer15
      8Post Flier26,7
      9Email Flier16,7
      10Prep Handout10-
      11Order Equip11
      12Prep AVs610
      13Check equipment111
      -Done-3,4,8,9,10,12,13

      (Close Table)
      Use an activity diagram to check the above table for logical errors. Correct and use the Critical Path Method to work out the earliest time the seminar can be ready. Then work out the latest times and the critical path.

      Review Management

    6. How do you start a complex project? What things must you set up?
    7. What is Configuration Management?
    8. How do set up a meeting?
    9. What is Brookes's Law and what does it mean?

    . . . . . . . . . ( end of section Review Questions) <<Contents | End>>

    Typical Quiz on Critical Path Methods

    Demonstrate doing CPM
    1. Given a list of tasks with durations and prerequisites:
      1. draw a CPM network(5 pts).
      2. calculate the earliest start and finish times(4 pts).
      3. calculate the latest finish and start times(4 pts).
      4. highlight the critical path(2 pts).
      5. errors in arithmetic (-1 pt each).


    . . . . . . . . . ( end of section Project Planning and Management) <<Contents | End>>

    Abbreviations

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

    Links

    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/ ]

    End