Two Branches of Software Engineering

Size: px

Start display at page:

Download "Two Branches of Software Engineering"

Nigel Jefferson
6 years ago
Views:

1 ENTERPRISE SOFTWARE ENGINEERING & SOFTWARE ENGINEERING IN THE ENTERPRISE Two Branches of Software Engineering 1 Crafting Software Resource Input Code Debug Product Test 2

2 Engineering Software Resource Input F R PM D C RA T Product 3 Build a Bridge vs. Build Software Design 10% Construction 90% Design 90% Construction 10%

3 Waterfall vs. Iterative & Incremental 6

4 The Waterfall Process Big Requirements Up Front (BRUF) System Requirements Software Requirements But Analysis Program Design Coding V&V Operations

The Waterfall Process Big Requirements Up Front (BRUF) System Requirements Software Requirements Specification Preliminary Design Document Software Requirements Prelim.

5 The Waterfall Process Big Requirements Up Front (BRUF) System Requirements Software Requirements Specification Preliminary Design Document Software Requirements Prelim. Review UI Design Document Preliminary Design Preliminary Design Analysis Final Design Analysis Design Review Program Design Program Design V&V Plan Coding Testing Usage Coding V&V Operating Instructions Operations

6 Risks in Waterfall and Iterative Methods We do risky things first R I S K Iterative development Waterfall T I M E 12

7 The Cost of Change in Waterfall and Iterative Methods WF Iterative Do it right the first time! 14

8 Gimme all requirements, or. Waterfall vs. Iterative & Incremental But... 16

9 TWO BRANCHES OF SOFTWARE ENGINEERING CAPABILITY MATURITY MODEL INTEGRATION (CMMI) 17

10 19 Intro Software Engineering Institute (SEI) at Carnegie Mellon University developed the first integrated CMMI models in 2000, together with associated appraisal and training materials; 2002 saw the release of CMMI version 1.1. In 2010 the CMMI version 1.3 was released 20

11 The History of CMMs 21 CMMI: 3 Complementary Constellations

12 DoD / Carnegie Melon University / Software Engineering Institute 23 Aircraft Software Size Chronology

13 CMMI Model Representations Staged Continuous ML5 ML4 ML3 ML2 ML 1 Organization Capability PA PA Process PA 25 Characteristics of the Maturity Levels High maturity 26

14 CMMI DEV Staged Representation Level Focus Process Areas Continuous Organizational Innovation and Deployment 5 Optimizing Process Causal Analysis and Resolution Improvement 4 Quantitatively Managed Quantitative Management Organizational Process Performance Quantitative Project Management Quality Productivity 3 Defined Process Standardization Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition (+ IPPD extras) Organizational Training Integrated Project Mgmt (+ IPPD extras) Risk Management Decision Analysis and Resolution Example 2 Managed 1 Initial Basic Project Management Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management Risk Rework Expected CMMI Model Structure Required Staged Continuous Maturity Levels Process Area 1 Process Area 2 Process Area n Process Area 1 Process Area 2 Process Area n Specific Goals Generic Goals Specific Goals Generic Goals Common Features Commitment to Perform Ability to Perform Directing Implementation Verifying Implementation Capability Levels Specific Practices Generic Practices Specific Practices Generic Practices 28

15 Specific Practices Associated with Specific Goals Process Area: Requirements Management Specific Goal REQM SG 2.1 1: Requirements are managed and inconsistencies with project plans and work products are identified. Specific Practice REQM SP 2.1 1: Establish Product and Product Component Requirements 29 An Example Requirements Development SP Establish Product and Product Component Requirements Establish and maintain, from the customer requirements, product and product component requirements essential to product and product component effectiveness and affordability ISO/IEC 15288, System Life Cycle Processes Clause Requirements Analysis Process IEEE/EIA , Software Life Cycle Processes Clause System Requirements Analysis Clause Software requirements analysis IEEE 1233, Guide for Developing System Requirements Specifications IEEE 830, Software Requirements Specifications

An Example Requirements Development SP 2.

product Clause 5.5.3 Requirements Analysis Process 5.5.3 Requirements Analysis Process 5.5.3.1 and Purpose product of the component Requirements Analysis Process IEEE/EIA 12207.

product requirement driven component view of desired services into a technical view of a required product that could deliver those services.

