Generalized Release Planning for Product-Line Architectures

Transcription

1 Genealized Release Planning fo Poduct-Line Achitectues Louis J. M. Taboda Macquaie Gaduate School of Management, Macquaie Univesity, NSW 2109, Austalia Abstact. This pape elaboates on the coodination and management of evolving softwae poduct-lines, whee development teams wok aound a shaed and eusable domain infastuctue. The tend away fom monolithic applications and towads component-based, poduct-line achitectues has enabled the development of complex softwae to be undetaken by autonomous and often, geogaphically sepaated teams. To delive a complete poduct o poduct-line equies significant coodination to bing the sepaate development steams togethe, at ageed points in the schedule, fo integation and test. In such complex development scenaios a Release Matix has been poposed as a genealization of elease planning and tacking, addessing multiple poducts, components and thei inte-dependencies at an entepise o maketplace level. Hee we descibe esults fom the pactical tials of the Release Matix that povide pagmatic guidelines fo its use and indicate aeas fo futue eseach. Relationships to established pocesses, including equiements engineeing and configuation management, ae claified and the methodology neutal technique is shown to complement wok in aeas, including Agile Methods and component contacts. 1 Intoduction Component-based development (CBD) [1] and poduct-line achitectues (PLAs) [2] ae becoming inceasingly popula because of the economic, quality and time-tomaket benefits that esult fom the systematic euse they enshine. These achitectues have influenced the oganizational stuctues adopted fo softwae-intensive pogams, offeing new, flexible altenatives to managing the complexity and distibution of development activities [3, 4]. Inceasingly the development of softwae is undetaken by autonomous, and often, geogaphically sepaated softwae teams. Each of the teams can wok on one o moe sepaate, lage-gained components, o sub-systems, that povide pat of the poduct capabilities. They may utilize diffeent technologies, development pocesses and can have thei own intenal elease schedules, so long as the components can be integated into the end poduct at some point in the schedule. At one exteme, system components may be commecial-off-the-shelf (COTS), in which case they behave as black-boxes in both the management and technical sense. At the othe end of the scale, components can be developed in-house and be subject to changes as a esult of evolving business needs. Iespective of thei natue, delivey of the completed poduct o poduct-line equies the confluence of these diffeent development steams at ageed points in the schedule to enable integation and testing. This entails highe-ode pocesses than Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

2 taditional softwae development and includes the identification, selection, integation, test and elease activities necessay to get the poducts to the maket [5, 6]. While the technical aspects of integating such component-based poducts ae familia, the complex set of coodinated steps that have to be pefomed just to get the coect vesions of the appopiate components togethe in a suitable envionment and then assemble them into the end-poduct, emains an open challenge. Many of these essential logistical o management aspects of development fall into the ealm of configuation management, and this discipline and its associated tools ae seen as essential to managing the complexity of such envionments [7, 2, 8]. But while these ae evey-day concens fo many softwae oganizations, the taditional appoaches to managing standalone development pojects ae poving to be inadequate [9-11] in the face of inceasing complexity. The Release Matix has been poposed [12] as a mechanism to facilitate the planning, communications and coodination of incemental eleases by consolidating the taditional equiements engineeing and configuation management pinciples. While these pinciples povide valuable guidance in any development scenaio, they ae based on the pemise of single-poduct development. The Release Matix is a geneic, methodology neutal technique that is, and has been shown to be, a genealization of taditional elease planning fo situations whee thee ae multiple poducts and components[13]. It offes a simple template that explicitly ecods the entepise o maketplace configuation that is the entie PLA and can captue diffeent stakeholde viewpoints of the development atifacts acoss the lifecycle. This pape epots on peliminay tials in a complex softwae development poject that set-out to ceate a new poduct based on seveal pe-existing sub-systems. The tial-poject team conducted a eview of the Release Matix technique using inteviews to validate the fundamental assumptions that undepin the technique. The technique was then applied to key featue sets, in paallel with the mainsteam development activity, to demonstate its applicability and validity. The emainde of this pape is oganized as follows. Section 2 discusses the challenges that inceasing softwae complexity ceates fo development and the calls fo new management paadigms to addess them. Section 3 biefly eviews the fundamental concepts behind the Release Matix, and Section 4 ecounts the expeiences of peliminay tials of the technique, placing the technique in the context of elated wok. Finally, the pape concludes by summaizing the key chaacteistics and benefits of the Release matix, indicating aeas of futue eseach. 2 The challenge to cuent best pactices The ising tide of complexity is inceasingly taxing cuent best pactices, and PLAs epesent one of the most significant management challenges of ou times. Planning fo a poduct-line equies temendous management and technical effot that can then be too easily wasted when changes have to be made. Such fustations ae not unique to PLAs. Rathe it is epesentative of the inceasing dissatisfaction and questioning of taditional best pactices that is taking place today. 2.1 Gowing disenchantment with best pactices The temendous inteest in standads and methodologies in the 1990s have been eplaced by a gowing disenchantment with these planned appoaches to development. Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

