1. James Nowotarski 11 September 2008 SE 425 Principles and Practices of Software Engineering Autumn 2008

2. 2 Understand what the course is about (i.e., course objectives) Understand how the course will achieve its objectives Get acquainted Level set: What is software engineering Why use a software engineering process What are the key vocabulary terms to understand Why does any of this matter Today’s Objectives

3. 3 Topic Duration Questionnaire & Intros30 minutes Does software engineering matter?45 minutes *** Break15 minutes Course overview15 minutes Key models and frameworks90 minutes Today’s Agenda

4. 4 Software = “single most important technology on the world stage” - Pressman, p.7 Does SE Matter?

5. 5 As noted by Carr, IT is often viewed as a commodity and, thus, not “core” IT is like electric power -- a commodity that is required by all but provides distinction to none IT capability is broadly accessible and affordable New or proprietary technologies offer opportunity for companies to gain a step, but this advantage is short-lived Further evidence of IT commoditization: –overcapacity –price drops –vendors positioning selves as “utilities” Source: Carr, N. (2003, May). IT doesn’t matter. Harvard Business Review, 81(5), 41-49.

6. 6 Buy vs. build Lease (utility model) vs. buy Open source download vs. lease Software as a commodity? “Although the industry is moving toward component- based construction, most software continues to be custom built” (Pressman, p.7) Does SE Matter?

7. 7 “Why write your own application for word processing or e-mail or, for that matter, supply-chain management when you can buy a ready-made, state-of-the-art application for a fraction of the cost?” “…more companies [are] replac[ing] customized applications with standardized ones” Source: Carr, N. (2003, May). IT doesn’t matter. Harvard Business Review, 81(5), 41-49. Does SE Matter?

8. 8 IT Outsourcing Buy Build CommodityDifferential Critical Useful Strategic Importance Potential for Differentiation Buy vs. build

9. 9 Software Engineering The establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines (Fritz Bauer, 1969) What is SE?

10. 10 Who is Fritz Bauer? Professor of Mathematics and Computer Science at Munich University of Technology

11. 11 Who is Fritz Bauer? Chairman of 1968 NATO Software Engineering Conference Credited with coining the term “software engineering”

12. 12 Who is Fritz Bauer? Software engineering = “The part of computer science that is too difficult for the computer scientists.”

13. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 1 Slide 13 What is software engineering? l Software engineering is an engineering discipline that is concerned with all aspects of software production. l Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available.

14. 14 Software Engineering (1)The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). Source: “IEEE Standard Glossary of Software Engineering Terminology,” IEEE std 610.12-1990 What is SE?

15. 15 Software Engineering Body of Knowledge Software requirements Software design Software construction Software testing Software maintenance Software configuration management Software engineering management Software engineering process Software engineering tools and methods Software quality Source: Guide to the Software Engineering Body of Knowledge. (2004). IEEE. www.swebok.orgwww.swebok.org What is SE?

16. 16 IT Outsourcing Best jobs in America 1. Software engineer 2. College professor 3. Financial adviser 4. Human resources manager 5. Physician’s assistant 6. Market research analyst 7. Computer/IT analyst 8. Real estate appraiser 9. Pharmacist 10. Psychologist Source: Kalwarski, T., Mosher, D., Paskin, J. & Rosato, D. (2006, May). 50 best jobs in America. Money. Retrieved September 8, 2008, from http://money.cnn.com/magazines/moneymag/bestjobs/2006/ http://money.cnn.com/magazines/moneymag/bestjobs/2006/

17. 17 IT Outsourcing Best jobs in America

18. 18 IT Outsourcing Fasting growing jobs in U.S. Source: Dohm, A. & Shniper, L. (2007, November). Occupational employment projections to 2016. Monthly Labor Review Online. Retrieved September 8, 2008, from http://www.bls.gov/opub/mlr/2007/11/art5full.pdf http://www.bls.gov/opub/mlr/2007/11/art5full.pdf

19. 19 IT Outsourcing Fasting growing jobs in U.S. Computer software engineers, application Computer systems analysts Network systems and data communication analysts Home health aides Medical assistants Personal and home care aides “Six occupations…will be among both the fastest growing occupations and the occupations that register the largest numeric growth:”

20. IT project failure rates are high 20 Source: Standish Group, 2007

