_03 Experiences of Large Banks

Experiences of Large Banks: Hurdles and enablers to the adoption of Software Product Line Practices in large corporate organisations

Martin Krsek, Dr. Jay van Zyl, Robert Redpath, Ben Clohesy SystemicLogic Research Institute, Australia & South Africa

[email protected], [email protected], [email protected], [email protected]

Nick Dean Australia and New Zealand Banking Group (ANZ)

[email protected]

Abstract

Product Line concepts are widely used and adopted

across a number of industries. Whilst the software product line concepts are readily accessible to commercial software product companies, the application within corporate environments whose core business is not software has been less evident. What are the types of challenges that large corporate organisations need to overcome? This paper presents a number of hurdles which have been observed during the adoption of the concepts at two large financial services organisations. One particular hurdle relates to the difficulty that business divisions within those organisations have in perceiving a return on investment when a product line is established that crosses business unit boundaries. Furthermore a number of enabling mechanisms, related to funding, IT project and general management aspects are proposed which are showing positive results in facilitating the adoption of Product Line Practices in corporate financial service organisations.

1. Context and Introduction

Product line practices as a concept is used in many forms by organisations around the world [1, 2]. Product managers in fast moving consumer goods related organisations have created a well defined body of knowledge as to the branding, marketing, distribution, and other supply chain related activities in product commercialization. Today these concepts have proliferated throughout most industries as commercial entities are trying to find the next market opportunity, whilst reducing their product and supporting costs.

Commercial software companies, who produce commercial “off-the-shelf” software products, have found the concepts defined by the Software Product Line Practices (SPLP) initiative of the SEI/CMU helpful in producing versions of their products for a number of markets. Corporate organisations, such as banks however, who are traditionally consumers of software, experience difficulties in adopting these practices, which have the potential to address some of their key IT issues.

This experience report documents our research and implementation initiatives between 2002 and 2007. We are introducing projects, implementing aspects of product line practices, in two large banks (ANZ Banking Group and another bank referred to as Bank 2). Large refers to a bank with four million or more customers. 2. General approach and related activity

SystemicLogic has been involved in a number of projects in large banks mostly in collaboration with the IT departments at those institutions. Whilst all of these organisations realize the potential benefits that may accrue from the successful adoption of the SPLP approach, they have encountered similar hurdles. A number of these hurdles relate to difficulties in motivating investment and amending existing funding models for the facilitation of product line developments.

In this paper we document the types of hurdles that have been observed and propose a number of potential solutions and enablers to overcome these hurdles.

Experience reports indicating challenges and best practice have been published before; for example Kircher et.al. [3] discuss the experience at Siemens and briefly outline their views on the challenges relating to skills, agility, outsourcing, tools and drivers for

12th International Software Product Line Conference

978-0-7695-3303-2/08 $25.00 © 2008 IEEE

DOI 10.1109/SPLC.2008.43

161

12th International Software Product Line Conference

978-0-7695-3303-2/08 $25.00 © 2008 IEEE

DOI 10.1109/SPLC.2008.43

161

Authorized licensed use limited to: University of Pretoria. Downloaded on November 20, 2009 at 09:58 from IEEE Xplore. Restrictions apply.

product line development. Their discussion does not explore models of investment and the disincentives associated with software funding, generally regarded as an expense in banks. Kircher et. al. [3] do make a useful distinction between a product-driven business, which they define as a business with a few standardized products that they offer, and a solution-driven business that is defined as a business that custom makes a solution for each customer. Financial organisations fall closer to a solution-driven business but do not match either model well with one distinction being the presence of a captive market consisting of the various profit generating divisions of the organisation.

Krueger [4] also discusses the adoption barriers at the deployment of product line practices. He advocates an incremental approach with a rapid return on investment. To achieve this he proposes choosing an appropriate adoption model from

• proactive - plan based on predictable requirements;

• reactive - implement several variations for each development cycle based on predictions; and

• extractive – make use of existing software products as a baseline for a new product line.