3 Fitzgeald eviews the pessue fo inceased fomalism and the liteatue bias in favo of methodologies [14]. He descibes the pessues fo new appoaches to systems development that include the changing natue of business and development, as well as the need fo apid application development. In a subsequent study that taced the oigins of the then cuent development methodologies [15] he agues that most wee founded on concepts, which emeged in the peiod fom about 1967 to While this study pedates the emegence of component-based development and PLAs, they can be seen as evolutionay outgowths of object-oiented concepts that can themselves be taced back to ealie times. The conclusion that is dawn fom this wok is that new methodological canons moe appopiate to the needs of cuent development need to be deived. A moe ecent call fo new development paadigms was made by the Agile Manifesto [16] authoed by a goup of methodologists and industy expets that banded togethe to expess thei disenchantment with the state of cuent best pactices as expessed in standads and industy pactices advocated by, fo example, the Softwae Engineeing Institute in its Capability Matuity Models. Instead, the authos called fo simple, moe flexible appoaches to softwae development that value: individuals and inteactions ove pocesses and tools; woking softwae ove documentation; custome collaboation ove contact negotiation; and esponding to change ove following a plan. A numbe of the poponents of Agile Methods, such as Highsmith [17], have adopted biological metaphos fo softwae development, and popose a moe adaptive and iteative appoach to development that coespond to the self-oganizing pinciples of complex systems in natue. The wod methodology theefoe has to be used cautiously in an Agile context and Highsmith instead poposes the tem ecosystem as the pefeed desciption of the flexible, collaboative and esponsive envionment that is necessay fo moden softwae development. The debate on the elative meits of Agile and taditional, planned development methods continues, and the pupose of this discussion is not to advocate one o anothe of these development philosophies. Rathe, it is pesented to suppot the agument that taditional appoaches to managing development ae inceasingly unde stain. The deficiencies in best pactices noted above ae only exacebated when the complexity of poduct-lines ae consideed. The fundamental debate appeas to be between the meits of the tacit knowledge advocated by the few good people needed fo Agile Methods vesus the codified knowledge of standads and othe best pactices. The undelying question that motivates the cuent eseach (and when answeed could ease the concens of both Agile and moe taditional methodologists alike) is whethe cuent best pactices, with thei focus on single-poducts, single-customes and single-supplies, ae addessing the eal-wold situations that moden developes face. Pehaps a moe appopiate epesentation of the cuent complexity would allow the tacit knowledge that is held by an expeienced softwae expet to be bette codified. 2.2 Management Pattens fo gowing complexity System decomposition, and thus the pinciples that undelie CBD, ae a esult of standad eductionism applied to system complexity. But while thee ae significant benefits povided by component achitectues that localize and insulate changes and Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

4 enable lage-scale euse, a tade-off has to be made in tems of the inceased management buden they impose. The gowing success of component-based technologies is esulting in the sepaation of softwae teams into poduces of specialized, eusable components (o sevices) and consumes of these components that then combine them into maketable applications, systems o poducts. The pesence of these two views of development has been labeled the Maketplace Patten [12] and is ecognizable within entepises whee teams wok with a common domain achitectue, o identifiable in industy alliances that utilize o poduce a shaed softwae infastuctue. The othogonality of poducts and domain assets and components is a ecognizable patten [18] that is also evident in envionments whee thee is a shaed infastuctue including Infomation Systems whee common systems o sevices (e.g. povided by an extenal agency) behave in the same manne as eused softwae components. Softwae poduct-lines povide the pefect example of the Maketplace Patten, since thei development equies the coopeation of multiple poduct teams that utilize common domain components. Clealy defined poduct (and maket/custome) esponsibilities and the ecognition that the achitectue is the key to the poduct-line combine to make the dependencies between component poduces and consumes moe ponounced (and ecognized). 2.3 Holistic Management The complexity of poduct-lines and othe componentized softwae achitectues have a significant influence upon the way in which the development oganization is stuctued. While a component-based achitectue and the vaiations in changevolatility can esult in components having diffeent elease-cycles, it is the oganization the teams that actually do the development - that ensues sepaate esponsibilities fo each elease and gives ise to the complex coodination necessay to effect a poduct delivey. In poduct-line development, the softwae teams that paticipate in the development pocess can behave as decentalized, independent agents that inteact to achieve the poduct eleases. The multiplicity of components, inteelationships and mutualdependencies that is evident in poduct-lines deseves the designation of a complex softwae ecosystem, in acknowledgement of the Agile methodologists. Such envionments ae ecognized as a management challenge beyond the standad softwae development [2]. In paticula, the configuation management (CM) poblem in such envionments is significantly inceased, and common CM techniques ae often inadequate o have to be stetched to tackle the diffeent levels at which the poblem manifests itself [2, 19]. Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

