CS499
Chapter 14
The Future of
Software
Engineering
Shari L. Pfleeger
Joann M. Atlee
4th Edition
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
Contents
14.1 How have we done?
14.2 Technology transfer
14.3 Decision making in software
engineering
14.4 The professionalization of software
engineering: licensing, certification
and ethics
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
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
CS499
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
CS499
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
CS499
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
CS499
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
CS499
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
CS499
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
CS499
14.2 Technology Transfer
Adopter Types
•
•
•
•
•
Innovators
Early adopters
Early majority
Late majority
Laggards
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
14.2 Technology Transfer
Adopter Types and the Chasm between the Early and Mainstream
Market
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
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
CS499
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
CS499
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
CS499
14.2 Technology Transfer
Types of Evidence and Their Audiences
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
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
CS499
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
CS499
14.3 Decision-Making in Software Engineering
Roots of Decision Science
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
14.3 Decision-Making in Software Engineering
Elements that Affect How We Make Decision
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
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
CS499
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
CS499
14.3 Decision-Making in Software Engineering
Issues in Group Decision-Making
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
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
CS499
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
CS499
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
CS499
14.3 Decision-Making in Software Engineering
Recognition-Primed Decision Model
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
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
CS499
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
CS499
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
CS499
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%
CS499
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
CS499
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
CS499
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
CS499
14.3 Decision-Making in Software Engineering
A Modest Observational Study (continued)
• Divergent group estimates
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
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
CS499
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
CS499
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
CS499
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
CS499
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
CS499
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 or computer
engineering
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
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
CS499
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
CS499
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
CS499
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
CS499
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
CS499
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
CS499
14.4 The Professionalization of Software Engineering
Licensing Process in Canada
• Academic requirements
• Satisfy engineering experience requirements
• All candidates must write and pass a
professional-practice examination that covers
relevant provincial law, professional practice,
ethics and liability
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
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
CS499
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
CS499
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
CS499
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
CS499
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
CS499
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
CS499
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
CS499
14.4 The Professionalization of Software Engineering
CSDP Experience Requirement Areas (continued)
• CSDP certification
process
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
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
CS499
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
CS499
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
CS499
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
CS499
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
CS499
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
CS499
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