Software Process ArchitecturesBarry Boehm, use

ICSE 17 Software Architecture 'VorkshopApril, 1995

1. Introduction

Beginning with the paper, "Software Processes Are Software Too," [Osterweil,1987], an attractive line of software process research has developed involving theexploitation of a duality between software products and software processes. This dualitycan be expressed as,

"If a given approach (disciplined programming, requirements definition andvalidation, reuse. risk management, performance modeling) is good for softwareproducts, then its process counterpart is good for software processes."

Given that diCferences exist between software products and software processessoftware products are executed by machines; software processes are executed bycombinations of people and machines), this duality cannot be pushed too hard or appliedunthinkingly. But, as seen in a number of papers in the series of InternationalConferences on the Soft\vare Process, this duality has provided useful insights and resultsin such process areas as process life-cycles [Feiler- Humphrey, 1993], processrequirements [Dowson, 1993], process validation [Cook-Wolf, 1994], and processevolution [Bandinelli et a1., 1994].

This paper add resses the hypothesis, "If archi tectures and architecting are goodfor software products, then their process architecture counterparts will be good forsoftware processes." The following sections address the major software productarchitecture subareas (architectural elements; architectural styles; system architectures;domain and product line architectures; and enterprise architectures), and elaborate ontheir software process architecture counterparts.

2. Architectural Elements

A reasonable composition of the [Garlan-Shaw, 1993] and [Perry-Wolf, 1992]definitions of software product architecture elements would include components,connectors, configurations, and rationale.

Examples of software product components perform such functions as sorting,summarizing, choosing, or displaying:. Counterpart software process componentsperform such functions as initiating software problem reports (SPRls), logging anddistributing SPR's, reviewing and classifying SPR's.

Examples of software product connectors transmit requests, commands, or datafrom one component to another, or they may express sequentiality (the successorcomponent begins to operate when the predecessor component completes its operation).Counterpart software process connectors operate in similar ways.

Examples of software product configurations would include a sort-summarize­display sequence of components, connected via connectors which sequence theirexecution and pass data from one to the next. Figure 2, from [TRW, 1973], shows asoftware process configuration counterpart, linking the process elements "Initiate SPR,"

Examples of software product configurations would include a sort-summarize­display sequence of components, linked via connectors which sequence their executionand pass data from one to the next. Figure 1, from [TRW, 1973], shows a softwareprocess configuration counterpart, linking the process elements "Initiate SPR," "Log anddistribute SPR," "Review and Classify SPR," etc., generally with connectors sequencingtheir execution and passing data from one to the next. Variants and extensions of thischange control process configuration have been explored extensively at the SixthInternational Software Process Workshop and followon workshops [Kellner et al., 1990].

The rationale for a software product architecture demonstrates that thecomponents, connectors, and configurations in the architecture define a system that, ifimplemented, would satisfy the needs of the system's stakeholders as expressed in anappropriate combination of requirements specifications, prototypes, standards, qualityobjectives, and other objectives and constraints [Gacek et al, 1994]. The rationale for asoftware process architecture performs a similar function.

3. Architectural Styles

[Garlan-Shaw, 1993] identifies a number of software product architectural stylessuch as sequential pipe and filter, event-based, and repository-based architectural styles.Some of these, such as the three above, have named software process architectural styleswhich are fairly close counterparts.

For example, the process counterpart of the sequential pipe and filter productarchitecture is the waterfall model [Royce, 1970]. It links "Requirements," "Design,""Code," "Test," and "Deploy" components with simple sequential connectors. Via theseconnectors, the successor component can begin operation once its predecessor componenthas completed its results and sent them to the sucessor via the connector.

The risk-driven spiral model [Boehm, 1988] has as its best counterpart an event­based product architecture. ' Various risk-resolution process elements, such asprototyping, simulation, modeling, and reference checking, register themselves for usewhen the project's risk patterns require their services (along with other process elementssuch as planning and scheduling). If the risk assessment determines that the mosteffective next step is "user interface prototyping," it broadcasts this message, alongappropriate user interface proto typing objectives and criteria.

