2.26_C p :Crim inalH istory/Records Index 2.16_C p :JIM S 2.26_B:JIM S-Crim inalH istory/ RecordsIndex 4.5:O btaining Inform ation on PriorA rrestsand Detentions 4.5_C p :RIM S 4.5_B:JIMS-RIM S 2.26_C d :Crim inalRecords iCBSP: Moving from Integration Requirements to an Integration Architecture Bill Rouse*, Doug Bodner*, Nenad Medvidovic+, Ivo Krka+, George Edwards+, Daniel Popescu+, Jo Ann Lane+ *Georgia Institute of Technology +University of Southern California Background: Conventional CBSP Method • Iterative method of moving from requirements to architecture using USC’s intermediate CBSP models • CBSP = component-bus-system-property • Uses USC’s WinWin requirements elicitation References iCBSP Results Summary •Effectively filters requirements •1800 total requirements 22 integration requirements •Supports requirements reconciliation and rewriting •6 requirement with high architect disagreement •Precisely relates integration requirements and architecture Contact Ivo Krka ([email protected] ), http://www-scf.usc.edu/~krka/ Department of Computer, University of Southern California, 941 W. 37th Place Los Angeles, CA 90089, USA Technology dependence Level of detail Low High Low High Requirements Architecture Intermediat e CBSP model Our goal: Refine integration requirements into an integration proto- architecture, while retaining strong traceability between them Solution Approach: Integration-CBSP Method • Reconceptualize CBSP in the context of integration, mergers, and interoperability • C = constituent systems • B = integration and interoperability mechanisms • S = merged, integrated system or SoS • P = properties of the above Pre-step: ﬁlter requirements for integration Step 1: stakeholders rate importance and feasibility Step 2: architects rate architectural relevance Step 3: architects negotiate and reconcile disagreements Step 4: requirements rephrased and traced to proto-architecture iCBSP in Action: Jail Information Management System (JIMS) • Provides data consistency and availability at seven San Diego County detention centers • JIMS needs to interoperate with multiple external systems (Warrant search systems, Criminal history system, etc.) JIMS requirement 4.5: When the RIMS criminal history module initially becomes available, JIMS shall interface with both it and the Records Index and the Criminal History Systems. This dual interface shall be maintained until such time as all records in the Records Index and the Criminal History Systems have been moved into RIMS. Archite ct End user Averag e Disagreeme nt Importanc e 2 3 2.5 1 Feasibili ty 1 1 1 0 Original requireme nt Required Interface Required Data Required Processin g RT-25 Net-Centric Requirements Management University of Southern California Georgia Tech High importance requirement with low disagreement Step 1 Steps 2 and 3 C B S CP BP SP Architect 1 3 3 0 0 0 0 Architect 2 0 3 0 2 3 2 Diff 3 0 0 2 3 2 Step 4 High disagreement between the architects, reconciliation necessary C B S CP BP SP Architect 1 2 3 0 0 0 2 Architect 2 2 3 0 0 0 3 Diff 0 0 0 0 0 1 Requirement related to constituent systems, their interconnections, and the interface availability Reconcil ed table P. Grunbacher, A. Egyed, and N. Medvidovic. Reconciling software requirements and architectures with intermediate models, Software and Systems Modeling, 2004.

ICBSP: Moving from Integration Requirements to an Integration Architecture Bill Rouse, Doug Bodner, Nenad Medvidovic+, Ivo Krka+, George Edwards+, Daniel

Download PPTX Report

Upload
damian-wilkinson
View
213
Download
0

Embed Size (px)

Citation preview

Page 1: ICBSP: Moving from Integration Requirements to an Integration Architecture Bill Rouse*, Doug Bodner*, Nenad Medvidovic+, Ivo Krka+, George Edwards+, Daniel

2.26_Cp: Criminal History/Records Index

2.16_Cp: JIMS

2.26_B: JIMS-Criminal History/Records Index

4.5: Obtaining Information on Prior Arrests and Detentions

4.5_Cp: RIMS

4.5_B: JIMS-RIMS

2.26_Cd: Criminal Records

iCBSP: Moving from Integration Requirements to an Integration Architecture

Bill Rouse*, Doug Bodner*, Nenad Medvidovic+, Ivo Krka+, George Edwards+, Daniel Popescu+, Jo Ann Lane+

*Georgia Institute of Technology +University of Southern California

Background: Conventional CBSP Method• Iterative method of moving from requirements to architecture using

USC’s intermediate CBSP models• CBSP = component-bus-system-property

• Uses USC’s WinWin requirements elicitation

References

iCBSP Results Summary• Effectively filters requirements

• 1800 total requirements 22 integration requirements• Supports requirements reconciliation and rewriting

• 6 requirement with high architect disagreement• Precisely relates integration requirements and architecture

• 16 processing elements, 16 buses, 11 data elements• Effectively maintains explicit traceability

ContactIvo Krka ([email protected]), http://www-scf.usc.edu/~krka/

Department of Computer, University of Southern California, 941 W. 37th PlaceLos Angeles, CA 90089, USA

Technology dependence

Lev

el o

f de

tail

Low High

Low

High Requirements Architecture

Intermediate CBSP model

Our goal: Refine integration requirements into an integration proto-architecture, while retaining strong

traceability between them

Solution Approach: Integration-CBSP Method

• Reconceptualize CBSP in the context of integration, mergers, and interoperability

• C = constituent systems• B = integration and interoperability mechanisms• S = merged, integrated system or SoS• P = properties of the above

Pre-step: filter requirements for integration

Step 1: stakeholders rate importance and feasibility

Step 2: architects rate architectural relevance

Step 3: architects negotiate and reconcile disagreements

Step 4: requirements rephrased and traced to proto-architecture

iCBSP in Action: Jail Information Management System (JIMS)• Provides data consistency and availability at seven San Diego County detention centers• JIMS needs to interoperate with multiple external systems (Warrant search systems, Criminal history system, etc.)

JIMS requirement 4.5: When the RIMS criminal history module initially becomes available, JIMS shall interface with both it and the Records Index and the Criminal History Systems. This dual interface shall be maintained until such time as all records in the Records Index and the Criminal History Systems have been moved into RIMS.

Architect End user Average Disagreement

Importance 2 3 2.5 1

Feasibility 1 1 1 0

Original requirement

Required Interface

Required Data

Required Processing

RT-25Net-Centric

Requirements Management

University ofSouthernCalifornia

GeorgiaTech

High importance requirement with low disagreement

Step 1 Steps 2 and 3 C B S CP BP SP

Architect 1 3 3 0 0 0 0

Architect 2 0 3 0 2 3 2

Diff 3 0 0 2 3 2

Step 4High disagreement between the architects,

reconciliation necessary

C B S CP BP SP

Architect 1 2 3 0 0 0 2

Architect 2 2 3 0 0 0 3

Diff 0 0 0 0 0 1

Requirement related to constituent systems, their interconnections, and the interface availability

Reconciled table

P. Grunbacher, A. Egyed, and N. Medvidovic. Reconciling software requirements and architectures with intermediate models, Software and Systems Modeling, 2004.

mailto:[email protected]

http://www-scf.usc.edu/~krka/

http://csse.usc.edu/csse/index.html