CS427: Software Engineering IQuestions on readingHomework 1Planning quotesWho plans?ManagementManager vs. architectPlanningExamplesSlide 10Planning is easyPlanning is hardPrinciples of planningYet another book?Facts on when and whoFacts on flexibilitySchedulingPERT charts (1)PERT charts (2)PERT charts (3)PERT charts (4)Project trackingWhen is a task finished?Wrong way to planRUP way to planMain project plan documentsBusiness caseSoftware development planWork breakdown structureRUP project milestonesManpower on RUP projectScheduling in RUPDefault top-down budgetTracking in RUPQuestions on planningNext: Guest lecture1CS427:Software Engineering IDarko Marinov(slides from Ralph Johnson)CS427 7-2Questions on readingReading before or after?Voting declares the winner: beforeOverlap of reading and lectures?Lectures typically cover lessHow much to read?See exams from previous yearsUse “History” on top of Wiki pagesCS427 7-3Homework 1Postponed for Tuesday, September 26Fair warning: don’t wait until the deadlineDeliverablesVision document (lecture 4)Use case model (lectures 6 and 6e)Risk assessments (lecture 5)Project plan (lecture 7, today)CS427 7-4Planning quotesAnonymous: “Nobody plans to fail. They just fail to plan.”Eisenhower: “Plans are nothing. Planning is everything.”Moltke: “No battle plan survives contact with the enemy.”CS427 7-5Who plans?ManagersDevelopers?Testers??XP1st edition: planning is a cooperative “game” between the customer and the developers2nd edition: not called “game” any moreCS427 7-6ManagementDecides what to build Product scope and requirementsGets and organizes peopleSelects processPlans projectEvaluates progressManagers vs. leadersCS427 7-7Manager vs. architectManagerPizzaEvaluationNew computersTop managementBuilds teamSchedulesArchitectRequirementsClient-server vs. web-basedDesign reviewsTough technical decisionsCS427 7-8PlanningHow much will it cost?How long will it take?How many people will it take?What kind of people will it take?What might go wrong?What can we do to minimize chance of failure?CS427 7-9ExamplesHow much would we save if we used Crystal Reports to generate our reports?How much would we save if we outsourced the project to Smith Brothers Software?CS427 7-10PlanningScoping - understand problem and the work that must be doneEstimation - time and effortRisk - what can go wrong? What can we do about it?Schedule - resources and milestonesControl strategy - how can we tell when things are going wrong?CS427 7-11Planning is easyFigure out all the tasksFigure out how long each task will takeFigure out who can do the workAssign workers to tasks to produce shortest scheduleCS427 7-12Planning is hardTasksDepends on requirements, designMeetings, emergencies, learning, helping othersEstimationCompare with pastImproves with practiceSimple tasks easier to estimate than complexCS427 7-13Principles of planningEstimates should be made by people who do the workEstimates for small items are more accurate than for large itemsLearning to estimate requires practiceHW1 is an opportunity to start practicingYou won’t be graded on accuracy of plansCS427 7-14Yet another book?“Facts and Fallacies of Software Engineering” by Robert Glass55 facts and 10 fallaciesNo, you don’t have to read itOne fact on importance of estimation“One of the two most common causes of runaway [software] projects is poor estimation.”What do you think the other cause is?CS427 7-15Facts on when and who“Estimation occurs at wrong time.”Most estimates are made at the beginning of a project, before requirements are defined and thus before the problem is understood.“Estimation is done by the wrong people.”Most software estimates are made either by upper management or by marketing, not by the people who will build the software or their managers.CS427 7-16Facts on flexibility“Software estimates are rarely corrected as the project proceeds.”Thus, those estimates done at the wrong time by the wrong people are usually not corrected.How do XP and RUP address this problem?“It is not surprising that estimates are bad. But we live and die by them anyway!” There is little reason to be concerned when projects do not meet estimated targets. But people are concerned anyway.CS427 7-17SchedulingDetermine needed resources for each taskPeople and skillscomputers, testing systemSchedule tasksSome tasks depend on othersSome tasks compete for resourcesCS427 7-18PERT charts (1)Represent tasks and their durationManage dependency between tasksDevelop parserDevelop type checkerDevelop code generatorDefine ASTs53 611Integrate3durationCS427 7-19PERT charts (2)End = start + durationStart = maximum of ends of predecessorsDevelop parserDevelop type checkerDevelop code generatorDefine ASTs053891714611Integrate33314 3startendCS427 7-20PERT charts (3)Time if there are plenty of workers = 17Time if there is only one worker = 28Time with two workers?Develop parserDevelop type checkerDevelop code generatorDefine ASTs053891714611Integrate33314 3CS427 7-21PERT charts (4)Critical path - path that takes longestSlack - extra time for taskOnly optimize steps on critical pathDevelop parserDevelop type checkerDevelop code generatorDefine ASTs053891114611Integrate3339 2Integrate1CS427 7-22Project trackingKeep track of when each task is finishedRUP: When is document done?XP: When is coding done?Compare plan to realityTasks are either finished or notForbid “75% finished” - decompose tasksCS427 7-23When is a task finished?Must be objective“Design passed review” not “Design is reusable”Different tasks are evaluated differentlyIn RUP, writing a document is a separate task from reviewing itIn XP, a programming task is not finished until all unit tests run correctlyCS427 7-24Wrong way to planVisionRequirementsDesignConstructionTestCS427 7-25RUP way to planProject manager responsible for:Project plan (developed during inception phase)Iteration plan (developed by end of previous iteration)Assessing iterationRisk listCS427 7-26Main project plan documentsBusiness CaseSoftware Development PlanWork Breakdown
View Full Document