Using Agile Software Development to Create an Operational Testing Tool

Transcription

1 DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited. ITEA Technology Review July 2011 Using Agile Software Development to Create an Operational Testing Tool 21 Jul 2011 F.T. Case Jennifer Ockerman

2 Contributors FT Case, Daryl Davis, Pam Jadwick, Bryan Johnson, Arthur Kang, Michael Moreno, Jennifer Ockerman, Dan Peletier, and Chris Steen Johns Hopkins University Applied Physics Laboratory Laurel, MD Susi McKee 505 th Command and Control Wing Hurlburt Field, FL 2

3 Motivation Rapid product development User needs definition to concept development to capability delivery within two years Classic Systems Engineering method did not seem appropriate for rapid product development Not enough time to complete the SE cycle Not enough money to fund the work required Blended classic Systems Engineering with an agile design and development approach Meet rapid design and development needs but still deal with expectations of sponsor for traditional acquisition deliverables 3

4 Agile Software Development A collection of software development methodologies Ex. Scrum, Extreme Programming, Feature Driven Development, etc. Focuses on incremental, iterative development of requirements, design, and products Strives for continual, heavy collaboration between the end user and the software development team Provides useful products to end users early and often throughout development Adapts to changing requirements as customer needs evolve 4

5 The Blended Approach Determined customer needs through multiple knowledge elicitation sessions Created total system requirements and top-level design upfront for sponsor approval Used agile methodology know as Scrum during system development Each sprint had a defined focus and product Initial System Requirements Review Interim Design Reviews Customer Needs Requirements Design Activities Development Testing Delivery Final System Requirements Review Critical Design Review 5

6 The Blended Approach Capabilities 12 Capabilities 6

7 The Blended Approach User Needs Analysis C M Capabilities A R Business Process Use Cases Capabilities 12 Needs - 27 Collect - 10 Analyze - 9 Manage - 4 Report - 5 7

8 The Blended Approach User Needs Analysis Use Case Definition Functional Requirements Decomposition C M Capabilities A R C A Business Process Use Cases Functional Req s Capabilities 12 Needs - 27 Collect - 10 Analyze - 9 Manage - 4 Report - 5 System Req s Collect - 74 Analyze - 28 Manage -15 Report - 19 M R 8

9 The Blended Approach User Needs Analysis Use Case Definition Functional Requirements Decomposition C M Capabilities A R C A M R Business Process Use Cases Functional Req s H/W Config Items Design Process Software Requirements Decomposition S/W System Arch Info Assure Application Service Abstraction Data S/W Config Items Capabilities 12 Needs - 27 Collect - 10 Analyze - 9 Manage - 4 Report - 5 System Req s Collect - 74 Analyze - 28 Manage -15 Report - 19 Config Items 59 S/W - 35 H/W 24 9

10 The Blended Approach User Needs Analysis Use Case Definition Functional Requirements Decomposition C M Capabilities A R C A M R Business Process Use Cases Functional Req s Design Process H/W Config Items Software Requirements Decomposition S/W System Arch Info Assure Application Service Abstraction Data S/W Config Items S/W Dev Sprints Capabilities 12 Needs - 27 Collect - 10 Analyze - 9 Manage - 4 Report - 5 System Req s Collect - 74 Analyze - 28 Manage -15 Report - 19 Config Items 59 S/W - 35 H/W - 24 Dev Sprints

11 The Blended Approach User Needs Analysis Use Case Definition Functional Requirements Decomposition C M Capabilities A R C A M R Business Process Use Cases Functional Req s Design Process Software Requirements Decomposition H/W Config Items Integration Test S/W System Arch Info Assure Application Service Abstraction Data S/W Config Items S/W Dev Sprints Capabilities 12 Needs - 27 Collect - 10 Analyze - 9 Manage - 4 Report - 5 System Req s Collect - 74 Analyze - 28 Manage -15 Report - 19 Config Items 59 S/W - 35 H/W - 24 Dev Sprints

12 The Blended Approach User Needs Analysis Use Case Definition Functional Requirements Decomposition C M Capabilities A R C A M R Business Process Use Cases DT Functional Req s Design Process Software Requirements Decomposition H/W Config Items Integration Test S/W System Arch Info Assure Application Service Abstraction Data S/W Config Items S/W Dev Sprints Capabilities 12 Needs - 27 Collect - 10 Analyze - 9 Manage - 4 Report - 5 System Req s Collect - 74 Analyze - 28 Manage -15 Report - 19 Config Items 59 S/W - 35 H/W - 24 Dev Sprints

