august 13, 2000 cse 7315 - sw project management / chapter 1 – software management overview...

August 13, 2000

CSE 7315 - SW Project Management / Chapter 1 – Software Management

OverviewCopyright © 1995-2000, Dennis J. Frailey,

All Rights Reserved

Slide # 1

CSE 7315

PLANNING AND MANAGING A SOFTWARE

PROJECT

August 13, 2000



All Rights Reserved

Slide # 2

CSE 7315

BUNGLING AND MANGLING A SOFTWARE DISASTER

August 13, 2000



All Rights Reserved

Slide # 3

COPYRIGHT NOTICE

NOTICE: This material is copyrighted and may be copied or downloaded ONCE ONLY by students who are registered in this course at Southern Methodist University or National Technological University.

August 13, 2000



All Rights Reserved

Slide # 4

Warning from Dilbert

“If you’re not on a ‘project,’ then you probably have a thankless, boring,

repetitive job. ... But if you are working on a project, life is very different. ...

you spend much of your waking hours fantasizing about how great it would be to have a thankless, boring, repetitive

job.”

Adams, The Dilbert Principle

August 13, 2000



All Rights Reserved

Slide # 5

Chapter 1

Software Management

OverviewHumphrey, chapters 1-2

August 13, 2000



All Rights Reserved

Slide # 6

Contents

1 - The Course2 - Process - The Framework for

Software Engineering3 - Facts and Myths about Software4 - Overview of the Planning Process

August 13, 2000



All Rights Reserved

Slide # 7

1.1 The Course

• The Course is focused on the PROCESS by which software is developed

• The Management Principles are designed to deal with the process

Software Risk Management

Software Project Management

Software Engineering Process

August 13, 2000



All Rights Reserved

Slide # 8

• People - Those who Perform the

Software Development

• Methods and Procedures -- How we Do

the Work– Design methods, testing procedures,

configuration control, etc.

Other Elements of Software Project Management

August 13, 2000



All Rights Reserved

Slide # 9

• Resources - What we Need to Do the

Work– Computers, Software, Test Equipment,

Facilities, etc.

• Artifacts - Things Produced During the

Course of the Work

• Communication - Within and without

Other Elements of Software Project Management

August 13, 2000



All Rights Reserved

Slide # 10

The Course Combines These Elements

• Planning what to do – Understanding the customer &

requirements– Selecting the lifecycle and the process– Work breakdown structure– Estimating the effort, size, and schedule– Documenting the plans

August 13, 2000



All Rights Reserved

Slide # 11

The Course Combines These Elements

• Managing the execution– Managing risk– Metrics– Configuration management

• Improving – Quality engineering– Continuous process improvement

August 13, 2000



All Rights Reserved

Slide # 12

Warning from Dilbert

“... the biggest obstacle to the success of any project is management itself.”

“... management ... will support [the project] in the following ways:

• Demand frequent status reports ... to explain why the team doesn’t have enough time to meet deadlines ...”

Adams, The Dilbert Principle

August 13, 2000



All Rights Reserved

Slide # 13

Student Assignments

# Due By Class # Description % of Grade1 3 Find a Library (see SOW) (*)2 5 Find an example of an alternative

lifecycle model 1%3 7 Proposal for paper/SDP (see SOW) (*)4 10 Size Estimation Spreadsheet 14%5 13 Cost Estimation Spreadsheet 10%6 15 Research paper or SDP (see SOW) 25%

(*) Assignments 1, 3, and 6 are all combined into one grade.

August 13, 2000



All Rights Reserved

Slide # 14

Research Paper(Student Project option 1)

• Write a Research Paper• Topic Must be Related to the Course– Project Management– Software Process– Any related topic

• Goal: To Gain Insight into an Area of Specialization– Identify key issues or problems, or– Compare two or more approaches or theories, or– Apply principles to a new application, or– Identify & discuss important literature on a given

topic

August 13, 2000



All Rights Reserved

Slide # 15

SOW for Research Paper

• Tasks:– Select Topic (Assignment 1 gives a start)– Research Topic– Develop a Thesis or Idea– Submit a Proposal (Assignment 3)– Write it Up– Submit to Professor (Assignment 6)

• Deliverables– Paper, in Specified Format– Annotated Bibliography

August 13, 2000



All Rights Reserved

Slide # 16

SW Development Plan (SDP)(Student Project, option 2)

• Write a SW Development Plan• For the “Mr. Television” Project– Project Organization– Software Development Process– Etc, etc.

• Goal: To apply what was learned in the course to a typical project– Identify key issues – Plan the project– Define risk management and metrics– etc.

August 13, 2000



All Rights Reserved

Slide # 17

SOW for SDP

• Tasks:– Study the topics of the course– Submit a plan proposal/outline

(Assignment 3)– Complete the plan– Submit to professor (Assignment 6)

• Deliverables– Plan, in Specified Format

August 13, 2000



All Rights Reserved

Slide # 18