5 Uses C 1 P1 C 2 P2 C 3 P3 C 4 Poducts Component Achitectue Fig. 1 Maketplace Patten fo multiple poducts and components While taditional methods focus on the development activities needed to ceate and elease a component, thee also needs to be pocesses to assemble the wide configuation of poducts. Planning and coodination needs to take place in both dimensions simultaneously and it has been peviously shown that to plan each elease in isolation is sub-optimal [12]. With moe than one poduct to manage in a poduct-line this eseach agues that the appopiate genealization is to conside the entie poduct-line as a single configuation whee all poducts and components ae managed togethe with thei elationships. This supe-configuation has to be teated holistically, much as systems engineeing attempts, to take an integated viewpoint of a complex, decomposed system configuation. The diffeence between poduct-line achitectues and an odinay complex system is howeve the euse elationships that educe the contol of any single poduct [13] and make it necessay to plan and coodinate all eleases in the ecosystem holistically and collaboatively. 3 Repise of the Matix Model The Maketplace Patten, simplistically illustated in Fig. 1, captues development ecosystems, such as PLAs, whee concuent poduct development is based upon a eusable, component-based famewok. Thee ae two distinct, othogonal management views that can be taken of such development envionments [12] the fist based on the poducts and the second based on the components. The patten can be shown to be sufficient to deive a matix epesentation [13] that is moe suited to the management of such complex softwae developments. Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

6 3.1 The Release Matix A matix epesentation offes the ability to ecod elevant, lifecycle infomation in each individual cell, while captuing the dependencies between membes of the ecosystem. In paticula, a Release Matix has been poposed as a means of planning and tacking the evolution of the system achitectue ove time. As shown in Fig. 2, the Release Matix ecods the components (x-axis) and the poducts (y-axis) that use these components, integating them into the maket offeing. P1 P2 P3 C1 C2 C3 C Poduct Releases Component Releases Fig. 2. A Release Matix consolidates the poduct and component pespectives The matix can be seen to coespond to the elationships shown in Fig. 1 whee the existence of a elationship between a poduct (P i ) and component (C j ) esults in an enty in the intesecting cell ( ij ). When no elationship exists between a poduct and component thee is a zeo o null enty in the coesponding cell. The content of the cells of a Release Matix can be simply egaded as the scheduled dates of the set of dependent eleases, howeve a family of simila matices can be employed to ecod diffeent lifecycle data depending upon the utilization of the matix. Fo example, in ode to deive and coodinate the elease schedules fo all poducts and components, a sepaate matix can be used to ecod the poduct equiements that have been allocated to the diffeent components. With efeence to the elease planning scenaio peviously descibed, the P2 ow could epesent the bill-pint poject whee C2, C3 and C4 would be the display, stoage and pint-management components. The multiplicity of eleases that ae a featue of CBD envionments can benefit fom the claification offeed by the Release Matix. It povides a succinct and explicit means of ecoding the dependencies between poducts and components, while suppoting the sepaation of concens pinciple by exticating the two pespectives. Each ow of the Release Matix epesents a poduct s elease plan that is deived fom, and must be compatible with the component eleases that the poduct is eliant upon. Similaly, each column epesents a component s elease plan, based upon the total set of poduct equiements that ae to be implemented in the elease. As a whole, the Release Matix epesents a maste elease plan that consolidates and synchonizes the individual elease plans of both the poducts and the components. By way of example, the highlighted column in Fig. 2 epesents the pespective of the team esponsible fo component C2 that needs to balance the demands of poducts P1 and P2. The highlighted ow coesponds to the eliance that poject P2 has on thee components, C2, C3 and C4, that may need to have coodinated eleases to Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

7 effect a business change. The intesection of these two pespectives indicates the specific plan o contact between the P2 and C2 teams. Simila plans must be negotiated fo all non-null cells as they point to a dependency between the stakeholdes that equies coodinated attention in ode to achieve an ageed and consistent set of eleases. In geneal, Fig. 2 shows that each poduct goup must attempt to align the components it elies upon acoss the ow, while each component poduce must weigh and pioitize the equiements of its customes shown in that column. These othogonal pespectives epesent the diffeent tensions that have to be balanced in a complex component-based envionment. 4 Application in the eal-wold The Release Matix is a elatively simple concept that is the esult of captuing and elevating a widely ecognized patten in complex component-based systems to become the cental tenet of its management paadigm. Its usefulness howeve can only be tuly gauged by application in a eal-wold industy setting. Tials of the Release Matix wee theefoe conducted in a lage softwae development oganization that was undetaking a challenging new pogam. This equied the euse and mino modification of pe-existing, lage-gained components that wee then integated and packaged fo a new maket segment even as each of these existing components continued to be maketed sepaately. As such, the scenaio epesented an example of the Maketplace Patten with a numbe of sepaate poducts competing to have thei featues developed by the sepaate component teams that themselves had to balance these and othe demands. The following povides an oveview of the pilot study whee the oganization s achitectue and activities wee mapped into the Release Matix s axes to detemine the applicability of the technique and the benefits it could offe. Each aspect of the tial is descibed fist in tems of the theoetical o ideal appoach that would be advocated, and then followed by the pagmatic appoach that had to be taken in pactice. 4.1 Requiements Management Each of the new poduct s featues placed new equiements on the eused components and had to be completed in the next elease cycle. These equiements spanned a numbe of the components and each had to be implemented befoe the new featues could be integated and tested. The new featues wee not the only equiements that wee placed on the components howeve, and othe goups made simila demands on the development teams. While the custome elease date was common to all poducts, intenal eleases that enabled poduct integation and testing had to be sepaately negotiated Requiements in Theoy The Release Matix is most applicable when an incemental elease stategy is adopted in an aleady existing PLA. New poduct equiements can necessitate the modification of existing components, with significant new featues having the potential to foce the development of entiely new components that extend the Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

