Notes for 12/16/08

• Summary of Issues
•  Adding to Agenda
• Add to beginning of Agenda: Working update
• Like 10 second summary
• Changes to schedule
• Project Plan Document
  • Remove redundancy with Risk Management Section
  • Add Requirements to each increment
  • Mention That releases are by priority
    • Should be releasable before starting next increment
• Add detail to the info at each bullet in increments
• Give definitions to terms
• Major Tasks
• Completion Requirements
• RIT’s deliverables
• Under Requirements
• Add more specifications
• Add definitions about business requirements, functional requirements
• Talk about where in the phase they are done (at first phase or so)
• More info is better, what these documents are
• What is to be included in Schedule Document
• Tasks to complete when they are do
• What Paetec requires
• What RIT requires
• We have two Risk management leads
• Joe should be Configuration Management lead
•  Add small description to accompany Work Breakdown Structure  Visio image
• Add smaller tasks as bullets
• Image is very big (narrow down)
• Add outline
• Microsoft project may not be compatible with Erika’s version
• Look into reader
• Look to send Erika a “demo” to see if compatable
• Add to artifacts
  • Release notes
  • Most mortem
  • Technical report
  • Deployment
• Decisions
  •  For Document keep in mind an uninformed audience
• Add who is developing what when information is available
• For Estimate we are doing three point as supposed to one point
• Lump some tasks together
• Put Meeting times under the time section
• Meeting with Paetec
• Meeting with Ourselves
• Meeting with Nate
• Beef up testing plan  (Move it up to earlier)
  • Add definiton to specify that quality and testing are same, as well as someone to make sure we follow process
• Concurrency is less of an issue
• May need a case for a read , but not not two editing at once
• Design start as web app and this way if we need to revert to desktop it could be easy 
  • Decide UI to be light and could go either way.
  • This way if we have a strong engine and a light UI the UI can be dropped later.
• Business requirements don’t specify how software works
  • Example: user can input this data
  • It is High-level information. Input can be on piece of paper or computer
  • Think as hierarchy: Business requirements first, then software, These BR can be reviewed by non it majors
• Anything in a use case there is no need for textual desktops
  • Blue print functional requirements are use cases ( can have sub cases) They are functional requirements. No need for text based (for functional ones)
  • Non functional will still need to be text passed,
• Basic Requirement Document
  • Use Case 9 will need to be greatly changed and refined.
• Groups for business
  • Products each could have versions
  • Might have a catalog v1 that was v1 for all
  • Catalog 2 could have one v2 and the rest as v1
    • At anytime they no they are selling these products with this definition
• Catalog contains all products and definitions
• Exporting croup low priority
• Design candidates
  • UI toolkit/Format if we have a major idea document what we went with and why we didn’t go with others.
• Action Items (w/ person responsible and dues dates)
  • Finish project Plan (remove all TBDs)
    • Who everybody
    • Due Friday
  • Create Sample in Microsoft Project
    • Who: Rob
    • Due Tonight/early tomorrow
  • Send Erika and Neil Project Plan doc Friday morning/Thursday evening