Maxim

• Start on the project right away• The second half of the course

involves a lot more homework assignments

The sooner you get behind, the longer you have to catch

up.

August 13, 2000



All Rights Reserved

Slide # 19

Requirements for Research Paper or Plan

• Size: 20-40 pages for body, including

bibliography (if paper is chosen)

• 1 1/2 space (leave room between lines

for comments and such)

• Format - Given in SOW

• Proposal: Must be Approved

• Approach and Format: See the SOW

August 13, 2000



All Rights Reserved

Slide # 20

Annotated BibliographyA collection of bibliographic entries

including comments on each entry Smith, George A., “Software Engineering Lacks a

Decent Process,” International Journal of Obscure Academic Topics (June, 1989), pp 27-32.

This paper explains why software engineering needs a good process model and why the author believes no such model exists. Smith cites four primary reasons why such a model is important: because Watts Humphrey says so, because Smith thinks it is a good idea, because the SEI says so, and because the software process modeling society says so. The required features of such a model include ..... (etc., etc.)

August 13, 2000



All Rights Reserved

Slide # 21

Assignment 1 - Find a Library

Purpose:

• To start the research process

• To help you learn where relevant

materials can be found

• To show what an annotated

bibliography is

• To prove that you are alive

August 13, 2000



All Rights Reserved

Slide # 22

Helpful Tools for ResearchScience Citation Index - Comes Out

Each Year

1988 1989 1990 1991 1992 1993 1994

WattsHumphrey

1987

All papers written in 1993 that

reference Humphrey’s Paper

This is a very valuable research aid that helps you find more recent

papers that are related to a paper of interest.

All papers written in 1990 that

reference Humphrey’s Paper

August 13, 2000



All Rights Reserved

Slide # 23

More Helpful Tools

ACM Computing Reviews - published monthly– Reviews of Recent Publications

ACM Guide to Computing Literature - comes out each year– Complete list of items published in a given year– Key Word in Context (KWIC) Index, by topic– Index by Author– Also lists where the items is reviewed, if it was

reviewed• You may be able to read the review to decide

whether to get the paper • This is very helpful for obscure, hard to find items

August 13, 2000



All Rights Reserved

Slide # 24

Books & Notes

• This course has one textbook

• And several reference books• There is no single book that covers

all of the material

• You must take good notes• Preprinted class notes are not a

substitute for taking good written notes!

August 13, 2000



All Rights Reserved

Slide # 25

Textbook

Humphrey, Watts. Managing the Software Process. Reading, Mass.: Addison-Wesley Publishing Company, 1989. ISBN 0-201-18095-2.

(This is the classic book on the subject. Ed Yourdon recommends as a “must buy” for software developers.)

August 13, 2000



All Rights Reserved

Slide # 26

Reference Books & PapersBrooks, Frederick, The Mythical Man-Month.

Reading, Mass.: Addison-Wesley Publishing Company, 1975.

Department of Defense, Cross Talk - The Journal of Defense Software Engineering, Ogden ALC/TISE, Hill AFB, Utah 84056-5205

Department of Defense, Defense System Software Development, Dod-STD 2167A, 29 Feb. 1988, Department of Defense, Washington D.C., 20201.

August 13, 2000



All Rights Reserved

Slide # 27

Reference Books & PapersHumphrey, W.S., "Characterizing the Software

Process: A Maturity Framework," IEEE Software, Vol. 5 #2 (March, 1988), pp. 73-79. Also available as a technical report from SEI: CMU/SEI-87-TR-23

IEEE, Standard for Developing Software Life-Cycle Processes, IEEE-STD-1074-1991. IEEE Computer Society, New York.

August 13, 2000



All Rights Reserved

Slide # 28

References - II

Paulk, Mark, et. al., Capability Maturity Model for Software, Version 1.1, Software Engineering Institute, CMU/SEI-93-TR-2, February, 1993.

Reifer, Donald, Tutorial: Software Management (third edition), IEEE Computer Society, order # 678, ISBN 0-8186-0678-9, IEEE catalog # EH0243-6

United States Air Force, Software Management Guide. Software Technology Support Center, OO-ALC/TISE, Hill AFB, Utah 84056.

August 13, 2000



All Rights Reserved

Slide # 29

1.2 Process - The Framework for Software Engineering

A process is a set of tools, methods and practices used to produce a product.

-- Humphrey, Managing the Software Process

A process is THAT WHICH HAPPENS when you perform a task.

-- Dennis Frailey

August 13, 2000



All Rights Reserved

Slide # 30

A Process is Something that Happens Over a Period of

Time• It involves activity– Eg., swimming or walking or computing

• It is dynamic– If it happens twice, that is two different

processes– Or two different instances of the same

process model

• It can be described in words, pictures, diagrams, etc.– The description is called a process model or

description or representation

August 13, 2000



All Rights Reserved

Slide # 31

Process Description vs. Process

Computer Program(process

description)