One of the adoption models is combined with lightweight technologies to obtain the optimal approach to reduce the barriers to adoption. Krueger’s ideas are useful but are hard to apply in large financial institutions where product line approaches require a formal approach in part simply because of the size of and number of divisions within the organisation.

Schmid and Verlage [5] identify big bang and incremental investment approaches to product line investment. They also recognize four situations and corresponding adoption schemes for product line engineering these being

• Independent – a new product line is begun without predecessor products

• Project-integrating – existing systems already under development are integrated into the product line development

• Reengineering-driven – Legacy systems cannot be used and non-trivial reengineering is needed

• Leveraged – A new product line is set up based on product line already in place.

Relating this to the financial institutions in this report, there were no pre-existing product lines in place, although for some of the product lines there are pre-existing legacy systems. Schmid and Verlage [5] also demonstrate that there is risk associated with all product line deployments and the investment will vary for the number of products developed thus affecting the break even point at which a traditional development will become a higher cost option.

Another case study by Kim [6] considers an insurance company. Kim sees the main problem in that report as managing variability and he demonstrates a method using rules changes to resolve variability issues. For the purposes of this report variability is of interest, as it will act to increase value to the business divisions. They will still need to be convinced that a return on investment will be obtainable in the short to medium term.

Organisational factors are addressed by Jaktman [7] where she considers the impact of organisational structure, business domain, management practices, and staffing characteristics on maintenance activities for the product line and the consequent effect on the quality of code. The study provided valuable insights with one example relevant here being that funding from Research and Development created a conflict when staff had different reporting lines. The study did not consider barriers to adoption and the two companies in the case study had well established product lines in the telecommunications sector at the time of the study. One of the barriers to adoption considered in this paper is establishing the business benefit. Krueger addresses this in his paper [8] where he suggests a 3-tiered methodology. The bottom tier is development, the middle tier is the engineering management and the top tier is executive and business. The tiers build upon and use the capabilities of the tier below. The approach has been found to reduce development costs and avoid application-focused processes and organisational structures that have been seen as an impediment to adoption of product line practices. While making clearer the benefits of a product line architecture it does not address resistance to adoption in the complex financial services sector where multiple divisions have a focus on the short term and an immediate return on investment.

With regard to cost models Nóbrega [9] provides an excellent survey of the literature on costing and the economic models for reuse generally and software product lines. These models do not address the necessity and particularities of returning funds to multiple divisions in a large financial organisation as are explored in this paper.

162162


3. Product Line Concepts in Large Banks 3.1 Opportunities and Challenges There are some common characteristics possessed by the organisations that are documented in this paper. These include: 1)software is not a core business of these organisations with typically, IT and more specifically their application systems being regarded as an expense that has to be borne by the business in order to deliver their services effectively and efficiently, and to automate the myriad of internal processes; 2) in both organisations the accountability for funding and controlling the application software development is delegated to individual business units, whilst in one, each business unit has its own IT organisation; 3) the long term organisation strategies do not extend to the sourcing and management of application software; and 4) there is a belief that there is a large percentage of commonality existing between the software intensive, financial service products delivered in different regions, to a number of market segments, through a variety of channels, within multiple regulatory frameworks, often using different application systems and infrastructure. Figure 1 indicates some of the issues and challenges that confront large banks as they exist now.

Weak strategic links

Tactical engagement

Reactive approach to IT capability

Paper-based application architecture

No IP preservation

Key people dependence

No product line implementations

Duplication of capability

Escalating cost

Approach scalability issues

Figure 1 Issues in the Existing Context In addition experience in working at the two banks

in question revealed some specific challenges that need to be highlighted. These include: 1) reducing duplicate infrastructure in a situation where the banks have huge investments in large and complex IT infrastructures with much of the infrastructure mirroring the traditional line of business silos such as current/savings accounts, mortgage lending, card products, and wealth management products; 2) reducing maintenance and