2 System Requirements This process builds a representation of a future system that will meet Analysis stakeholder requirements and that, as far as

4 Software requirements requirements that specify, from the developer s perspective, what analysis characteristics it is to possess and with what magnitude

2 Requirements Analysis Process Outcomes As a result of the successful implementation of the Requirements IEEE Analysis 1233, Guide for Developing System

16 An Example Requirements Development SP Establish Product and Product Component Requirements ISO/IEC 15288, System Life Cycle Processes Establish and maintain, from the customer requirements, product Clause Requirements Analysis Process Requirements Analysis Process and Purpose product of the component Requirements Analysis Process IEEE/EIA , Software Life Cycle The requirements purpose of the Requirements essential Analysis to product Process is to transform the Processes stakeholder, and product requirement driven component view of desired services into a technical view of a required product that could deliver those services. effectiveness and affordability Clause System Requirements This process builds a representation of a future system that will meet Analysis stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system Clause Software requirements requirements that specify, from the developer s perspective, what analysis characteristics it is to possess and with what magnitude in order to satisfy stakeholder requirements Requirements Analysis Process Outcomes As a result of the successful implementation of the Requirements IEEE Analysis 1233, Guide for Developing System Process: Requirements Specifications a) The required characteristics, attributes, and functional and performance requirements for a product solution are specified. IEEE 830, Software Requirements b) Constraints that will affect the architectural design of a system and the means to realize it are specified. Specifications c) The integrity and traceability of system requirements to stakeholder requirements is achieved.... Source: ISO/IEC CD FDIS, ISO/IEC2002. Paul R. Croll 31 SW Industry vs. NASA 10 MLOC 6 SIGMA 3.4 Defects Per Million Opportunities DPMO 32

17 SW Requirements: IEEE SW Requirements: IEEE

18 SW Requirements: IEEE 830 Requirements in Extreme Programming and SCRUM: User Stories 35

19 TWO BRANCHES OF SOFTWARE ENGINEERING AGILE METHODOLOGIES 37 Q: How do you eat an Elephant? A: One increment at a time!

20 Agility Defined Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. Agility is the ability to balance flexibility and stability. 39 It's an Agile World 40

21 Agile 2001 vs vs Scrum; 3% Lean; 7% Other; 17% XP; 38% DSDM; 19% ASD; 22% FDD; 23% extreme Programming (XP): 38% 4% Scrum: 3% 58% 41 The Goal of Scrum Manage Complexity, Unpredictability and Change through Visibility, Inspection and Adaptation

22 Scrum Today: 1 2 weeks 43 Roles Scrum Framework Product owner ScrumMaster Team Ceremonies Sprint planning Sprint review Sprint retrospective Daily scrum meeting Artifacts Product backlog Sprint backlog Burndown charts

23 The Boss The Boss

24 Product Owner Owner of project vision Represents the customer Scrum Master Servant leader Team protector Troubleshooter Scrum guide

25 The Team Small (5 9 people) Colocated Cross functional Self organized Full time Sprint Planning Team capacity, Product backlog, Current product, Business, Technologies + Goal =

Daily Scrum Meeting Parameters Daily 15 minutes

invited Only team members, ScrumMaster, product

other unnecessary meetings 51 Daily Scrum Meeting

26 Daily Scrum Meeting Parameters Daily 15 minutes Stand up Not for problem solving Whole world is invited Only team members, ScrumMaster, product owner, can talk Chickens and Pigs Helps avoid other unnecessary meetings 51 Daily Scrum Meeting Parameters Daily What did you do yesterday? 15 minutes What will you do today? Stand up Not for problem Is solving anything in your way? Whole world is invited Only team members, ScrumMaster, Product Owner, can talk Chickens and Pigs Developer oriented 52

27 Sprint Review Satisfy Product Owner Get feedback on product

28 Sprint Retrospective Evolve theprocess Scrum & XP 56

29 Scrum & XP Scrum & Agile Whatever Whatever agile agile practices practices you you like like 57 Scrum and XP (most common practices) Pair programming Test-driven development Collective code ownership Coding standards

30 Stories,Themes and Epics 59 User Stories Mike Cohn 60

31 User Stories Mike Cohn = value for user 61 Team capacity Product backlog Business conditions Current product Technology Sprint planning meeting Sprint prioritization Analyze and evaluate product backlog Select sprint goal Sprint planning Decide how to achieve sprint goal (design) Create sprint backlog (tasks) from product backlog items (user stories / features) Estimate sprint backlog in hours Sprint goal Sprint backlog