FOR I = 1 TO 10 DO IF A > B THEN CASE J OF ETC ETC ELSE DO SOMETHING ENDIF

Computer in Execution (process)

...

as the computer executes the program, things happen (variables change, data are communicated, devices operate, etc.)

...

August 13, 2000



All Rights Reserved

Slide # 32

Uniprocessing

Processor or agent

Program:

xxxxxxx

xxxxxxx

xxxxxxx

xxxxxxx

xxxxxxx

xxxxxxx

A process happens when

a processorexecutes aprocess

description

August 13, 2000



All Rights Reserved

Slide # 33

MultiprocessingProgram (process model):

xxxxxxx

xxxxxxx

xxxxxxx

xxxxxxx

xxxxxxx

xxxxxxx

xxxxxxx

xxxxxxx

xxxxxxx

xxxxxxx

Process # 1

Process # 2

Process # 3

Process # 4

Processor or agent

Processor or agent

Processor or agent

Processor or agent

August 13, 2000



All Rights Reserved

Slide # 34

Examples of Processes

Process Description

Computer Program

Roadmap

Recipe

Set of instructions for how to put up wallpaper

Process

Program Execution

Take a Trip

Cook a Meal

Put up Wallpaper

August 13, 2000



All Rights Reserved

Slide # 35

Several Interpretations of“Software Process”

A Software Process Description is a definition -- it tells you what process to follow when producing software

Executing the Software Development Process is an activity that produces programs

Programs are Computer Process Descriptions which tell the computer what process to follow when executing the program

Executing the Program produces some desired outcome

August 13, 2000



All Rights Reserved

Slide # 36

A Process has a Beginning and an End in Time

Starting point - when the process starts

.... .... .... something happens .... ....Ending point - when the

process finishes (or it could be

indefinite)

When the process is happening, we say the process is being instantiated or enacted or executed.

August 13, 2000



All Rights Reserved

Slide # 37

A Process Description or Model exists before and/or

after the process is enactedProcess Description (prescriptive) -- What is Supposed to Happen

Wallpaper Hanging

Process Description (descriptive) -- What

Actually Happened

Process (something happens)

August 13, 2000



All Rights Reserved

Slide # 38

Process, Methods and Tools

A Map -- WHAT to do

PROCESS (description)

METHODS

TOOLS

Detailed Instructions - HOW to Do It

AUTOMATION - Do it Efficiently

Eg. - Design, then Review - Plan Tests with Requirements

Eg. - Object Oriented Analysis - Structured Walkthroughs

Eg. - Compiler, - CASE, - Test Generator, - Measurement Tool

“If you automate without a process, you screw up more efficiently” -- Anonymous

INCREASING KNOWLEDGE

August 13, 2000



All Rights Reserved

Slide # 39

Why Process is Important• Tools without Processes or Methods

are like a Fast Car with an Inexperienced Driver – You may drive fast– But who knows where you will end up?– Wrecks are likely

• Methods tell you how to drive - like giving driving lessons

August 13, 2000



All Rights Reserved

Slide # 40

Why Process is Important• But Methods without Processes are

like a Good Driver who Doesn’t know Where He Is or Where He is Going– You may eventually get there– And you may go fast– But you won’t get to the right place very

soon

August 13, 2000



All Rights Reserved

Slide # 41

Process Gives Knowledge

• Where to Go

• How to Get There

• Which Shortcuts will work

• Which Shortcuts will NOT work

• Risks of Each Option

• Why, not just What

August 13, 2000



All Rights Reserved

Slide # 42

How to Describe or Document a Process

It depends on who will use the description and for what purpose

But there are three essential elements of a process description:

-- Tasks or Activities to be Performed -- Artifacts (inputs needed and outputs

produced) -- Relationships and Sequences among

these

August 13, 2000



All Rights Reserved

Slide # 43

Process Descriptions Include ...• Tasks or Activities -- What to do

• Sequencing and Information Flow -- When to do what

• Information or Data (Artifacts)

(compare with a computer program)• Executable Statements• Statement Sequence; Conditional

Statements; Loops; Go To; other Flow of Control constructs

• Data Declarations; Procedure Parameters

August 13, 2000



All Rights Reserved

Slide # 44

Optional Information• Additional information depends on the

purpose of the process description

• Examples of additional information include:– Comments and Documentation– Entry and/or Exit Criteria– Why– Who– What and When to Measure– Risks– References– ...

August 13, 2000



All Rights Reserved

Slide # 45

Representing a Process

• It Depends on Who will Enact the Process

Process Description

Agent

Process

August 13, 2000



All Rights Reserved

Slide # 46

Alternative Representations

ProcessDescription

ComputerProgram

Roadmap Recipe

Agent Computer Driver Cook

ProcessEnaction

A SpecificInvocationof theProgram

A SpecificTrip

Preparationof A SpecificDish

Data Flow orPetri Nets orEnglish, etc.

SWDeveloper

Developmentof

Software

