Download presentation
Presentation is loading. Please wait.
1
James Nowotarski 19 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006
2
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
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
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 http://money.cnn.com/magazines/moneymag/bestjobs/
5
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), 41-49.
6
6 “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?
7
7 Buy vs. build Lease (utility model) vs. buy Open source vs. lease Software as a commodity? Does SE Matter?
8
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
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
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
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
14 Systems development life cycle (SDLC) PlanningModelingConstruction Deployment Example Core Concepts
15
15 SDLC model The iteration and control strategy adopted by a systems development organization Examples - Waterfall - Iterative/Evolutionary/Spiral - Incremental Core Concepts
16
16 The waterfall model is the granddaddy of life cycle models Core Concepts Planning Modeling Construction Deployment
17
17 What’s wrong with waterfall?
18
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
19 Incremental life cycle models advocate delivering the end product piecemeal MCD Version 1 MCD Version 2 MCD Version 3 Core Concepts
20
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
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
22 Modeling/Diagramming Technique Core Concepts
23
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
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
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
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
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
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
29 Why focus on change? Life cycle phase Cost of change Req Anal.Des. Impl.Test Prod y = ax p
30
30 Ways to Accommodate Change
31
31 Controlling Parallel Development Multiple developers Multiple teams Multiple sites Multiple iterations Multiple releases Multiple projects Multiple platforms
32
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
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
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
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
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
37 Benefits of Architecture
38
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
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
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
41 Benefits of Component Architectures Resilient Reuse proven solution elements
42
42 RUP “Hump” Diagram
43
43 MCD Version 1 MCD Version 2 MCD Version 3 Iterative Development
44
44 Product is the result of development cycles Version 1 Development CycleVersion 2 Development Cycle Version 3 Development Cycle Product delivered to users
45
45 Development cycle consists of phases Development Cycle InceptionElaborationConstructionTransition
46
46 Phase consists of Iterations Development Cycle Elaboration Iteration n Iteration n+1
47
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
48 Each Iteration is a mini-waterfall R A&D C T R C T R C T
49
49 Iterative Advantages/Disadvantages Advantages Disadvantages
50
50 Waterfall model System requirements Software requirements Analysis Program design Coding Testing Operations Source: Royce, W. "Managing the Development of Large Software Systems."
51
51 Is RUP = Waterfall in disguise? System requirements Software requirements Analysis Program design Coding Testing Operations Inception Elaboration Construction Transition
52
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
53 Inside each phase, you plan iterations across disciplines
54
54 Phase boundaries in RUP are milestones InceptionElaborationConstructionTransition
55
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
56 Phase boundaries in waterfall are activities System requirements Software requirements Analysis Program design Coding Testing Operations Phase
57
57 Phase boundaries in RUP are milestones System requirements Software requirements Analysis Program design Coding Testing Operations RUP Phase Milestone
58
58 RUP Artifacts by Phase and Discipline Discipline InceptionElaborationConstructionTransition Business Modeling Requirements Analysis & Design Implementation Test Deployment
59
59 RUP Artifacts by Phase and Discipline Discipline InceptionElaborationConstructionTransition Configuration and Change Management Project Management Environment
60
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
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
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
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
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
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
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
67 RUP Links RUP Resources http://www- 136.ibm.com/developerworks/rational/products/rup http://www- 128.ibm.com/developerworks/rational/products/rup
68
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
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
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
71 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
72
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
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
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
75 Phase boundaries in waterfall are activities System requirements Software requirements Analysis Program design Coding Testing Operations Phase
76
76 Phase boundaries in RUP are milestones System requirements Software requirements Analysis Program design Coding Testing Operations RUP Phase Milestone
77
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
78 Anatomy of XP Planning Terminology Release Iteration Story Activity consists of is produced by
79
79 What is XP Incremental Change MCD Version 1 MCD Version 2 MCD Version 3
80
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
81 What is XP “What is the simplest thing that could possibly work?” Flattened change curve Assume Simplicity Embrace Change
82
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
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
84 What is XP Quality is assumed Excellent, or Insanely excellent Quality Work
85
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
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
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
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
89 Read Pressman Chapter 25 Indiana Jones activity Assignment 5 – first batch For September 26
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.