RT‐25 Overview: Requirements Management for Net‐Centric Enterprises By Doug Bodner, Nenad Medvidovic, Barry Boehm, Jo Ann Lane, Bill Rouse, George Edwards, Ivo Krka, Animesh Podar, and Daniel Popescu Annual SERC Research Review October 5‐6, 2011 University of Maryland MarrioP Inn and ConvenQon Center HyaPsville, MD www.sercuarc.org Annual SERC Research Review, October 5‐6, 2011 1
Agenda • Overview ― MoAvaAon and approach ― Methodological framework • Technical details ― CapabiliAes to requirements ― Requirements to architectures ― Case study analysis/support • ValidaAon • Future work Annual SERC Research Review, October 5‐6, 2011 2
Overview Annual SERC Research Review, October 5‐6, 2011 3
Problem Statement • Net‐centric enterprises engage semi‐autonomous business units, each with its own goals and methods for characterizing “requirements” • These units oTen need to collaborate using common IT systems, involving integraAon or merging • Missions and unit needs evolve over Ame • Legacy systems exist and must be addressed • How should capabiliAes and requirements be managed? Annual SERC Research Review, October 5‐6, 2011 4
Approach • Enable “requirements management” throughout integraAon lifecycle via a methodological framework and associated methods, processes and tools (MPTs) ― Requirements definiAon and reconciliaAon ― Traceability ― Architecture specificaAon ― Balance between automaAon and decision support • Address ― OrganizaAonal differences ― SelecAon‐from‐alternaAves vs. design ― Ambiguity and robustness • Use concept of integraAon/mergers/connecAons as a framework ― IntegraAon case studies, including acknowledged SoS • Validate with addiAonal third‐party IT integraAon experts Annual SERC Research Review, October 5‐6, 2011 5
CapabiliQes, Requirements & Architectures • Decompose high‐level capabiliAes Candidate Decision Drivers: Netcentric SoS • Available assets/systems into soTware requirements • Dependability of assets/ Capabilities systems • Interoperability of assets • Then into architectures • Cost/schedule/risk of Refinement options Key Decisions: • Provide support for mulAple • Capability to requirements decomposition stakeholders involved in net‐centric • Allocation of requirements integraAon to assets/systems Candidate ― ConflicAng needs Netcentric SoS Requirements ― Compartmentalized informaAon Decision Drivers: • Type • Orientation Refinement • Provide support for traceability • Information access • Platforms and technology Key Decisions: • Use a spiral decision process to • Integration style • Buy/reuse/build incrementally involve lower levels of • Adaptation and extension mechanisms detail and incorporate evoluAon of Candidate Netcentric SoS needs Architecture Annual SERC Research Review, October 5‐6, 2011 6
Decision Process • Facilitate reconciliaAon of conflicAng capabiliAes and requirements among stakeholders Decision Framework • Consider context of the system MulQ‐Actor Start integraAon or merger (technical system ReconciliaQon characterisAcs, intended duraAon, etc.) Decision Drivers Decision • Consider constraints that affect the PrioriQes integraAon or merger (technical Context D1 Variables constraints, cost/schedule, regulaAons) Input Decision D3 D2 Process • Evaluate prioriAes by considering value Constraint Output Variables and risk • Make decisions (select‐from‐exisAng vs. design‐new, allocate capabiliAes to systems, etc.) Annual SERC Research Review, October 5‐6, 2011 7
Methods, Processes and Tools • Win‐Win – method for negoAaAng and resolving mulA‐stakeholder conflicts regarding IT requirements • System‐of‐systems toolkit – methods for going from capabiliAes to requirements ― UML object models, reliability/dependability models, inter‐operability/net‐centricity matrices, use cases • Adopt‐and‐Go – method for selecAng one system from among mulAple systems • CBSP – method for deriving architecture design decisions from IT requirements • COSYSMO for SoS – method for esAmaAng cost of soTware‐intensive system‐ of‐systems given size factors and cost parameters • These MPTs exist already, but need to be adapted for integraAon and net‐centric enterprises Annual SERC Research Review, October 5‐6, 2011 8
MPT Mapping Candidate Netcentric SoS Capabilities COSYSMO for SoS Refinement SoS Toolkit Decision Framework MulQ‐Actor Start Adopt‐and‐ ReconciliaQon Go Candidate Netcentric SoS Requirements Decision Drivers Decision Win‐Win PrioriQes Context Refinement D1 Variables Input Decision D3 D2 Process CBSP Constraint Output Variables Candidate Netcentric SoS Architecture Annual SERC Research Review, October 5‐6, 2011 9
Case Study ApplicaQons • Goals ― Apply the methodology/MPTs: PaAent Laboratory Management System o IdenAfy issues/challenges System o Determine adaptaAons for MPTs Health Care o Evaluate methodology benefits/costs Network Imaging Management ― Expected outputs: Pharmacy System System o Manual/tutorial for methodology Telemetry System o EnumeraAon of remaining research problems o Evidence of value to the user • Case studies ― Health IT Net - Centric SoS Net-Centric Connectivity ― Regional area crisis response system ― Corporate mergers (HP‐Compaq) ― Back‐office IT integraAon (ISP) Annual SERC Research Review, October 5‐6, 2011 10
Technical Details Annual SERC Research Review, October 5‐6, 2011 11
CapabiliQes to Requirements Select desired capability IdenAfy resources and viable opAons Net - Centric SoS Net-Centric Connectivity Assess opAons Select opAon Illustrate using Regional Area Crisis Response SoS (RACRS) Develop and allocate requirements to consAtuents Annual SERC Research Review, October 5‐6, 2011 12
CapabiliQes Engineering IdenQfy resources: UML Objects Determine opQons: Responsibility/ dependability modeling Assess opQons: • Net‐centricity/ interoperability matrices • Use cases to evaluate how • Trades with respect to data fusion needs/formats Select opAon Develop and allocate requirements to consAtuents Annual SERC Research Review, October 5‐6, 2011 13
RACRS Capability Intents & Resources • Primary needs • PotenAal Resources ― Improve number of fire‐fighAng ― Local assets: professional responders resources available to fight major and equipment, volunteers, low‐risk fires in the region inmates ― Further reduce the Ame and number ― Military assets (personnel firefighAng of official crisis management equip, UAVs, UGVs) personnel resources required to ― TV/radio staAon announcers evacuate a specified area ― Satellite and local road camera ― Protect evacuated areas from looters images showing crisis area (e.g., fire) and traffic status • Related goals ― Buses for transporAng people ― Minimize local government expense (city, ― New Reverse‐911 system to support county) evacuaAon noAficaAons. ― Minimize risk to human life (crisis ― Homeowner alarm/security systems responders and local populaAon) to support evacuaAon and protecAon ― Minimize workload on skilled personnel responsible for responding to crisis Annual SERC Research Review, October 5‐6, 2011 14
Requirements to Architectures • iCBSP • Process of use ― Proposed method for refining ― Pre‐step: filter requirements for integraAon requirements into an integraAon integraAon architecture ― Step 1: stakeholders rate importance ― Augmented version of the CBSP and feasibility method ― Step 2: architects rate architectural ― Retains strong traceability from relevance architecture to requirements ― Step 3: architects negoAate and reconcile disagreements ― Step 4: requirements rephrased and traced to proto‐architecture ― Step 5: integraAon architectural soluAon selected and applied to proto‐architecture Annual SERC Research Review, October 5‐6, 2011 15
IntegraQon Styles and ProperQes • Style guides the composiAon • IntegraAon Style = of elements into an o Connector Roles + Topology + Linkage Mechanisms architecture ― Connectors • MulAple styles may be used in o Adaptor, arbitrator, distributor, etc. ― Topologies a system or SoS o Point‐to‐point, hub and spoke, shared bus, etc. • Different styles result in ― Linkage different system qualiAes o Shared data, messaging, screen‐ scraping, etc. • How styles are used in iCBSP: ― Examples: ― Candidate styles are characterized o SOA = distributor, shared bus, according to advantages and messaging disadvantages o Federated DB = arbitrator, hub and ― Desired properAes used to select spoke, shared data appropriate style Annual SERC Research Review, October 5‐6, 2011 16
Recommend
More recommend