August 13, 2000



All Rights Reserved

Slide # 47

Possible Exam Question

Fill in the chart on the previous page

(assuming some parts are blank)

August 13, 2000



All Rights Reserved

Slide # 48

Goals of a Process Representation

• Specific Enough to Enable a Correct Outcome– A map should be accurate

• Flexible Enough to Allow Judgment– A good map:• Shows alternate routes• Does not dictate speed, type of car, or other

excessive details that can vary• Does not have to be to scale or precise so long as

it serves its purpose

August 13, 2000



All Rights Reserved

Slide # 49

Compare with a Good Recipe

• Specific Enough to Enable a Correct Outcome– Lists all ingredients– Indicates the proper sequence and procedures

for preparing

• Flexible Enough to Allow Judgment– Allows some variation in ingredients without

total failure– Warns about which steps must be followed

precisely

August 13, 2000



All Rights Reserved

Slide # 50

Flexibility vs. Exactness• Staying in the Lane Without Constant

Correction (Experienced Driver vs. Novice)

• A computer program needs precise instructions with no room for variation

-- because a computer cannot exercise judgment

• A human being needs a degree of latitude

August 13, 2000



All Rights Reserved

Slide # 51

Human Processes Rely on Flexibility

• A process to be executed by humans (such as software development) relies on human judgment

-- because of the large number of variables in the environment and the application

• But too much latitude can result in chaos

August 13, 2000



All Rights Reserved

Slide # 52

Some Approaches to Representing a Process

• Computer Program– Specific and Exact– Translates to Machine Language– (but more than one possible translation)

• English or Other Natural Language– Usually Vague– Subject to Interpretation– Assumes Judgment and Experience by AgentRecipe example:• Take 3 Bananas [ripe?]• Add 1 TB Cinnamon [ground?]• etc. [etc...]

August 13, 2000



All Rights Reserved

Slide # 53

Some Formal Methods that are In Between the Previous

Two• Flow Charts– Strong on control/sequencing but weak on

data flow – Little support for parallel processing

• Data Flow Diagrams– Strong on data flow but weaker on control– Good support for parallel processing– Weak on iteration

August 13, 2000



All Rights Reserved

Slide # 54

Some Formal Methods that are In Between the Previous

Two• Petri Nets and Similar Systems– Very precise control and data flow – Parallel processing– Non-intuitive for human interpretation– Too precise for many human processes

August 13, 2000



All Rights Reserved

Slide # 55

Data Flow Elements

Task or Procedure

Flow of Data

DataReposito

ry

Typical Data Flow Diagram

DO X

DO Y

DO Z

DO Q

STORAGE

A

C

D

B

B

August 13, 2000



All Rights Reserved

Slide # 56

Example Process Description:

Frailey’s Possibly Good Chicken

Ingredients:

One Chicken

One Can of Cream of Chicken Soup

1/2 Pound of Mushrooms

3 Tablespoons of Flour

1 teaspoon of Paprika

1 Tablespoons of Butter

Salt and Pepper

August 13, 2000



All Rights Reserved

Slide # 57

Tools

Tools:

One Oven

One Mixing Bowl

Mixing Spoon

Shallow Pan

Knife (to cut up chicken)

Paper or Plastic Bag

August 13, 2000



All Rights Reserved

Slide # 58

Procedures or Tasks

Procedure:

Preheat Oven to 425°

Place Butter in shallow pan and put in oven to melt

Meanwhile, unwrap, wash and cut up the chicken

Mix Flour and paprika and then shake chicken pieces (in bag) to coat

August 13, 2000



All Rights Reserved

Slide # 59

Tasks (continued)

Remove pan from oven and place chicken in pan, skin side down

Put back into oven and turn down to 350° Meanwhile, wash and slice mushrooms

Mix mushrooms, soup, salt & pepper

Pour over chicken (in pan in oven)

Cook for 45 minutes, turn, cook 1/2 hr

Serve

August 13, 2000



All Rights Reserved

Slide # 60

Notes about the Recipe

• The sequencing of steps and data is implied by the order of the recipe commands

• The recipe includes:– Parallel Processing ("Meanwhile ...")

– Repeated Subroutine Calls ("shake chicken pieces")

August 13, 2000



All Rights Reserved

Slide # 61

Student Challenge

• Draw a flow chart or data flow model of the recipe

• Compare with the English recipe for accuracy, ease of comprehension, etc.

August 13, 2000



All Rights Reserved

Slide # 62

Here is Another DescriptionDallas, Texas, 1995. David Zichtermann's house caught fire last night while he was cooking dinner. According to David, he turned on his oven to cook a new chicken recipe, put in a pan with some butter according to the recipe, and then started washing and cutting up the chicken. After he was finished he cut up some mushrooms and mixed them with chicken soup and spices. As he was finishing this task, the oven "burst into flame". The fire marshal is trying to determine whether the cause of the fire was leftover grease in the oven or the butter in the pan. In either case, he believes the oven was set at too high a temperature.