21. Software failures are legion 21 The London Stock Exchange (LSE) shut down for seven hours on Monday due to a software problem as opposed to too much trading volume as was initially speculated, Reuters reported. Reuters quoted an LSE spokesperson as saying: It was software-related, a coincidence, due to two processes we couldn't have foreseen. We've introduced a fix and we're confident it will not happen again. Source: Charette, R. (2008, September 10). London Stock Exchange shutdown caused by software problem. Message posted to http://blogs.spectrum.ieee.org/riskfactor/2008/09/london_stock_exchange_shutdown.htmlhttp://blogs.spectrum.ieee.org/riskfactor/2008/09/london_stock_exchange_shutdown.html

22. 22 Topic Duration Questionnaire & Intros30 minutes Does software engineering matter?45 minutes *** Break15 minutes Course overview15 minutes Key models and frameworks90 minutes Today’s Agenda

23. 23 Activity – Software categories In small groups, develop a 1-minute summary of one of the following: System software Application software (custom) Application software product Engineering/Scientific software Embedded software Web-based applications For each, describe and discuss software engineering challenges

24. 24 System software Description Challenges

25. 25 Application software (custom-built) Description Challenges

26. 26 Application software (product) Description Challenges

27. 27 Engineering/Scientific software Description Challenges

28. 28 Embedded software Description Challenges xx

29. 29 Web-based applications Description xx Challenges xx

30. 30 Technology Process People The software engineering discipline consists of people, process, and technology components Core Concepts

31. 31 Technology 1 Process People The focus of SE 425 is the process component of software engineering Core Concepts Technology 1 Process People … for the delivery of technology-enabled business solutions 1 SE is primarily concerned with the software subset of technology

32. Core Concepts process Sequence of steps performed for a given purpose “A specific ordering of work activities across time and place with a beginning, an end, and clearly identified inputs and outputs” -- Tom Davenport An overloaded term, can apply at multiple levels 32

33. 33 software process (also known as “method”) Within the context of software engineering, a formalized approach or series of steps for performing some significant portion of software development Software Process (aka “Methodology”) A collection of methods based on a common philosophy that fit together in a framework called the systems development life cycle -- Ken Orr Core Concepts

34. 34 A systematic way of doing something Typically consists of these key content pieces: 1.Steps (what) 2.Deliverables (what) 3.Techniques (how) 4.Roles (who) 5.Estimating guidelines (how long) In SE 425, we will use the terms “software process” and “Software Process” interchangeably Core Concepts

35. 35 Key Question:Deliverables StepsTechniques What does the system need to do? Functional requirements Quality requirements Data model Process model 1.Gather requirements 2. Create data model 3. Create process model Interviewing Observation Entity-relationship modeling Normalization Data flow modeling Example: Analysis RolesEstimating guidelines Business analyst Domain expert End user 8 hours per data entity etc.

36. 36 Justifying a Methodology Vendors and consultants have not done much to substantiate quantitatively the value of their methodologies What would you say if asked to provide justification?

37. 37 Justifying a Methodology Reasons xx

38. 38 Common Drivers Behind Methodology Adoption Project failure leads to realization that “we need a more formal process” Codify best practices, so as to increase predictability and reliability of software development process especially as IT organization grows Continued pressure on time to market and quality (web services) Certification (e.g., Capability Maturity Model) Desire to stay current and/or sustain/develop competitive edge Need to support distributed development teams (multi-site and/or multi-organization)

39. 39 Methodology - Who needs it? “Any first attempt at converting folklore into knowledge, and a guessing game into a discipline, is liable to be misread as a downgrading of individual ability and its replacement by a rule book. Any such attempt would be nonsense, of course. No book will ever make a wise man out of a donkey or a genius out of an incompetent. The foundation in a discipline, however, gives to today’s competent physician a capacity to perform well beyond that of the ablest doctor of a century ago, and enables the outstanding physician of today to do what the medical genius of yesterday could hardly have dreamt of. No discipline can lengthen a man’s arm. But it can lengthen his reach by hoisting him on the shoulders of his predecessors. Knowledge organized in a discipline does a good deal for the merely competent; it endows him with some effectiveness. It does infinitely more for the truly able; it endows him with excellence.” From Managing for Results, by Peter F. Drucker

40. 40 Systems development life cycle (SDLC) A description of the phases of an information system PlanningModelingConstruction Deployment Example Core Concepts SDLC is another synonym for software process

41. 41 SDLC model The iteration and control strategy adopted by a systems development initiative Examples - Waterfall - Iterative/Evolutionary/Spiral - Incremental - Agile Core Concepts