development costs in environments typified by legacy systems and the use of complex and extensively modified software products; 3) dealing with additional channel technologies with the banks deploying their banking services across many electronic and physical channels for example internet banking, automated teller machines, branches, various intermediaries and mobile phones; 4) managing portfolios of projects across many different types of assets with the more business project oriented cultures of banks forcing behavior away from strategic re-use and into more tactical decision making with in most cases no mechanisms for project teams to become aware of re-use opportunities; 5) addressing the limited organisational appetite for implementing the changes required by a product line approach, including the ability to change the organisational culture to allow these changes to be proliferated. 3.2. The Large Bank Context

Large banks are typically divided into numerous divisions based on lines of business, geography, market segments, and channels of delivery. They are managed separately and each will usually constitute a profit centre in its own right. Whilst they may share infrastructure (although in some cases not even infrastructure is shared) they often have their own IT capability or employ the services of the IT department or independent software houses on a project by project basis. There is no funding for the common (those functions that are very close or common across the various divisions described above) in the sense required for the development of a product line or product family. Where reuse does occur it is usually arrived at on a very opportunistic basis. This project by project approach is shown in figure 2.

When we compare this to a software company or manufacturing company, there is an external purchaser of the software or the manufactured item with embedded software function, and therefore a profit motive. There is no exact equivalent to the external purchaser of the software product in a bank. There is an absence of a clear, strictly commercial or profit motive for the establishment of the product line. Rather, in most cases, the motive is the reduction of IT costs.

In contrast in a commercial software company there is a clear motive to employ a product line approach. The identification of commonality will allow its exploitation and the subsequent delivery to market of individual product variants in shorter times than would otherwise be the case and at lower cost, beyond a certain break-even point, based on the number of

163163


derived products [10]. In that situation product time to market is clearly linked to competitiveness and consequently profitability so the incentive is stronger for the establishment of the product line. Furthermore, the requirement of investment in the product line is in the forefront of business decision-making.

Business Unit2

Business Unit1

Year 2Year 1Year 0

IT Project

IT Project

IT ProjectBusiness

Unit3

Cost that could be avoided through reuse of

common capability

Total cost of developing common capability

Common capability

development

Individual Project Funding

Individual Project Funding

Project Funding

Figure 2 Existing Project Based Funding At the bank the incentive to establish a software

product line is not so apparent, primarily because software is considered as a cost, with no profit “upside”. Time to market is achieved by maintaining control of IT capability, and thereby avoiding long cross-divisional decision cycles. Each business unit is heavily incentivised on profitability in the current quarter or year making the time, cost and risk required to establish a successful product line too high a hurdle to overcome. The size of investments, the uncertainty of returns too far in the future, combined with the other factors detailed, all contribute to the lack of appetite to adopt a product line approach.

Product line approaches have been successfully deployed within a single business unit. Aspects of the approach have been tried with success in internet banking at one of the financial institutions (Bank 2) considered. Bank 2 in this study linked the software product line to its card offering (banking product), thereby gaining recognition at the highest levels. This was done through an executive champion who had a strong appreciation for banking and IT, possessed sufficient political clout, and the authority to accept the risk of the approach. In addition for the approach to be viable the bank's strategy was altered to allow the offering to be extended beyond the internal business units (which were viewed to have limited market scope). Bank 2 was successful during their implementation of the product line approach, by having to reassess their approach to existing disciplines such as configuration management, release management and requirements engineering.

In spite of successes as just described it is recognized that to realize the full benefit of a product line approach, commonalities across business unit boundaries need to be exploited. Enablers to assist in achieving this are proposed and explained in the next section.

4. Proposals to Enable Product Lines in the Banking Context 4.1 Alignment with business strategic goals

In the organisations being considered in this paper, application software may be capitalized but is often not treated as an organisation-wide asset, rather as an expense, and usually no strategy for the software product(s) exists. One of the hurdles therefore is the acceptance of the value to the organisation of the software product lines; value in this context meaning the recognition that it is contributing to the goals of the organisation. A key advantage of software product lines is the potential of strategic reuse and it is in the alignment of the technology direction with business strategy that we find indicators of where the organisation value may lie.