August 13, 2000



All Rights Reserved

Slide # 63

Two Types of Errors• Errors in Following the Process:– Did not put chicken into oven before cutting

up mushrooms, thus leaving the butter in alone too long

– Did not reduce temperature to 350°

• Errors or Flaws in the Process Model:– Did not specify that the oven should be clean

• This is an IMPLICIT REQUIREMENT

– Might have had too high a temperature for melting the butter

– or perhaps should warn not to keep at 425° so long

BOTH of these kinds of errors can be corrected by improving the process

August 13, 2000



All Rights Reserved

Slide # 64

Some Kinds of Process Improvements

• Correct Fundamental Process Errors that Result in Incorrect Results– Lower oven temperature?– Specify a clean oven?

• Improve the Description so that the Agent is Less Likely to Make a Mistake -- I.e., make the process fault tolerant.

(in this case, the cook is the agent)– Warn not to leave the butter in the oven at

425° for more than 15 minutes

Note: the recipe may have additional flaws not yet detected.

August 13, 2000



All Rights Reserved

Slide # 65

Additional Process Problems and Improvements

• The recipe, as corrected, might produce edible chicken, but it might not taste as good as it might– Flavor too spicy or not spicy enough– Chicken too tough (cooked at too high a

temperature or did not specify type of chicken to use)

– Undercooked or overcooked– etc.

• These are quality improvements that are made by changing the recipe (improving the process)

August 13, 2000



All Rights Reserved

Slide # 66

Further PossibleRecipe Improvements

Speed (cycle time) and Cost (mushrooms)– Use cream of mushroom soup instead

of cream of chicken and cut out the mushroom processing

STUDENT CHALLENGE: Find other improvements to the

recipe

August 13, 2000



All Rights Reserved

Slide # 67

Why All the Attention to Process?

• Software Disasters are Costing Lots of Money and Getting More Attention as Software Becomes a Larger Part of Almost Every Manufactured Product

• Process management is being Recognized as the Core Issue behind Software Development Problems

August 13, 2000



All Rights Reserved

Slide # 68

Some Types of Software Project Management

Problems• Software development costs more time/money/resources than anticipated– Business plans new data base for $250K and 9

months– After $2.5 Million and Two years, they still need $1M

to complete – Program is canceled (1)

• Software development costs more time/money/resources than it should – Who knows how much it should cost?– Different contractors often give very different

estimates

(1) McFarlan, F.W. "Portfolio Approach to Information Systems," Harvard Business Review (January, 1974)

August 13, 2000



All Rights Reserved

Slide # 69

More Problems• Fails to meet requirements– System delivers only half of promised

features (Functional requirements -- what it is

supposed to do)– CAD system operates so slowly that it is

unusable (Performance requirements -- speed, space, etc.) (1)

(1) Frailey, Dennis, Private Communication with CAD system programmers who were fired as a result

August 13, 2000



All Rights Reserved

Slide # 70

More Problems• Fails to meet standards of quality or

safety– X-ray machine gives 10,000X dose of

radiation to patient due to faulty software (2)

– Buggy software is constantly crashing– Microsoft Windows calculator has bug in

second digit

(2) ACM/Corporation for Public Broadcasting, "The Machine that Changed the World," (volume 5), PBS program available on video tape.

August 13, 2000



All Rights Reserved

Slide # 71

More Problems• Software causes unanticipated results– Insurance software for claims processing sends

$60M in double payments. 35,000 policy holders quit. (3)

We could go On and On

The basic message is that Software Must be Better Managed in Order to Produce

Acceptable Products

(3) Rothfeder, Jeffery, "It's Late, Costly, Incompetent - But Try Firing a Computer System." Business Week (November 7, 1988).

August 13, 2000



All Rights Reserved

Slide # 72

Software is No Exceptionto the

Basic Principles of Quality Management

• We have Learned that Process is the Proper Focus of Attention for Effective Quality Improvement

• Although this is NOT a course in quality engineering, we do need to be aware of certain basic principles of quality management

August 13, 2000



All Rights Reserved

Slide # 73

Some Basic Principles of Quality Management

Quality Engineering Principle:The quality of a product is determined by

the quality of the process used to develop and produce the product.

August 13, 2000



All Rights Reserved

Slide # 74

Some Basic Principles of Quality Management

Quality Management Principle:The way to improve quality is to:- Define (document) the process- Measure and evaluate the process as it

is executed- Improve the process based on these

measurements and evaluationsConsider the process of cooking and the

application of these principles.

August 13, 2000



All Rights Reserved

Slide # 75


Explain the Basic Principle of Quality Management (i.e., the way to improve quality).

August 13, 2000



All Rights Reserved

Slide # 76

Principles of Productivity and Process Automation

Process Automation Principle:If you automate the wrong process, you

simply do the wrong thing more efficiently

In other words, you must know what process to follow before automating that process.

August 13, 2000