32 Scalability Scalability Typical individual team is 7 ±2 people Scalability comes from teams of teams Factors in scaling Type of application Team size Team dispersion Project duration Scrum has been used on multiple 500+ person projects

33 Scaling Through the Scrum of Scrums Scrum of Scrums of Scrums

34 Scrum Advantages Completely developed and tested features in short iterations Simplicity of the process Clearly defined rules Increasing productivity Self organizing Each team member carries a lot of responsibility Improved communication

35 Agile Planning Scrum

36 Scrum 5 Level Planning Dwight David "Ike" Eisenhower Plans are nothing; planning is everything.

37 Level 1: Product Vision Planning (1 2 per year) Level 2: Product Roadmap Planning (1 4 per year)

38 Level 3: Product Release Planning (4 12 per year) Level 4: Sprint Planning (Every Sprint 1 4 weeks)

39 Level 5: Daily Scrum (Every day) Agile Planning Summary

40 Agile Processes Agile Process (Generalized)

41 The Agile Paradigm Shift Waterfall Agile Constraints Requirements Cost Schedule Plan Driven Value /Vision Driven Estimates Cost Schedule Features The Plan creates cost/schedule estimates The Vision creates feature estimates 81 A Continuous Flow of Iterations that Deliver Working Increments 82

42 Traditional vs. Agile Traditional: Plan what you expect to happen Enforce that what happens is the same as what is planned Directive management Control, control, control Use change control to manage change Change Control Board Defect Management Agile: Plan what you expect to happen with detail appropriate to the horizon Control is through inspection and adaptation Use Agile practices to manage change: Continuous feedback loops Iterative and incremental development Prioritized backlogs 83 How Organizations Become More Responsive *D. Anderson: Agile Software Management Accounting for Systems Three Levers to Increase Responsiveness Increase Throughput Decrease Investment Decrease Operating Expense Shorten cycle times to speed delivery of functionality to customers Reduce inventory and the cost capture, elaboration, communication and scheduling Eliminate waste to produce higher quality with less effort 84

Parallel Acceptance Test Driven Cycle Time Year + Increase Throughput 2

Feedback Delays Most Defects caught in system test Decreased Operating

Decrease Risk $50,000 85 Agile Agile Development Process Waterfall

Parallel Development Acceptance Test Driven Development Measure of Success

43 Traditional vs. Agile Agile Development Waterfall Iterative Iterative and Incremental Parallel Acceptance Test Driven Cycle Time Year + Increase Throughput 2 weeks Detailed Inventory Whole Project Decrease Investment Increment Feedback Delays Most Defects caught in system test Decreased Operating Expense Most defects caught in the feature development Risks $1,200,000 Decrease Risk $50, Traditional vs. Agile Agile Development Process Waterfall Development Iterative Development Iterative and Incremental Development Parallel Development Acceptance Test Driven Development Measure of Success Conformance to Plan Response to Change Culture Command-and-Control Leadership /Collaborative Design Big Design Up Front Continuous QA Big Test on Backend Continuous 86

44 Why Agile? 87 Summary

45 Respect Complexity Five Key Benefits of Agile, which all executives have heard about:

46 Agile vs. CMMI Process Process Complexity Chaos Agile CMMI

47 Two Branches of Software Engineering Agile vs Traditional

Leaders Do Right Things 95 Creators and stewards The problem the creators have is that they want to go for the big prize, to realize their visions in pure form; anything short of

48 Leaders Do Right Things 95 Creators and stewards The problem the creators have is that they want to go for the big prize, to realize their visions in pure form; anything short of that they see as less than successful. The stewards, on the other hand, can't get excited about an innovation until they understand how the economic value (profit) will be created 96

49 Simple Rules Agile Success There is no silver bullet but agile methods come close

50 Dimensions Affecting Method Selection 99 The Five Critical Agility/Discipline Decision Factors 100

51 If all you have is a hammer, everything looks like a nail AGILE More Fun, Happy Teams 102

Agile Essentials Track: Business Services

Agile Essentials Track: Business Services Presenter: Mark Thomas Synopsis Are you a victim of building the wrong solutions slowly? If so, you re not alone, and considering an Agile approach may be the