Chart 1-1 Copyright © 2004 by R. Fairley CSE 516 Summer, 2004 CSE 516 (formerly known as CSE 500) Introduction to Software Engineering SESSION 1: INTRODUCTION

chart 1-1Copyright © 2004

by R. FairleyCSE 516Summer, 2004

CSE 516 (formerly known as CSE 500)Introduction to Software Engineering

SESSION 1: INTRODUCTIONdeveloped by

Richard E. Fairley, Ph.D.Professor and Director of Software Engineering

Oregon Graduate [email protected]

Modified and presented bySanjeev Qazi ([email protected])



BIOGRAPHICAL STATEMENT

Richard E. Fairley, Ph.D.

Dr. Richard E. Fairley(Dick) is a professor of computer science and Director of Software Engineering at the Oregon Graduate Institute in Beaverton, Oregon. He is also founder and principal associate of Software Engineering Management Associates, Inc. (SEMA), a firm specializing in consulting services and training in software systems engineering, software project management, software cost estimation, project planning and control techniques, object-oriented methods, software risk management, and software process assessment and improvement. Dr. Fairley has more than 20 years experience as a university professor, researcher, consultant, and lecturer in software engineering. He has designed and implemented educational programs in universities and in industry, and he has headed research programs in software engineering.

In 1988-89 Dr. Fairley held a two year appointment as a Distinguished Visiting Scientist at the Jet Propulsion Laboratory and consultant to the NASA Headquarters software quality group. He is past chairman of the advisory committee to the Education Division of the Software Engineering Institute. From 1984 through 1993 he was chairman of the COCOMO Cost Estimation Users Group and program chair for the Group's annual meetings. He is a member of the Board of Directors of the Rocky Mountain Institute of Software Engineering, and a member of the program committee for the International Conference on Software Engineering.

Dr. Fairley is author of the text book Software Engineering Concepts, editor of three texts, author/presenter of several videotape series in software engineering, and a principal author of ANSI/IEEE Standard 1058 for Software Project Management Plans. He is also a principal author of ANSI/IEEE Standard 1362 for Operational Concept Documents. He is the author of numerous research papers on a variety of topics in computer science and software engineering. Dr. Fairley has Bachelors and Masters degrees in Electrical Engineering. His Ph.D. in computer science is from UCLA. Prior to obtaining his Ph.D., Dr. Fairley worked in industry as an electrical engineer and computer programmer.



OVERVIEW OF SESSION 1

• Introductions• Course Objectives - syllabus• Textbooks• Academic Integrity Policy• Introduction to Software Engineering• Readings

– Preface and Chapter 1 and 2 of Sommerville– Prefaces, Chapter 1 and 2 of Brooks



OBJECTIVES FOR THE COURSE

After taking this course, you should have a good understanding of:

• Nature of software engineering.

• Work activities accomplished by software engineers and software organizations.

• Work products generated in each phase of the software lifecycle.

• The problems typically encountered during software development, and the current best practices for overcoming them.

After taking this course, you should have a good understanding of:

• Nature of software engineering.

• Work activities accomplished by software engineers and software organizations.

• Work products generated in each phase of the software lifecycle.

• The problems typically encountered during software development, and the current best practices for overcoming them.



OBJECTIVES FOR THE COURSE - II

After taking this course, you should be prepared to:

• Apply software engineering techniques to development and modification of software.

• Apply software engineering techniques to management of software projects.

• Note: As with most courses/concepts, it does take a fair amount of on the job practice (experience) to use this knowledge effectively.

After taking this course, you should be prepared to:

• Apply software engineering techniques to development and modification of software.

• Apply software engineering techniques to management of software projects.

• Note: As with most courses/concepts, it does take a fair amount of on the job practice (experience) to use this knowledge effectively.



TEXT BOOKS

• Textbooks for the course are

– Required• Software Engineering: 6th Ed., by Ian Sommerville,

ISBN 0-201-39815-X

– Optional• The Mythical Man-Month, Anniversary Edition

by Fred Brooks, Addison-Wesley, 1995ISBN 0-201-83595-9

• Textbooks can be obtained from Follett Express Sales:– phone: 1-800-808-2665