Next, the user interface prototyping component receives, evaluates, and operateson the message, and broadcasts its results for the next appropriate process component toreceive and operate upon. The number and order of such risk-resolution processinvocations depends on the number, order, and priorities of risk elements identifiedduring the overall system definition and development process.

The evolutionarY development model can be considered as a counterpart of therepository architectural style, with the evolving software product serving as therepository. Various process components measure patterns of usage in the existingsoftware product in the repository; analyze needs to change the product; coordinateproposed changes; perform changes; and validate the changes. Other process componentsperform general repository management functions such as backup and recovery.

2

II"'C ~ r{U~ Software Development and Configuration Management ManualsysrlMS C~~~ •.

'ROJECT ..••CTIONS

CONFIGURA nONMANAGEMENT OF"ICE

1C'0401

SYSTE~ENGINE:~ OEVELCP!;~S

INOEPENOENTTEST TEA .•••

I'Y

2. LOG "'NO OIST~I.9UTE 9'1

1. INITIATE SPR

1. SYS7EM ENGINE:R ",NO OE'I=1.0''''ENT

~P'A '1E'/iEW "'NO CL->SSIFY 9'1

MAJOR IICHANGE

4. SYS'7=~A e~4GINe:=:1 ,.\NO OEVEl.CP\4cNT"'P··'~E'IIEW spq FC R 0IS?OSI7ICN

I

I MINO~CHANGE

7. ORIGiNATEEXPL->NATOPY $I.I~

'Y

9. ORIGINATE ~EXPLANA TORY s.,,\;; ~I

....

CD

I

I..

16. FIX PRC31.:'ATEST. SU3.'AI7·FIX WITH SMR

~IX

?ROBI.E~.'

28. SYSTE ••.••ENGINEER AND DEVELOP.MENT "'PM REVIEW FIX FOR CLASS IIMPACT ON DOCUMENTATION

n. LOG S••.••R. OBCR. OUT.AND DISTRIBUTE

25. (;po •••TE EXIST'NGSPR NO. 'MTHREVISION NO.

"'PPROVE

t 7.19. :OCU·

ME.~7.U"ICNI,.!P"'C,EO

n. INTEGR •••TE

;~~NT~~~ EI.:'AE~T.

24. VALIDATECHANGE

UNAc::e..:rrABLE ACCE?TAaI.E

2S. UPOA TE SPR

Figure 1. Software Process Architecture Configuration for Change Control (TRW, 1973]

3

4. System Architectures

As each software project's product has an architecture composed of architecturalelements from perhaps a mix of architectural styles, so has each project's process. Anexample is shown in Figure 2: the system process architecture of the CCPDS-R project[Royce, 1990].

5. Domain and Product Line Architectures

As with product architectures, particular software application domains or productlines can have process architectures, tailored to the characteristics of their domain orproduct line. For example, the current embedded avionics domain frequently uses ahybrid spiral/waterfall model. Several spiral cycles are used to identify and resol ve suchrisk items as meeting real-time deadlines; processing high-volume, noisy or multisourcesensor data; and ensuring ultrareliable operation.

Once the risks are adequately resolved, and a satisfactory resulting combination ofproduct plans, requirements, and architecture specifications is achieved, a project in theavionics domain generally proceeds to use a waterfall model to build the software productto its specifications. The main rationale for using the waterfall model involves the needto synchronize the software process with relatively fixed hardware schedules and productinterface specifications; and the need for thorough verification of the developed softwarewith respect to its specifications.

Figure 3, from [Boehm, 1989, page 437], provides a decision table giving a top­level illapping from various software application domains (in the final column) to processarchitectural styles (in the next-to final column), based on a set of process drivers in theleft-hand columns. Thus for example, the sixth row in the figure shows that thereconlmended process model (architecural style) for "high performance avionics" is the"risk reduction followed by waterfall" model.

6. Enterprise Architecture

Beyond a domain or product line architecture, which relates to individual softwaresystems, is the enterprise architecture, which addresses how individual systems willinteroperate across an enterprise's full ensemble of software systems. Examples ofsoftware product enterprise architectures are the conventions enabling interoperability ofthe elements in such product complexes as Microsoft Excel, the DISA TechnicalArchitecture Framework for Information Management (TAFIM), and the Air ForceInformation Architecture [Druffel et aI, 1994J. A related multi-system architecture is theHP-NIST-ECMA "toaster" model for interoperability of tools within and across softwareenvironment frameworks [NIST, 1993].

An example process counterpart of the product enterprise architecture is thetoaster model variant shown in Figure 4. The product toaster model provides slots intowhich various instances of software tools can be placed, and interface spacifiactionsalong the slot boundaries which ensure that tools developed in compliance with theinterface specifications will interoperate with each other.

4

Figure 2. CCPDS-R System Process Architecture [Royce, 1990]

C:i:icalT~:~5d.s

Bl:ildin~Bloc:',

r?undation

Prt):o!y~~,

