scaling up agility the architected agile approach
play

Scaling Up Agility: The Architected Agile Approach Barry Boehm, - PowerPoint PPT Presentation

Scaling Up Agility: The Architected Agile Approach Barry Boehm, USC JAOO 2009 October 5, 2009 10/05/2009 (c) USC-CSSE 1 Outline Increasing importance of both agility and quality Scalability, accuracy, availability, safety,


  1. Scaling Up Agility: The Architected Agile Approach Barry Boehm, USC JAOO 2009 October 5, 2009 10/05/2009 (c) USC-CSSE 1

  2. Outline • Increasing importance of both agility and quality – Scalability, accuracy, availability, safety, … • Challenges of achieving both agility and quality • Approaches for achieving both agility and quality • Case studies and critical success factors • Conclusions 10/05/2009 (c) USC-CSSE 2

  3. Need for Agility: Increasing Pace of Change • Technology change • Related infrastructure and services • Marketplace dynamics • Competition dynamics • Organizational change • Software is critical • User agility aids are even more critical 10/05/2009 (c) USC-CSSE 3

  4. The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individuals and interactions over processes and tools tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 10/05/2009 (c) USC-CSSE 4

  5. The Need for Software Quality • “The world runs on software” – Stroustrup • “With C, you can easily shoot yourself in the foot. With C++, you can easily blow off your leg” – Stroustrup • Critical global infrastructure: finance, energy, • Critical global infrastructure: finance, energy, transportation, communications, trade • Dependability: everything you depend on – Accuracy, adaptability, affordability, availability, … – Complex attribute conflicts and tradeoffs 10/05/2009 (c) USC-CSSE 5

  6. Traditional Quality Approach • Complete, consistent, testable requirements • Traceable to design, code, test cases • Heavyweight documentation • COCOMO documentation rates, Very High • COCOMO documentation rates, Very High Reliability projects – Average 120 pp/KSLOC; median 83; range 32-241 • Rewriting needed for 1000 KSLOC project – 160 people; 120,000 pages of documentation – 1% change/month: 1200 pages (7.5 pages/person) – 10% change/month: 12,000 pages (75 pages/person) 10/05/2009 (c) USC-CSSE 6

  7. Sarbanes-Oxley • A new US Law – Congress’ response to Enron, WorldCom, et al – Internal Controls: evaluate and disclose effectiveness – Disclose fraud – Affects public companies and “significant” vendors • Development process must include internal controls for for – Fraud – Asset Management and Safeguarding – Financial Reporting • Why is this important to executive management? – Executives can go to jail. – IT management can be held grossly negligent and sued by a company or shareholders. • In effect since 2004 10/05/2009 (c) USC-CSSE 7

  8. What an Auditor Looks for… Processes and tools over individuals and interactions Comprehensive documentation over working software Contract negotiation over customer collaboration Following a plan over responding to change Following a plan over responding to change An Auditor Manifesto? 10/05/2009 (c) USC-CSSE 8

  9. Average Change Processing Time: 2 Systems of Systems 160 140 120 • Average number of 100 days to days to 80 process 60 changes 40 20 0 Within Across Contract Groups Groups Mods 10/05/2009 (c) USC-CSSE 9

  10. Agile Methods and Quality • Responding to change over following a plan – Major source of software-induced rocket failures • Small releases: It’ll be fixed by next month – OK for discomfort; not for safety – OK for discomfort; not for safety • Test-driven development helps, but often leads to patching – Example: Ada compiler validation suite 10/05/2009 (c) USC-CSSE 10

  11. Agile and Plan-Driven Home Grounds: Five Critical Decision Factors • Size, Criticality, Dynamism, Personnel, Culture Personnel Personnel (% Level 1B) (% Level 1B) (% Level 2&3) (% Level 2&3) 40 40 15 15 30 30 20 20 20 20 20 20 25 25 25 25 Criticality Criticality Dynamism Dynamism (Loss due to impact of defects) (Loss due to impact of defects) 10 10 30 30 (% Requirements -change/month) (% Requirements -change/month) 0 0 35 35 Many Many 0.3 Lives Lives Single Single 1.0 Essential Essential 3.0 Life Life Discretionary Discretionary Funds Funds 10 Comfort Comfort Funds Funds 30 3 3 90 90 10 10 70 70 30 30 50 50 100 100 30 30 300 300 Size Size 10 10 (# of personnel) (# of personnel) Culture Culture (% thriving on chaos vs. order) (% thriving on chaos vs. order) 10/05/2009 (c) USC-CSSE 11

  12. Outline • Increasing importance of both agility and quality • Challenges of achieving both agility and quality • Approaches for achieving both agility and quality • Approaches for achieving both agility and quality • Case studies and critical success factors • Conclusions 10/05/2009 (c) USC-CSSE 12

  13. Using Risk to Balance Discipline and Agility - Overview Plan-driven risks Plan-driven risks Step 1. Step 1. Step 2. Step 2. dominate dominate Risk Analysis Risk Analysis Risk Risk Go Risk-based Go Risk-based Agile Agile Comparison Comparison Rate the project’s Rate the project’s environmental, agility- environmental, agility- Compare Compare oriented and plan-driven oriented and plan-driven the agile the agile Go Risk-based Go Risk-based risks. risks. and Plan- and Plan- Plan-driven Plan-driven Agility risks Agility risks driven risks driven risks dominate dominate Neither dominate Neither dominate Uncertain Uncertain No No Step 3. Step 3. Step 3. Step 3. about about about about Architecture Architecture ratings? ratings? Analysis Analysis Go Risk-based Go Risk-based Agile in agile Agile in agile Yes Yes Architect application to Architect application to parts; Go Risk- parts; Go Risk- encapsulate agile parts encapsulate agile parts based Plan- based Plan- Buy information via Buy information via driven elsewhere driven elsewhere prototyping, data prototyping, data collection and analysis collection and analysis Step 5. Step 5. Execute and Monitor Execute and Monitor Deliver incremental Deliver incremental Tailor life cycle process Tailor life cycle process Note: Feedback Note: Feedback capabilities according to capabilities according to around risk patterns around risk patterns loops present, loops present, strategy strategy and anchor point and anchor point but omitted for but omitted for commitment milestones commitment milestones simplicity simplicity Monitor progress and Monitor progress and risks/opportunities, risks/opportunities, readjust balance and readjust balance and Step 4. Step 4. process as appropriate process as appropriate Tailor Life Cycle Tailor Life Cycle 10/05/2009 (c) USC-CSSE 13

  14. Hybrid Agile/Plan-Driven Strategy – CRACK: collaborative, representative, authorized, committed, knowledgeable LCO LCA Startup Teambuilding Systems Architecting Development Stakeholders �!��������������������� �"���������������������� �������������� ����#������� �������������������� ���������������� �$������ ������������%� ���������� �������������� ���������������� ������������ ��������������������� ������ ����������������������� � Risk �������������� �������������� ������� ������� ������������ ������ � ������������ ������ � Project Leadership, Ris Management Teams �*������#(������� � �����#����*�����������+ ������������ ������ � �$������������������ � !����������������� �&��������� �����#����*� ���(������������ ����)� ��������� ������'����� ����������+ ���������� �������%� ��������(������)� ���������*������������� ����� ������������*���������������� ���%��������%���� ������������������� ���������� Agile, Plan Developers ����������������#��� ������������� ������ � Driven ����������*����� �����#����*����������� ���������� 10/05/2009 (c) USC-CSSE 14

Recommend


More recommend