• Textbooks for the course are

– Required• Software Engineering: 6th Ed., by Ian Sommerville,

ISBN 0-201-39815-X

– Optional• The Mythical Man-Month, Anniversary Edition

by Fred Brooks, Addison-Wesley, 1995ISBN 0-201-83595-9

• Textbooks can be obtained from Follett Express Sales:– phone: 1-800-808-2665



ACADEMIC INTEGRITY

• You must complete all assigned work by yourself unless specifically instructed otherwise

• You can discuss concepts and ideas with one another but not the details of your solutions.

• See the Academic Integrity Policy.

• If you are in doubt, ASK ME, YOUR INSTRUCTOR.

• You must complete all assigned work by yourself unless specifically instructed otherwise

• You can discuss concepts and ideas with one another but not the details of your solutions.

• See the Academic Integrity Policy.

• If you are in doubt, ASK ME, YOUR INSTRUCTOR.



OVERVIEW OF SESSION 1

• Introductions

• Course Overview - syllabus• Textbooks• Academic Integrity Policy

Introduction to Software Engineering

• Readings – Preface and Chapter 1 and 2 of Sommerville– Prefaces, Chapter 1 and 2 of Brooks



TOPICS FOR DISCUSSION

• What is engineering?

• What is software?

• What is software engineering?

• What do software engineers do?

• What are the problems of software?

• What problems does software engineering attempt to solve?

• What is engineering?

• What is software?

• What is software engineering?

• What do software engineers do?

• What are the problems of software?

• What problems does software engineering attempt to solve?



WHAT IS ENGINEERING?

• Engineering is concerned with applying scientific principles and management skills to develop systems and products for use by society within the constraints of:

– time: schedule– money: budget– product selling price consumer accpetance revenue

generation– business: profit, stability, growth– technology: platform and domain– quality: safety, security, reliability, . . .– ethics: serving society

• These constraints provide the distinction between engineering and science

• Engineering is concerned with applying scientific principles and management skills to develop systems and products for use by society within the constraints of:

– time: schedule– money: budget– product selling price consumer accpetance revenue

generation– business: profit, stability, growth– technology: platform and domain– quality: safety, security, reliability, . . .– ethics: serving society

• These constraints provide the distinction between engineering and science



SCIENCE AND ENGINEERING

• Science is concerned with trying to understand and explain the universe around us– traditional science is concerned with studying energy and

matter in their various forms.

• Engineering is concerned with applying – scientific knowledge, – economics, – quality concerns, – and ethical considerations to build systems that improve human life in various ways

• Computer science is a “science of the artificial”– unlike traditional science, computer science is concerned with

studying information– all other sciences are concerned with energy and matter

• Science is concerned with trying to understand and explain the universe around us– traditional science is concerned with studying energy and

matter in their various forms.

• Engineering is concerned with applying – scientific knowledge, – economics, – quality concerns, – and ethical considerations to build systems that improve human life in various ways

• Computer science is a “science of the artificial”– unlike traditional science, computer science is concerned with

studying information– all other sciences are concerned with energy and matter


by R. Fairley



ENGINEERING IS PROBLEM SOLVING

• Define the problem: Requirements Analysis

• Define the solution: Design

• Build the product: Implementation

• Validate the product: Test and Demonstrate

• Deliver the product: Install/Ship

• Support the product: Maintenance

• Define the problem: Requirements Analysis

• Define the solution: Design

• Build the product: Implementation

• Validate the product: Test and Demonstrate

• Deliver the product: Install/Ship

• Support the product: Maintenance

Engineers are problem-solvers who build and maintain systems for use by other people

NOTE: writing the programs (implementation)is a small (but crucial) part of software engineering



What Is Software?

• Software is a set of descriptions that causes computers to function in particular ways

– software allows us to build special purpose machines from a general purpose computer. These are the applications we run, or the use of embedded computers.

• Usually the entire description is too complex to be written directly in the programming language

– so we prepare different descriptions at different levels of abstraction.

• Software is a set of descriptions that causes computers to function in particular ways

– software allows us to build special purpose machines from a general purpose computer. These are the applications we run, or the use of embedded computers.

• Usually the entire description is too complex to be written directly in the programming language