anci

R.ef-neme:!:,

SAS

p~~\oq'?e'and

fo'ouncia\ion I R..':~~-<:-::,E:1hanc:men:,! - .

DIA

EVoLU

IoN

PRoDUC

I:-i

TER~t

T..

Ot:'erDemos

CDRDemo

SSRDe:::o

Sn.S,

SDRD<::":'Io

PDRD<:moSDD,

Inior.:1alB&,eline

FormalBaseline

Com?onent

P :ototy?<:,and

n.efinementJ

Enhancement,

In("rm ••1

Ba,eline

I !n::;~a:e ane!

rI Com?one\':t? ~otot7?e'

and?e~n<:ment,

In(or::: •.:B a ,:!i::.

Com:>?::.:::

?~oto::::~~nc

Reno::::.:::,

Te~t and

:.1aintenance

I In:e~~"\: andrI1

I C:::icai-:')~:>o:1:n\?~~:ot7?<:'

and

Ln(or:,:,:al3aJeiir.e

T<:H and~ain: e:\ance

For::141

Bo"Ene

Iniormal

S ••.,,,line

Test andi'ttaint~:1anc:

Te,t an':Mainten&:1ee

Te,t and~aintenance

Test andMaintenance

Soft. ware Product BaselinesSoftwareProductsBaselincs

5

Figure 3. Mapping of Software Domains onto Process Architectural Syles [Boehm, 1989]

C~=:iIVES, CCNSi;::.AINTS AL7'E,:;N,:, ilVES

i ME:;U,\

II

I ~ACHITECT\JRE II UNCE,'1Si ~NCING

I O· R-' 'L f"0-:: ! 0"/-0• M i J,., '- I •... _ .• I

ME:ll..'MI

MODEL

I AI'" --A --,- ~-"--Ol• n , .., r"r";\'" _ •..••11 I n

I SO~NAME5~?CORTEN'.JIRONM::r;"

S;:IF,AL

F,ISt< :=.EOUCTION

.& WATERFALL

BUY COTS I SIMPLE INVE.'iiORY CONTROL

TRANSr=ORM OR I SMALL SL:Si~;ES5 - DPEVCL. DEVEL. APPLICATICN

i EVCl. PROTOTYPE I ACVANCEJ ::~'i"7E~NI nECCGNITiC,';

'.VA TE:;F,';LL I RE3UILD C= :::1..J 5YSTE~1

RISi< ,:;EJUCTiON I CO!,~_LE,:< ~:,~''':A TIONFOLLcwEJ BY _A_5_S_=_;:;)_S_,,_1E_,_, _

WA ,E::;r=ALL I HIGH-?E::;~-::: ',lANCE AVIONICS

E'/CLUTiCNARY I NE'n DEC:S:C:; SUPPORT

CEIJELCFMENI I SYSTEM

CA?ABILITIES- .0- I ELEC'RON:C "';BUSHING

R='JUI;:;~~J1=NTS

LOW

LOW

HIGH

HIGH

~,!EJIUM TO

~IGr.

COTS

i<fGL.

TR~,,'JSr=OR~1

AVAL,A18LE

TECHNCLCGv

I LARGE

I REIJS;.2LECCMFCJNE~JiS

L'JW

:~IGH

:~!GH

RC:USiNESS

LC'::· \lEDIUM

LOW

LOW

LOW

HIGh

I UNDE;:;ST ~NDING IOF ;;OTS.

I LOWII

LlMIEJ

GRCWn;ENVE'..CPE

i lIMITEOr---­lIMITEJ

1 V-::-Y lAO~-

'I1.1::'"1.1 ~:"LARGE

I LIMITE] TOLARGE

I

r

f LIMITED IvI MEOIUMIlIMITEJ 10LARGE

CONDITIONS FOR ADDITIONAL COMPLEMENTARY PROCESS MODEL OPTIONS

- DESIGN- TO-COST OR SCHEJULE: FIXED BUDGET OR SCHEDULE AVAILA.BLE

-INCRS~ENTALOEVELOPM=N~

(ONLY ONE CONDITION,IS SUFFICIENT)

EARLY CAPABILITY NEEDED

LIMITED STAFF OR BUDGET AVAILA.BU:DOWNSTREAM REOUIREMENTS POORLY UNDEiiSTOODHIGH-RISK SYSic:M NUCLEUSLARGE TO VERY LARGE APPLICATIONREOUIRED PHASiNG WITH SYSTc:M INCREMENTS

6

The software process enterprise architecture in Figure 4 operates on the sameprinciple. For example, the interface specifications between the Product Design slot andthe Defect/Risk Identification slot are identified in Table 1 below in terms ofpreconditions and postconditions. If these preconditions and postconditions are satisfiedby a design of any form (Booch, Coad- Yourdon, DeMarco, Jackson, ~artin, Rumbaugh,Shlaer-Mellor, etc.) and by any form of design defect/risk identification activity (Faganinspection, structured walkthrough, quality metrics analyzer, automated consistencychecker, SEI team risk assessment, corporate risk management group assessment,automated risk assessment advisor, etc.), then any of the forms of design can undergo anyof the defect/risk identification activities in a predictable and controllable manner.

Table 1. Interface Specifications Between Product Design and DefectlRisk Identification

Precondi tions

1. Design artifact objectives and constraints (artifact requirements, artifact architecture,standards, quality attribute requirements, other objectives and constraints).

2. Design artifact.

3. Design artifact rationale: evidence that the artifact as designed would satisfy theobjectives and constraints.

4. Defect/risk identification objectives and criteria: selection and prioritization amongsuch criteria as completeness, consistency, traceability, feasibility, testability,implementation risk, cost/schedule risk. and such quality attributes as usability,maintainability, safety, reliability, availability, security, accuracy, etc. [Boehm, 1984].

5. Necessary defect/risk identification resources (budget, schedule, qualified personnel,tools and techniques).

6. Defect/risk resolution plan, including consistent specification of objectives, milestones,schedules, responsibilities, approaches, resources, and assumptions.

7. Commitment of the plan's participants to the plan.

postconditions

1. Satisfaction of defect/risk identification objectives and criteria.

2. Plans for defect removal and risk resolution: these can be as simple as a list of actions,agents, and due dates; or they may take the fonn of a plan such as in Figure 5 [Boehm,1989, p. 136].

7

Open Process Architecture: Toaster Variant

Process Coordination

Product Scoping & Architecting(ops concept, rqts, architecture)

Planni ng &/:-, Product

Product Generation Managel11ent(code, docunlentation)Processes

Resource

Product Creation ProcessesDefect/RiskEstimation

Identification

I Planning

II

DefectjRiskResolution

I Monitoring

II II Baselining/Change Control

I Control

IIII C0rI?mitment

Reviews

Process Coordination

** Interface specifications between process elen1ent categories enable interoperable insertion of alternative process elements

~-

Figure 5. Risk Resolution Plan Outline and Example [Boehm, 1989]

FOR EACH RISK ITEM, ANSWER THE FOllOWING QUESTIONS1. WHY?

RISK ITEM IMPORTANCE. RELATION TO PROJECT OBJECTIVES

2. WHAT, WHEN?

RISK F,ESOLUTION DE:"!VERABLES, MilESTONES. ACTIVITY NETS

3. WHO, WHERE?RESPONSIBILITIES, oP.G.A.NIZATION

4. HOW?

APPF,OACH (PROTOTfPES, SURVEYS, MODE~S .... )

5. HOW MUCH?

RESOURCES (BUDGE-. SCHEDULE, KEY PEi1S0Nf'JEL)

Table 2.6: Example Risk Management Plan: Uniword WYSIWYG Editor Product Features

OBJECTIVES (WHY?)• DETE.=1MINE 'vVYSIW\~'? EDITOR PRODUCT FEATURES• CREA,TE PROJECT-C:;',IP,t;TIBLE WYSIV/YG DEVELOPMENT PLAN

DELIVERABLES AND Mll:STONES (WHAT, WHEN?)• BY "'VEEK 3:

1-TECHNICAL EVAL.UATION OF EXISTING vVYSlvVYG PRODUCTS2-USER EV ALUA TiCN OF EXISTING WYSiWYG PRODUCTS3-ASSESSMENT OF r,EUSABLE COMPONENTS4-STRAWMAN PRCDUCT FEATURE DESCRIPTION

• 8Y WEEK 7:5--0PERATING PRCiOTYPE 'WITH KEY USER FEATURES6-STRAWMAN DEVE!...OPMENT PLAN7-REPRESENTATIVE USERS TO EXERCISE PROTOTYPE

• BY WEEK 10:

8--USER EVALUATION; ITERATION OF PF,OTOTYPE9-REVISED PRODUCT FEATURE DESCRIPTION

1o-REVISED DEVELOPMENT PLAN

RESPONSIBILITIES (WHO: WHERE?)

• SYSTEM ENGINEER : TASKS 4,6.9,10• MARKETING MANAGE~ : TASKS 2. 7, 8a• LEAD PROGRAMMER : TASKS, 1,5. 8b; SUPPORT TASKS 6,10• PROTOTYPE PROGRAMMER: TASK 3; SUPPORT TASKS 1,5, 8b

APPROACH (HOW?)

• DESIGN-TO-SCHEDULE PROTOTYPING EFFORT

• EMPHASIZE REUSE, STANDARD INTERFACES• USE C LANGUAGE, SHELL SCRIPTS WHERE FEASIBLE

RESOURCES (HOW MUCH?)

• DEDICATED S.E., L.P., P.P. (10 WK) (3 FSP) (S2/FSP-WK)• M.M. DEDICATED IN WKS 1·3, 8-9; PROVIDED BY SOFTWARE HOUSE• 4 DEDICATED UNIWINDOW WORKSTATIONS: PROVIDED BY U. MICRO• 2 DEDICATED, 2 PART-TIME USERS IN WKS 8-9; PROVIDED BY M. MANAGER• CONTINGENCIES

9

S60K

ooo

20K

S80K

If the interface specification postconditions in Table 1 are satisfied. and they andother interface specification preconditions to another process element are satisfied, thenthe DefectlRisk Identificltion process element will intcroperate with its neighbor processelements as \-vell. For eX2.mple. the preconditions for the Defect/Risk Resolution processelement in Figure 4 are: .

(0.). Pl:1ns for deCec[ removal Jnd risk resolution.

(b). Commitment of the defect removJl and risk resolution pbns' participants to thepbns.

Therefore. sJtisfJction of the Product ManJ£!ement "DefectJRisk Identification"postconditicns (:.1) an': th~ Process Coordin;tion "Commitment to Defect/RiskResolution" postcondit:ons (b) will ensure sJtisl':.lctory en;.lctment of the Design/RiskRcsolution process elcr.:enl. SimilJr interf;.lce spdecific;.ltions can be provided for all ofthe intcrt':lces among process elements in Figure 4, to ensure process elementinterc:per2.bility Jcross tt-:eprocess enterprise J.rchitccture.

7. Conciusions

\\"ith respect to t~:e initial hypothesis, "If architectures and archite ting are goodfor sofLv:are products, then their process architecture counterparts wil be good forsoftw:lre processes.!! this paper provides initiJI evidence that the hypothes s will be truefor some significant p!'ocess activities. These activities include reuse of processcomponents, devclopi:lg process components for reusJ.bility. reJ.soning aboutcompos:bility of prcc~ss components, Qnd ensuring interoperahility of processcompon~nt;.

in panicul:u·. th~ touster model rre~,:~nted here provides 2.n existence proof forsoftware precess enterp:"ise models. It or alternati ve process ente~"prise models can beused as (l bJsis for developing, reusing, interoperutin£!, and safelv enacting softwareprocess elem~nts within and ac;oss multiple SOflWJre ent~rprises. - ~

8. References

[Bandinelli et al., 1994]. S. Bandinelli, E. DiNitto, and A. Fuggetta, "Policies andMechanisms to Support Process Evolution in PSEE's," Proceedings. ICSP 3, IEEE,October 1994.

[Boehm, 1984]. B. Boehm, "Verifying and Validating Software Requirements andDesign Specifications," Software, January 1984, pp. 75-88.

[Boehm, 1988]. B. Boehm, "A Spiral Model of Software Development andEnhancement," Computer, May 1988, pp. 61-72.

[Boehm, 1989]. B. Boehm, Software Risk \1anagement, IEEE Computer Society Press,1989.

[Cook-\Volf, 1994]. 1. Cook and A. Wolf, "Toward 11etrics for Process Validation,"Proceedings. ICSP 3, IEEE, October 1994.

[Dowson, 1993]. M. Dowson, "Software Process Themes and Issues," Proceedings. ICSP2., IEEE, February 1993.

[Druffel et al., 1994]. L. Druffel, N. Loy, R. Rosenberg, R. Sylvester, and R. Volz,"lnfonnation Architectures that Enhance Operational Capability in Peacetime andWartime," US Air Force Scientific Advisory Board Report, Washington DC, February1994.

[Feiler-Humphrey, 1993]. P. Feiler and \1..1. Humphrey, "Software Process Developmentand Enactment: Concepts and Definitions," Proceedings. ICSP 2, IEEE, February 1993.

[Gacek et aI., 1994]. C. Gacek, A. Abd-Allah, B. Clark, and B. Boehm, "On theDefinition of Software System ~A.rchitecture,"USC Center for Software EngineeringTechnical Report, November 1994 (also submitted to lCSE-17 Architectures workshop).

[Garlan-Shaw, 1993]. D.Garlan and M. Shaw, "An Introduction to SoftwareArchitecture," in V. Ambriola and G. Tortora (ed), Advances in Software Engineeringand Knowledge Engineering, World Scientific Publishing Co., 1993, pp. 1-39.

[Kellner et aI, 1990]. M. Kellner, P. Feiler, A. Finkelstein, T. Katayama, L. Osterweil,M. Penedo, and H.D. Rombach, "Software Process Modeling Problem," Proceedings.ISP\V6, IEEE, October 1990, pp. 19-29.

[NlST, 1993]. NIST Special Publication 500-211. Reference Model for Frameworks ofSoftware Engineering Environments (Technical Report ECMA 1RJ55, 3rd ed.), NationalInstitute of Standards and Technology, August 1993.

[Osterweil, 1987]. L. Osterweil, "Software Processes Are Software Too," Proceedings.ICSE 9, IEEE, March 1987, pp. 2-13.

[Perry-Wolf, 1992]. D. Perry and A. Wolf, "Foundations for the Study of SoftwareArchitecture," ACM Software Engineering Notes, April 1994, pp. 40-52.

[Royce, 1970]. W. W. Royce, "Managing the Development of Large Software Systems:Concepts and Techniques," Proceedings. WESCON, August 1970.

[Royce, 1990]. W. E. Royce, "TRW's Ada Process Model for Incremental Developmentof Large Software Systems," Proceedings. lCSE 12, IEEE, March 1990, pp. 2-11.

[TRW, 1973]. "TRW Software Development and Configuration Management Manual,"TRW, Redondo Beach CA, December 1973..