All Rights Reserved

Slide # 77

Principles of Productivity and Process Automation

Productivity Principle:If you design a process for perfect people, it will fail when executed by

human beings-- Design the process for real people-- Automate the parts that people do not

do well.

August 13, 2000



All Rights Reserved

Slide # 78

Possible Exam Questions Explain why automation alone is not likely to improve a

company’s real productivity and quality

Give an example in the software process where automation is a good idea; give an example where automation does not work very well and people should be charged with doing the job.

August 13, 2000



All Rights Reserved

Slide # 79

But .... Software is Not a Manufacturing Process!

• Does this apply to Software?• Isn’t Software Different?One of the most insidious problems with

improving anything is the PERCEPTION OF UNIQUENESSExample: almost every small town thinks its

sports teams are the best because they are unique

Nevertheless, software does have some special characteristics that must be dealt with

August 13, 2000



All Rights Reserved

Slide # 80

1.3 Facts and Myths about Software

• We will examine a few myths that have developed about software

August 13, 2000



All Rights Reserved

Slide # 81

The “Super Programmer” Myth

Software is a creative and artistic endeavor. All you need to do it

right are highly creative individuals (the GURUs & Super Programmers),

whom you leave alone.

August 13, 2000



All Rights Reserved

Slide # 82

The “Creative Genius” Myth

Creative people (like myself) need freedom, not constraints

and “discipline”

August 13, 2000



All Rights Reserved

Slide # 83

Fact: The Essence of Art is Working in a Disciplined

Manner within the Constraints of a Medium

• Sculptor - chisels statues out of stone, not putty– The characteristics of the stone make it a

challenge for the artist rather than a hobby for everyone

August 13, 2000



All Rights Reserved

Slide # 84

Fact: The Essence of Art is Working in a Disciplined

Manner within the Constraints of a Medium

• The strength of the stone is what makes statues possible and what makes them valuable when the artist is complete

“The granite is my enemy and my friend.”

August 13, 2000



All Rights Reserved

Slide # 85

All Artistic Media have Constraints

• Painter - works with a specific painting medium (oils, watercolors, charcoal, etc.)– Each medium has its challenges, possibilities

and limitations

• Musician - works with a specific instrument– A trumpet is hard to play well and it cannot

replicate the sound of a piano– But a really accomplished trumpeter can

make wonderful music

August 13, 2000



All Rights Reserved

Slide # 86

All Artistic Media have Constraints

We measure an artist both by CREATIVITY and by TECHNICAL SKILL

Producing beauty within the constraints of the medium

August 13, 2000



All Rights Reserved

Slide # 87

Promising Young Artists

“... have technical skills but have not yet developed insight ...”

“... have brilliantly creative ideas but cannot bring them to fruition because of a lack of discipline ...”

August 13, 2000



All Rights Reserved

Slide # 88

Established, Respected Artist

“... plays effortlessly, with deep insight, yet with the control and discipline that can only come with experience and extraordinary talent”

“... has defied the traditional rules in a brilliant display of creativity, yielding wonderful new possibilities for the medium. ... [He] has devised a new technique that brings forth the depth of color of oils in the watercolor medium.”

August 13, 2000



All Rights Reserved

Slide # 89

Fact: Structure and Discipline Produce the Best Results

• Cost-effective systems result from applying creativity and discipline to both the design of the product and the design of the system used to produce it

• Extending this to the process used to design the systems is a focal point for software, since the production of software is largely a matter of design

• Discipline enables you to focus on the things that matter (the critical few) rather than the things that don’t (the trivial many)

August 13, 2000



All Rights Reserved

Slide # 90

Example - Airplane Flight Crews• Very well defined process

• Extensive training

• Can handle unexpected, emergency situations• Can function well when individuals are replaced

on short notice (illness, etc.)

August 13, 2000



All Rights Reserved

Slide # 91

Note

• This does not mean that they are not highly qualified

• This does not mean that they are poorly paid

• This does not mean that they are non-heroes

August 13, 2000



All Rights Reserved

Slide # 92

Another ExampleProfessionals vs. Amateurs

• Professional Baseball vs. Sandlot Baseball• Professional Drivers vs. Average Drivers• Professional Software Developers vs.

Amateurs?

• The difference is:– Process well defined– Extensive training– Skill and determination

Consider highly skilled sports teams that never win the championships

August 13, 2000



All Rights Reserved

Slide # 93

The “Development Tools” Myth

The best development tools are the main thing

you need to get high productivity.

Super Mega Hyper

Workstation

August 13, 2000



All Rights Reserved

Slide # 94


My grades will be higher if you get me a computer

August 13, 2000



All Rights Reserved

Slide # 95

The “Development Tools” MythFacts

• Lack of tools is rarely the root cause of a problem. – If you don’t know what to do, a tool

will not help you– Data from real programs show that

knowledge & procedures are more important than tools

August 13, 2000



All Rights Reserved

Slide # 96