– so we prepare different descriptions at different levels of abstraction.



Descriptions: The Work Products of Software Engineering

• The work products of software engineering include:

– operational requirements: user needs

– technical specifications: developer’s guidance

– design documents: structure and interfaces

– test plans: product validation

– source code: implementation

– project plans: project roadmaps

– status reports: visibility

– reference manual: product dictionary

– on-line help: user guidance

– installation instructions: operators’ guidance

– release notes: know issues, limitations, hints, platforms supported

– maintenance guide: maintainers’ guidance

• The work products of software engineering include:

– operational requirements: user needs

– technical specifications: developer’s guidance

– design documents: structure and interfaces

– test plans: product validation

– source code: implementation

– project plans: project roadmaps

– status reports: visibility

– reference manual: product dictionary

– on-line help: user guidance

– installation instructions: operators’ guidance

– release notes: know issues, limitations, hints, platforms supported

– maintenance guide: maintainers’ guidance



What is Software Engineering?

• Traditional engineers build complex physical structures

– mechanical engineers design and build complex physical structures, using metal, plastic, wood and so forth as the raw materials.

• Software engineers build complex conceptual structures

– software engineers design and build complex conceptual structures, using notations as the raw materials

– a software development method specifies what notations to use and what descriptions to make, in what order, to build a software system

• Traditional engineers build complex physical structures

– mechanical engineers design and build complex physical structures, using metal, plastic, wood and so forth as the raw materials.

• Software engineers build complex conceptual structures

– software engineers design and build complex conceptual structures, using notations as the raw materials

– a software development method specifies what notations to use and what descriptions to make, in what order, to build a software system



What is Software Engineering? - II

• Because software engineering is concerned with preparing descriptions, the central issues are:– knowing what descriptions to prepare

– knowing when to prepare them

– coordinating the work of preparing them

– communicating the descriptions to others

• The problems of preparing, coordinating, and communicating software descriptions become more severe when:– more people are involved

– when people are separated by

• geography and/or

• organizational structures and/or

• social cultures

• Because software engineering is concerned with preparing descriptions, the central issues are:– knowing what descriptions to prepare

– knowing when to prepare them

– coordinating the work of preparing them

– communicating the descriptions to others

• The problems of preparing, coordinating, and communicating software descriptions become more severe when:– more people are involved

– when people are separated by

• geography and/or

• organizational structures and/or

• social cultures



What Is Software Engineering? - III

• Software engineering is concerned with

– applying computer science,

– management skills,

– quality concerns,

– business needs, and

– ethical considerations to describing and building software-intensive systems

– that satisfy human needs and wants

– that are built in a timely and economical manner

– that are safe, secure, and reliable

– that improve human life

– that create jobs and wealth

• Software engineering is to computer science as electrical engineering is to physics, or as chemical engineering is to chemistry

• Software engineering is concerned with

– applying computer science,

– management skills,

– quality concerns,

– business needs, and

– ethical considerations to describing and building software-intensive systems

– that satisfy human needs and wants

– that are built in a timely and economical manner

– that are safe, secure, and reliable

– that improve human life

– that create jobs and wealth

• Software engineering is to computer science as electrical engineering is to physics, or as chemical engineering is to chemistry



WHAT IS A SYSTEM?

stimuli responses

system

Environment

interfaces

other systems



WHAT IS A SYSTEM?

• A system is a collection of interacting components that exist in an environment– a system receives stimuli from the environment and

generates responses that influence the environment.

• The components of systems are also systems

• The stopping point for the recursive definition must be decided in each case

• A system is a collection of interacting components that exist in an environment– a system receives stimuli from the environment and

generates responses that influence the environment.

• The components of systems are also systems

• The stopping point for the recursive definition must be decided in each case



SOFTWARE-INTENSIVE SYSTEMS

• A software-intensive system is a system that includes one or more computers and is dependent on software for operation.

• Software is found in most (if not all) areas of modern society:–communications–transportation–health care–manufacturing–consumer products –utilities–Defense

• Software is pervasive in modern society

• A software-intensive system is a system that includes one or more computers and is dependent on software for operation.

