Organization of Software Projects

Organization of Software Projects

Why care about software project organization? A study shows that only 10% of projects were successful between 1998 and 2004 Delays in final product delivery Cost over-runs Inappropriate Scheduling

Project Organization 4 Ps People the most important element of a successful project Product the software to be built Process the set of framework activities and software engineering tasks to get the job done Project all work required to make the proposed product a reality

Key Knowledge Areas for Project Organization Project (integration) management Scope Time Cost Quality Human resource Communications Risk Procurement

Trade-off Triangle Fast, cheap, good. Choose two. Know which of these are fixed & variable for every project

People as Stakeholders Senior managers who define the business issues that often have significant influence on the project. Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work. Practitioners who deliver the technical skills that are necessary to engineer a product or application; often make poor team leaders Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. End-users who interact with the software once it is released for production use. Key requirement in an architect's job is to organize and bring value from these people

Architect Role as a leader The MOI Model Motivation - The ability to encourage (by push or pull ) technical people to produce to their best ability. Organization - The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. Ideas (or Innovation) - The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.

Role as a leader Make sure the following activities happen Formal risk management Empirical cost and schedule estimation Metrics-based project management Tracking amount of work done, costs, work remaining, etc Defect tracking against quality targets People aware project management

Understanding the Problem At the beginning you should ask yourself these questions Why is the system being developed? What will be done? When will it be accomplished? Who is responsible? Where are they organizationally located? Barry Boehm How will the job be done technically and managerially? How much of each resource (e.g., people, software, tools, database Which?) will be needed?

Define success and failure Don t lie to yourself! An ethical issue,!se. Be confident, trust yourself for success! Quantify your project outcomes to allow success or failure A vague or un-measurable outcome is much less helpful Scheduling One of the most important things you can do is schedule. Also one of the first things you should do! Few Tools - OpenProj.org, Edraw Max etc.

Planning Time is the key resource requires carefully managing it. You must begin planning immediately Given limited information - Plan anyway and then revise. Major step Creating a plan.

Creating a plan: Things to know Software Project Scope Context - How does the software to be built fit into a larger system, product, or business context and what constraints are imposed as a result of the context? Information objectives - What customer-visible data objects are produced as output from the software? What data objects are required for input? Function and performance - What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed? Software project scope must be unambiguous and understandable at the management and technical levels.

Creating a plan: Things to do Problem Decomposition: Sometimes called partitioning or problem elaboration Once scope is defined It is decomposed into constituent functions It is decomposed into user-visible data objects or It is decomposed into a set of problem classes Decomposition process continues until all functions or problem classes have been defined.

Schedule List of tasks With dates With assigned resources (people) With durations (expected time) With predecessors and successors How do you get buy-in (e.g., commitment) from the team for a schedule? History - Use historical data from past projects Increments track progress

Scheduling Rules of Thumb One person should always edit the schedule If you have two people that need to, create a mechanism to link them together. Keep it simple and useful Level your resources Share the schedule with your team 40-20-40; coding is 20% of the effort

Scheduling Steps Add in all the tasks (preferably in a hierarchy) Add in all the dependencies Break down large tasks into smaller tasks. Optimally (one possible opinion) you want to schedule so the duration of each smallest task is at most 3-5 days Assign people (resources) to tasks Level your resources

Schedule Terms Critical path Any activity on the critical path that is delayed in completion, delays the entire project. Activities not on the critical path contain slack time and allow the project manager some flexibility in scheduling. Longest sequence (in terms of time) of activities in a project. Slack time Amount of time a task can be delayed without affecting the overall completion date. Start slack - amount before task needs to start Finish slack - amount before task needs to finish Milestone - An import date in the schedule Dependencies - relationship between tasks

Schedule Dependencies FS - Finish to start (most common) A FS B. B doesn t start until A is finished Build wall FS Paint wall FF - Finish to finish A FF B. B doesn t finish before A is finished Write final chapter FF Complete Index SS - Start to start A SS B. B doesn t start until A has started Project funded SS Project activities begin SF - Start to finish (Not often used) A SF B. B doesn t finish before A has started Once A starts, B is allowed to finish. StartB triggers StopA. Study for exam SF Write exam