8 achitectue. Futhe, component teams can have thei own technical, non-poduct equiements that also have to compete fo development time and esouces [11]. In the Release Matix, each poduct elease is epesented by a ow with each cell captuing the set of equiements that the poduct places on the component epesented in that column. These sets ae the accumulation of the poduct featues to be included in the elease, each of which can in geneal have allocated equiements that impact moe than one component. This situation is illustated in Fig. 3. and can be seen to epesent the equiements allocation and taceability that is at the coe of equiements engineeing. Featues Pioity Comp. 1 Comp. 2 Comp. 3 Comp. 4 P 1 Poduct 1 featue set 2 P 2 Poduct 2 featue set 1 P 3 Poduct 3 featue set 1 Fig. 3 Requiements allocation and taceability in the Release Matix Whee each poduct ow is expanded to descibe each featue and its allocated equiements explicitly, the Release Matix can be seen to be no moe than a list of individual equiements. The equiements in each cell ae elated to the contact between the use (consume) and supplie (poduce) of the component. In a poductline ecosystem, howeve, thee ae multiple, potentially competing contacts between a component supplie and its diffeent uses that have to be negotiated and consolidated so as to be consistent - in an analogous fashion to the meging of diffeent vesions of a souce-file that has been subjected to paallel changes. While it cuently lacks the fomalism of eseach into euse [20] and equiements [21] contacts, the matix epesentation does povide the means to aay the multiple, elated contacts necessay fo the development of poduct-lines. The epesentation can also be made compatible with sepaate poduct-line equiements management techniques poposed in the liteatue [22, 23] by explicitly identifying the common and vaiant equiements Requiements in Pactice Two poduct featue-sets wee studied in detail and the specific equiements allocated to the components affected. The oiginal specification documentation was dissected and eoganized so that common equiements that impacted all components wee sepaated fom those that had unique demands of some of the components. Even elatively simple poduct featues wee found to impact diffeent components and equied all to be implemented befoe the featue s benefit could be ealized. While the focus of the tial-poject was on these new equiements, the component teams had othe equiements that they also had to addess in the same elease-cycle. A simple speadsheet was used to implement the Release Matix, and the expanded ows containing the individual featues wee listed in coloed poduct bands to identify thei souce. While space was limited, it was possible to summaize the key points in each cell and utilize hypelinks to point to elated infomation as equied. Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

9 Featues Pioity Comp. 1 Comp. 2 Comp. 3 Comp. 4 P 1 Poduct 1 featue set 2 P 2 Poduct 2 featue set 1 P 3 Poduct 3 featue set 1 Fig. 4 Coss-poduct elease planning conducted by each component team The Release Matix was shown to povide claity to the diffeent equiements peviously embedded in a numbe of specifications documents. This showed its potential as a communications device, especially duing peiods of intense negotiation when a definitive and ageed set of eleases was being planned. It was also obseved that the Release Matix povided value as a notation even whee thee was no euse and hence no need to negotiate the featues acoss poducts. The simple gid layout (also utilized in [23]) allowed fo impoved planning at the moe ganula level whee diffeent featues within one poduct had to be assigned to a scheduled incemental elease. The only eal diffeence between this moe detailed scenaio and that of the poduct-line elease planning is the numbe of oganizational stakeholdes involved. Thee ae still stakeholdes to be satisfied in the taditional, incemental elease planning scenaios [24], howeve, they ae less visible at the entepise level. 4.2 Release Planning Concuent demands placed by the sepaate poducts upon the limited development esouces of the component teams epesent a majo planning challenge in poductlines. While this situation is not unusual in softwae pojects that have to juggle and pioitize equiements fom diffeent uses that have competing needs, poduct boundaies and pioities have to be negotiated in poduct-lines (Fig. 4). Each poduct can act unde the illusion that its evolution can be sepaately planned when in fact the diffeent demands all impact the coe, eusable components and esult in vitual dependencies between the poduct schedules. This is shown in the simple poduct-line planning scenaio descibed in [12] Planning in Theoy The Release Matix has been descibed not as a single matix but as a template that allows the captue of divese development infomation in what is moe accuately a family of elated matice [12]. It can be consideed as compising of layes, each holding diffeent lifecycle infomation appopiate to the stage of the development (Fig. 5). When scooping a elease, the cells can captue the sepaate estimates made by the affected component teams fo each poduct s pioitized featue, ultimately followed by a ecod of the ageed schedule dates o build-cycles. As detailed planning commences, each poduct team should have a pioitized list of featues poposed fo the elease. In poduct-lines, this pioitization is not just Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