• Software is found in most (if not all) areas of modern society:–communications–transportation–health care–manufacturing–consumer products –utilities–Defense

• Software is pervasive in modern society



SOME TYPES OF SOFTWARE-INTENSIVE SYSTEMS

• Embedded systems

– automobiles, aircraft, space shuttle, TV, VCR

• Stand-alone systems

– automated teller machines, Unix workstations

• Software products

– Microsoft Office, CorelDraw

• Software packages

– Word, Excel, games

• Software tools

– Rose, C++ compilers, debuggers, web browsers

• Embedded systems

– automobiles, aircraft, space shuttle, TV, VCR

• Stand-alone systems

– automated teller machines, Unix workstations

• Software products

– Microsoft Office, CorelDraw

• Software packages

– Word, Excel, games

• Software tools

– Rose, C++ compilers, debuggers, web browsers

society’s demand for software is insatiable- software is not going to go away -



What Is Software Engineering? - IV

• Software engineering is concerned with applying science, technology, and management skill to develop products and systems for use by society within the constraints of:

– time: schedule– resources: human, corporate assets– technology: platform and domain– quality: safety, security, reliability, . . .– business: competition, profit, stability,

growth– ethics: serving society

• Software engineering is concerned with applying science, technology, and management skill to develop products and systems for use by society within the constraints of:

– time: schedule– resources: human, corporate assets– technology: platform and domain– quality: safety, security, reliability, . . .– business: competition, profit, stability,

growth– ethics: serving society

constraints and uncertainty are the primary sources of problems in software engineering



CORPORATE ASSETS

• Assets are the corporate resources available to conduct a software project

• Assets include:– engineers: skills, numbers, domain knowledge– managers: project level, higher level– technology: platform and domain– development process model – supporting processes: CM, QA, V&V, training– infrastructure: work stations, software tools, LANs

• Assets have both quality and quantity attributes

• Inadequate assets are resource deficits

• Assets are the corporate resources available to conduct a software project

• Assets include:– engineers: skills, numbers, domain knowledge– managers: project level, higher level– technology: platform and domain– development process model – supporting processes: CM, QA, V&V, training– infrastructure: work stations, software tools, LANs

• Assets have both quality and quantity attributes

• Inadequate assets are resource deficits



CONSTRAINTS AND UNCERTAINTY

• A constraint is a limit imposed from outside– schedule: not enough time– resources: insufficient quantity; inadequate quality,

inadequate skills– technology: imperfect; not properly understood– quality: must achieve an “acceptable” level– business: market window, short term goals,

long term goals– ethics: determining acceptable trade-offs

• A constraint is a limit imposed from outside– schedule: not enough time– resources: insufficient quantity; inadequate quality,

inadequate skills– technology: imperfect; not properly understood– quality: must achieve an “acceptable” level– business: market window, short term goals,

long term goals– ethics: determining acceptable trade-offs

constraints and uncertainty are the primarycauses of problems in software engineering



Essential Difficulties and Accidental Difficulties

• According to Fred Brooks*:– essential difficulties are difficulties inherent in the nature of

computer software– accidental difficulties are the result of today’s way of doing

software engineering that are not inherent in the nature of software

• Brooks says there are four inherent properties of software that make software engineering essentially difficult:- complexity - changeability- conformity - invisibility

*”No Silver Bullets” in the IEEE Computer magazine, 1987 and in Chapter 16 of The Mythical Man-Month, publishedby Addison Wesley, 1995.



Essential Difficulties of Software

• Complexity: we cannot understand or remember all of the details; or the work is unfamiliar to us

• Conformity: the parts must fit together exactly; software has no physical tolerances

• Changeability: impact of change must be assessed and handled; everyone must be notified

• Invisibility: it is difficult to know the state of progress or to see the defects

• Complexity: we cannot understand or remember all of the details; or the work is unfamiliar to us

• Conformity: the parts must fit together exactly; software has no physical tolerances

• Changeability: impact of change must be assessed and handled; everyone must be notified

• Invisibility: it is difficult to know the state of progress or to see the defects



SOME QUOTES FROM “NO SILVER BULLETS”“Software entities are more complex for their size that perhaps any other human construct”

