AW7 Concurrent Session 11/7/2012 2:15 PM "Right-sized Architecture: Integrity for Emerging Designs" Presented by: Ken Kubo Northrop Grumman Corporation Brought to you by: 340 Corporate Way, Suite 300, Orange Park, FL 32073 888 ‐ 268 ‐ 8770 ∙ 904 ‐ 278 ‐ 0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com
Ken Kubo Northrop Grumman Electronic Systems Ken Kubo is director of software engineering with twenty years of service at Northrop Grumman Electronic Systems, Intelligence, Surveillance, Reconnaissance, and Targeting Systems Division, Azusa campus. His work has focused on the development of satellite ground systems, building the bigger picture from individual bits of data. Information radiators are Ken’s natural focus in agile development. A certified Lean-Agile ScrumMaster and Certified ICAgile Professional, he developed and teaches a Lean-Agile Development overview course for NGES. Ken firmly believes that lean-agile and government acquisition processes are not completely incompatible.
Right-Sized Architecture Integrity for Emerging Designs AW7 - 7 November 2012 – 2:15 PM Ken Kubo, James Yoshimori, Jason Liu Agenda • Software Engineering and Lean-Agile • Right-Sized Architecture Right Sized Architecture • Collaborative Design • Extending the Metaphor • Retrospective
Acknowledgements • The team gratefully acknowledges the support and interest of the Sensor Exploitation Systems/SAIG business area leadership. 3 But First…A Word From Our Sponsor • Northrop Grumman Corporation (NYSE: NOC) is a leading global security company providing innovative systems, products and solutions in aerospace, electronics, information systems, and technical services to government and commercial customers worldwide The company has government and commercial customers worldwide. The company has over 120,000 employees in all 50 states and 25 countries around the world. • Our core competencies are aligned with the current and future needs of our customers and address emerging global security challenges in key areas, such as unmanned systems, cyber-security, C4ISR, and logistics that are critical to the defense of the nation and its allies. • Our Electronic Systems sector is a leader in airborne radar, navigation, y , g , electronic countermeasures, precision weapons, airspace management, space payloads, marine and naval systems, communications, biodefense, and government systems.
The Need for Agility Increase in Software in DoD Systems Software Content of Sample Major DoD Weapon Systems 1960 - 2020 18 FCS 16 F-35 Aircraft 14 and Ground 12 ESLOC in Millions 10 DDX 8 6 Virginia SSN Virginia SSN SBIRS 4 F-22 Patriot Aegis System PAC-3 2 Polaris A3 ACS 0 1960 1970 1980 1990 2000 2010 2020 Sea Systems Missiles/Space Ground Systems Aircraft Sources: CARD Data, SEI, CSIS Analysis 5 The Need for Agility • Defense Science Board Recommends More agile Acquisition Process (March 2009) “A new acquisition process for information ew acqu s t o p ocess o o at o • National Defense Authorization Act for Fiscal Year 2010 (H.R.2647) technology should be developed— modeled on (Became Public Law No: 111-84 October 2009) successful commercial practices , for the rapid • AFEI Task Force 804 Report – June 2010 acquisition and continuous upgrade and improvement of IT capabilities. The process Recommended (Among Other Things): “Institute continuous, iterative, development, should be agile and geared to delivering test, and certification processes that drive the test, and certification processes that drive the commercial IT state of the art to deliver more meaningful increments of capability in trusted, standard, off-the-shelf building blocks” approximately 18 months or less —increments that are prioritized based on need and technical readiness.” 6
Software Engineering (and other oxymorons) • Definitions: – Software: a set of instructions which define and enable the operation of a computer system to perform a desired task y p – Engineering: the discipline and profession of applying technical, scientific, and mathematical knowledge to practical problems • Historical endpoints – 1968 NATO Software Engineering Conference – Software Engineering Body of Knowledge (SWEBOK) (IEEE, 2004) 7 Software Engineering Practices • Systemic view and development lifecycle (requirements analysis, design, development, testing, deployment, maintenance) • Risk analysis • Best practices – Lessons learned – Design patterns • Certification – Certified Software Development Associate/Professional (CSDA/P) – PMI-ACP, ICAgile Certified Agile Professional, role certification etc. 8
The Agile Transition Predictive Develop FS A RA HLD DD Develop FS B I&T V&V PDS RA HLD DD Develop FS B I&T V&V PDS Develop FS C FS A,B,C Adaptive … RA RA HLD HLD PDS FS A FS B FS D FS C 9 Agile Execution Analysis “Desirement Analysis” with iteration planning and backlog (work queue) grooming. Also and backlog (work queue) grooming. Also A Architecture hit t used for risk identification/mitigation. Design Traditional engineering activities all still occur, but note that they (mostly) happen Development collaboratively, not sequentially. I & T I & T 10
When Engineering Goes Bad… Traditional predictive practices and “ilities” can commit too early • Lock-down architecture at the beginning of the project (Big Design Up Lock down architecture at the beginning of the project (Big Design Up Front) • Only discuss design with customer prior to development • Design for all possible customer requests, enhancements, and expandability Wide focus can be uninformed 11 When Agile Goes Bad… Agile methodology focus can incur technical debt • Agile methodology impacts Agile methodology impacts – Iteration focus can emphasize coding activity – de-emphasizing others – “Just in time” design can devalue architecture • Technical debt – Neglecting the “big picture” – Decoupling architecture – Losing sight of system design integrity Tight focus can prove short-sighted 12
Agile as a Philosophy • Execute with lean agility – Avoid waste – Creating shared knowledge > creating documentation Creating shared knowledge > creating documentation • Leverage social interaction – Use a common “information radiator” • Artifacts and processes are open to view • Artifacts are easily accessible • Single source creates common understanding – Build a social environment for development p • Encourage developers to work closely with one another • Strengthen trust within the community – Establish common understanding of artifacts being constructed Shared understanding drives efficiency 13 Implementing Agile Architecture • Avoid waste – just enough (George Fairbanks) “You‘ll be smarter later” • The Zen of “just enough” – Avoid big design up front (BDUF) – Decide on the vision for your framework – Pick your focal points (risk and ignorance) – Make design a convenient part of the workflow – Emphasize creating knowledge, not creating diagrams • Encourage an open team dynamic so team members can say when they have enough information to code – Prefer the collaboration dynamic to automation tools – Don’t force documentation of design sessions – Be disciplined but not rigid Just Enough Architecture A Little Before Its Time 14
Roles and Responsibilities • Initial Design Objective: identify interfaces, processing partitions/components, general system sketch, build the framework for the developers – Architect: maintains big picture, helps identify and define interfaces, keeps focus of the meeting, controls documentation – Product Owner: clarifies objectives and done-ness, fills in unstated (“wasn’t that obvious?”) requirements – Technical Lead(s): identify where development activity has to occur, help define interfaces • Delta Design Objective: sanity check and impact analysis ( not the search for the perfect design) Objective: sanity check and impact analysis ( not the search for the perfect design) – Developer(s): present (proposed) solution, highlight any changes/detailing to architecture – Architect: helps perform impact analysis, verifies design integrity, controls documentation – Technical Lead(s): help perform impact analysis 15 Eyes on the Big Picture • Apply Agile philosophy – Understanding > documentation • How? – Using my Agile eyes … • Inspiration – CRC: class, responsibilities & collaborators (Ward Cunningham) • Informal grouping of index cards (4”x6”) • Simple, easily remembered rules • Visual and collaborative 16
Color Map Affinity Diagrams • Use colored index cards and push-pins – advanced developers may use self-adhesive notes • Assign colors to the various types of high level components you may have (more details to follow) • Find sufficient vertical space to place the index cards • Have fun ☺ 17 Example • Project: Support processing, archive, and display of satellite wideband data, substantial legacy code • Team size: 5 members • Platform: SGI and Linux • Language: C/C++ and Java 18
Recommend
More recommend
