James Nowotarski 19 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006

2 Note that we will skim or skip many of these slides In keeping with the principles of an agile process, we will adapt to the results and feedback as the class unfolds Disclaimer

3 Topic Duration Does software engineering matter? 15 minutes Recap of session 1 & assignment 130 minutes Rational Unified Process45 minutes *** Break Agile methods 60 minutes Self-test15 minutes Today’s Agenda

4 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, 2006, from

5 Does IT matter? 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),

6 “Why write your own application for word processing or 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), Does SE matter?

7 Buy vs. build Lease (utility model) vs. buy Open source vs. lease Software as a commodity? Does SE Matter?

8 Topic Duration Does software engineering matter? 15 minutes Recap of session 1 & assignment 130 minutes Rational Unified Process45 minutes *** Break Agile methods 60 minutes Self-test15 minutes Today’s Agenda

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) Core Concepts

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

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

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

13 Technology Process People The focus of SE 425 is the process component of software engineering Core Concepts Technology Process People … for the delivery of technology-enabled business solutions

14 Systems development life cycle (SDLC) PlanningModelingConstruction Deployment Example Core Concepts

15 SDLC model The iteration and control strategy adopted by a systems development organization Examples - Waterfall - Iterative/Evolutionary/Spiral - Incremental Core Concepts

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

17 What’s wrong with waterfall?

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

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

20 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 Contents of a Process Model. Example: Analysis RolesEstimating guidelines Business analyst End user etc. 8 hours per data entity etc.

21 1. Review existing data models 2. Define entities a.Independent b.Dependent, including Intersection entities 3. Define attributes and keys (primary, foreign) 4. Define relationships 5. Finalize ERD 6. Normalize 7. Integrate data models as required 8. Verify completeness of the data model 9. Validate the data model a.With users b.With the enterprise’s data administrator Process for Building Data Models Process technique available Diagramming technique available Core Concepts

22 Modeling/Diagramming Technique Core Concepts

23 1NF = No repeating groups 2NF = 1NF + no partial dependencies (non-key attribute dependent on portion of primary key) 3NF = 2NF + no transitive dependencies (non- key attribute dependent on another non-key attribute) Normalization (Process Technique) Core Concepts

24 Topic Duration Does software engineering matter? 15 minutes Recap of session 1 & assignment 130 minutes Rational Unified Process45 minutes *** Break Agile methods 60 minutes Self-test15 minutes Today’s Agenda

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

26 Continuously Verify Quality In the Rational Unified Process, quality is defined as: “ The characteristic identified by the following: satisfies or exceeds an agreed upon set of requirements, and assessed using agreed upon measures and criteria, and produced using an agreed upon process." More than simply "meeting requirements" or producing a product that meets user needs, or expectations, etc. Quality also includes identifying the measures and criteria to demonstrate the achievement of quality, and the implementation of a process to ensure that the product created by the process, has achieved the desired degree of quality (and can be repeated and managed).

27 Test Each Iteration Start testing early Continuously test Test each iteration for functionality and performance Iterative development makes regression testing necessary Use automated tests whenever possible

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

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

30 Ways to Accommodate Change

31 Controlling Parallel Development Multiple developers Multiple teams Multiple sites Multiple iterations Multiple releases Multiple projects Multiple platforms

32 Configuration Management Configuration Management is the process which controls the changes made to a software system and manages the different versions and releases of the evolving software products Librarian like function Manages the version number for each software product Changes made are controlled by a Change Control Process Can be managed manually or through the use of a configuration management tool (Difficult to do manually, but it can be done.) Check In Check Out Read only for others

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

34 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”

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

36 Architecture: Compelling need to stay ahead Think of the architecture as an “application” to be used by systems developers Architecture development and application development are related but separate activities that are staggered and occur in parallel: Architecture AnalyzeDesign ImplementSupport Application Analyze DesignImplement Support

37 Benefits of Architecture

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

39 Software Components Definition: A software component can be defined as a nontrivial piece of software, a module, a package, or a subsystem, that fulfills a clear function, has a clear boundary and can be integrated in a well-defined architecture. It is the physical realization of an abstraction in your design. Definition: A software component can be defined as a nontrivial piece of software, a module, a package, or a subsystem, that fulfills a clear function, has a clear boundary and can be integrated in a well-defined architecture. It is the physical realization of an abstraction in your design.

40 Components Airplane Private Data Object Operations Airplane Private Data Object Operations Engines Private Data Object Operations Engines Private Data Object Operations Wings Private Data Object Operations Wings Private Data Object Operations Fuselage Private Data Object Operations Fuselage Private Data Object Operations Tail Private Data Object Operations Tail Private Data Object Operations COMPONENTS - Are objects that are combined into new objects without the use of inheritance

41 Benefits of Component Architectures Resilient Reuse proven solution elements

42 RUP “Hump” Diagram

43 MCD Version 1 MCD Version 2 MCD Version 3 Iterative Development

44 Product is the result of development cycles Version 1 Development CycleVersion 2 Development Cycle Version 3 Development Cycle Product delivered to users