Resource Leveling A process to examine a project for an unbalanced use of people and to resolve over-allocations or conflicts Happens when multiple tasks are scheduled at the same time for the same person Solution: Make tasks sequential by introducing fake dependencies Split resource usage among tasks (50% on task 1, 50% on task 2)

PERT/CPM Charts Time-scale Charts

Project Evaluation and Review Technique (PERT) A PERT chart is a graphical representation of a project s schedule. Used as a project management tool. Used in planning and tracking software projects. It shows sequence of tasks, which tasks can be performed What it is? When to use it? simultaneously, and critical path of tasks that must be completed on time in order for project to meet its completion deadline. The chart can be constructed with a variety of attributes, such as earliest and latest start times for each task, earliest and latest finish times for each task, and slack time between tasks. It can document an entire project or a key phase of a project. Benefits: The chart allows a team to avoid unrealistic timetables and schedule expectations, To help identify and shorten tasks that are bottlenecks, and to focus attention on most critical tasks.

Process to construct PERT charts Identify all tasks or project components. Make sure the team includes people with first hand knowledge of the project so that during the brainstorming session all component tasks needed to complete the project are captured. Document the list of tasks. Identify the first task that must be completed. Place the appropriate task at the extreme left of the chart. Identify other tasks that can be started along with task #1. Align these tasks either above or below task #1 on the chart. Identify the next task that must be completed. Select a task that must wait to begin until task #1(or a task that starts simultaneously with task #1) is completed. Place the appropriate next task to the right of the preceding task. Identify other tasks that can be started along with task #2. Align these tasks either above or below task #2 on the chart. Continue this process until all component tasks are sequenced.

Process to construct PERT charts cont d Identify task durations. Using the knowledge of team members, reach a consensus on the most likely amount of time each task will require for completion. Document this time for each task. Use this information to construct the PERT chart. Number each task, draw connecting arrows, and add task characteristics such as duration, anticipated start time, and anticipated end time. Determine the critical path. The project s critical path includes those tasks that must be started or completed on time to avoid delays to the total project. Critical paths are typically displayed in red.

Computing ES Critical Path Draw a network diagram of activities ES - earliest time the activity can start Determine the Early Start (ES) of each node. Work from beginning node (ES=0) to final node ESNode = Max(ESPrevNode + DurationPrevNode) ES: 4 ES: 2 A B 7 10 ES: 12?? C Compute ES(C) ES(A)+dur(A) = 4 + 7 = 11 ES(B)+dur(B) = 2 + 10 = 12 Maximum (11,12) = 12 = ES(C)

Computing LS Critical Path Determine the Late Start (LS) of each node. LS:? LS:? A B Work from the final node to the beginning node. The latest time the activity can start without changing the end date of the project LSNode = MIN(LSNextNode - DurationPrevNode) Remember: For the last node LS = ES 7 10 LS: 12 Compute LS(A), LS(B) LS(C) - dur(a) = 12-7 = 5 = LS(A) LS(C) - dur(b) = 12-10 = 2 = LS(B) C LS:? A 7 7 LS: 13 B LS: 12 C Compute LS(A) LS(B) - dur(a) = 13-7 = 6 LS(C) - dur(a) = 12-7 = 5 Min(6,5) = 5 = LS(A)

Example Project Specification Activity Description Predecessor Duration A Product design (None) 5 months B Market research (None) 1 C Production analysis A 2 D Product model A 3 E Sales brochure A 2 F Cost analysis C 3 G Product testing D 4 H Sales training B, E 2 I Pricing H 1 J Project report F, G, I 1

Example Node Network ES:0 LS: A ES:0 LS: B ES:5 LS: C ES:5 LS: D ES:5 LS: Compute ES(H) ES(E)+dur(E) = 5 + 2 = 7 ES(B)+dur(B) = 0 + 1 = 1 Maximum = 7 = ES(H) E H ES:7 LS: ES:7 LS: F G ES:8 LS: I ES:9 LS: Compute ES(J) ES(F) + dur(f) =? ES(G) + dur(g) =? ES(I) + dur(i) =? Maximum =? = ES(J) ES:12 LS: J Activity Description Predecessor Duration A Product design (None) 5 months B Market research (None) 1 C Production A 2 D Product model A 3 E Sales brochure A 2 F Cost analysis C 3 G Product testing D 4 H Sales training B, E 2 I Pricing H 1 J Project report F, G, I 1