42. 42 The waterfall model is the granddaddy of life cycle models Core Concepts Planning Modeling Construction Deployment

43. 43 Advantages of waterfall?

44. 44 What’s wrong with waterfall?

45. 45 Protracted integration and late breakage Conventional application of the waterfall model typically results in late integration and performance showstoppers Development progress (% coded) 100% Late design breakage Original target date Source: Royce, W. (1998). Software project management: A unified framework. Addison-Wesley. Integration begins What’s wrong with waterfall?

46. 46 Iterative/Evolutionary/Spiral life cycle models advocate multiple “threads” through the SDLC phases MCD Version 1 MCD Version 2 MCD Version 3 Core Concepts

47. 47 Incremental life cycle models advocate delivering the end product piecemeal MCD Version 1 MCD Version 2 MCD Version 3 Core Concepts

48. 48 Waterfall model System requirements Software requirements Analysis Program design Coding Testing Operations Source: Royce, W. (1970). "Managing the Development of Large Software Systems."

49. 49 Rational Unified Process (RUP)

50. 50 RUP Guiding Principles Iterative Development Quality Customer Value Attack risk Accommodate change Work together Executable software Architecture baseline Component-based development Objectives Strategies Tactics

51. 51 MCD Version 1 MCD Version 2 MCD Version 3 Iterative Development

52. 52 In RUP, end product is the result of development cycles Version 1 Development CycleVersion 2 Development Cycle Version 3 Development Cycle Product delivered to users

53. 53 Development cycle consists of phases Development Cycle InceptionElaborationConstructionTransition

54. 54 Phase consists of Iterations Development Cycle Elaboration Iteration n Iteration n+1

55. 55 Iteration consists of Activities Development Cycle Elaboration Iteration n+1 Iteration n R A&D C T R C T Each phase contains one or more iterations

56. 56 Each Iteration is a mini-waterfall R A&D C T R C T R C T

57. 57 Iterative Advantages/Disadvantages Advantages Disadvantages

58. 58 Iterative Advantages/Disadvantages Advantages Resolves risks before making large investments Enables early user feedback Makes testing and integration continuous problems are discovered when they are easier to address minimizes later rework Focuses on most essential requirements Makes partial deployments possible Accelerates project team learning Facilitates reuse Disadvantages Waterfall life cycle is more familiar since it is similar to hardware life cycle Iterative Life Cycles difficult to estimate and manage. Only recently used on real projects - therefore little track record Rework takes place from one iteration to the next Iterative life cycle best used for problems that are not well understood.

59. 59 Copyright © 1997 by Rational Software Corporation Risk Transition Inception Elaboration Construction Preliminary Iteration Architect. Iteration Architect. Iteration Devel. Iteration Devel. Iteration Devel. Iteration Transition Iteration Transition Iteration Post- deployment Waterfall Time Risk Profile: Iterative vs. Waterfall Iterative

60. 60 Is RUP = Waterfall in disguise? System requirements Software requirements Analysis Program design Coding Testing Operations Inception Elaboration Construction Transition

61. 61 Phase boundaries in waterfall are activities System requirements Software requirements Analysis Program design Coding Testing Operations Phase

62. 62 Phase boundaries in RUP are milestones System requirements Software requirements Analysis Program design Coding Testing Operations RUP Phase Milestone

63. 63 RUP Guiding Principles Iterative Development Quality Customer Value Attack risk Accommodate change Work together Executable software Architecture baseline Component-based development Objectives Strategies Tactics

64. 64 Why focus on risk and change? Life cycle phase Cost of change Req Anal.Des. Impl.Test Prod y = ax p

65. 65 RUP Guiding Principles Iterative Development Quality Customer Value Attack risk Accommodate change Work together Executable software Architecture baseline Component-based development Objectives Strategies Tactics

66. 66 Why emphasis on executable software? “Without this first pass, the project manager is at the mercy of human judgment. With this first-pass ‘simulation,’ he can at least perform experimental tests of some key hypotheses and scope down what remains for human judgment, which in the case of computer program design... is invariably and seriously optimistic”

67. 67 RUP Artifacts by Phase and Discipline Discipline InceptionElaborationConstructionTransition Business Modeling Requirements Vision Use Cases (20-80%) Actors Software Req Spec Glossary Analysis & Design Software Arch Doc Implementation Build Plan Build Test Results Test Test Plan Test Script Test Data Test Results Test Strategy Deployment Deployment Plan Training Materials Support Materials Acceptance Test Results Change Requests Product Executable Architecture User Interface Prototype User Interface Design Use Case Realization Design Model Database Design Business Architecture