“I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it or testing the fidelity of the representation”

“If this is true, building software will always be hard. There is no inherently silver bullet.”

but we can make it easier by reducing(or eliminating) the accidental difficulties



HOW CAN SOFTWARE ENGINEERS DEAL WITH COMPLEXITY, COMMUNICATION AND COORDINATION?

• In the same way that humans deal with complexity in general

– naming, specifying, and designing the pieces and parts

– naming and, specifying, and designing the relationships among the pieces and parts

• And by following systematic engineering processes to analyze, design, build, and maintain our systems

– by preparing a series of descriptions



A BRIEF HISTORY OF SOFTWARE ENGINEERING

• The term “software engineering” was coined by Fredrick Bauer of the University of Munich in 1968 to describe a NATO-sponsored workshop

• The IEEE Computer Society introduced the Transactions on Software Engineering in 1975

• International Conferences on Software Engineering started in 1975

• First Masters programs in software engineering introduced around 1980 (Seattle University and Wang Institute)

• Software Engineering Institute established in 1983

• “Software engineer” first used as a job title around 1990

• Software engineering recognized as an engineering discipline around 1998

• IEEE CS is currently developing a Body of Knowledge and a Competency Recognition Program

– a certification exam will be available this year

• The term “software engineering” was coined by Fredrick Bauer of the University of Munich in 1968 to describe a NATO-sponsored workshop

• The IEEE Computer Society introduced the Transactions on Software Engineering in 1975

• International Conferences on Software Engineering started in 1975

• First Masters programs in software engineering introduced around 1980 (Seattle University and Wang Institute)

• Software Engineering Institute established in 1983

• “Software engineer” first used as a job title around 1990

• Software engineering recognized as an engineering discipline around 1998

• IEEE CS is currently developing a Body of Knowledge and a Competency Recognition Program

– a certification exam will be available this year



GOALS OF SOFTWARE ENGINEERING

• The primary goals of software development (and modification) are to develop software-intensive systems that:

– satisfy technical requirements, user needs, and customer

expectations

– are developed on time and within budget

– are easy to modify and maintain

– support the business goals of our organization

– instill pride in the developers



A BIG PROBLEM

• Software defects are the source of most problems in software engineering

– defects make systems unsafe, insecure, and unreliable– defects make users unhappy– defects result in rework (defect fixing)– rework reduces productivity, increases cost– rework causes schedule pressure– rework causes unplanned overtime– rework reduces morale– Less time for beer, pool, google,… :=)

• Software defects are the source of most problems in software engineering

– defects make systems unsafe, insecure, and unreliable– defects make users unhappy– defects result in rework (defect fixing)– rework reduces productivity, increases cost– rework causes schedule pressure– rework causes unplanned overtime– rework reduces morale– Less time for beer, pool, google,… :=)

a major goal of software engineering is todetect defects early and to prevent defects



A BIG PAYOFF

• Early detection and prevention of defects reduces rework.– QA (Quality Assurance) process should start early.

• Reduced rework improves productivity, user satisfaction, and developer morale

• Each dollar invested in defect reduction and defect prevention typically returns 5 to 10 dollars

– plus happier customers and users– plus happier managers and workers

• Early detection and prevention of defects reduces rework.– QA (Quality Assurance) process should start early.

• Reduced rework improves productivity, user satisfaction, and developer morale

• Each dollar invested in defect reduction and defect prevention typically returns 5 to 10 dollars

– plus happier customers and users– plus happier managers and workers

“Quality is free” but only to those who are willing to invest in it



A Cost-of-Quality Model for Software

DefectLevel

TotalEffort

Rework Cost

X Y

ConformanceCost

Q: what is “good enough quality” for your organization and your customers?



A KEY POINT

• If a method, tool, or technique is not cost-effective then it should not be used– cost-effective may be in the longer term

• If a method, tool, or technique is found to be cost-effective by other organizations then the burden of proof is on you

– to show why it would not be cost-effective in your organization

• If a method, tool, or technique is not cost-effective then it should not be used– cost-effective may be in the longer term

• If a method, tool, or technique is found to be cost-effective by other organizations then the burden of proof is on you

– to show why it would not be cost-effective in your organization