10 within one poduct as in taditional development pojects [25], but the common domain achitectue necessitates pioitization be done acoss all poducts. Cosspoduct equiement dependencies must be added to those evident in single-poduct development [11], complicating the planning activities. Release planning theefoe takes place in both dimensions of the Release Matix, with poducts pioitizing thei featues and components having to estimate and plan the implementation effot needed fo the allocated equiements. Poduct Dimension t FS1 Estimation v Time (Lifecycle) FS2 v v FS3 e d d t t t e e e e d d d t t t e e d d Release Plan Test Plan Delivey Analysis Featues Achitectue Dimension Pioitized Poduct Featues Allocated Requiements fo each Component Estimates of Effot Scheduled Dates Test Plan and Cases Deliveed Configuation (vesions) Fig. 5 Layes of the Release Matix containing lifecycle infomation Complications aise because poduct featues often equie a numbe of component modifications to be completed to achieve the desied capability, and patial implementation is not pacticable. Depending upon whethe the oganization woks to a fixed elease cycle, o deives its schedule based upon the ageed featues in a elease, detemines whethe the featue s availability is pushed out to the latest component team s implementation date o, potentially, is dopped fom the elease. In eithe case, sepaate ounds of planning and negotiation may have to take place befoe all component teams can agee to the contents of the elease. A set of commitments eventually esults fom the poduct-line s stakeholdes and can be captued in the Release Matix. Fo each featue, the negotiated commitment is epesented by a tick-in-the-box fo each affected component teams, so each featue ow in the expanded matix has the elevant component team s committed schedule. Thus the Release Matix can be seen to povide a consolidated view of the multiple, Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

11 individual component contacts [21, 20] that have to be negotiated in a poduct line envionment Planning in Pactice If planning a elease fo a single poduct is had, then the effot and communication necessay to achieve an ageed schedule fo a PLA intoduce anothe dimension of complexity. While the multiplicity of stakeholde views is taditionally funneled though an analyst, in the case of the tial-poject s coss-poduct setting, each poduct s featue set had to be negotiated diectly with the poduct epesentatives. While the tial was sepaate fom the mainsteam planning pocess undetaken by the oganization, it was evident that the numbe of stakeholdes diectly involved in the planning was significant, and the communications necessay to each an ageed plan, wee consideable. The oganization woked to fixed date eleases and had aleady aligned the elease of each component and poduct team to allow a single, synchonized elease fo the entie poduct-line. Planning was equied not simply fo the final elease but also fo a numbe of inteim eleases necessay to integate and test specific featue sets befoe final delivey. Since the elease planning was acoss multiple poducts, the stategy adopted was to eview the pioitized featue lists and whittle them down to meet its published shipdate. Theefoe the negotiations between the diffeent stakeholdes wee intense with each component team effectively having a ight of veto in deciding on the feasibility of a poduct featue. Unless a featue can be implemented sepaately in each component (and so be eleased incementally ove multiple elease-cycles, that intoduces futhe planning complexity even whee technically feasible) a component team being unable to commit to implementing its allocated equiement in the eleasecycle an the isk of the featue being dopped. Given that such a scenaio was not the poduct manage s desied outcome and so was unpalatable, had decisions egading the elimination of featues wee difficult to make. Thee was some evidence that it was easie to appea to agee to include featues, letting them eithe be de-scoped o dopped by attition late in the elease cycle. What was evident and fustating to the poduct team, was that a definite schedule fo the availability of component capabilities was difficult to pin-down, making integation and testing of the poduct poblematic. In inteviews, it was evident that the need fo a pe-elease poduct eview milestone dove the need fo some cetainty, and thus led to the utilization of a table that esembles the Release Matix. In this table each capability to be demonstated was epesented in a ow and the development manages esponsible fo each component had to supply the date by which thei (allocated) equiement would be met. When all component teams implementing pat of the capability had committed to a date, that featue was then tacked though fom delivey to integation, test and finally demonstation. The esult of the peliminay tials of the Release Matix has shown its potential to be utilized as a holistic planning tool that allows bette visualization of the planning pocess and the completeness and stability of the poduct-line s elease commitments and schedules. It offes a means to impove team communications and to suppot decision making, both in the ealy planning stages and in the maintenance and tacking of the plan, as was used to manage the poduct eview milestone. Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

