Chapter 14
The Future of
Software
Engineering
Shari L. Pfleeger
Joann M. Atlee
4th Edition
Contents
14.1
14.2
14.3
14.4
How have we done?
Technology transfer
Decision making in software engineering
The professionalization of software engineering:
licensing, certification and ethics
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.2
Chapter 14 Objectives
• The Wasserman principles and how we have done
• Technology transfer
• How researchers provide evidence for technology
adoption
• Decision making in software engineering
• Next step in research and practice
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.3
14.1 How Have We Done?
• Use complex languages
• Use patterns and abstractions
• Apply formal methods
• Build a vast array of tools
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.4
14.1 How Have We Done?
Challenges Ahead
• Provide great accuracy in the large: we can tell
– when a space vehicle will reach Mars
– when a chemical reaction will reach a critical stage
• Do not have accuracy in small: we cannot tell
– precisely when a software product will fail again
– exactly how a user will exercise system’s function
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.5
14.1 How Have We Done?
Wasserman’s Steps to Maturity
• Abstraction
• Analysis and design notations
• User interface prototyping
• Software architecture
• Software process
• Reuse
• Measurement
• Tools and integrated environments
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.6
14.1 How Have We Done?
What Now?
• Should consider how well we move the new software
engineering ideas into practice
• Must consider how well our research and practice
support decision making about processes, resources,
and products
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.7
14.2 Technology Transfer
• Producers: create and use new technologies
• Consumers: adopt and use new technologies in new
products and services
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.8
14.2 Technology Transfer
How We Make Technology Transfer Decision Now
• In the 1960s and 1970s, it took an average of 7.5 years
for new technology to become widely available
• Because of time-to-market pressure, new
technologies must prove themselves quickly
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.9
14.2 Technology Transfer
Adopter Types
• Innovators
• Early adopters
• Early majority
• Late majority
• Laggards
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.10
14.2 Technology Transfer
Adopter Types and the Chasm between the Early and Mainstream Market
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.11
14.2 Technology Transfer
Evidence Supporting Technology Decisions
• Researchers: reproducible validation methods
– theoretical proof, static analysis, and simulation
• Practitioners: methods relevant to their environment
– case studies, field studies, and replicated controlled
experiments
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.12
14.2 Technology Transfer
Types of Evidence
•
•
•
•
•
Tangible evidence
Testimonial evidence
Equivocal testimonial evidence
Missing evidence
Accepted facts
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.13
14.2 Technology Transfer
Factors Influence Speed of Technology Transfer
• The nature of the communication channels used to increase
awareness and knowledge of the technology
• The nature of the social system in which the potential user
operates
• The extent of efforts to diffuse the technology throughout an
organization
• The technology’s attributes
– relative advantage
– compatibility
– complexity
– trialability
– observability
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.14
14.2 Technology Transfer
Types of Evidence and Their Audiences
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.15
14.2 Technology Transfer
New Model of Technology Transfer
• Preliminary evaluation of a new technology
• Identify promoters and inhibitors
• Evaluate the evidence
– compare the old ways to the new ways
– whether the evidence is conflicting, consistent and objective
• Evaluate the supportive infrastructure
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.16
14.3 Decision-Making in Software Engineering
• Two points of view of decision-making
– Descriptive: provides evidence about how decisions are
actually made
– Prescriptive: provides frameworks and methods to help
decision-makers
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.17
14.3 Decision-Making in Software Engineering
Roots of Decision Science
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.18
14.3 Decision-Making in Software Engineering
Elements that Affect How We Make Decision
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.19
14.3 Decision-Making in Software Engineering
Example of Decision-Making: Choosing New Office Space
Office option
Rent per month
Distance from home
Size (m2)
Quality
1
$450
10 km
4000
Medium
2
$475
15 km
2500
High
3
$460
14 km
1500
Average
4
$500
5 km
1750
High
5
$510
7 km
2500
high
• Many rules to select the best option
–
–
–
–
Choose the office with the lowest rent
Choose the office closest to home
More complex rule: combination of rent and size
Multiple steps approach
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.20
14.3 Decision-Making in Software Engineering
Elimination by Aspect Strategy
• Each attributes (xj) has a pre-assigned criterion value
(v(xj))
• Each attribute is assigned weigh or priority (wj)
• Sum the products of the weights and the attributes
values
– V = ∑wj v(xj)
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.21
14.3 Decision-Making in Software Engineering
Issues in Group Decision-Making
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.22
14.3 Decision-Making in Software Engineering
Strategies to Address Issues in Group Decision-Making
• Dialectical strategies
• A third party
• Brainstorming
• Nominal group techniques
• Social judgment approach
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.23
14.3 Decision-Making in Software Engineering
Types of Decision
• Strategic decision: affects the well being and nature of
the organization
• Tactical decision: affects pricing, employee
assignment, customer interaction, or operations
• Routine decision: repetitive in nature, local in scope,
and guided by organizational rules or policies
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.24
14.3 Decision-Making in Software Engineering
How We Really Decide
• Pre-selected options
• Comparative evaluation
• Create new option
• Evaluate each option on its own merits
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.25
14.3 Decision-Making in Software Engineering
Recognition-Primed Decision Model
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.26
14.3 Decision-Making in Software Engineering
Example of Bias Caused by Decision Context
• Consider two equivalent questions
– Question 1: You have a 50% chance of losing $200 and a
50% chance of losing nothing. Would you be willing to pay
$100 to avoid this situation?
– Question 2: You can pay $100 to avoid a situation where
you may lose $200 or nothing. Would you pay if there were
a 50% chance of losing?
• Different responds
– 6% of the group answer “yes” for question 1
– 32% of the group answer “yes” for question 2
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.27
14.3 Decision-Making in Software Engineering
Example of Bias in Risk-Analysis Decision-Making
• First framing
– Program A: Exactly 200 lives will be saved
– Program B: 1/3 chance of saving all 600, and 2/3 chance of saving none
• Alternate framing
– Program C: Exactly 400 lives will be lost
– Program D: 1/3 chance that no one will die, and 2/3 chance that 600
will die
• The problems are mathematical identical, however, the
responds were dramatically different
– 75% chose A for first framing
– 22% chose C for the alternate framing
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.28
14.3 Decision-Making in Software Engineering
Sidebar 14.1 Delphi Techniques
• A group of experts receives the specification plus an estimation
form
• The experts discuss product and estimation issues.
• The experts produce individual estimates
• The estimates are tabulated and returned to the experts
• An expert is made aware only of his or her own estimate; the
sources of the remaining estimates remain anonymous
• The experts meet to discuss the results.
• The estimates are revised
• The experts cycle through steps 1 to 7 until an acceptable
degree of convergence is obtained
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.29
14.3 Decision-Making in Software Engineering
Example Used in Assessing Group Effects
Condition
Error rate
Subject is alone
1%
With one person who says A
3%
With two people who say A
13%
With three people who say A
33%
With six who say A and one who say B
Pfleeger and Atlee, Software Engineering: Theory and Practice
6%
Chapter 7.30
14.3 Decision-Making in Software Engineering
A Modest Observational Study
• 12 graduate students of Bournemouth University
were organized in four teams
• Each team was required to capture requirements and
develop a prototype for a simple information system
• Each team was asked to predict the size of the
prototype in lines of code
• Three rounds, the last two rounds applying Delphi
Technique
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.31
14.3 Decision-Making in Software Engineering
A Modest Observational Study (continued)
• Estimation errors from three rounds of predicting size
Estimate
Median error
Minimum error
Maximum error
160.5
23
2249
Round 1
40
23
749
Round 2
40
3
949
Initial
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.32
14.3 Decision-Making in Software Engineering
A Modest Observational Study (continued)
• Convergent group estimates
– Three groups show improvement
– Fourth group diverged from the true value
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.33
14.3 Decision-Making in Software Engineering
A Modest Observational Study (continued)
• Divergent group estimates
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.34
14.3 Decision-Making in Software Engineering
Another Observational Study
• Post graduate students at University of Maryland
• All students were working practitioners
• Yielded comparable results, in that successive rounds
of the Delphi technique led to a substantial reduction
in the range of estimation
• Each student completed a Myers-Briggs test
(personality test)
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.35
14.3 Decision-Making in Software Engineering
Another Observational Study (continued)
• Maryland group’s confidence in final estimate
Group
Number in group
Median confidence in estimate
Range of estimate
1
2
91
2
2
4
65
15
3
3
80
0
4
3
80
0
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.36
14.3 Decision-Making in Software Engineering
Perceived Strengths and Weakness of the Delphi Technique
Weakness
Strength
Can wrongly influence an individual
and the impact of a dominant
individual
Experts with different
backgrounds/perspective
Depends upon knowledge/expertise
of individual
Group discussion can correct mistakes
Risk of erroneous assumptions
Reconsideration
Group discussion made little
difference to the result (consensus
group)
Users expert judgment
High variability in predictions
Provides comparison with other
estimates
In appropriate target, should use for
more detailed problems
Anonymity/independence combined
with group benefits
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.37
14.3 Decision-Making in Software Engineering
Lessons Learned from the Two Studies
• The subjects had a broadly positive attitude to the
technique
• Personalities can dominate the discussion, event
when the dominant participant is not correct
• Increase in confidence have no relationship to the
experience of the team members
• It is important to acknowledge the role of group
dynamics in the estimation process
• Decision-making can be applied in a wider context
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.38
14.4 The Professionalization of Software Engineering:
Licensing, Certification and Ethics
• Improve software engineering education
• Licensing or certification to improve process and
product
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.39
14.4 The Professionalization of Software Engineering
Software Engineering Education
• Specializing in software engineering as part of a
computer science major
• Specializing in software engineering as part of a
computer engineering major
• Specializing in software engineering as part of an
engineering major
• Specializing in software engineering as a separate
degree from computer science r computer
engineering
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.40
14.4 The Professionalization of Software Engineering
Software Engineering Involves Both Computer Science and Engineering
Computer science
Engineering
Data management
Disciplined processes
Data patterns
Large, integrated systems
Data transformation
Coordinated teams
Algorithm paradigms
Nonfunctional properties (e.g.,
performance, reliability,
maintainability, ease of use)
Programming language
Human-computer interaction
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.41
14.4 The Professionalization of Software Engineering
Software Engineering and Engineering’ Principles and Practices
• Software engineering borrows and adapts principles
and practices from engineering
– Early planning and development activities
– Systematic, predictable design and development properties
– Consideration of nonfunctional properties
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.42
14.4 The Professionalization of Software Engineering
Software Engineering vs. Computer Science
• Computer science
– Focuses on data, data transformation, and algorithm
– Advance courses present designs and programming techniques for
specific application domain
• Software engineering
– Focuses on building software products
– Looks at all activities involved in developing a software system from
initial idea to final product
– Designs concept tend to focus on general-purpose design principles,
patterns, and criteria
– Advance courses present design and analysis techniques that scale to
large software system
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.43
14.4 The Professionalization of Software Engineering
Software Engineering Body of Knowledge
• Computing curricula-software engineering (SE2004),
IEEE-CS and ACM 2004
• Software engineering body of knowledge (SWEBOK),
IEEE-CS 2004
• Software engineering syllabus (CEQB 1998)
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.44
14.4 The Professionalization of Software Engineering
Software Modeling and Analysis
• The knowledge unit Modeling Foundation is
decomposed into the topics
– Modeling principles (e.g., abstraction, decomposition,
views)
– Pre- and post-conditions and invariants
– Mathematical models and specification language
– Properties of modeling language
– Distinction between notations’ syntax and semantics
– Importance of models explicating all information
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.45
14.4 The professionalization of Software Engineering
Licensing Software Engineering
• Licensing: a legal restriction on who is allowed to
practice in a regulated profession
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.46
14.4 The Professionalization of Software Engineering
Licensing Process in Canada
• Academic requirements
• Satisfy engineering experience requirements
• All candidates must write and pass a professionalpractice examination that covers relevant provincial
law, professional practice, ethics and liability
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.47
14.4 The Professionalization of Software Engineering
Licensing Process in Canada (continued)
• Route to becoming a professional engineering (P.Eng)
in Canada
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.48
14.4 The Professionalization of Software Engineering
Licensing Process in the United State
• Must have academic qualifications, preferably including
graduation from and Accreditation Board for Engineering and
Technology (ABET)
• Applicant who hold a degree from an ABET-accredited program
require four years of engineering experience, other require
eight years experience
• Candidate must pass an eight hour examination in
fundamentals of engineering
• After no more than four years of experience, the candidate for
licensure must pass a second examination, this time addressing
the principles and practices of engineering in a disciplinespecific topic
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.49
14.4 The Professionalization of Software Engineering
Licensing Process in the United State
• Professional engineer (PE) application process in the
US
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.50
14.4 The Professionalization of Software Engineering
Proponent of Licensing Software Engineers
• The practice of software engineering falls under statutes such
as the Professional Engineers Act
• Licensing software engineers would improve software quality
• Licensing would encourage software developers to obtain a
solid educational foundation for their practices
• Licensing would encourage the use of best practices
• Licensing would improve the engineering of software and the
education of software engineers
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.51
14.4 The Professionalization of Software Engineering
Opponent of Licensing Software Engineers
• There is no evidence that licensed software engineers produce
and maintain the best software
• Licensing may afford false assurance to the public that software
developed by licensed professionals is of high quality
• There is no widely accepted body of knowledge whose mastery
would define competency in software engineering
• Public safety would be best ensured by certifying the products
rather than the processes or the procedures
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.52
14.4 The Professionalization of Software Engineering
Certification
• A voluntary assessment that a practitioner may
choose to undergo to demonstrate competency
• Administered and bestowed by a professional society
• The IEEE Computer Society offers certification as a
certification as a certified software development
professional (CSDP)
• The Computer Information Processing Society (CIPS)
has an information system professional (ISP)
certificate
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.53
14.4 The Professionalization of Software Engineering
CSDP Experience Requirement Areas
•
•
•
•
•
•
•
•
•
•
•
Professionalism and engineering economic
Software requirements
Software design
Software construction
Software testing
Software maintenance
Software engineering management
Software configuration management
Software engineering process
Software engineering tools and methods
Software quality
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.54
14.4 The Professionalization of Software Engineering
CSDP Experience Requirement Areas (continued)
• CSDP certification process
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.55
14.4 The Professionalization of Software Engineering
ISP Certification
• ISP certification process is different: higher level of
independent judgment and a significant level of
knowledge
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.56
14.4 The Professionalization of Software Engineering
Code of Ethics Key Functions
• It stimulates ethical conduct
• It inspires public confidence
• It offers a formal basis for evaluating actions and
disciplining professionals who have agreed to adhere
to the code
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.57
14.4 The Professionalization of Software Engineering
Duties of Professional Engineers
• Imposed by The Association of Professional Engineer
of Canada (PEO)
–
–
–
–
–
–
Duty to society
Duty to employers
Duty to client
Duty to colleagues and employees
Duty to the engineering profession
Duty to oneself
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.58
14.4 The Professionalization of Software Engineering
Characteristics of Professional Misconduct
• Defined by The Association of Professional Engineer of
Canada (PEO)
–
–
–
–
Negligence
Harassment
Failure to safeguard the safety, health, or property of a user
Signing or sealing a document that a professional did not
prepare or check
– Failure to disclose conflict of interest
– Performing a task outside one’s area of expertise
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.59
14.4 The Professionalization of Software Engineering
Sidebar 14.2 ACME/IEEE SE Code of Ethics and Professional Practice
• Software engineers shall act consistently with the public interest
• Software engineers shall act in a manner that is in the best interests of their client
and employer, consistent with the public interest
• Software engineers shall ensure hat their products and related modifications meet
the highest professional standards possible
• Software engineers shall maintain integrity and independence in their professional
judgment
• Software engineering managers and leaders shall subscribe to and promote an
ethical approach to the management of software development maintenance
• Software engineers shall advance the integrity and reputation of the profession,
consistent with the public interest
• Software engineers shall be fair to and supportive of their colleagues
• Software engineers shall participate in lifelong learning regarding the practice of
their profession and shall promote an ethical approach to the practice of the
profession
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.60
14.4 The Professionalization of Software Engineering
Professional Development: Maintaining Competency
• Developing standard
• Publishing research journals that extend our knowledge
• Publishing practitioner journals that facilitate technology
transfer between researches and practitioners
• Holding technical conferences that facilitate communication
with colleagues
• Acting as a public representative for our interests
• Forming special-interest groups to explore focused topics
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.61
14.4 The Professionalization of Software Engineering
Next Steps in Research and Practice
• Study the ways we are similar to other engineers
• Study the ways we are different from other engineers
• Make sure that we view software engineering in its broader
setting, recognizing that quality of software products and
process are generated by creative people working in team
• Embrace other disciplines, including the social science
• Pay more attention to the consequences of the software
engineering decisions
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 7.62