13 The Blended Approach User Needs Analysis Use Case Definition Functional Requirements Decomposition C M Capabilities A R OT C A M R Business Process Use Cases DT Functional Req s Design Process Software Requirements Decomposition H/W Config Items Integration Test S/W System Arch Info Assure Application Service Abstraction Data S/W Config Items S/W Dev Sprints Capabilities 12 Needs - 27 Collect - 10 Analyze - 9 Manage - 4 Report - 5 System Req s Collect - 74 Analyze - 28 Manage -15 Report - 19 Config Items 59 S/W - 35 H/W - 24 Dev Sprints

14 The Blended Approach Training User Needs Analysis Use Case Definition Functional Requirements Decomposition C M Capabilities A R OT C A M R Business Process Use Cases DT Functional Req s Design Process Software Requirements Decomposition H/W Config Items Integration Test S/W System Arch Info Assure Application Service Abstraction Data S/W Config Items S/W Dev Sprints Capabilities 12 Needs - 27 Collect - 10 Analyze - 9 Manage - 4 Report - 5 System Req s Collect - 74 Analyze - 28 Manage -15 Report - 19 Config Items 59 S/W - 35 H/W - 24 Dev Sprints

15 Agile Design Funnel Customer s Business Process Customer Needs Business Use Cases System Requirements Software Use Cases Design Feasibility Assessments User Interface Mockups Hardware Architecture Software Architecture Configuration Items Developer Work Packages (Stories) 15

16 Agile Development Process Development occurs during focused work intervals [sprints] Variable duration: two four six weeks Project s system engineer [product owner] creates work packages [stories] for the developers Describe the capability to be developed, Includes verification criteria for testing the capability Traceable to the system requirements [features] During the pre-sprint planning session Product owner selects stories to be completed in the sprint, assigns each a sprint priority, and describes them to the developers Developers assess the level-of-effort to produce the stories as described and assign units of work [story points] to each work package Developers select stories to work based on sprint priorities and their own knowledge and strengths Code for each story is tested against its own story verification criteria Stories are unit tested by independent test team. Defects are assessed and given a defect priority Defects are fixed based on priority, or severity Completed stories with no Pri 1 defects are demonstrated at the end of the sprint 16

17 Ideal Sprint Schedule 17

18 Life of a Story 18

19 Contents of a Work Package 19

20 The System s Work Packages NEW (10) REVIEW COMPLETE (4) READY FOR DEVELOPMENT (5) IN DEVELOPMENT (4) READY FOR TESTING (4) IN TESTING (0) READY FOR DEMO (8) DEMONSTRATED (23) 20

21 Sprint Metrics Reviewed at Daily Scrum 21

22 Demonstrate System Capability to Customers 22

23 Successes Satisfied sponsor need for requirement and configuration item documentation in early stages Established a collaborative development lab to maintain contact with customer/sponsor/remote team members during project execution Telecon lines, web-based collaboration tools Self-synchronization of the team shift roles and activities to meet current needs Example: Hardware architect also tests code Product owner, developers and tester in same lab during same hours to facilitate communication beyond daily update meetings All but one of the team members are part-time work afternoon together in lab. Adaptable to new customer needs and suggestions during development 23

24 Lessons Learned Meeting some documentation requirements in early stages is contradictory to and a burden on the agile method Detailed design documents before their time Need to have a work process in place to facilitate efficient and effective design and development Access to end users is critical throughout the agile design and development process and very hard to get in sufficient quantity 24

25 Current and Future Challenges No full-time developers Getting feedback from very busy testers Integrating developmental and operational test Continuing to educate sponsors on potential benefits of agile software development How to show sponsors that product will be completed in an acceptable manner without complete upfront design 25

26 Thank You 26

27 Backups 27

28 How does Agile compare to Waterfall Software Development? Agile Iterative Short duration but continuous designing Adaptable Provide product modules throughout process Little documentation Waterfall Linear Long, thorough upfront designing of entire software product Predictable Provide product at end of process Lots of documentation 28

29 Actual Sprint Schedule 29

30 Manifesto for Agile Software Development 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 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. 30

31 Principles of Agile Development 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 31

32 Scrum Meetings Meet briefly daily Plan for each sprint (6-7 weeks) Demonstrate working software at end of each sprint Use Mingle to develop and process stories (small bits of code to develop with verification criteria for testing) and defects Requirements Tracing within Mingle Needs are Mingle Epics Requirements are Mingle Features Code Units are Mingle Stories 32