12 4.3 Shaed Achitectue As peviously stated, the components that wee ecoded in the columns of the Release Matix wee a pat of a pe-existing achitectue. Simila to the poduct dimension, these can be boken down fom sub-system into the lowe-level components that wee impacted by the diffeent featues. Thus the Release Matix pesents the entepise o maketplace achitectue compising the entie inventoy of softwae (and potentially othe) assets that compise the poduct-line Achitectue in Theoy The columns of the Release Matix epesent the high-level, achitectual clumps that elate diectly to the configuation items of classical, systems configuation management. It should be noted that this epesents the achitectual view fom a management pespective that taditionally beaks-down a system (o poduct) into lowe level components. While Object Oiented (OO) thinking has ovetaken stuctued, top-down, functional methods in design and development, the need to divide a pogam s scope into manageable clumps emains valid in a management context. Theefoe, even whee the achitectue may be achieved though diffeent means, it is agued that fom a management and oganizational context it can be viewed as decomposable, at least at the highe-levels of abstaction. When the Release Matix was fist intoduced [12] thee was a bief discussion of the composition of the columns. A PLA compises of both poduct specific components and shaed domain components. While the use-euse elationships gave ise to the Maketplace Patten that esulted in the Release Matix, configuation management consideations led to the inclusion of both shaed and poduct specific components in the columns of the matix. This also had the benefit of avoiding semantic discussions about what constituted domain components and avoided the sepaate teatment of eused components that ae not a pat of the domain. Discussion of the Release Matix as applied to poduct-lines is not complete without claification of its elationship to vaiation management. Kuge has clealy aticulated the configuation management challenges faced in poduct-line development [26] and intoduces vaiation management as a new dimension to taditional CM. The ole of the Release Matix in managing vaiation points has not cuently been exploed with the discussions and tials to date teating poduct vaiability as a design challenge, athe than as a management one. The influence of CM thinking is evident in the management focus taken hee at the expense of design vaiability. CM has taditionally viewed its ole as independent fom the details of the configuation itself [27] that suppots the view that vaiability be consideed a design poblem athe than a CM poblem [28] Achitectue in Pactice The fist ealization in applying the Release Matix was that eal-wold achitectues ae not the idealized stuctues of textbooks and that thei evolution ove time can lead to component stuctues that ae highly intetwined. The oganization conducting the tials had an emeging poduct-line that meant that many euse oppotunities wee still to be ealized and component elationships wee complex and still evolving. Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

13 In applying the Release Matix, identification of the columns at the sub-system level was not difficult but poved insufficient to actually descibe the featue impacts. Dilling deepe meant descending into an inceasingly complex achitectue whee the dependencies between poducts and components fa exceeded the idealized, many-tomany elationship of the Maketplace Patten. Thee wee ambiguities ove what was a component and what was a poduct, since some elatively low-level components wee sepaately maketed. Sub-systems, when decomposed into thei components, wee shown to have lowe-level components in common. Thee wee familia pathological dependencies identified in the detail[11], whee a component would bundle lowelevel modules, yet the poducts that used the component also diectly used the capabilities of some of the modules. Theefoe the idealized image of a decomposable achitectue captued by the columns of the Release Matix, while potentially a useful goal, did not exist in eality. Indeed, the maketplace patten was evident at diffeent levels in the achitectue, as euse was evident at diffeent levels of ganulaity. Theefoe the tials took on a moe pagmatic appoach that attempted to apply the Release Matix to the components that wee actually in play when consideing diffeent featue sets. Allocated equiements wee often moe appopiately discussed at a lowe-level of detail, thus, the low-gained components wee eplaced with only those lowe-level components that wee affected This poved to be valuable in that it eliminated components that wee not impacted by the featues fom view and focused discussion at a level at which the paticipants wee comfotable. Utilizing a speadsheet to captue the Release Matix necessitated the ceation of sepaate speadsheets dependent upon the featue set and the affected components, a limitation that could be ovecome easily with a moe sophisticated tool that suppoted the Release Matix concept. The ultimate goal in such a tool would be to undetake the analysis at the detailed level, which the tool could then consolidated with othe equiements placed on the components 1. In this manne, the complete scope demanded of each achitectual component could be viewed and assessed in the planning stage. 4.4 Oganizational Consideations and Impacts The manne in which the development oganization is stuctued influences the packaging and delivey of the softwae capabilities. Diffeent oganizational stuctues, whethe a small in-house team, a emote o off-shoe development goup, o a thid-paty contacto o vendo, esult in the bundling of the capabilities within thei scope into eleases. The oganization of the development should follow the achitectual boundaies but this may not necessaily be the case. The oganizational stuctue theefoe seves to incease the numbe of sepaate deliveables that have to be integated togethe to povide the end-poduct Oganizations in Theoy The headings in the twin dimensions of the Release Matix identify the significant stakeholdes involved in the poduct-line. The ow headings identify the poducts that aim to satisfy the maket segment that thei poduct sevices. The column headings have been identified above as the configuation items that elate to the high-level 1 Technology suppot fo the matices descibed in this pape is the subject of a patent application to potect the commecialization of these concepts Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