The “Development Tools” MythFacts

• A good musician can make a poor instrument sound wonderful

• But a poor musician cannot make a good instrument sound right

August 13, 2000



All Rights Reserved

Slide # 97


Conclusion• Good tools can make a big

difference when used by people who know what to do with them– But you have to use the right tool at

the right time and in the right place– Which means you have to know what

you are doing and where a tool can help you

– ... and why it can help you

August 13, 2000



All Rights Reserved

Slide # 98

The Gunslinger Myth:Planning Wastes Time – Just Do

It!Do you want me to plan or to

build software?

Do you want a plan or a product?

This is e-commerce – we don’t have a long time to do the job!

This example is taken from Cusumano and Yoffie, Competing on Internet Time, 1998.

August 13, 2000



All Rights Reserved

Slide # 99

The Gunslinger Myth: Another Opinion

“This is sheer b*** s*** … The way you hit the bull’s eye the first time is by planning things [properly]…”

David Stryker, shared component software manager at Netscape in 1996-97

August 13, 2000



All Rights Reserved

Slide # 100

Planning:Netscape’s Stryker Continues

“You can’t plan everything down to the atoms. The art of planning is articulating your goals and nongoals … really clearly and picking the things that have to be planned down to the atoms … goals [must be] measurable and concrete.”

August 13, 2000



All Rights Reserved

Slide # 101

More on Goals and Nongoals: Netscape’s Stryker Continues

“The nongoals are more important than the goals because, when you’re doing midcourse correction, which you do on a 72-hour basis, the best guidance you can get is to remember what you weren’t trying to do.”

August 13, 2000



All Rights Reserved

Slide # 102

Some Facts about Software

Fact #1: Software Products are Increasingly More Complex and Therefore Must be Managed Accordingly

• Armies of people or expensive tools will not suffice.– Studies show that complexity and management

problems grow disproportionately as size increases

– Consider biological systems -- the larger the organism, the more complex it must be in order to function

– This stems from fundamental laws of physics

August 13, 2000



All Rights Reserved

Slide # 103

Some Facts about Software

• Talented people can only handle so much– Picasso and DaVinci could not paint the

world trade center– Do you want your company’s success to

depend on a few talented but temperamental heroes?

August 13, 2000



All Rights Reserved

Slide # 104

Strawberry Shortcake Example

• Strawberry Shortcake Recipe Makes 4 Servings

• Easy to modify for 2 or 8 servings• But what do you do for 20,000 servings?

0

20

40

60

80

100

2 4 8 16 32 64 128

–acquisition of strawberries, cream, flour, etc.

–adequate tools for baking, mixing, keeping cold, etc.

–proper procedures for production

–storage and serving facilities

–etc.

Good Manageme

nt Essential

Good Manageme

nt Nonessent

ial

August 13, 2000



All Rights Reserved

Slide # 105

Ford Clutch Story• Assignment: write a manual on how to

design a clutch• Problem: there is only one person in the

company who can design a clutch, and he is in failing health - ought to be retiring

• Additional Problem: “Mr. Clutch” has always been treated as a hero, and he does not want to lose his stature by giving away his secrets

“The first task of a new manager should be to identify all the people you cannot live without and fire them.”

August 13, 2000



All Rights Reserved

Slide # 106

More Software Facts Fact #2: Software has Unique Characteristics

that Make it More Difficult to Develop than Many Other Technical Artifacts

• Software has no natural physical laws– Example: with a mechanical device, increased

force will have results within specifiable limits– But software can be made to behave in any

fashion

• Discontinuities are the rule in software, whereas they are the exception in other disciplines– Interpolation, Extrapolation, etc. do not always

apply to software

August 13, 2000



All Rights Reserved

Slide # 107

How to Deal with Software’s Lack of Physical Constraints• Must understand the architecture

and design of the software in order to understand the impact of changes

• Must preserve accurate design descriptions when the software is in a maintenance mode

August 13, 2000



All Rights Reserved

Slide # 109

More Software Facts

Fact #3: Software Development is Fun• Finding an elusive bug• Figuring out how to gain access to

obscure files• Adding an attractive feature to a new

product that is under development

August 13, 2000



All Rights Reserved

Slide # 110

More Software Facts

It is too easy for software to end up costing a lot more money, taking a lot more time, and having a lot of excess baggage (unwanted features)

The manager must focus the developers’ creativity on the parts that really need creative input

August 13, 2000



All Rights Reserved

Slide # 111

More Software FactsFact #4: Change is A Constant in Software

Development• The hardware capabilities change constantly– Memory capacity doubles roughly every 2 years– Processor speed does roughly the same– 1950’s - Mainframe; Assembly Language– 1960’s - Time Sharing; Cobol and Fortran– 1970’s - Minicomputer; Pascal– 1980’s - Personal Computer & Workstations; Lisp

and C– 1990’s - Laptops; Information Highway; Object

Oriented– 2000’s - ??? (it probably won’t be like today)

