chart 1-1 copyright © 2004 by r. fairley cse 516 summer, 2004 cse 516 (formerly known as cse 500)...
Post on 22-Dec-2015
213 Views
Preview:
TRANSCRIPT
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 Institutedfairley@cse.ogi.edu
Modified and presented bySanjeev Qazi (sqazi@cse.ogi.edu)
chart 1-2Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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.
chart 1-3Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-4Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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.
chart 1-5Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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.
chart 1-6Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-7Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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.
chart 1-8Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-9Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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?
chart 1-10Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-11Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-11Copyright © 1998
by R. Fairley
chart 1-12Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-13Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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.
chart 1-14Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-15Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-16Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-17Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-18Copyright © 2004
by R. FairleyCSE 516Summer, 2004
WHAT IS A SYSTEM?
stimuli responses
system
Environment
interfaces
other systems
chart 1-19Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-20Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-21Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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 -
chart 1-22Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-23Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-24Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-25Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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.
chart 1-26Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-27Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-28Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-29Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-30Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-31Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-32Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-33Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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?
chart 1-34Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-35Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-36Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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.
chart 1-37Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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”
chart 1-38Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-39Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-40Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-41Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-42Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-43Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-44Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-45Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-46Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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.
chart 1-47Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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.
chart 1-48Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-49Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-50Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-51Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-52Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-53Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-54Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-55Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-56Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-57Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
chart 1-58Copyright © 2004
by R. FairleyCSE 516Summer, 2004
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
top related