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. It’s hard to tell your boss/supervisor that it can’t 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. Don’t 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 don’t 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?