The Future of

1
Chapter 14

• The Future of
• Software
• Engineering
• Shari L. Pfleeger
• Joann M. Atlee
• 4th Edition
• 4th Edition

2
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

3
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

4
14.1 How Have We Done?

• Use complex languages
• Use patterns and abstractions
• Apply formal methods
• Build a vast array of tools

5
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 systems function

6
14.1 How Have We Done?Wassermans Steps to
Maturity

• Abstraction
• Analysis and design notations
• User interface prototyping
• Software architecture
• Software process
• Reuse
• Measurement
• Tools and integrated environments

7
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

8
14.2 Technology Transfer

• Producers create and use new technologies
• Consumers adopt and use new technologies in new
  products and services

9
14.2 Technology TransferHow 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

10
14.2 Technology TransferAdopter Types

• Innovators
• Early adopters
• Early majority
• Late majority
• Laggards

11
14.2 Technology TransferAdopter Types and the
Chasm between the Early and Mainstream Market
12
14.2 Technology TransferEvidence 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

13
14.2 Technology TransferTypes of Evidence

• Tangible evidence
• Testimonial evidence
• Equivocal testimonial evidence
• Missing evidence
• Accepted facts

14
14.2 Technology TransferFactors 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 technologys attributes
• relative advantage
• compatibility
• complexity
• trialability
• observability

15
14.2 Technology TransferTypes of Evidence and
Their Audiences
16
14.2 Technology TransferNew 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

17
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

18
14.3 Decision-Making in Software
EngineeringRoots of Decision Science
19
14.3 Decision-Making in Software
EngineeringElements that Affect How We Make
Decision
20
14.3 Decision-Making in Software
EngineeringExample of Decision-Making Choosing
New Office Space

• 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

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
21
14.3 Decision-Making in Software
EngineeringElimination 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)

22
14.3 Decision-Making in Software
EngineeringIssues in Group Decision-Making
23
14.3 Decision-Making in Software
EngineeringStrategies to Address Issues in Group
Decision-Making

• Dialectical strategies
• A third party
• Brainstorming
• Nominal group techniques
• Social judgment approach

24
14.3 Decision-Making in Software
EngineeringTypes 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

25
14.3 Decision-Making in Software EngineeringHow
We Really Decide

• Pre-selected options
• Comparative evaluation
• Create new option
• Evaluate each option on its own merits

26
14.3 Decision-Making in Software
EngineeringRecognition-Primed Decision Model
27
14.3 Decision-Making in Software
EngineeringExample 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

28
14.3 Decision-Making in Software
EngineeringExample 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

29
14.3 Decision-Making in Software
EngineeringSidebar 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

30
14.3 Decision-Making in Software
EngineeringExample 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 6
31
14.3 Decision-Making in Software EngineeringA
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

32
14.3 Decision-Making in Software EngineeringA
Modest Observational Study (continued)

• Estimation errors from three rounds of predicting
  size

Estimate Median error Minimum error Maximum error
Initial 160.5 23 2249
Round 1 40 23 749
Round 2 40 3 949
33
14.3 Decision-Making in Software EngineeringA
Modest Observational Study (continued)

• Convergent group estimates
• Three groups show improvement
• Fourth group diverged from the true value

34
14.3 Decision-Making in Software EngineeringA
Modest Observational Study (continued)

• Divergent group estimates

35
14.3 Decision-Making in Software
EngineeringAnother 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)

36
14.3 Decision-Making in Software
EngineeringAnother Observational Study
(continued)

• Maryland groups 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
37
14.3 Decision-Making in Software
EngineeringPerceived 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
38
14.3 Decision-Making in Software
EngineeringLessons 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

39
14.4 The Professionalization of Software
Engineering Licensing, Certification and Ethics

• Improve software engineering education
• Licensing or certification to improve process and
  product

40
14.4 The Professionalization of Software
EngineeringSoftware 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

41
14.4 The Professionalization of Software
EngineeringSoftware 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 Nonfunctional properties (e.g., performance, reliability, maintainability, ease of use)
Human-computer interaction Nonfunctional properties (e.g., performance, reliability, maintainability, ease of use)
42
14.4 The Professionalization of Software
EngineeringSoftware 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

43
14.4 The Professionalization of Software
EngineeringSoftware 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

44
14.4 The Professionalization of Software
EngineeringSoftware 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)

45
14.4 The Professionalization of Software
EngineeringSoftware 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

46
14.4 The professionalization of Software
EngineeringLicensing Software Engineering

• Licensing a legal restriction on who is allowed
  to practice in a regulated profession

47
14.4 The Professionalization of Software
EngineeringLicensing 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

48
14.4 The Professionalization of Software
EngineeringLicensing Process in Canada
(continued)

• Route to becoming a professional engineering
  (P.Eng) in Canada

49
14.4 The Professionalization of Software
EngineeringLicensing 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
  discipline-specific topic

50
14.4 The Professionalization of Software
EngineeringLicensing Process in the United State

• Professional engineer (PE) application process in
  the US

51
14.4 The Professionalization of Software
EngineeringProponent 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

52
14.4 The Professionalization of Software
EngineeringOpponent 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

53
14.4 The Professionalization of Software
EngineeringCertification

• 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

54
14.4 The Professionalization of Software
EngineeringCSDP 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

55
14.4 The Professionalization of Software
EngineeringCSDP Experience Requirement Areas
(continued)

• CSDP certification process

56
14.4 The Professionalization of Software
EngineeringISP Certification

• ISP certification process is different higher
  level of independent judgment and a significant
  level of knowledge

57
14.4 The Professionalization of Software
EngineeringCode 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

58
14.4 The Professionalization of Software
EngineeringDuties 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

59
14.4 The Professionalization of Software
EngineeringCharacteristics 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 ones area of expertise

60
14.4 The Professionalization of Software
EngineeringSidebar 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

61
14.4 The Professionalization of Software
EngineeringProfessional 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

62
14.4 The Professionalization of Software
EngineeringNext 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