68. 68 RUP Artifacts by Phase and Discipline Discipline InceptionElaborationConstructionTransition Configuration and Change Management Project Management Risk List Risk Mgmt Plan Business Case QA Plan Software Dev Plan Environment Dev Case (Process) Tools Guidelines Templates Support CM Plan CM Environment Change Requests

69. 69 Agile/Light/Lean Methods On February 11-12, 2001 seventeen proponents met at Snowbird ski resort and what emerged was the: Agile “Software Development” Alliance “We have come to value: Individuals and interactionsoverprocesses and tools Working software overcomprehensive documentation Customer collaborationovercontract negotiation Responding to changeoverfollowing a plan”

70. 70 ApproachReferences XPwww.extremeprogramming.org www.xprogramming.com M. Marchesi et al, Extreme Programming Perspectives, Addison-Wesley, 2002. CrystalA. Cockburn, Agile Software Development, Addison-Wesley, 2001 SCRUMK. Schwaber and M. Beedle, Agile Software Development with Scrum, Prentice Hall, 2001. Adaptive Software Development J. Highsmith, Adaptive Software Development, Dorset House, 2000. FDDS. Palmer, A Practical Guide to Feature-Driven Development, Prentice Hall, 2002. Agile - Generalhttp://www.agilealliance.org/home http://www.agilemodeling.com Agile/Light/Lean Methods

71. 71 XP Background Developed by Kent Beck and Ward Cunningham Based on Beck and Ward’s experiences developing Smalltalk software at Tektronix First large project was the C3 Payroll Project at Chrysler 1993 project started with Business Modeling 1994 development begun with a small 40 person consulting firm & Smalltalk 1995 performance problems - Kent Beck brought in to improve quality 1996 Kent Beck took over project and began implementing project in a new method that we now call Extreme Programming (XP)

72. 72 RUP Guiding Principles Iterative Development Quality Customer Value Attack risk Accommodate change Work together Executable software Architecture baseline Component-based development Objectives Strategies Tactics

73. 73 XP Conceptual Framework Iterative Development Quality Customer Value Attack risk Accommodate change Work together Executable software Architecture baseline Component-based development Objectives Strategies Practices

74. 74 Phase boundaries in waterfall are activities System requirements Software requirements Analysis Program design Coding Testing Operations Phase

75. 75 Phase boundaries in RUP are milestones System requirements Software requirements Analysis Program design Coding Testing Operations RUP Phase Milestone

76. 76 XP winds the RUP model more tightly System requirements Software requirements Analysis Program design Coding Testing Operations Each day on an XP project Functioning Code

77. 77 What is XP Life cycle phase Cost of change Req Anal.Des. Impl.Test Prod y = ax p RUP – “In general, as the project progresses, you should be more careful about introducing change”

78. 78 What is XP Time Cost of change XP purports to change the curve so that the cost to find and repair software problems does not rise dramatically over time

79. 79 RUP vs. XP AttributeRUP (“Heavyweight”)XP (“Lightweight”) Time and Effort Allocation2 weeks-6 months2 weeks - 2 months ArchitectureStabilized during Elaboration phase Just enough to support functionality Scope of Activities and Artifacts BroadNarrow Few, simple. Omits: Business modeling Deployment Project sizeSmall to Very LargeSmall to Medium Artifacts25-30 in small project roadmap roughly 30 Roles~ 30 (5 in small project roadmap) 7

80. 80 Read Pressman Chapters 1-4, 7-8 Read Royce article Assignment 1- Critique the Royce article For September 18

81. 81 Extra slides

82. 82 Solution “Stack” Application software and Data Middleware Hardware/Network System Software Examples Workstations, Mobile devices Servers, storage Routers, switches Development tools, languages Web servers, App servers Database management systems Operating systems CRM ERP Payroll Application programming interfaces Transaction processing monitors Solution stack Public Infrastructure Internet Telecomm providers Business processes Customer service Product development

83. 83 Testing RequirementsFunctional Design Technical Design Detailed Design Code Unit Test Integration Test System Test Acceptance Test Flow of Work Verification Validation Testing: Test that the product implements the specification Legend:

84. 84 Four major forms of conversion