45 Development cycle consists of phases Development Cycle InceptionElaborationConstructionTransition

46 Phase consists of Iterations Development Cycle Elaboration Iteration n Iteration n+1

47 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

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

49 Iterative Advantages/Disadvantages Advantages Disadvantages

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

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

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

53 Inside each phase, you plan iterations across disciplines

54 Phase boundaries in RUP are milestones InceptionElaborationConstructionTransition

55 Milestones Exit criteria Decide to proceed, abort, or change course Measure progress, e.g., –use cases completed –features completed –performance requirements satisfied –risks eliminated –test cases passed

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

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

58 RUP Artifacts by Phase and Discipline Discipline InceptionElaborationConstructionTransition Business Modeling Requirements Analysis & Design Implementation Test Deployment

59 RUP Artifacts by Phase and Discipline Discipline InceptionElaborationConstructionTransition Configuration and Change Management Project Management Environment

60 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

61 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

62 Executable architecture is key artifact from Elaboration Executable architecture Driven by carefully selected use cases Essential Difficult Representative cross-section Addresses most risky technical elements Needs to satisfy functional and nonfunctional requirements (“ilities”) Performance, reliability, usability, availability, etc. Also concurrency, interprocess communication, data/process distribution, etc.

63 Unified Modeling Language (UML) “ The Unified Modeling Language™ (UML) is the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. It simplifies the complex process of software design, making a "blueprint" for construction” Modeling language, not a method Notation, or diagramming technique UML is independent of process Can be used with any process

64 Visual Modeling Using UML Actor A Use Case 1 Use Case 2 Actor B Window95 ¹®¼­°ü¸® Ŭ¶óÀ̾ðÆ®.EXE Windows NT ¹®¼­°ü¸® ¿£Áø.EXE Windows NT Windows95 Solaris ÀÀ¿ë¼­¹ö.EXE Alpha UNIX IBM Mainframe µ¥ÀÌŸº£À̽º¼­¹ö Windows95 ¹®¼­°ü¸® ¾ÖÇø´ Document FileManager GraphicFile File Repository DocumentList FileList Use Case 3 Use case diagram Class diagram Collaboration diagram Sequence diagram Component diagram Statechart diagram Deployment diagram

65 Types of UML Models Functional requirements models Use Cases Domain Models (glossary) Structural modeling Class Diagrams Object Diagrams Component Diagrams Deployment Diagrams Behavioral modeling Interaction Diagrams Sequence Diagrams Collaboration Diagrams Activity Diagrams State Chart Diagrams

66 Use Cases Typical interaction between a user and a computer system Example: Word use cases Make some text bold Create an index Content: A few paragraphs of description Essential tool in requirements capture during Inception and (mostly) during Elaboration Characteristics Captures some user-visible function May be small or large Achieves a discrete goal for the user

67 RUP Links RUP Resources ibm.com/developerworks/rational/products/rup ibm.com/developerworks/rational/products/rup

68 Topic Duration Does software engineering matter? 15 minutes Recap of session 1 & assignment 130 minutes Rational Unified Process45 minutes *** Break Agile methods 60 minutes Self-test15 minutes Today’s Agenda

69 Topic Duration Does software engineering matter? 15 minutes Recap of session 1 & assignment 130 minutes Rational Unified Process45 minutes *** Break Agile methods 60 minutes Self-test15 minutes Today’s Agenda

70 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”

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

72 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

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

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

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

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

77 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

78 Anatomy of XP Planning Terminology Release Iteration Story Activity consists of is produced by

79 What is XP Incremental Change MCD Version 1 MCD Version 2 MCD Version 3

80 What is XP “Don’t ask me, ask the system” “Have you written a test case for that yet” Put in production as soon as possible i.e., don’t “shelter” your code “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” – Royce, 1970 Rapid Feedback

81 What is XP “What is the simplest thing that could possibly work?” Flattened change curve Assume Simplicity Embrace Change

82 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”

83 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

84 What is XP Quality is assumed Excellent, or Insanely excellent Quality Work

85 What is XP Test all the time Continuous integration Pair programming Coding standards Collective ownership Do simplest thing that will work today “design tomorrow for tomorrow’s problems” Metaphor to aid in understanding the architecture Refactoring and evolutionary design Key Practices/Features

86 What is XP Customer on-site as integral part of team Incremental planning learning to drive programmers provide estimates Short iterations, small releases 2 month releases, 2 week iterations 40-hour week Key Practices/Features (cont.)

87 What is XP Start design with a test Start coding with a test Test things that might break Testing is isolated Testing is integrated Testing is automated At least one dedicated tester Begin with the end in mind...

88 Topic Duration Does software engineering matter? 15 minutes Recap of session 1 & assignment 130 minutes Rational Unified Process45 minutes *** Break Agile methods 60 minutes Self-test15 minutes Today’s Agenda

89 Read Pressman Chapter 25 Indiana Jones activity Assignment 5 – first batch For September 26