Strategic reuse refers to the ability to implement the derivative software products supporting different segments of the organisation, exploiting their common features whilst managing the variations through tools such as COVAMOF [11]. It is incumbent on the software product line initiative to prove that the features and products produced at each point in time are part of, and align with the strategic direction of the organisation at that point.

The idea of ensuring that projects and initiatives are related to the organisational strategy and outcomes is generally considered in the context of the business case when approving such undertakings. It is at this point that the Software Product Lines can run into difficulty It is suggested here that the relationship of the SPL to the strategy needs to be broad and demonstrable; that the outcomes that it helps deliver go beyond the ‘silo’ of the IT support function.

The evidence of the long term return on investment from using software product lines is difficult to impress on a short-term (year-on-year) strategy. Software Product Lines will never be seen as a valuable asset in and of themselves; it is the end result and the by-products of the practices that will provide business value.

To overcome this hurdle, the IT business line should be proactive and indicate specifically where, within the organisation’s business model, the software product line approach will assist. The Business

164164


Motivation Model [12], as an example, provides some much needed formalism within this domain. The combination of the business meta-model and the system meta-model ensures that there are mechanisms for providing traceability and substantive argument for the benefit of software product lines (this approach could also act for other technical formalisms that struggle for business relevance). The key concepts that are applicable are1:

• Strategy (long term, broad in scope, implemented by Tactics)

• Tactic (short term, narrow in scope, implement Strategies)

• Goal (long term, focussed scope, quantified by Objectives)

• Objective (short term, SMART,2 quantify Goals) • Project (courses of action taken by the business)

How do we then utilise these concepts to enable the organisation to overcome the hurdles of adoption and acceptance? The Software Product Line proponent must consider the following steps:

• Review the Banks defined strategy, or establish a strategy

• Model the strategy/tactics and goals/objectives. This is likely to require working with other business unit managers to understand their needs. This is important to help generate the necessary desire for the Software Product Lines in the business lines.

• Review the planned projects for the strategy cycle.

• Relate the projects to the Tactics they represent and the Objectives they satisfy.

• Identify which projects are likely to benefit from the Software Product Lines.

• Demonstrate the links and benefits.

Figure 3 indicates the relationships and flow of information. With this in place, it becomes possible to then draw a direct parallel between the Software Product Line initiative and the objectives of business units and their leaders. Given that a major objection to the Software Product Lines is the initial cost which needs to be incurred by a non-profit generating IT function, the suggested steps provide a vehicle to show that the value of the Software Product Line can be 1 Some of these are considered within the Business Motivation Model, however for our purposes this is simplified and extended 2 SMART-Specific Measurable Achievable Realistic Timely

realised through the success of other projects and objectives.

MeansMeans

Strategy-Retail division-Corporate division-Markets & Capital division-IT Division

Strategy-Retail division-Corporate division-Markets & Capital division-IT Division

Tactics-Implement 2 software product lines

Tactics-Implement 2 software product lines

Ends

Goals-Enterprise goals-Divisional goals

Goals-Enterprise goals-Divisional goals

Objectives-Reduce 20% cost through software product line 1 -Product Line 2 to deliver card processing to new client by end 2008

Objectives-Reduce 20% cost through software product line 1 -Product Line 2 to deliver card processing to new client by end 2008

IT Project portfolioIT Project portfolio

Product line 1

Product line 1

Product line 2

Product line 2

Alignment & planning processes

Figure 3 Aligning Strategy and the Software Product Lines Formalising the business strategy model is an

important part of ensuring that there is recognition of the value of the Software Product Line as a collection of strategic assets. These strategic assets include the strategy alignment model, requirements and software architecture models, as well as the software components, processes, tools, testing collateral, people and skills. Gomaa [13] gives a comprehensive structure for modeling software product line requirements and architecture. In turn, these should be related to the aligned business strategy model. Early definition of these models provides elements of guidance toward the prioritized delivery of the entire initiative and assists with the necessary task of continuously ensuring that the Software Product Line is in line with the unfolding strategy. The modeling assets facilitate the Software Product Line being leveraged in other parts of the organisation as organisation priority and opportunity allow.