Compute LS(A) LS(C) dur(a) = 7 5 = 2 LS(D) dur(a) = 5 5 = 0 LS(E) dur(a) = 7 5 = 2 Min(2,0,2) = 0 = LS(A) ES:0 LS:0 A ES:0 LS:8 B ES:5 LS:7 C ES:5 LS:5 D ES:5 LS:7 E Example Node Network H ES:7 LS:9 ES:7 LS:9 F G ES:8 LS:8 I ES:9 LS:11 Compute LS(F) LS(J)-dur(F) = 12 3 = 9 ES:12 LS:12 J Activity Description Predecessor Duration A Product design (None) 5 months B Market research (None) 1 C Production A 2 D Product model A 3 E Sales brochure A 2 F Cost analysis C 3 G Product testing D 4 H Sales training B, E 2 I Pricing H 1 J Project report F, G, I 1

Example Node Network Paths ACFJ = 11 ADGJ = 13 AEHIJ = 11 BHIJ = 5 ES:0 LS:0 A ES:0 LS:8 B The Critical Path ES:5 LS:7 C ES:5 LS:5 D ES:5 LS:7 E H ES:7 LS:9 ES:7 LS:9 F G ES:8 LS:8 I ES:9 LS:11 ES:12 LS:12 J Activity Description Predecessor Duration A Product design (None) 5 months B Market research (None) 1 C Production A 2 D Product model A 3 E Sales brochure A 2 F Cost analysis C 3 G Product testing D 4 H Sales training B, E 2 I Pricing H 1 J Project report F, G, I 1

Game Development Exercise Find the critical path using the PERT chart. TASK DURATION (days) A Graphics Engine 14 PREDECESSORs - B Sound Engine 5 I C Music Engine 5 J D Input Engine 10 A E Gameplay/general programming 31 B, C, D F Physics 7 E G 2D Artwork 14 - H 3D Artwork 21 G I Sound Effects 14 - J Music 9 - K Level Design 21 F, H

Time-scale Charts TASKS A Study current email system B Define end-user requirements C Design Class diagram D Acquire computer technology E Plan & code email modules F Acceptance test new system G Deliver new system 1 2 3 4 5 6 7 8 9 10 11 12 Today Questions: From the above, can you guess: Which, if any, tasks should have been completed by today and aren t even started? Which, if any, tasks have been completed? Which, if any, tasks have been completed ahead of schedule? Which, if any, tasks are on or ahead of schedule? Which, if any, tasks are behind schedule?

Building and Using a Time-scale Chart Steps for building a Time-scale Chart 1. Identify the tasks to be scheduled 2. Determine the durations of each task 3. List each task down the vertical axis of chart In general, list tasks to be performed first at the top and then move downward as the tasks will happen 4. Use horizontal axis for the dates/time 5. Determine start and finish dates/time for activities Consider which tasks must be completed or partially completed before the next task To use the Time-scale chart to report progress: If the task has been completed, completely shade in the bar corresponding to the task If the task has been partially completed, shade in the percentage of the bar that represents the percentage of the task that has been completed Unshaded bars represents tasks that have not been started.

PERT/CPM Chart Problem Task. A project has been defined to contain the following list of activities along with their required times for completion: Activity No Activity Expected completion time Dependency 1. Requirements collection 5-2. Screen design 6 1 3. Report design 7 1 4. Database design 2 2,3 5. User documentation 6 4 6. Programming 5 4 7. Testing 3 6 8. Installation 1 5,7 a. Draw a PERT chart for the activities. b. Calculate the earliest expected completion time. c. Show the critical path. Problem Statement

PERT/CPM Chart (cont d) Solution a. Draw a PERT chart for the activities. Using information from the table, show the sequence of activities. 2 5 8 1 4 3 6 7

PERT/CPM Chart (cont d) Solution b. Calculate the earliest expected completion time. Using information from the table, indicate earliest expected completion time for each activity (T E ) and the entire project. T E = 11 T E = 20 T E = 23 T E = 5 2 6 T E = 14 5 6 8 1 1 4 5 T E = 12 3 7 2 T E = 19 T E = 22 6 7 5 3