14 PLA. While each item is an achitectual component o sub-system, its selection is deeply ooted in the oganization stuctue to be utilized. The only equiement to utilize the Release Matix, howeve is that each of these components is developed and eleased sepaately [11]. The selection of the configuation items has long been a contentious and vague pocess in CM. Today, whee incemental and iteative development methods ae the eigning paadigm, the decision to manage (o contol in a CM sense) a component sepaately entails effot to bundle, build, test and delive capabilities in a seies of evolutionay eleases. If the Release Matix technique wee to assume the full weight of CM best pactices, it too would become enmeshed in the debate of what was the pefect oganizational stuctue to manage a paticula pogam o achitectue a topic that waants futhe eseach in its own ight. To be effective in diffeent envionments, the Release Matix technique is theefoe positioned as a captue of oganizational decisions aleady made and in pactice. If its application thows some new light on the effectiveness of these decisions, then its pupose has been seved. Any impovements that esult fom a eview of the development oganization o elease stategy can then be captued in a subsequent elease (matix) Oganizations in Pactice The tial pogam involved a multi-site oganization with geogaphically sepaated development goups based aound the key sub-system components. Poduct manages epesented each poduct goup, while each component team had a development lead. When poject and test manages ae included along with domain expets and developes, the oganization that fomed aound any initiative gew quite lage. Theefoe, when coss-poduct domain components wee affected, the numbe of affected stakeholdes involved in elatively simple poduct-line enhancements could quickly become difficult to manage. Getting a fim commitment fom these cosspoduct, coss-functional goups was not easy and, as peviously descibed, communications consumed a lot of time. While the alignment between oganizational stuctue and achitectue was shown to be good at the highe level, the coespondence gew muky in the detail. It was clea that the oganizational units lagely influenced the detemination and scope of elease packages. Iespective of the achitectue demacations, it was the team that had to ovecome any poblematic design dependencies though caeful implementation and management attention. The Release Matix can natually be elated to the matix oganizational stuctue and by consideing just the stakeholdes that epesented poducts and components, a vitual matix oganization was clea and echoed the decision making foums that had emeged. What also became clea duing the tial was the elative instability of the ecosystem that the Release Matix epesented. The only foce binding the Release Matix togethe and peventing its beakup into independent development steams was the decision by top executives to delive on the new poduct. At lowe levels in the oganization thee wee numeous tensions aising fom competing pioities and incentive mismatch [29], which if left unchecked could pesent a isk to the pogam. Failue to balance the diffeent needs of the stakeholdes would see a evesion to the individual poduct stategy and loss of the benefits of systematic euse. Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

15 5 Conclusion This pape has elaboated on the application of the Release Matix that has been poposed as a technique fo the planning and tacking of softwae poduct-line. Tials of the technique in a new development pogam that added a new poduct vaiant to an existing poduct-line ae discussed. The maketplace patten was found to be clealy evident at multiple levels within the achitectue, and a Release Matix was ceated fo the two key featue-sets that wee studied. The concuent equiements placed on the diffeent component teams wee epesented in a concise and clea fomat so that thei wok scope could be moe easily estimated and negotiated. Although the Release Matix was not used fo the actual planning of the tial pogam, a simila constuct was independently utilized to dive commitment fo, and to tack the delivey of, a poduct eview milestone. The complex and intedependent achitectue was shown to equie the micoapplication of the technique which, with the assistance of suitable tools, still offes the oppotunity to establish the scope of wok and oll-up the esults into a consolidated Release Matix. The esults of the tial showed the potential of the Release Matix as a catalyst fo focusing attention on oganizational and achitectual anomalies. The expeience gained, theefoe, has esulted in both an oppotunity to efine the technique to suit the impefections of eal-wold poduct-line development, and to show the tial-poject team oppotunities fo pocess impovement. In paticula, the concepts embodied in the Release Matix ae being used to focus the multi-site, coss-functional, cosspoduct communications and povide impoved suppot fo decision making. The tial helped to flesh-out the initial desciption of the technique that wee highlevel and lacking detail. In paticula, the ole of the Release Matix as a template to be used to populate diffeent lifecycle infomation was claified. Aguably the singula matix is confusing as thee ae multiple facets to a elease. In the incemental elease stategies popula today, a elease is not simply an event, but encompasses the lifecycle of an iteation including the gatheing of equiements, estimation of effot, negotiating and planning, and finally captuing and tacking the ageed schedule. Theefoe the Release Matix attempts to consolidate this citical development infomation and pesents as diffeent views of the elease s status. Futhe eseach is being undetaken on both the application and efinement of the Release Matix technique. Case studies and tials ae poposed in oganizations woking with component-based o poduct-lines that exemplify softwae euse. The maketplace patten that motivates the Release Matix is evident in many othe envionments and its wide application in IS and othe complex envionments emains to be exploed. As a context and methodology neutal technique, the Release Matix should be futhe investigated as a geneic management method that is appopiate in any envionment chaacteized by concuent demands being placed on limited, shaed esouces. Refeences 1. Szypeski, C.: Component Softwae, Beyond Object-Oiented Pogamming. Addison-Wesley (1997) 2. A Famewok fo Softwae Poduct-line Pactice,. Softwae Engineeing Institute. (2003) Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