To conclude this section, while it may seem obvious that the business strategy should be aligned with the product line adoption our experience has found that in practice this has not been successfully done at financial institutions in the past. The use of models3 has been a key element in the strategic alignment at ANZ and the expectation is that further product line adoption will occur, now that alignment can be demonstrated.

4.2 Organisation structure

As has already been described in section 3.2, application software development in financial services

3 Including extensions in UML – disconnected documents, spreadsheets and presentations are not enough.

165165


organisations is often solely driven by the immediate requirements of individual business units. The development organisation is reactive, executing IT projects which address a collection of these short-term business requirements. To overcome this hurdle a number of measures must be taken. Firstly there must be an individual possessed of sufficient authority who will assume a visionary role to override the narrower concerns of the individual business units. This visionary must motivate that an appropriate funding model is in place, secure funding for the establishment of a product line approach and then subsequently ensure the support of a critical mass of business units so that it becomes sustainable. In reality business units are very loathe to relinquish their power with respect to IT development resources that are exclusively under their control. The implications of the power shift towards centralised IT is one of the greatest hurdles that must be overcome. Alternate approaches with measures including having representatives of the business units on a controlling steering committee that sets the funding priorities have had varied success. This politically difficult issue has not been adequately resolved at either of the banks considered in this paper.

Secondly a product management function, being responsible for the requirements analysis, longer term product planning and management for all of the products which are in scope of the product family supported by a software product line, must be established. This is an unfamiliar role in corporate IT departments and its establishment needs to be motivated and accompanied by change management interventions to address the short-term reactive approach to applications development and enhancement. The product management function, similar to this role in the commercial software companies, has the responsibility to ensure that the product line addresses a sufficient scope to be economically viable. It differs from the roles in commercial software companies in that support for the product line must be lobbied and commitment obtained, since the deflection of a business unit could drastically change the product line’s business case, as the “market” is most often limited to the corporate organisation.

In addition, governance mechanisms for managing the product line scope, the product line architecture and prioritization of features are required, albeit not all at the same level. The product line scope is the primary governance function, with the product line architecture and prioritization of features governance, supporting it and other organisation-wide objectives. The mandates of these mechanisms must be clearly defined, using a charter, or similar mechanism, approved at senior level.

Figure 4 Product Line Implementation Processes

The cultural shift from a largely reactive project

focus to a more proactive product focus and prioritization of features across the organisation, rather than within individual business unit silos is another hurdle. This prioritization is more difficult and requires new decision making structures, and strategy driven guidelines for decision-making to remove, as far as possible, the role of individual business unit agendas and vested interests as also identified by Murphy [14].

Figure 4 shows the proposed processes ANZ will be using for implementation of the approach in sequence and around which the governance is being built. 4.3 Economic model

In order for the proven benefits of Software Product Lines to be realised in non-commercial software organisations, the product line visionary must motivate the business units by demonstrating a link to the core objectives that meet the organisation’s strategies. In order to determine return on investment (ROI) with any degree of confidence, and therefore achieve commitment to the approach, sufficient planning, strategically scoping the product line, is required. In one case a bank (Bank 2) linked the software product line to a banking product strategic proposition. In other cases, adoption of the product line is preceded with up-front product-line planning which determines the product line scope and business model or business case during which the ROI can be determined,

In [15] Böckle et al propose a method for calculating returns on investment in software product

Product Line Implementation Processes

Define Funding

Structure the organisation

Train on Product Line Operating Model

Define Product Line Architecture

Plan execution

Implement Customer Interface Management

Develop an Acquisition Strategy

Manage risk

Define PL Features

Appoint Product Line

Define Product Line

166166


lines. These approaches are extended in [9,16,17,18] However recovery and benefit allocation mechanisms between business units can present further challenges in corporate organisations.