SOME TERMINOLOGY• Humans make mistakes (errors)

• A human mistake results in a software defect (fault or bug)

• When encountered in operation, a defect causes a failure

• A failure is any departure from required behavior– some failure are system crashes– others are less severe

• Others define failure as anything that makes the user unhappy

• NOTE: A system can have a defect, but that may “never” cause a failure.

• Humans make mistakes (errors)

• A human mistake results in a software defect (fault or bug)

• When encountered in operation, a defect causes a failure

• A failure is any departure from required behavior– some failure are system crashes– others are less severe

• Others define failure as anything that makes the user unhappy

• NOTE: A system can have a defect, but that may “never” cause a failure.

the meaning of defect and failure must be defined in each case



WHY DO HUMANS MAKE MISTAKES?

• Primary reasons humans make mistakes in software engineering are:

– inadequate communication and coordination,

– lack of adequate skills and tools,

– poorly designed products that are difficult to modify,

– and schedule pressures.

• Primary reasons humans make mistakes in software engineering are:

– inadequate communication and coordination,

– lack of adequate skills and tools,

– poorly designed products that are difficult to modify,

– and schedule pressures.



WHY DO HUMANS MAKE MISTAKES? - II

• Failures of communication are the major reason for human mistakes in software engineering

– “I didn’t receive the necessary information”

– “The information I received was out of date”

– “The information changed and I wasn’t told”

– “I misinterpreted the correct information”

• Human fallibility is another major reason for human mistakes:

– “I was sick, tired, troubled, . . .”

– “I lack the motivation to do this job”

• Failures of communication are the major reason for human mistakes in software engineering

– “I didn’t receive the necessary information”

– “The information I received was out of date”

– “The information changed and I wasn’t told”

– “I misinterpreted the correct information”

• Human fallibility is another major reason for human mistakes:

– “I was sick, tired, troubled, . . .”

– “I lack the motivation to do this job”



SUCCESS FACTORS FOR SOFTWARE ENGINEERING

• Three key factors in software engineering

– people: numbers and skills– process: the way of working– technology: platform and domain

• Good processes help people to apply technology

– efficiently: without wasting time or effort, and

– effectively: to achieve a desired result



PEOPLE, PROCESS, AND TECHNOLOGY

• Process is the way in which people, working in teams, apply technology to build high quality products - efficiently and effectively.

• Real world note: Adherence to process is imperative, however, cannot be a stickler… Process “standards” differ from group to group, company to company…

People Process Technology

Capability

Product



TECHNICAL ISSUES IN SOFTWARE PROJECTS

• System engineering

• Software requirements engineering

• Software design

• Software implementation

• Software verification and validation

• System integration and validation

• Software maintenance

• System engineering

• Software requirements engineering

• Software design

• Software implementation

• Software verification and validation

• System integration and validation

• Software maintenance



A MODEL FOR SYSTEM DEVELOPMENT

DefineOperationalRequirements

SpecifySystemRequirements

DevelopSystemArchitecture

ObtainSoftwareComponents

IntegrateSoftwareComponents

systemvalidation

systemvalidation

User NeedsCustomer Expectations

User NeedsCustomer Expectations

softwarevalidation

softwarevalidation

IntegrateTotalSystem

Allocate theSoftwareRequirements

DevelopSoftwareDesign

Allocate theHardwareRequirements

Allocate thePeopleRequirements

add othercomponents

operationalvalidation

starthere

endhere



MANAGERIAL ISSUES IN SOFTWARE PROJECTS• Planning and Estimating

– identify work activities– prepare a schedule– prepare a budget

• Measuring and Controlling– quality and productivity– schedule and budget– product evolution

• Leading and Motivating– communicating– coordinating– Educating

• Communicating and Coordinating– internal and external



customer

management

Planning and Replanning

ActivityDefinition

WorkAssign-ments

SoftwareDevelopment

Quality Assurance

Independent Validation

Measuring

Controlling

DataRetention

Estimating

ReportingStatus ReportsProject Reports

Requirementsand Constraints

Directives andConstraints

Change Requests and Problem Reports

ConfigurationManagement

product

. . . . . . . . . . . . .. . . .

