1 / 76

Convener: Houman Younessi

Software Engineering Management. Course # CISH-6050. Lecture 4: . Software Process & Project Management Part 1. Convener: Houman Younessi. 06/04/2012. AGENDA. SW-CMM Level 2: Software Process & Project Management Requirements Management Project Tracking & Oversight

fisseha
Download Presentation

Convener: Houman Younessi

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Engineering Management Course # CISH-6050 Lecture 4: Software Process & Project Management Part 1 Convener: Houman Younessi 06/04/2012 1

  2. AGENDA • SW-CMM Level 2: Software Process & Project Management • Requirements Management • Project Tracking & Oversight • Risk Management • Project Planning • SQA • Software Configuration Management • Sub-contract Management 2

  3. Software Project Management • Software Project Management includes: • Carrying out the definition of a job to be completed • Completing a plan to get a job done • Foundation: • Commitments are made to get the job done • Plans, estimates, reviews & tracking systems support those commitments 3

  4. Software Project Management … • Balance between getting product “out the door” & maintaining the organization’s long-term capability • Need Sr. Management commitment to ensure that a proper project management system is in place and followed 4

  5. Software Project Management … • Questions to be answered to develop effective software development plan: • Why is system being developed? • What will be done, by when? • Who is responsible for each function? • Where are they organizationally located? • How will the job be done technically & managerially? • How much resource is needed? 5

  6. Software Project Management … • Effective Project Management focuses on the 4 P’s: • People – Motivated, highly skilled • Product – Objectives & scope • Process – Framework for development • Project – Planned and controlled 6

  7. Requirements Management • As project progresses and customer looks closer at the problem/solution, they generally identify “changes” • Requirements must be managed in order to preserve project plan, schedule, milestones, etc. • Manage Scope Creep 7

  8. Requirements Management … • Traceability tables can be created to help manage requirements: • Features Traceability • Source Traceability • Subsystem Traceability • Interface Traceability 8

  9. Requirements Management … • Requirements Engineering: • Requirements Definition – natural language statement of the services system will provide • Requirements Specifications – Structured document identifying system services • Software Specifications – Abstract definition of software; basis for design & implementation 9

  10. Requirements Management … • Requirements Engineering Stages: • Feasibility Study • Requirements Analysis • Requirements Definition • Requirements Specification 10

  11. Requirements Management … • Requirements Document: • Combination of requirements definition and requirements specifications • NOT a design document – What, not How • Addresses: • External system behavior • Implementation constraints • Easy to change • Serves as a reference tool for system maintainers 11

  12. Requirements Management … • Requirements Validation: • Verify requirements do what customer wants system to do • Validity: further analysis of requirements might identify additional function • Consistency: Ensure requirements don’t conflict with one another • Completeness: Satisfies customer needs • Realism: Make sure requirements can be realized 12

  13. Requirements Management … • Requirements Evolution: • Refining requirements = better understanding of user’s needs • Process feeds information back to user, which can cause requirements to change • Evolving Requirements: • Enduring – Stable • Volatile – Likely to change 13

  14. Requirements Management … Some observed Requirements Pitfalls to avoid 14

  15. Avoiding Requirement Pitfalls • Reference Point: • Steve McConnell, Rapid Development: Taming Wild Software Schedules, Microsoft Press, Redmond WA, 1996 • Chapter 14: Feature Set Control • Utilized most approaches suggested for controlling function – some worked, some didn’t • Most serious problem: scope creep 15

  16. Avoiding Requirement Pitfalls … • Minimum Specification: • On larger projects, Analysts (unintentionally) used vague statements or left specific requirement details for programmer’s interpretation • In the correct situation, minimum specifications can help, but not in this case • Clearly identify function being requested • Never assume developer has same level of application knowledge as analyst 16

  17. Avoiding Requirement Pitfalls … • Requirements Scrubbing: • Usually more function requested than development schedule will allow • Requirements are scrubbed to eliminate function or offer alternative (cheaper) solutions • Approach works to maintain schedule, but doesn’t satisfy customer • Avoid scrubbing requirements to extent they don’t meet customer needs 17

  18. Avoiding Requirement Pitfalls … • Versioned Development: • Use this approach when customer won’t allow function to be eliminated, but all function can’t be contained in given schedule • Pursue a phased/staged approach for delivering function • Caution – Ensure the additional phases are scheduled and implemented! 18

  19. Avoiding Requirement Pitfalls … • Feature Creep Control: • Attempt to strictly enforce change management during development • We’ve done this well on some projects and not so well on other projects • Customer identifies change late in the cycle that must be done or else they won’t accept product! • Avoid labeling design changes or new features as problems, so they get fixed 19

  20. Software Tracking and Oversight Risk Management 20

  21. Project Tracking & Oversight • Requirement for sound project management is ability to determine project status • Planning process includes schedule with checkpoints (milestones) • Tools for creating project schedules • Microsoft Project • ABT Project Workbench • Spreadsheets 21

  22. Project Tracking & Oversight … • Project Schedule provides roadmap for project mgr to manage project • Project Schedule defines tasks and milestones to be properly tracked and controlled • Tracking done through: • Status mtgs, evaluating results of reviews, tracking project milestones, comparing actual dates against plan dates, verifying time spent on tasks, etc. 22

  23. Project Tracking & Oversight … • Project Plan: • Provides baseline cost and schedule • Brief document addressed to diverse audience • Not static – updating risks, estimates, schedules, etc. • Communicates scope & resource • Defines risks and risk mgmt techniques • Outlines how quality ensured and change managed 23

  24. Project Tracking & Oversight … • Risk Management: • Reactive vs. proactive risk strategies & management • Crisis management & fire fighting will jeopardize project • Risk needs to be proactively managed throughout life of project 24

  25. Project Tracking & Oversight … • Types of Risks: • Project Risks – threaten project plan • Technical Risks – threaten timeliness & quality; can it be implemented? • Business Risks – threaten validity of software being built; may jeopardize project 25

  26. Project Tracking & Oversight … • Types of Business Risks: • Building excellent product no one wants • Building product that no longer fits into business strategy • Building a product that the sales force doesn’t understand how to sell • Losing support of senior management • Losing budget or personnel commitment 26

  27. Project Estimation • Two aspects of Project Estimation • Effort • Schedule • Software Estimation needed to determine: • How big the project is (effort) • How much it will cost to complete • How long it will take to complete (schedule/duration) 27

  28. Project Estimation … • Are highly precise estimates really needed, vs. reasonable estimates? • Estimates become self-fulfilling prophecy • Schedules derived from estimates • Can’t precisely determine if estimates were correct • “Work expands to fill available time” 28

  29. Project Estimation … • Facts about Estimating from R. L. Glass Facts and Fallacies of Software Engineering • Poor estimation is one of the two most common causes of runaway projects • Estimates are really wishes vs. realistic targets • Shortcuts taken to make targets • Problems with estimation techniques: experts, algorithmic approaches, LOC, FP 29

  30. Project Estimation … • Software estimation usually occurs at the wrong time: • Software estimates usually done at the very beginning of a project • To make meaningful estimate, need to know a lot about the project • First phase of project is requirements gathering, so total facts about project not known yet • Estimating solution time & cost while total problem isn’t understood 30

  31. Project Estimation … • Software estimation is usually done by the wrong people: • Software estimates should be done by folks who build the software – programmers, project managers, etc. • Corporate “politics” – estimation done by senior management, marketing organization, customers, and user • Wishes vs. reality 31

  32. Project Estimation … • Software estimates are rarely corrected as the project proceeds: • As the project proceeds and more information is known about the project, estimates aren’t adjusted • Developers pursue achieving the original estimates; upper mgmt not interested in revising estimates • Project results usually measured against the first estimates 32

  33. Project Estimation … • Software estimates are faulty, but everyone is concerned when they are not met: • Given how inaccurate estimates can be and not adjusted during project, should estimates be treated as relatively unimportant? • Instead, software projects are always managed by schedule • Other ways to manage project success or failure, rather than just by schedule 33

  34. Project Estimation … • Disconnect between management and their programmers: • Research study: project failed to meet estimates – management felt project was failure; developers thought it was a success • 419% over budget; 193% over schedule; 130% over original size estimate • Project was completed; did what it was suppose to; no post-release defects 34

  35. Project Estimation … • The answer to a feasibility study is always ‘Yes’: • No new problem is too tough to solve • Optimism – believe we can produce error free code very quickly • Reality – error-removal phase takes longer than analysis, design, and code • When feasibility study done, often proceed with project because we feel it can be done; find out too late that it couldn’t be done 35

  36. Project Estimation … • Fallacy: To estimate cost & schedule, first estimate LOC: • Evolved over the years - notion of using LOC to estimate size • LOC then converted to cost & schedule • Fallacies with most popular method? • COBOL LOC = to C++ LOC? • Mathematic vs. business LOC? • Junior programmer vs. experienced 36

  37. Project Estimation … • Some other thoughts on Software Estimation: • All system attributes affect one another • Reach goals in one area by sacrificing others • Design to cost vs. attempting to cost a design • Understand quality requirements to estimate cost • Past project data useful; current project data better 37

  38. Cost Estimation • Four Techniques for estimating effort and schedule: • Expert Opinion • Analogy • Decomposition • Models 38

  39. Cost Estimation … • Expert Opinion: • Utilizes mature developer’s experiences • Parameters of project described and experts make predictions based on past experiences • Expert may use tools, models, or other methods to generate estimates • Strength of estimates relies on expert and their breadth of experience 39

  40. Cost Estimation … • Analogy: • Formal, more visible approach to expert opinion • Compare proposed project with one or more past projects • Similarities & differences in projects identified; differences used to adjust effort • Estimators describe project in terms of key characteristics 40

  41. Cost Estimation … • Decomposition: • Thorough analysis of project characteristics that affect cost • Focus on products being delivered or tasks required to build software • Described in smallest components / tasks, which are estimated • For project estimate, low-level estimates are summed or used with compositional rules for complexity 41

  42. Cost Estimation … • Models: • Uses techniques that identify key contributors to effort, generating mathematical formulas • In addition to size, may include experience of team, language, degree of code reuse, etc. • Models usually based on past experience and may require some decomposition 42

  43. Cost Estimation Models … • Models: • Most organizations prefer Models or decomposition vs. expert opinion or analogy • Two types of models to estimate effort: • Cost Models – provide direct estimates of effort or duration. Ex: COCOMO • Constraint Model – relationship over time between 2 or more parameters of effort, duration or staffing. Ex: Putnam 43

  44. Cost Estimation … • Each of the 4 techniques can be applied in one of two ways: • Bottom-up estimation • Estimates done at the lowest-level parts or tasks • Similar to decomposition, but applies to analogy, expert opinion, & models • Top-down estimation • Full estimate made for overall process or product • Estimates for components calculated 44

  45. Software Measurement History • Ground work for software measures and measurement, including estimation, was established in the 1960’s and mainly in the 1970’s • Work continues in this area • Most software specialist agree that higher reliability is achieved when software systems are highly modularized & structure kept simple 45

  46. Software Measurement History … • LOC is earliest software measure • Used in 1955 to analyze size of first FORTRAN compiler • SLOC (Source Lines of Code) in 1960’s were counted by the number of 80-column cards (physical lines of code) • McCabe’s Measure - 1970’s: minimum # of paths in flowgraph 46

  47. Software Measurement History … • Halstead Measures – 1970’s: based on source code of program; effort can be expressed as function of operator count, operand count, or usage count • Ruston Measures – 1981: describes program flowchart by means of a polynomial; suitable for network measurement, not as popular as McCabe 47

  48. Software Measurement History … • Estimation Models: • Delphi 1966 • RCA Price-S System 1976 • Putnam’s SLIM Model 1978 • Function-Point Method 1979 • COCOMO Model 1981 • Bailey and Basili 1981 • Mark II Function Points 1988 • Pfleeger Model 1989 • COCOMO 2.0 Model 1996 48

  49. Software Estimation Models • Price To Win • Low Bid or First to Market • Under bid the competition to get contract • Figure out later (after have the contract) how to meet the cost, schedule, and effort • SPQR • Software Productivity, Quality, and Reliability Model • Produced by Capers Jones • Based on 45 factors influencing cost & productivity 49

  50. Software Estimation Models: Delphi • Delphi • Based on iterative expert opinion • Requires domain and organizational expertise • Experts use analogies from past experiences • Improves with low level decomposition • Maybe used for new or unprecedented systems 50

More Related