The Future of - PowerPoint PPT Presentation

Loading...

PPT – The Future of PowerPoint presentation | free to download - id: 564f2a-ZTc5M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

The Future of

Description:

Chapter 14 The Future of Software Engineering Shari L. Pfleeger Joann M. Atlee 4th Edition 14.3 Decision-Making in Software Engineering A Modest Observational Study ... – PowerPoint PPT presentation

Number of Views:53
Avg rating:3.0/5.0
Slides: 63
Provided by: CraigW153
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: The Future of


1
Chapter 14
  • The Future of
  • Software
  • Engineering
  • Shari L. Pfleeger
  • Joann M. Atlee
  • 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
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

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 or 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
About PowerShow.com