A MODEL FOR MANAGING PROJECT WORKFLOW



SOFTWARE ENGINEERING ROLES

• There are many roles to be played in software engineering:

– user– customer – project manager– system system engineer– software architect– software designer– programmer– tester– configuration manager– quality assurer– documentor– trainer– and so forth

• There are many roles to be played in software engineering:

– user– customer – project manager– system system engineer– software architect– software designer– programmer– tester– configuration manager– quality assurer– documentor– trainer– and so forth



SOFTWARE ENGINEERING ROLES

• We must distinguish the roles from the people who play those roles:

– each role requires certain skills

– many people may be required to play one role

– one person may play many roles• at the same time• at different times

• We must distinguish the roles from the people who play those roles:

– each role requires certain skills

– many people may be required to play one role

– one person may play many roles• at the same time• at different times



SOME CHALLENGES OF SOFTWARE ENGINEERING

• Software requirements change frequently.

• Software technology changes frequently.

• Software “maintenance” changes the system

– Changing and distributing software to customers is

“easy”.

• Multiple platform support.

• Software requirements change frequently.

• Software technology changes frequently.

• Software “maintenance” changes the system

– Changing and distributing software to customers is

“easy”.

• Multiple platform support.



SOME CHALLENGES OF SOFTWARE ENGINEERING

• Test cases (where applicable) not available early enough.

• Meeting the market window.

• Legacy software.

• Underlying hardware and/or software environment may be

changing.

• Test cases (where applicable) not available early enough.

• Meeting the market window.

• Legacy software.

• Underlying hardware and/or software environment may be

changing.



Some Best Influences on Software Engineering*

• Reviews and Inspections

• Information Hiding

• Incremental Development

• User Involvement

• Automated Revision Control

• Development Using the Internet

• Programming Languages

• Capability Maturity Model

• Object-Oriented Development

• Component-Based Development

• Metrics and Measurement

• Reviews and Inspections

• Information Hiding

• Incremental Development

• User Involvement

• Automated Revision Control

• Development Using the Internet

• Programming Languages

• Capability Maturity Model

• Object-Oriented Development

• Component-Based Development

• Metrics and Measurement

* IEEE Software, January/February, 2000



COMMENTS ON THE TEXT BOOKS

• The Sommerville text is mostly oriented to technical issues

• The Brooks text is mostly oriented to managerial issues

• Sommerville text is newly published (2001, 6th edition)

• Brooks original text is 20 years old and describes experiences of 30 years ago

• The Sommerville text is mostly oriented to technical issues

• The Brooks text is mostly oriented to managerial issues

• Sommerville text is newly published (2001, 6th edition)

• Brooks original text is 20 years old and describes experiences of 30 years ago



SOME COMMENTS ON BROOKS’ “THE MYTHICAL MAN-MONTH”

• The cover depicts the “Tar-Pit of Software Engineering”

– the tar-pit in which many software engineering projects have floundered

– many fossils have been preserved in the tar-pits

– many lessons can be learned by studying the tar-pit environment and the fossils

• The cover depicts the “Tar-Pit of Software Engineering”

– the tar-pit in which many software engineering projects have floundered

– many fossils have been preserved in the tar-pits

– many lessons can be learned by studying the tar-pit environment and the fossils



SOME COMMENTS ON THE BROOKS TEXT

• Session 1 reading assignment: – Prefaces, Chapter 1 and related material

• The text was first published in 1975 and describes Brooks’ experiences on a 1960s project– the operating system for the IBM 360 computers

(OS/360)

• The 1995 edition is the original text with four additional chapters

• The book has sold more than 300,000 copies

• This classic text describes fundamental problems of software engineering

• Session 1 reading assignment: – Prefaces, Chapter 1 and related material

• The text was first published in 1975 and describes Brooks’ experiences on a 1960s project– the operating system for the IBM 360 computers

(OS/360)

• The 1995 edition is the original text with four additional chapters

• The book has sold more than 300,000 copies

• This classic text describes fundamental problems of software engineering



THE MYTHICAL MAN-MONTH

• The title refers to the fact that software projects are conducted by teams of people working for some period of time

• Effort required to do a job is the product ofPEOPLE x TIME

