This page is for working an information kit to assist Professional Computing students who are working on their first project.

Structure

What structure will it have? What sections will it have?

• Tabbed Indexes (Group Meeting Essentials, Client Meeting Essentials)

Content

• Unit Goals
  • At the first meeting, ask everyone what mark they want from the unit and how much effort they're realistically willing to put in.
  • Make sure everyone agrees on the amount of work to be put in.
• Effective Meeting Techniques
  • Each meeting has:
    • An agenda: things that need to be discussed. This helps to keep everyone on track.
    • A time limit: Ensures that you don't waste time talking about non-pc307 stuff.
    • A list of action items: Things that the meeting attendees need to do before the next meeting, worked out during the meeting.
    • Minutes: A record of what happened at the meeting for reference and anyone who was absent.
  • Nominate a chair for the meeting. This person will bring up items on the agenda and lead the meeting. Make sure this isn't someone that goes off into tangential topics which aren't related to the project.
  • Nominate a secretary, preferably someone that won't be a major participant in the meeting. This person will record the minutes.
  • Make sure the minutes are sent out very soon after the meeting.
  • Ensure that you set a time for the next meeting at the end of the meeting.
  • The chair should send out a reminder about meetings the day before the meeting.
  • Meeting time is incredibly time expensive. If possible, only have related people at each meeting.
• Effective Time Management
• Team Skills Analysis
  • If one person is good at everything, make them the review person. Have other team members prepare the deliverables.
• Team Roles
  • There will always be overlap in roles, but at least nominate people to generally be one of these so someone is responsible for each role:
    • Project Manager: Oversees the project as a whole. Pick the most organised person in the group to do this.
    • Programmers: Cuts code.
    • Testers: Tests the programmer's code.
    • Documenters: Generates doco for the system.
    • Reviewers; Checks that code and doco are of sufficient quality.
• Project Leader Responsibilities
  • Unbiased Delegation of Work
  • Time chit tracking
  • Setting Short and Long Term Goals
  • Adjusting the Goal datelines in accordance to man-hours remaining and Deliverable dates
  • Making Decisions
  • Motivating your team
• Practicing Professionalism in Meeting Clients
  • Synchronized Dress Code
  • Recording Minutes
  • Voice Recording of the meeting if possible so that absent team members can listen to the session
  • Appointment Scheduling
• A schedule of major events Deliverable A, B, C, D
• A checklist of things to ask the client.
• Distribution of tasks amongst members.
• Forms templates (testing procedure template, timesheet template, use case templates)
  • Timesheet template
    • Timesheets should be simple.
    • Each timesheet entry should have:
      • Person's name
      • Amount of time used (in hours, any further granularity is not worth the hassle)
      • Task that was undertaken
  • Testing template
    • Each test should have:
      • Test Specification: what is the purpose of this test
      • Test Description
        • Means of control: How will the test proceed? Will someone need to manually enter data, is the test automated?
        • Basic flow: A numbered sequence of events for the test
        • Alternative flows: What other flows are allowed?
        • Relation to use cases.
        • Test cases, each having:
          • Scenario: Which scenario the case relates to
          • Input data
          • Input commands
          • Expected output
          • System messages produced
• Suggested headings for Documents:
  • Software Project Management Plan (write this before anything else and distribute it to the team so they know what's going on)
    • Project Overview
    • Project Deliverables
    • Project Organisation
      • Task breakdown: split up each component into tasks.
      • Time estimates: estimate the duration of each task.
      • Task descriptions: describe each task
        • Progress: How will we track what percentage is complete?
    • Requirements Analysis and Engineering
      • Elicitation from the client
      • Conducting requirements analysis and getting specifics
      • Prototyping GUIs: will this help the client to understand their requirements?
      • Prototyping software that the team has less experience developing
      • Researching technologies the team doesn't have experience with
      • Client review of Requirements Document
      • Revision of Requirements Document
      • Absolute deadline for requirements analysis
    • System Design
      • Define Use Case descriptions: what will the system do?
      • Define Dynamic models: interactions between systems
      • Define Acceptance Tests: how do we know that we've done the right thing?
      • How will the client review the system design (eg. does the client understand UML? will the design be presented in stories?)
      • Define data persistence layers: how will data be stored?
      • Absolute deadline for system design
    • Implementation
      • List the components that will be implemented and their dependencies.
      • Unit Testing: Will this be done? What test harnesses will be used? Will methodologies like XP or TDD be used?
      • System integration: How will this be achieved? What interfaces exist between systems?
    • Testing
      • How will the system be tested?
      • What resources are required for testing?
      • How long will testing take?
    • Documentation
      • How does the system need to be documented? Does it need to be documented?
    • Wrap up
      • Compilation of timesheets, meeting minutes.
    • Time chart / Gantt chart
      • A visual representation of how the project will progress.
  • Requirements document:
    • General goals
    • Current system
    • Proposed system
    • Overview
    • Functional Requirements
    • Non-Functional Requirements
    • Constraints
  • System Design Document
    • Scenarios
    • Use Cases
    • Object Models
    • Class Models
    • Dynamic Models
    • Sequence Diagrams
    • Screen mockups
    • Reuse: Does this project reuse any existing software? Eg. Open source software, commercial libraries.
    • Prototypes: Will there be any prototyping of user interfaces?
  • Test Manual
    • Objectives
      • Summary of tests (what is being tested, what is not)
      • Testing strategy (how will testing proceed: by scenario, by component, by order of completion)
      • Test materials and equipment: what is necessary to perform testing.
      • Testing template: Describe the standard template that all test cases will follow.
      • Test specification: Using the template, show how each scenario will be tested.
      • Test analysis and report: Results of testing and discussion of the results.
• Risk management: How to identify risks, how to manage risks.
  • At least make note of the following. Some possible mitigation strategies are listed, but think of your own as well:
    • Lack of knowledge
      • Eg. Insufficient knowledge of Javascript. Assigned team member A to research topic and write up a short syntax guideline for other members.
      • Eg. Insufficient knowledge about project management. Team leader will read a book on software project management.
      • Eg. Group has not worked together as a team before. Weekly meetings will be held until the team is more comfortable with progress.
    • Resource risks
      • Eg. Team member falls sick. Team members will ensure to update documentation and use CVS so everyone has all files. Pair programming will be used to ensure more than one person understands the code in the system.
      • Eg. Team member is hit by a bus. Probability is low so risk is accepted.
      • Eg. Team member drops the unit. Team members leaving will be expected to notify the remainder of the team and hand over their tasks.
      • Eg. Unable to use CS resources due to honours students running MPI Matlab on all of the computers during the day. Handle this risk by complaining to unit coordinator.
    • Time constraints
      • Eg. Insufficient time to complete all requirements. Requirements will be prioritised so the client still obtains utility from the software even though not all requirements are completed.
      • Eg. Team members have a heavy workload towards the end of semester. Project will be front-end-loaded with the majority of work to be completed before assignments are due.
    • Quality constraints
      • Eg. Insufficient time for testing as final code will not be integrated until quite late in the semester. Split project up into components and develop as much in parallel as possible with separate test harnesses for each component. Testers can then test individual components prior to full integration of the system.