CMSC 345 Project Planning

Customer’s Perspective Do you understand my problem? Can you develop and deliver a system that will solve my problem? How long will it take? How much will it cost?

Project Deliverables Documents Demonstration of function Demonstration of subsystems Demonstration of accuracy Demonstration of extra-functional properties: reliability, security, performance, etc. Milestone = end of activity producing deliverable

Project Schedule Derived from deliverables Phases or stages of project Break into discrete activities that produce deliverables Estimate time each activity will take Estimate number (and skills) of developers needed to complete each activity Estimate other resources required for each activity Timeline for activity begin/end and corresponding delivery

PROJECT PHASE 1 ACTIVITY 1.1 ACTIVITY 1.2 ACTIVITY 1.3 : PHASE 2 PHASE n STEP 1 STEP 2 : STEP 1 STEP 2 : STEP 1 STEP 2 : ACTIVITY 2.1 ACTIVITY 2.2 ACTIVITY 3.3 :

Work Breakdown Structure Depicts project as set of discrete pieces of work Customer can be informed which activities are in progress and which milestones have been achieved Does not show interdependencies and possible parallelism of work units

Build communications softwareSystem planning (1.0) Coding (3.0) Testing(4.0)Delivery (5.0) Top-level design (2.1)Prototyping (2.2)User interface (2.3)Detailed design (2.4)System design (2.0)Review specification(1.1)Review budget (1.2)Review schedule(1.3)Develop plan (1.4)

Activity Definition Precursor: events that must occur before activity can begin Duration: length of time to complete activity (estimated) Due date: date when activity must be completed (e.g., contractual deadline) Endpoint: milestone and/or deliverable

Activity Graph Depicts dependencies among activities Nodes are project milestones Directed edges are activities involved in producing those milestones Shows what can be done simultaneously (assuming sufficient personnel) Depend on understanding of parallel nature of tasks. If work cannot be done in parallel, the (mostly straight) graph is not useful

Milestones in Building a House 1.1 Survey complete 1.2 Permits issued 1.3 Excavation complete 1.4 Materials on hand 2.1 Foundations laid 2.2 Outside walls complete 2.3 Exterior plumbing complete 2.4 Exterior electrical work complete 2.5 Exterior siding complete 2.6 Exterior painting done 2.7 Exterior doors and fixtures mounted 2.8 Roof complete 3.1 Interior plumbing done 3.2 Interior electrical work complete 3.3 Wallboard in place 3.4 Interior painting done 3.5 Floor covering laid 3.6 Interior doors and fixtures mounted

START FINISH Surveying Request permits Excavation Buy materials Lay foundation Build outside wall Install interior plumbing Install interior electrical Install wallboard Paint interior Install interior doors and fixtures Install flooring Install roofing Install exterior plumbing Install exterior electrical Install exterior siding Paint exterior Install exterior doors and fixtures

START FINISH

Project Personnel Differences Ability to perform the work Interest in the work Experience with similar applications Experience with similar tools or languages Experience with similar techniques Experience with similar development environment Training Ability to communicate with others Ability to share responsibility with others Management skills

Two people1 line of communication Three people Four people Five people 3 lines of communication 6 lines of communication 10 lines of communication : n people n(n-1)/2 lines of communication

Meetings – Ugh! Purpose of meeting unclear Attendees unprepared Essential people absent or late Conversation veers away from purpose Some meeting participants argue, dominate, or do not participate Decisions made not enacted afterwards

Productive Meetings Clarify who should attend, when start and end, and what accomplish Written agenda distributed in advance Moderator to keep discussion on track and resolve conflicts Recorder records each action item and ensures it is done Minimize number of meetings and number of participants

Work Style Components The way your thoughts are communicated and ideas gathered Extrovert – tell others your thoughts Introvert – ask for suggestions The degree to which emotions affect decisions Intuitive – base decisions on feelings Rational – examine facts; consider options

INTUITIVE RATIONAL INTROVERT EXTROVERT INTUITIVE INTROVERT: Asks others Acknowledges feelings INTUITIVE EXTROVERT: Tells others Acknowledges feelings RATIONAL INTROVERT: Asks others Decides logically RATIONAL EXTROVERT: Tells others Decides logically

Work Styles Rational extrovert: judges colleagues by results produced, efficiency is priority, good at making sound decisions quickly Rational introvert: judges peers by busyness, accurate and thorough, gathers all information on subject

Work Styles (2) Intuitive extrovert: follows feelings (professional judgment), assertive, creative, enjoys interaction Intuitive introvert: sensitive, good listener, wants to make the right decision, examines relational dependencies and emotions

Implications of Work Styles Determine communication styles Understanding work styles can help you be flexible in dealing with others Choice of workers for a task Intuitive may prefer design & development (requiring new ideas) Rational may prefer maintenance (analysis and attention to detail)

Project Organization Project organization based on Backgrounds and work styles of members Number of members Management styles of customers and developers Flexibility of team members

Chief Programmer Team Chief: totally responsible for design and development, supervises all others, does all design, assigns programming to others Understudy: substitutes for chief when necessary Librarian: maintains documentation, compiles and links code, performs preliminary testing as code submitted Hierarchy minimizes communication

Chief programmer Assistant chief programmer Test teamAdministrationLibrarianSenior programmers Junior programmers

Egoless Approach Everyone held equally responsible Criticism of process or product, but not people involved Democratic - members vote on decisions

Risks Unwanted event with negative consequences Risk impact: loss (of time, quality, money, control, understanding, etc.) associated with event Risk probability: likelihood that event will occur Risk control: ability to change outcome (minimize or avoid impact) Risk exposure: impact * probability, must be tracked over time Major risk sources: Generic – common to all software projects Project-specific – threats for this project

Risk Reduction Strategies for risk reduction Avoid the risk Transfer the risk Assume the risk

Boehm’s Top 10 Risks 1. Personnel shortfalls – top talent, morale, team building 2. Unrealistic schedules and budgets – design to schedule, incremental development, requirements scrubbing 3. Developing the wrong software functions – organizational analysis, prototyping, early user’s manuals 4. Developing the wrong user interface – prototyping, scenarios (use cases) 5. Gold plating – cost-benefit analysis, design to cost

Boehm’s Risks (cont’d) 6. Continuing stream of requirements changes – high change threshold, incremental development 7. Shortfalls in externally performed tasks – preaward audits, competitive design 8. Shortfalls in externally furnished components – inspections, compatibility analysis 9. Real-time performance shortfalls – simulation, instrumentation, tuning, modeling 10. Straining computer science capabilities – technical analysis, prototyping