• People and time are not interchangeable, except within narrow limits– a 60 person-month project might mean:

• 6 people working for 10 months• 5 people working for 12 months• 4 people working for 15 months

– but it does not mean 60 people working for one month or one person working for 60 months

• The title refers to the fact that software projects are conducted by teams of people working for some period of time

• Effort required to do a job is the product ofPEOPLE x TIME

• People and time are not interchangeable, except within narrow limits– a 60 person-month project might mean:

• 6 people working for 10 months• 5 people working for 12 months• 4 people working for 15 months

– but it does not mean 60 people working for one month or one person working for 60 months



BROOKS’ PREFACES

• In the Anniversary preface he mentions the topic:“No Silver Bullets” - reprinted in Ch. 16

– No single technique will bring about an order-of-magnitude improvement in software productivity in ten years

• The First Edition preface (1975) says the field of software engineering is “by no means ready for a systematic textbook treatment”

• Software Engineering Concepts, by R. Fairley, (published in 1985) was one of the first software engineering textbooks

• In the Anniversary preface he mentions the topic:“No Silver Bullets” - reprinted in Ch. 16

– No single technique will bring about an order-of-magnitude improvement in software productivity in ten years

• The First Edition preface (1975) says the field of software engineering is “by no means ready for a systematic textbook treatment”

• Software Engineering Concepts, by R. Fairley, (published in 1985) was one of the first software engineering textbooks



BROOKS’ PREFACES - II

First Edition preface:• “The text is intended for professional programmers, professional

managers, and especially professional managers of programmers”

• “Large programming projects differ in kind from small ones, due to division of labor”

– hence, the need for systematic project management

• “I believe the critical need to be the preservation of the conceptual integrity of the product itself”

– hence, the need for a lead software engineer• the software architect

First Edition preface:• “The text is intended for professional programmers, professional

managers, and especially professional managers of programmers”

• “Large programming projects differ in kind from small ones, due to division of labor”

– hence, the need for systematic project management

• “I believe the critical need to be the preservation of the conceptual integrity of the product itself”

– hence, the need for a lead software engineer• the software architect



BROOKS - CHAPTER 1

• Figure 1.1 - distinctions among– programs: individual programmer, individual use– programming products: used by many people (x3)– programming systems: system components (x3)– a programming systems product: a collection of systems

components used by many people (x9)• See Chapter 1 for a description of the distinctions among programs,

programming products, programming systems, and programming systems products

• Figure 1.1 - distinctions among– programs: individual programmer, individual use– programming products: used by many people (x3)– programming systems: system components (x3)– a programming systems product: a collection of systems

components used by many people (x9)• See Chapter 1 for a description of the distinctions among programs,

programming products, programming systems, and programming systems products



BROOKS - CHAPTER 1

Why is programming fun?• Joy of making things• Making things that are useful to other

people• Complex puzzle-solving• Always learning• Tractable medium • Instant gratification

Why is programming fun?• Joy of making things• Making things that are useful to other

people• Complex puzzle-solving• Always learning• Tractable medium • Instant gratification



BROOKS - CHAPTER 1

Why is programming hard?• Exactness of details• Dependencies on other people and other

artifacts• Tediousness of debugging• Rapid obsolescence of our products

Why is programming hard?• Exactness of details• Dependencies on other people and other

artifacts• Tediousness of debugging• Rapid obsolescence of our products



ASSIGNMENT #1

READING

• Session One Readings– Sommerville : Chapter 1 and Chapter 2– Brooks(optional): Prefaces, chapter 1 and chapter 2

• Session Two Readings– Sommerville: Chapter 3: Software Processes – Brooks(optional): Chapters 3 and 4

ASSIGNMENT

• Complete the Session 1 Homework Assignment

– it must be turned in at the start of class next week

READING

• Session One Readings– Sommerville : Chapter 1 and Chapter 2– Brooks(optional): Prefaces, chapter 1 and chapter 2

• Session Two Readings– Sommerville: Chapter 3: Software Processes – Brooks(optional): Chapters 3 and 4

ASSIGNMENT

• Complete the Session 1 Homework Assignment

– it must be turned in at the start of class next week