The Future of Software Engineering: Challenges and Decision Making

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 system’s function

6. 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

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 technology’s 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. 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 14.3 Decision-Making in Software EngineeringExample of Decision-Making: Choosing New Office Space

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

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. Estimation errors from three rounds of predicting size 14.3 Decision-Making in Software EngineeringA Modest Observational Study (continued)

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. Maryland group’s confidence in final estimate 14.3 Decision-Making in Software EngineeringAnother Observational Study (continued)

37. 14.3 Decision-Making in Software EngineeringPerceived Strengths and Weakness of the Delphi Technique

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

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