Convener: Houman Younessi

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

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

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

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

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

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

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

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

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

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

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

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

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

Requirements Management … Some observed Requirements Pitfalls to avoid 14

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

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

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

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

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

Software Tracking and Oversight Risk Management 20

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Convener: Houman Younessi