The requirement for an investment to initiate the product line is recognized in order to fund the organisation change and establishment of the core asset base e.g. [15]. Investment can be either funded centrally by the CEO or CIO, and not explicitly recovered (this is referred to as the taxation model for funding [19]) or by a specific business unit or a consortium of business units. In the latter case the hurdle is providing equitable recognition (and monetary benefits) to the investors. What has been proposed is a per-use charging model for the core assets of the product line realized from the investment. Figure 5 illustrates a usage based model to recover investment in the product line. The per-use charging must cover maintenance and upgrade releases of the product line’s core assets and provide a return to the investors involved in its establishment.

Project Funding

Project Funding

Dividends

Year 3Year 2Year 1

IT Project

IT Project

IT Project

Total cost of developing common capability once less

than developing separately

Cost of integration & configuration of core assets

Production – pay per use

Income pool, (zero sum game)



Allocation for maintenance of core assets

Business Unit

3

IT ProjectCore asset

development

Seed

fundin

g / in

vestmen

t

Business Unit

2

Business Unit

1

Project Funding

Figure 5 A Usage Based Economic Model This is in contrast to the common approach where

business units fund the development of applications up-front, with no follow up costs thereafter. (Some variations on this theme exist). The often un-intended consequence of this approach is that the application is not “maintained” as any asset should be, until a new business requirement is identified. Whilst the “per-use” approach is not a new way to deal with hardware and base software infrastructure, it is resisted especially for internally developed software, because it implies that a “cost-centre” may make a profit. However the benefit is that non-investors getting benefits from the core-assets will pay for their use proportional to their need (relieving new smaller business units of the burden to fund large up-front application development costs). Under this scheme the costs to the investing business units are off-set by the distribution of the “profit” back to them proportional to their initial investment. This may be implemented as a discount. Through this, the

operating cost centre does not retain any of the profit, although prudently, some funds should be retained for re-investment in the assets’ sustainability.

5. Conclusion

Table 1 below, summarises the approaches to overcoming these hurdles observed at the two banks we have worked with, and contrasted with the approach previously observed at a commercial software organisation using SPLP.

There are important differences between IT in financial services organisations and commercial software companies. These differences imply that there are additional hurdles that must be overcome for Software Product Line Practice to be successfully adopted.

From our observations it is a key issue that the Software Product Line approach is demonstrated to align with the organisation’s strategic business objectives, and is shown to provide business benefits with acceptable risk. Modeling techniques and tools are available for product line modeling and they should be used to aid this strategic alignment. The business silo project driven organisation design must be amended and complemented specifically with the creation of a product management function and governance mechanisms to ensure that products scoped into a product line are not withdrawn without due consideration of the implications, and specifically the implications for the product line business case.

An economic model comprising the initial investment, charging model and return on investment by the product line over time must be designed and integrated into the internal costing mechanisms of the organisation. Financial service organisations that pursue the adoption of Software Product Lines by addressing these hurdles are positioning themselves to derive similar benefits, albeit on a smaller scale to those obtained by commercial software companies operating in the open market.

Future work will undertake further empirical studies, at large financial institutions, of Software Product Line adoption to more closely identify the hurdles to adoption as well as refining the solutions and enablers to overcome them. Approaches to be employed will focus on identifying and formalising points of commonality and variability during requirements modeling and engineering.

167167


ANZ Bank 2 Reference commercial s/w company

Company strategy

SPLP is an IT response to the business strategy demanding variants of IT systems.

Business product supporting a business strategy incorporates SPLP based IT. This approach ensures access to clients outside of the corporate boundary.

Core organisational strategy to develop software product deployable at multiple clients and markets, from core assets.

Organisation structure

IT General Manager of all Product Lines, to whom Product Line managers report. Product Line Councils govern scope.

General Manager of IT Product supporting a business product line and relying on SPLP concepts.

Product manager at general manager level. Product line architecture compliance responsibility of CTO.

Funding model

Seed investment from primary business unit. Per-use charging model being implemented.

Investment from founding partners, together with shared risk / reward model for added products.

JV Capital raising phase and arms-length responsibility for ROI thereafter.

Table 1 Enablers compared for different organisations

In addition, economic models and methods to