August 13, 2000



All Rights Reserved

Slide # 112

Fact #4 (change) - continued

• The infrastructure for software development changes with a 5-10 year horizon– languages (Assembly-Fortran-Pascal-Ada-

Lisp-C-C++-??)• GUIs and 4GLs are becoming the dominant

languages today

– tools (assembler, compiler, linker, CASE, integrated tools)

– design methods (flow chart, data flow, information engineering, object oriented methods, ...???)

August 13, 2000



All Rights Reserved

Slide # 113

Fact #4 (change) - continued

• The infrastructure for software development changes with a 5-10 year horizon– recommended procedures and methods– debugging methods– testing approaches

• Technical obsolescence occurs roughly every 5 years, according to Yourdon and others

August 13, 2000



All Rights Reserved

Slide # 114

Dealing with Change

• The software manager must keep abreast of change and avoid getting left behind– Alternative -- a career spent maintaining 30

year old Cobol programs

• But must also avoid change for change sake– Fads are common in software– Programmers like to be pioneers, but

pioneers get a lot of arrows in their backs - and their managers get crucified!

August 13, 2000



All Rights Reserved

Slide # 115

Dealing with Change

• Some fundamental principles do not change– Human nature– Basic theory of computer science– Principles of management– The nature of software (?)

August 13, 2000



All Rights Reserved

Slide # 117

Notes on Planning

“Plans are nothing, planning is everything.”-- Dwight Eisenhower

“Plans are nothing” because: -- they represent a best guess based on

incomplete knowledge -- they are obsolete as soon as they are

complete

This does not mean plans should not be used.

August 13, 2000



All Rights Reserved

Slide # 118

Plans Provide a Framework

• A consistent starting point for all participants– What to do– How to work together– What to expect

• A basis for organizing– Who needs to be involved

• A basis for allocating resources• A basis for deciding whether or not to

go ahead

August 13, 2000



All Rights Reserved

Slide # 119

Golf Analogy

• The first shot is aimed at the pin• It usually moves you in the right

direction, but it seldom gets you all the way there

• That’s why you need a second shot• And a third• And a fourth• And ....

• And a few extra golfballs

August 13, 2000



All Rights Reserved

Slide # 120

Planning is Everything

Planning forces you to understand the issues

KNOWLEDGE

Knowledge helps you make better decisionsEXPECTED DEVELOPMENTSUNEXPECTED PROBLEMS

With knowledge, you know when NOT to follow the plan, and why

August 13, 2000



All Rights Reserved

Slide # 125

A Model that focuses onPlanning

Manage Risks

Definethe Approach

GenerateDetailed Plans

Understandthe Need

Monitor Execution

Note that the cycle continues throughout the software development process

August 13, 2000



All Rights Reserved

Slide # 126

Relationship to Course

Manage Risks -- CHAPTER 9

Definethe Approach

3.3-3.5

GenerateDetailed Plans

4,5,6,7,8

Understandthe Need

3.2

Monitor ExecutionCHAPTERS 10, 11, 12

August 13, 2000



All Rights Reserved

Slide # 127

Summary of Chapter

• Process is the framework for software engineering and the proper focus of management– the process of developing software– the process of managing software

development

• Risk management is a key part of the total management process

August 13, 2000



All Rights Reserved

Slide # 128

Summary of Chapter (continued)

• The course combines three elements– Planning– Managing execution– Improving

• The process is what happens; the process description is how the process is documented

August 13, 2000



All Rights Reserved

Slide # 129

Summary of Chapter(continued)

• Tools without processes and Methods without processes are insufficient

• Process representation or documentation must include three key elements:– tasks– artifacts– relationships or sequencing among the

above

August 13, 2000



All Rights Reserved

Slide # 130


• Human processes must allow flexibility and judgment - that’s what the humans are there for

• Errors occur in two ways:– Errors in following the process– Errors in the process model

August 13, 2000



All Rights Reserved

Slide # 131


• Process improvements can be of several kinds:– Improve the process so that it produces

fewer errors or performs more efficiently– Improve the process description so that the

agent(s) are less likely to make mistakes

• The basic principles of quality management– Product quality depends on process quality– Quality improvement comes from process

improvements

August 13, 2000



All Rights Reserved

Slide # 132


• A process that requires perfect people will fail

• Automation of the wrong process just does the wrong thing more efficiently

• There are many myths and facts about software

August 13, 2000



All Rights Reserved

Slide # 133


• True artists work with discipline and within the constraints of a medium– The same is true for true artists in the field of

software development

• Software management grows exponentially with the size of the software to be built

• Software has unique characteristics– Lack of physical constraints– Does not need to follow laws of physics– Discontinuities are common

• Change is part of the software environment

august 13, 2000 cse 7315 - sw project management / chapter 1 – software management overview...

Documents

software projectcse

software developmentmethods

software engineering3

plansthe course

coursethe course

withoutthe course

research papertasks

research papertopic