1. Project Management Chapter 5, PG 92

2. Introduction Why is software management particularly difficult?  The product is intangible Cannot be seen or touched Managers cannot see progress  There are no standard software processes Processes vary drastically between different organizations  Large software projects are often “one-off” projects Changing technology can make managements experience obsolete Lessons learned are not always transferable to new projects

3. Management Activities Proposal writing Project Planning and Scheduling Project Cost Project Monitoring and Reviewing Personnel Selection and Evaluation Report Writing and Presentations

4. Management Activities (cont’d) Settling for a less-than-ideal staff  Project budget may not cover the use of highly paid staff  Staff with appropriate experience may already be assigned to other projects  Inexperienced staff may be assigned to a project to lean and gain experience

5. Project Planning Pseudo-code for the project planning process Establish the project constraints Make initial assessments of the project parameters Define project milestones and deliverables While project has not been completed or cancelled Loop draw up project schedule initiate activities according to schedule wait ( for a while) review project progress revise estimates of project parameters update the project schedule renegotiate project constraints and deliverables If (problems arise) Then initiate technical review and possible revision End If End Loop

6. Project Plan Has the following parts:  Introduction  Project Organization  Risk Analysis  Hardware and Software Resource Requirements  Work Breakdown  Project Schedule  Monitoring and Reporting Mechanisms

7. Project Planning - Introduction The Introduction should provide a brief description of the objectives of the project It will also set out constraints  Time  Budget  Technology  Others?

8. Project Plan – Project Organization This area describes the way in which the development team is organized, the people involved, and their roles in the team Things to consider  Team Structure Democratic Chief Programmer Model Modified Chief Programmer Hierarchical Model Others?

9. Project Plan – Risk Analysis Describes possible project risks, likelihood of occurring, and possible ways to mitigate Possible risks  Staff turnover  Management change  Hardware unavailability  Requirements change  Specification delays  Size underestimate  CASE tool underperformance  Technology change  Product competition

10. Project Plan – Risk Analysis (cont’d) Possible Risk Types  Technology Database cannot process enough requests as originally thought  People Illnesses, training for staff not available  Organizational Restructured organization, new management over project  Tools CASE Tools cannot be integrated, perform inefficiently  Requirements Changes to requirements  Estimation Time required to complete and early activity is extended or deadlines not met

11. Project Plan – HW/SW Resource Requirements Specifies HW and support SW required to carry out the development Possibilities  Viso  Visual Studio  Dia  Compiling programs  CASE TOOLS

12. Project Plan – Work Breakdown Sets out the breakdown of the project into activities and identifies milestones and deliverables with each activity Milestone  It might be a module  Or a subsystem Deliverables  What all needs delivered to the client, upper- level management, etc.

13. Project Plan – Project Schedule This shows the dependencies between activities, estimated time for each, and person responsible for activity Example:  Requirements Elicitation  Requirements Definitions  Requirements Specification

14. Project Plan – Monitoring and Reporting Mechanisms Defines management reports that should be produced, when they should be produces, and project monitoring mechanisms used Example:  Weekly report of progress to manager  Check list of completed functionality

15. Project Plan Template Due: February 1, 2007 11:00AM

16. Requirements Elicitation

17. Why is it important? What possible problems could arise?

18. Requirements Elicitation - Rules Should provide a list of questions 24 -72 hours in advance  This helps the client have time to be prepared for the questions going to be asked and will speed up the process No session should last more than 30-60 minutes  After this timeframe, the clients attention is lost Should provide a summary of the meeting within 24-72 hours after the meeting has taken place  While fresh in everyone’s mind, problems or discrepancies between what was said by the client and what was heard by the developers can probably be cleared up quickly

19. Exercise

20. Brainstorm on Coliseum Management System Focus on:  Scheduling  Concessions  Workers

21. Coliseum Management System Now lets come up with questions we might ask a client that has asked us to develop this system.

22. Security During the Design Phases

23. Security Problems What are some ways to ensure security in a system? What are the main principles we are trying to accomplish with security?

24. Security Confidentiality Integrity Availability

25. Security How can these items be addresses during design? What are common security issues you see in systems you use everyday? Are there ways to document in a design security concerns or issues?