16 3. Bosch, J.: Softwae Poduct-lines: Oganizational Altenatives. Poceedings of the Twenty-Thid Intenational Confeence on Softwae Engineeing. (2001) 4. Toft, P., Colman, D., Ohta, J.: Coopeative Model fo Coss-Divisional Poduct Development fo a Softwae Poduct-Line. Poceedings of the Fist Softwae Poduct-line Confeence. (2000) 5. Baye, J., et al.: PuLSE: A Methodology to Develop Softwae Poduct-lines. Poceedings of the Poceedings of the Symposium on Softwae Reusability. (1999) 6. Bug, W.D., et al.: Exploing a Compehensive CBD Method: Use of CBD/e in Pactice. Poceedings of the Thid Intenational Wokshop on Component-Based Softwae Engineeing. Limeick, Ieland. (2000) 7. Technology Dimensions of Poduct-line Implementation Appoaches. Faunhofe Institute, IESE-Repot No /E (2002) 8. van Ommeing, R.: Configuation Management in Component-Based Poduct Populations. Poceedings of the Tenth Intenational Wokshop on Softwae Configuation Management (SCM-10). Toonto, Canada. (2001) 9. Bosch, J.: Poduct-Line Achitectues in Industy: A Case Study. Poceedings of the Twenty-Fist Intenational Confeence of Softwae Engineeing. (1999) 10. Cnkovic, I., Lasson, M.: A Case Study: Demands on Component-based Development. Poceedings of the Intenational Confeence on Softwae Engineeing. (2000) 11. Cnkovic, I., Lasson, M.: Challenges of Component-based Development. Jounal of Softwae Systems. Vol. 61, No. 3, (2002) 12. Taboda, L.J.: Planning and Managing Poduct Line Evolution. Poceedings of the Fifth Poduct Family Engineeing (PFE-5). Siena, Italy. Spinge-Velag, LNCS (2003) 13. Taboda, L.J.: The Release Matix fo Component-Based Softwae Achitectues. Macquaie Gaduate School of Management, Woking Pape (2004) 14. Fitzgeald, B.: Fomalised Systems Development Methodologies: A Citical Pespective. The Infomation Systems Jounal. Vol. 6, No. 1, pp (1996) 15. Fitzgeald, B.: Systems Development Methodologies: The Poblem of Tenses. Infomation Technology & People. Vol. 13, No. 2, pp (2000) 16. Agile Manifesto. (2001) 17. Highsmith, J.: Agile Softwae Development Ecosystems. Addison-Wesley (2002) 18. van Ommeing, R.: Roadmapping a Poduct Population Achitectue. Poceedings of the Fouth Poduct Family Engineeing (PFE-4). Bilboa, Spain. Spinge-Velag, LNCS (2001) 19. Sowiajan, S., van de Hoek, A.: Managing the Evolution of Distibuted and Inteelated Components. Poceedings of the Elventh Intenational Wokshop on Softwae Configuation Management. Potland, Oegon. (2003) 20. Steyaet, P., Lucas, C., Mens, L.: Reuse Contacts: Making Systematic Reuse a Standad Pactice. Poceedings of the Object-Oiented Pogamming Systems, Languages and Applications. (1996) 21. Rausch, A.: Softwae Evolution in Componentwae using Requiements/Assuances Contacts. Poceedings of the Intenational Confeence on Softwae Engineeing. (2000) 22. Faulk, S.R.: Poduct-Line Requiements Specification (PRS): An Appoach and Case Study. Poceedings of the Fifth IEEE Intenational Symposium on Requiements Engineeing. (2001) 23. Sutheland, M.: Poduct Line Requiements Management. Poceedings of the Twelfth Annual Intenational Symposium of the Intenational Council on Systems Engineeing. (2002) Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.

17 24. Calshame, P., Regnell, B.: Requiements Lifecycle Management and Release Planning in Maket-Diven Requiements Engineeing Pocesses. Poceedings of the DEXA Wokshop. (2000) 25. Kalsson, J.: Softwae Requiements Pioitizing. Poceedings of the Second Intenational Confeence on Requiements Engineeing. IEEE CS Pess (1996) 26. Kuege, C.: Vaiation Management fo Softwae Poduction Lines. Poceedings of the Second Intenational Softwae Poduct-line Confeence. (2002) 27. Estublie, J.: Softwae Configuation Management: A Roadmap. Poceedings of the Intenational Confeence of Softwae Engineeing. (2000) 28. Zelle, A., Fuhaul, K.: Softwae Configuation Management: State of the At, State of the Pactice. Poceedings of the Dagstuhl Semina. (1999) 29. Fichman, R.G., Kemee, C. F.: Incentive Compatibility and Systematic Softwae Reuse. Jounal of Systems and Softwae. Vol. 57, No. 1, (2001) This pape was pesented at the SPLC 2004 confeence and the poceedings ae published in Spinge s Lectue Notes in Compute Science. Refeencing infomation is as follows: Louis J. M. Taboda: Genealized Release Planning fo Poduct Line Achitectues. Poceedings of the Thid Softwae Poduct Line Confeence: SPLC 2004, Boston, MA, USA, August 30-Septembe 2, LNCS 3154, Edited by Robet L. Nod. ISBN: , pages Louis J. M. Taboda, All ights eseved. Mateial may be quoted with coect efeencing see end of pape fo details.