Schedule to end of semester

1
Schedule to end of semester

• Formal Project presentations will be on Mon, May
  1 and Wed, May 3. All teams will make
  presentations on both days.
• Presentations will be 10-15 min per team.
• The first presentation will be on Project
  Definition and project requirements and
  specifications.
• The second presentation will be on Planning,
  scheduling, analysis and design.
• The project does not include Construction and
  Deployment.

2
Final Project Presentation

• Your web presentation will be the form for
  submitting your presentation. No paper copy is
  required.
• But the web presentation should be in a format
  somewhat amenable to printing a copy if needed.
  It could be a sequence of MS Word pages.
• Front or home page should have links to any of
  the sections in the report.
• You may want to use a rough prototype or sample
  screen, etc., to show system?

3
Final Project Presentation

• A good project presentation would be one that
  clearly defines the project and how it will be
  developed and deployed.
• It would be ready, if approved, to move to
  coding, development and testing.
• All members of a team should participate in
  presentation. And all members should be prepared
  to answer questions about project.
• Sell your project. Treat this as something you
  want to be accepted or purchased! Enthusiasm.

4
Software Project Scheduling

• Nobody has a worse reputation for delivering late
  or missing deadlines than software development.
• Schedules are often generated by when the
  customer wants it and not by any realistic
  estimate of when it can be finished.
• Its hard to tell your boss/supervisor that it
  cant be done in the time span given by the boss.
• Schedules are generated as if everything will go
  smoothly with no special problems.

5
Software Project Scheduling

• Be wary of items over which you have no control.
  Dont trust outside vendors to deliver as
  promised for SW or HW.
• Always get as much cushion as possible. You will
  never get criticized for delivering early but
  late delivery can get you fired.
• The list of things that can cause delays is
  nearly endless while the list of things that can
  speed things up is very short.

6
Change Management

• Often call software maintenance.
• Often delegated to newest people when it is often
  considered the most difficult of jobs.
• Older veteran people dont like software
  maintenance. They use their seniority to get the
  new projects and leave maintenance to new people.
• Too often, change is a reaction to a problem or
  crisis. Nobody saw the situation coming.
• Remember Y2K everybody saw it coming!

7
Change Management

• You may be working on code that has been changed
  several times before.
• It can be very hard to follow with all the
  changes. People comment out old code, insert
  undocumented subroutines, etc.
• Have you ever tried to help a friend debug their
  program? And did you secretly wonder why they
  took what seems like such a strange approach?