motivate a view of software as an asset based on traditional valuation models, as used for physical assets that exhibit features of an upfront investment, compulsory charges for those making use of the asset, ongoing maintenance costs and depreciation over the life of the asset will be investigated. The presence of service oriented architectures must also be factored into approaches and a conception of Service Line Practices introduced with their attendant implications and shift in thinking. 6. References [1] Pohl, K.; Böckle, G.; van der Linden, F., Software Product Line Engineering, Springer, 2005. [2] Clements, P.; Northrop, L., Software Product Lines, Addison-Wesley, 2001. [3] Kircher M. Schwanninger C. Groher I., Transitioning to a Software Product Family Approach – Challenges and Best Practices 10th International Software Product Line Conference (SPLC’06), IEEE, 2006, Pages: 9 pp.

[4] Krueger C., Eliminating the Adoption Barrier IEEE Software July/August 2002, pp. 29-31 [5] Schmid K. Verlage M., The Economic Impact of Product Line Adoption and Evolution IEEE Software July/August 2002, pp. 50-57 [6] Jeong Ah Kim, Case Study of Product Line Engineering in Insurance Company IEEE International Conference on Information Reuse and Integration, 2006, pp. 303-306 [7] Jaktman C. B., The Influence of Organisational Factors on the Success and Quality of a Product Line Architecture IEEE Australian Software Engineering Conference, 1998. IEEE, 1998, pp. 2-11 [8] Krueger C. W., The 3-Tiered Methodology: Pragmatic Insights from New Generation Software Product Lines 11th International Software Product Line Conference (SPLC’07), IEEE, 2007 [9] Nóbrega, J.P. Santana de Almeida1, E. Meira, S.R.L., A Cost Framework Specification for Software Product Lines Scenarios WDBC Dec 2006 - Workshop de Desenvolvimento Baseado em Componentes, Sociedade Brasileira de Computa, 2006 http://wdbc2006.cesar.org.br/wp-content/uploads/23948.pdf [10] van Zyl, J., Product Line Architecture and the Separation of Concerns Second International Conference Software Product Lines, SPLC2, 2002. published as Proceedings Series: Lecture Notes in Computer Science, Vol. 2379 Chastek, G. J. (Ed.), Springer, 2002, pp. 83-119 [11] COVAMOF: Variability Management in Software Product Families, A Plug-in for Microsoft Visual Studio .NET http://www.covamof.com/index.php/introduction [12] Business Motivation Model http://www.businessrulesgroup.org/bmm.shtml http://www.omg.org/technology/documents/bms_spec_catalog.htm [13] Gomaa, H., Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures, Addison-Wesley, 2005 [14] Murphy, T., Achieving Business Value from Technology: A Practical Guide for Today’s Executive, Gartner Press - John Wiley & Sons Inc., 2002 [15] Böckle, G. Clements, P. McGregor, J. D. Muthig, D. Schmid, K., Calculating ROI for Software Product Lines IEEE Software May/June, IEEE 2004, pp. 23-31 [16] Yoshimura, K. Ganesan, D Muthing, D., Defining a strategy to introduce a software product line using existing embedded systems 6th ACM & IEEE International conference on Embedded software, IEEE 2006, pp. 63-72

168168


[17] Clements, P., McGregor, J.D. and Cohen, S.G., The Structured Intuitive Model for Product Line Economics (SIMPLE) Technical Report CMU/SEI-2005-TR-003, February 2005 [18] Ganesan, D Knodel, J. Kolb, R. Haury, U. Meier G., Comparing Costs and Benefits of Different Test Strategies for Software Product Line: A Study from Testo AG 11th International Software Product Line Conference (SPLC’07), IEEE, 2007 [19] Bosch, J., On the Development of Software Product-Family Components Second International Conference Software Product Lines, SPLC2, 2002. published as Proceedings Series: Lecture Notes in Computer Science, Vol. 2379 Chastek, G. J. (Ed.), Springer, 2002, pp. 146-164

169169


Documents

_03 Experiences of Large Banks