PERT/CPM Chart (the end) Solution c. Show the critical path. T E = 11 T E = 20 T E = 23 T E = 5 2 6 T E = 14 5 6 8 1 1 4 5 T E = 12 2 T E = 19 T E = 22 3 6 7 7 5 3 All Paths 12458 = 5+6+2+6+1 = 20 124678 = 5+6+2+5+3+1 = 22 13458 = 5+7+2+6+1 = 21 134678 = 5+7+2+5+3+1 = 23

Time-scale Chart: Exercise Task Prec Tasks Description Time(hrs) A none decide on date for party 1 B A book bouncy castle 1 C A send invitations 4 D C receive replies 7 E D buy toys and balloons 1 F D buy food 3 G E blow up balloons 2 H F make food 1 I H, G decorate 1 J B get bouncy castle 1 K J, I have party 1 L K clean up 4 M K send back bouncy castle 1 N L send thank you letters 3 O M donate unwanted gifts 3

Time-scale Chart: Exercise Draw the Time-scale / Gantt chart using the following criteria: Label hours 0 to 30 across the horizontal axis Mark a review stage at hour 14 to monitor the progress Assume and illustrate that tasks A, B, C and D have been completed at hour 14 State which tasks are ahead and which tasks are behind schedule

Schedule using Time-scale chart Lets try to schedule this work among our three developers D1, D2, and D3 TASK DURATION (days) A Graphics Engine 14 PREDECESSORs B Sound Engine 5 I C Music Engine 5 J D Input Engine 10 A - E Gameplay/general programming 31 B, C, D F Physics 7 E G 2D Artwork 14 - H 3D Artwork 21 G I Sound Effects 14 - J Music 9 - K Level Design 21 F, H

Practice Exercises

PERT vs. Time-scale chart PERT chart All us to show dependencies explicitly Allow us to calculate critical path Can tell us how one task falling behind affects other tasks Time-scale charts Allow us to record progress of project Allow us to see what tasks are falling behind Allow us to represent overlapping tasks

Project Scope and Risk

Scope Creep The scope of your project is all the work you initially planned to do. Scope creep is, when your project gets new tasks throughout it s lifetime without adding more resources to handle new tasks. The scope is creeping up Scope changes are OK, and really unavoidable that s fine. However, you must update the resources (time, features or people accordingly)

Scope Change versus Creep Your company has a $1million dollar contract with a defined scope. Scope change: Customer: please add all these requirements, and I ll increase the contract to $2 million dollars Manager: Certainly! Scope creep: Customer: please add all these requirements, and I ll be really happy. Manager: Certainly!

Managing Scope How to deal with the inevitable Scope creep? Joint Application Development and prototyping Formal change approval Defer additional requirements as future system enhancements

Managing Risk Document your risks in a risk management plan 1 Description of risk 2 Likelihood of occurrence (0-100%) 3 Impact - 1(low) 5 (high), or cost (in currency) 4 Exposure = Impact * Likelihood 5 Mitigation strategy How to lessen the impact of the risk? How to lessen the likelihood? An action plan, if risk occurs Update and track your risks. Communicate your risks to upper management

Software Projects get into trouble when People in s/w development don t understand their customer s needs. The product scope is poorly defined. Changes are managed poorly. The chosen technology changes. Business needs change [or are ill-defined]. Deadlines are unrealistic. Users are resistant. Sponsorship is lost [or was never properly obtained]. The project team lacks people with appropriate skills. Managers [and practitioners] avoid best practices and lessons learned.

Classic Mistakes Overly optimistic schedule Failing to monitor the schedule Failing to update the schedule Adding people to a late project Failure to manage expectations of others Leaving out a task The above mistakes should be best checked and preferably avoided.

Common Technology-Related Mistakes Overestimated savings from new tools and methods Switching tools in mid-project Lack of automated source-code control

Project Approaches to Remember Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objectives and expectations. Maintain momentum. The project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the team s way. Track progress. For a software project, progress is tracked as work products (e.g., models, source code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity. Make smart decisions. In essence, the decisions of the project manager and the software team should be to keep it simple. Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project.