Evaluating Standard Software with V-Modell XT A Case Study By Ulrich Birowicz

A DISSERTATION

28th September 2005

ABSTRACT Evaluating Standard Software with V-Modell XT A Case Study By Ulrich Birowicz

V-Modell XT is a new project management methodology that has been created for the use of the German federal administration, both for IT projects as well as for other system development projects (e.g. the development of weapon systems such as the Eurofighter's radar). Emphasis lies with 'development' – the V-Modell has a long tradition of developing individual systems. This newest version, which builds upon the older V-Modell 97, is intended to be more flexible and scalable than its predecessor and to incorporate new software engineering concepts, e.g. such as agile programming. Another current trend in software engineering is the use of commercial-offthe-shelf (COTS) applications and components in the building of solutions. This topic has been incorporated into the V-Modell XT only partially, so far only on the side of the solution supplier. As far as the model's creators are concerned the evaluation of COTS software is a supplier issue only, the customer should only care for the abstract requirements. This point of view is definitely inconsistent with the needs of many IT projects, public or private. It is normal practice for a company or public administration body today to take a closer look at available COTS applications before defining and ordering a system. This dissertation tries to close this gap by discussing, designing and implementing the necessary changes within V-Modell XT to enable the specifier to evaluate COTS products. The results are evaluated by discussing the newly found procedures with responsible officials from three on-going public administration projects. The changes are to be published within V-Modell XT Release 1.2 in January 2006.

DECLARATION

I hereby certify that this dissertation constitutes my own product, that where the language of others is set forth, quotation marks so indicate, and that appropriate credit is given where I have used the language, ideas, expressions or writings of another. I declare that the dissertation describes original work that has not previously been presented for the award of any other degree of any institution.

Signed, Ulrich Birowicz

ACKNOWLEDGEMENTS "Fortune has many fathers, mishap is an orphan." This work of mine must be a fortunate one, as it has just one father, but lots of god-fathers. I want to thank my partners with the WEIT team, Mrs. Doris Rauh from Siemens AG and Mr. Hans-Jürgen Meinhardt of IABG. Without their help, cooperation and inspiration, this dissertation definitely would not have been possible. Other WEIT team members helpfully involved were J.Prof. Andreas Rausch from the Technical University of Kaiserslautern as well as Mr. Michael Gnatz and Ms. Ulrike Hammerschall from the Technical University of Munich. My partner in Hamburg's public administration was the team of ITB, consisting of Mr. Jörn Hecker and Mr. Hansjörg Schwoch. They as well as Dr. Reinhard Verch and Mr. Daniel Cutter of the Brandenburg Ministry of the Interior helped me by readily answering my many questions. Many thanks for your cooperation! Last but by far not least the biggest thanks of them all to my family: my wife Marina and our children Irene and Tobias, who for two and a half years tolerated me being constantly absent-minded.

TABLE OF CONTENTS LIST OF FIGURES....................................................................................................ix CHAPTER 1 INTRODUCTION................................................................................. 1 The V-Modell XT .................................................................................................... 1 V-Modell XT and COTS software products............................................................. 4 CHAPTER 2 BACKGROUND AND A REVIEW OF LITERATURE ........................... 6 Project management methodology V-Modell XT .................................................... 6 Make-or-buy decision............................................................................................. 9 Software reuse and COTS applications................................................................ 10 Evaluation of COTS applications.......................................................................... 11 Legal aspects....................................................................................................... 13 CHAPTER 3 SOLUTION ALTERNATIVES ............................................................ 15 Customising V-Modell XT..................................................................................... 15 Current implementation........................................................................................ 16 Alternative 1: relocating MoB and modifying FP ................................................... 18 Alternative 2: modifying FP and requirements assessment .................................. 18 Alternative 3: integrating MoB into process module FP ........................................ 18 Alternative 4: a new general evaluation process module...................................... 19 Choice of solution ................................................................................................ 20 CHAPTER 4 IMPLEMENTATION........................................................................... 23 Design.................................................................................................................. 23 New method reference 'evaluation methods' ........................................................ 23 Integration of FP into project type 'customer project' ............................................ 23 Structural changes of the process module FP ...................................................... 24 Structural changes of the product market review.................................................. 24 Structural changes of the process module ANFE ................................................. 25 Other structural changes...................................................................................... 25 Text changes within the part 'V-Modell XT basics'................................................ 26 Text changes within the process module FP ........................................................ 26 Text changes within the process module ANFE ................................................... 27 CHAPTER 5 EVALUATION AND IMPROVEMENTS.............................................. 28 Test case 1: ITB, Hamburg - Gewerberegister ..................................................... 28 Test case 2: Brandenburg Ministry of the Interior, Potsdam - BOA....................... 32 Test case 3: IABG, Munich - ITAmtBw ................................................................. 33 Resulting improvements of the implementation .................................................... 35 CHAPTER 6 CONCLUSION AND RECOMMENDATIONS .................................... 36

vii

Bibliography ............................................................................................................ 38 Appendix A V-Modell XT terms used...................................................................... 41 Appendix B Confirmation by WEIT team ................................................................ 44 Appendix C Documentation of implementation ....................................................... 45

viii

LIST OF FIGURES Figure

Page

Figure 1: Success statistics of IT projects (CHAOS report, Standish Group) ............. 6 Figure 2: the phases of the OTSO method [Solberg & Dahl, 2001].......................... 11 Figure 3: Structure of RCPEP method [Lawlis et al., 2001]...................................... 12 Figure 4: V-Modell XT Editor Tool ........................................................................... 15 Figure 5: standard implementation of MoB with V-Modell XT .................................. 17

ix

CHAPTER 1 INTRODUCTION The V-Modell XT In a world that becomes increasingly complex, the number and scale of projects rises exponentially. In ancient and medieval times, the biggest projects concerned buildings such as pyramids, aqueducts or cathedrals with a project duration of 10 to 200 years. Nowadays, projects with comparable or even higher complexity have to be completed in a fraction of that time span. We do not know whether there was any project management methodology in use in those earlier times (besides 'in God we trust'), but today quite a number of such methods are used. In recent years a multitude of new project management methodologies have emerged – some with a totally new approach, most being a new mix of other methods, a few being the ongoing evolution of older methodologies to adapt to new findings and developments. V-Modell XT is one of the latter, being the successor to V-Modell '97, which has not been changed since 1997. V-Modell XT is the official project management methodology of the Federal German administration released as recently as February 20051 and is to be used by other administrative bodies at state as well as local level. This new version has been developed by a diverse group of participants [Broy & Rausch, 2005, p. 221]. The German Federal Ministry of the Interior2 initiated the project in 2003 under the project name WEIT3. Another official body involved is the German Federal Forces Office for Information Management and IT4 on behalf of the German Department of Defence5, the academic partners are the Technical University of Munich (TUM) and the Technical University of Kaiserslautern. Companies

1

One English news report can be found at http://europa.eu.int/idabc/en/document/3895/336

2

German: Bundesministerium des Inneren, abbreviated BMI

3

Abbreviation of 'Weiterentwicklung des Entwicklungsstandards für IT-Systeme des Bundes auf Basis des V-Modell 97' = Evolution of the development standard for Federal IT systems on the basis of V-Modell 97

4

German: Bundesamt für Informationsmanagement und Informationstechnologie der Bundeswehr (IT-AmtBw)

5

German: Bundesministerium der Verteidigung (BMVg)

1

Siemens, EADS and IABG represent the private sector; 4Soft GmbH, a TUM spin-off, carried out the tool development6, namely the Eclipse-based V-Modell XT Editor and the XML-based V-Modell Projektassistent for tailoring the V-Modell XT. These creators of V-Modell XT had two objectives in mind, which are difficult to achieve simultaneously: V-Modell is short for Vorgehensmodell (literally: proceeding model), the XT stands for extended tailoring and means that the methodology should be usable to handle projects of all kinds and sizes. At the same time, V-Modell XT is meant to be adaptable to new software engineering methods such as agile development. The methodology is meant both to be flexible and scalable. Therefore, V-Modell XT has a modular structure that can be customised to the project's needs. The main element of the model is the product, a deliverable that is drawn up within the project, e.g. the requirements specifications. Each product is connected to an activity that describes how the deliverable is to be produced in the course of the project. One or more products are logically combined into process modules7. These modules fall into two categories: general modules such as project management or risk management are core modules that are obligatory with any project, the other modules' use depends on the kind of project. There are three basic project types within V-Modell XT, the customer8 project, the supplier9 project and the project to develop and implement an organisation specific subset of V-Modell XT. The customer project [V-Modell XT, 2005, pp. 3-17 – 3-19] starts with the project proposal that initiates the project, and then defines the requirements and the tender process to find a supplier for the required solution. This includes the interactive process of clarifying what exactly the supplier will have to do to fulfil the customer's wishes as well as the testing and finally taking over of the delivered solution. The supplier project [V-Modell XT, 2005, pp. 3-19 – 3-21] is initiated by evaluating the tender documents that support with the customer's bidding process and the decision to submit a bid. In case of a successful bid, the above-mentioned 6

An current and complete list of participants can be found at http://www.kbst.bund.de/VModell/-,376/Projektbeteiligte.htm (accessed 24 July 2005, German only) 7

German: Vorgehensbaustein (literally: proceeding building brick), abbreviated VB

8

German: Auftraggeber (customer, ordering party), abbreviated AG

9

German: Auftragnehmer (supplier, contractor, vendor), abbreviated AN

2

process to define the final outcome of the project ensues, terminated by the customer's acceptance of the supplier's performance. The organisation specific V-Modell project [V-Modell XT, 2005, pp. 3-21 – 323] shortens the process of tailoring for future projects by adjusting the V-Modell XT to that specific organisation's needs. Normally the tailoring process requires at least two steps: first the static tailoring, i.e. selecting a project type and thereby the associated process modules. Next comes the dynamic tailoring within the project. Immediately after project kick-off, the project handbook is created which includes the whole project structure and all the components. The products of the selected process modules are reviewed for their relevance to the project and chosen accordingly – dependent on the size and the needs of the project at hand. The organisation specific V-Modell XT does this with an eye on all possible projects that organisation will do in the foreseeable future. The V-Modell XT is tailored as far as possible, the products get prepared (e.g. by inserting logos and / or using organisation specific reporting schemes), so there would be minimal changes necessary to set up new projects for that organisation. Some standard strategies for standard forms of projects are implemented as well, several project implementation strategies10 such as System development project of a customer are predefined. The strategies define the course of the project by defining the milestones the project has to deliver. These milestones11 are linked to the selected products: e.g., the milestone Requirements defined is achieved when all the products Change Status List, Requirements Specification, Requirements Assessment, Managerial Project Status Report, Project Plan and Project Status Report have been completed (when selected during tailoring) [V-Modell XT, 2005, p. 3-45]. The milestones are instantiated within sequence units12 that define the sequence of milestones. For each milestone, there is a list of products that have to be completed to reach that step. The instantiations can be project specific, according to the tailoring for the project at hand.

10

German: Projektdurchführungsstrategie (abbreviated PDS)

11

German: Entscheidungspunkt (decision point, abbreviated EP)

12

German: Ablaufbaustein

3

V-Modell XT and COTS software products V-Modell XT has been designed with a special view to the needs of public administration on how to do projects. In this model, the administration acts as the customer of development activities. In this role, they just define the requirements, without pre-empting eventual solutions. The specifier describes what (s)he wants, and the supplier offers a solution, with absolute freedom concerning hardware, system architecture and applications used. Therefore, V-Modell XT mentions the choice and use of standard applications or components, but on the supplier's side only. The supplier does all system design and system integration based on the customer's requirements specification, he solely decides what parts will have to be developed and which reusable components or commercial-off-the-shelve (COTS) applications will be used to build the system the customer gets offered. The latter part of choosing COTS applications is not done in one step but two: the evaluation of COTS software is a separate topic in V-Modell XT in a separate process module (VB) called Finished Products13 [V-Modell XT, 2005, pp. 3-38 – 339]. Subsequently, the evaluation results are used to make a make-or-buy-decision (MoB) as part of the project module System construction14 [V-Modell XT, 2005, pp. 331 – 3-32]. This segregation between customer and supplier is an old-fashioned view that less and less mirrors the reality of public administration in the days of NPM15 and eGovernment16. An IT project no longer automatically means the development of individual software. The days of separate individual IT solutions are (nearly) over, the on-going trend for integrated and standardised solutions require general IT strategies and capabilities within the administrative bodies as well. Therefore special entities

13

German: Fertigprodukte, abbreviated FP

14

German: Systemerstellung, abbreviated SE

15

New Public Management, a movement in public management to renew public management procedures and structures started in the US in the 1990s (see e.g. http://www.oecd.org/topic/0,2686,en_2649_37405_1_1_1_1_37405,00.html, accessed 24 July 2005) 16

Short for electronic Government. One concise definition: "E-Government refers to the use of information and communications technologies to improve the efficiency, effectiveness, transparency and accountability of government." (http://www1.worldbank.org/publicsector/egov/, accessed 24 July 2005)

4

like administration IT departments are often responsible for such projects nowadays which often act as 'informed buyers'. V-Modell XT currently does not allow the ordering party either to take a look at standard software (COTS) products or to conduct a qualified make-or-buy (MoB) decision process. This study's task is to change this, to enable the customer to do so. This objective is achieved in a series of steps, which are represented by the following chapters. First is a look at the background of the problem and a review of relevant literature, followed by a discussion of possible solution alternatives. The (argued) choice of one of these alternatives leads to its implementation, producing a modified version of V-Modell XT. This is tested subsequently by discussing the changes with responsible representatives from three current projects, resulting in a conclusion of its usability in the real world.

5

CHAPTER 2 BACKGROUND AND A REVIEW OF LITERATURE

Project management methodology V-Modell XT The need for methods to make projects work as desired has been growing along with the scale and complexity of the projects at hand. The Standish Group's well-known CHAOS report states that in 1994 only 16% of all projects met their predefined targets, about half of them (51%) failed, the rest reached at best inadequate results [Standish, 1994]. Project management tools and methodologies have been improved in the meanwhile, so the success rate has doubled to 34% in 2002, failures have dropped dramatically to 15% [Brock, 2003, p. 3].

Figure 1: Success statistics of IT projects (CHAOS report, Standish Group)

In the 1970s, the US Department of Defence (aka the Pentagon) started defining and using formal procedures for the management of projects, resulting in MIL-STD-498 of 1994 eventually. European NATO allies such as Great Britain and Germany adapted those rules and developed their own project management methodologies out of it, PRINCE in the UK and V-Modell in Germany. These methodologies were meant to be used in the procurement of weapon systems originally, but were soon adapted for military and public IT development projects as well. The current versions are IEEE/EIA 12207, "Information technology - Software

6

life cycle process" in the USA, PRINCE2 in the UK and V-Modell XT in Germany [Schuppan, 1999, p.13; Kranz, 2004, p.11]. V-Modell stands for 'Vorgehensmodell', which is the German term for process model. The first V-Modell was issued in 1992 with exactly that meaning in mind: to create a model that gives its users a guideline how to proceed with a project to reach the expected results. The model was intended for the Federal German Forces to use with their IT projects and followed the standard software engineering model of that time, the waterfall model [Sommerville, 2001, p. 45]. This resulted in a very rigid structure of sequential project steps that the users often felt was too complex as well as too voluminous to handle. Additionally, some parts of the Federal Forces administration felt left out as only IT projects were covered, other types of general system development projects such as the development of new weapon systems could not be handled with the methodology [Filss, 2005, p. 13]. This critique and the development of new software engineering methods such as iterative [Sommerville, 2001, pp. 51 - 55] and evolutionary development [Sommerville, 2001, pp. 46 - 48] led to a new version called V-Modell 97 in 199717. In the meantime, the user basis of the model had been broadened to the whole federal German administration and into the civilian sector; the responsibility for it had been moved from the Department of Defence (BMVg) to the Ministry of the Interior (BMI). In 2003, the BMI decided to initiate a completely new version of the VModell and started the WEIT project (s.a. p. 1) with a whole list of intentions [Broy & Rausch, 2005, p. 221] highlighting what was thought to be still missing: Improvement of the support for better tailoring, usability, scalability and modifying of the V-Modell. Consideration of the current state of technology and adaptation to the latest regulations and norms. Extension of the model's relevance to the implementation of the whole system life cycle within development projects. Introduction of an organisation specific improvement mechanism for process models.

17

A short English introduction to V-Modell 97 can be found at http://www.vmodell.iabg.de/kurzb/vm/b-vm.doc (accessed 5 September 2005)

7

In continuation of the concepts first used with V-Modell 97 the V-Modell XT is a process model intended for project management in general (V-Modell XT, 2005, p.1-6), i.e. for IT as well as other system development projects – it doesn't matter in principle whether the aim of the project is the development of an eGovernment website or the Eurofighter aircraft (the German parts of which have been developed using the predecessor version V-Modell '97). In this respect, it is a unique methodology, applicable to both general project management as well as to software engineering. In fact, it is designed to be adaptable to various software engineering methodologies such as the waterfall model, object (reuse) oriented development or incremental development, which get implemented through project implementation strategies (V-Modell XT, 2005, p. 3-53ff.). Therefore, VM XT is not a software engineering methodology itself, but rather provides the environment for software engineering. To be usable in any context and to provide the possibility to provide reliable project quality, emphasis was put into the adherence to international standards, namely ISO 15288 and CMMI. With some restrictions, V-Modell XT projects are recognised to comply with CMMI maturity level 3 [SEI CMMI, 2001, p.22; Kranz, 2004, p.90; Kneuper, 2005, p.60]. The scope of the software life cycle covered by V-Modell XT has been crucially enlarged in comparison to V-Modell 97. That model looked at how to build software, how to help a software producer to develop an individual system. V-Modell XT now considers the party procuring the software as well, and describes the processes of defining the requirements and initiating and controlling the procurement process. The focus of this project lies within this special area of knowledge that exists in both worlds: requirements engineering in the software engineering context (Sommerville, 2001, chapter 6, pp. 125 – 145), procurement planning within IT project management (Schwalbe, 2004, chapter 12, pp. 426 - 449). Those fields of knowledge both deal with the elicitation, negotiation and validation / verification of software requirements in general. The evolution of the V-Modell versions mirrors the development in this field as well: for a long time, there was a very rigid view regarding of when and how requirements should be included in a project and what they should contain. There should be a defined period in a project when the abstract requirements are considered and analysed so that clear objectives are established for developing the

8

software. To prevent scope creep no requirements changes are allowed after the completion of the requirements documents. Requirements engineers must not think about system design so they do not feel constrained in their definition of the requirements. However, this is a concept for an ideal world that does not exist and most probably never will. The reality is generally somewhat different. Software engineering theory has over time been brought into line with that reality, resulting in the acceptance of a world where the constant lack of time and the need for a fast turnaround leads to adjusted software engineering methods [Sommerville, 2005, p.18]. Management looks for a fast ROI on IT expenses, business processes get more and more volatile, keep changing all the time. To get quick results, prototypes iteratively grow into productive programs, software components are reused to shorten development durations. This environment encompasses the use and the role of COTS applications in IT projects. The evaluation of COTS software in the course of a qualified make or buy decision is a special case in this field.

Make-or-buy decision The make-or-buy (MoB) decision is a topic that originally emerged within the manufacturing industry. The question behind it is whether it makes more business sense in the short as well as the long term to produce an item yourself or purchase it from a third party. This was first discussed by Williamson, 1975, while developing his theory on transaction cost analysis: the more a transaction is seen as asset specific the more advantageous it should be to produce the item within the enterprise and vice versa. Therefore, another name for this topic is 'strategic sourcing' [Humphreys, 2002, with further references]. In the meantime, the MoB is seen as the description of a complex process that involves not only financial aspects but strategic ones such as long-term competitiveness, managerial performance and risk reduction as well [Padillo, 1999]. It involves not only a question of the product and its production but necessarily requires consideration of its environment as well, including internal influences like the business's strategy as well as external factors such as supplier relationship and supplier quality. It is always a multi-step process that starts with a definition of requirements and continues with a selection and evaluation of suppliers (and their

9

products), terminating in a final statement, favourably with a recommendation on how to procure the product [McIvor & Humphreys, 2000].

Software reuse and COTS applications In connection with software the question arising is whether to develop a required application individually or to buy a COTS software application or component. There are two ways of building systems without having to program every element of it. The first option is to reuse whole applications or components that have been developed in-house or whose source code is available to the in-house developers. This approach is very popular with modern object-oriented programming and the open-source community [Cummins, 2002, p. 274]. The second type is to purchase COTS applications or components on the market and to integrate them into a system environment. The use of COTS software has the decisive advantage that there is a rather high probability of saving a significant percentage of time and money – the software just has to be implemented, not developed, and such a package is cheaper to buy than to develop individually. One must not forget the risks and disadvantages as well: the COTS software could have the wrong and/or insufficient functionality, may be incompatible with the existing system architecture, and could be too complex to handle for the users [Solberg & Dahl, 2001, para. 2.4; Torchiano & Morisio, 2004, p.92]. In my 10 years of experience with SAP R/3 there have been quite a number of projects that came near to failing due to these risks. SAP R/3 is the most complete and therefore most complex business software package available. Therefore, many customers take it for granted that R/3's functionalities meet all the needs of their specific business processes. But R/3 is a standard software, which can only contain standardised processes. Those can be customised to some degree, but this has definite limitations. Large companies regularly can afford to adjust their processes to meet the SAP R/3 standard, SMEs normally cannot do so. Their capacity to compete successfully with larger companies in most cases depends on special and flexible business processes that often cannot be delivered with standard SAP R/3. This leads to higher project costs and duration due to necessary modifications and/or workarounds that SMEs find hard to afford.

10

This example shows how important it is to compare requirements with the characteristics of current products before the start of an implementation project.

Evaluation of COTS applications There is quite a number of solution approaches available on this problem and have been discussed already. [Port & Chen, 2004, p.184] list 18 methods in this field. With MoB being the origin, it seems only logical to use the transaction cost theory for COTS applications as well [Wang, 2002]. Most of the other approaches are procedural methods that look not only at the evaluation of COTS application but think of pre-steps like the selection of possible candidates and terminal stages like the integration of the found application into the existing system architecture as well. Any evaluation starts with the question of what and how to evaluate. This sounds like a very simple item, but experience shows this to be the major obstacle on the way to a selected COTS product [Maiden et al., 1997]. The question has many facets: what products are to be how selected, what data do I need and how do I get them? What criteria do I define and when and how do I do that? Some methods such as OTSO (off-the-shelve option) [Kontio, 1996; Solberg & Dahl, 2001] have a strictly sequential approach, starting with a search first for evaluation criteria and then for eligible COTS products.

Figure 2: the phases of the OTSO method [Solberg & Dahl, 2001]

Another approach is PORE (procurement-oriented requirements engineering) [Maiden & Ncube, 1998] that sees listing candidate products and defining evaluation criteria as something that should be happening at the same time for practical

11

reasons. Additionally they see the evaluation as an iterative process that keeps repeating until a result is reached. Yet another process structure is favoured by the RCPEP (requirements-driven COTS product evaluation process) method [Lawlis et al., 2001]. The evaluation process here has two steps: first the selection of possible candidates using outside source data results for the products and then a second round applying refined criteria and defined test cases.

Figure 3: Structure of RCPEP method [Lawlis et al., 2001]

Written evidence based on practical experience supports the view that evaluation criteria as well as the metrics of the interpreted data should be as distinctive and unambiguous as possible [Maiden et al., 1997; Carney & Wallnau, 1998; Sedigh-Ali et al., 2001; Lewis & Morris, 2004]. This helps to get clear results in the evaluation. The evaluation as such raises a new question: how to define the objectives from the statistics and data that has been gathered? The solution lies in finding ways and methods to weight and interpret the results properly. One such method is the weighted scoring method (WSM) [Schwalbe, 2004, pp. 150 - 152]. First, each of the defined criteria is weighted according to its impact on the whole project (e.g. essential, very important, important, nice to have, unimportant or as numerical values from 10 to 0). In the evaluation the degree of fulfilment of each criterion is noted, e.g. 70%. To get the weighted result for this criterion, the percentage has to be multiplied with the criterion rating, e.g. 70% x 7. This gives an evaluation criterion result of 4.9 points. The sum of all weighted criteria

12

gives the overall rating for the product at hand, which then can be compared with other products results. Additionally there can be a definition of minimum ratings per criterion and per product. If a product does not reach this value this can result in a failure in the overall rating. Another weighting method is the analytic hierarchy process (AHP) [Kontio, 1996] that is based on a decision matrix. The criteria are arranged in hierarchy levels according to relevance and are compared and evaluated in pairs. The risk of wrong or erroneous weighting definitions is inherent to both methods (especially AHP). This could result in the inconsistency of the whole model, making the evaluation worthless. Another danger is criteria overload, i.e. the definition of too many criteria that could make the model inoperable. Therefore, the main difficulty with evaluating COTS software lies with the model's complexity. It must not be too simple, otherwise the results could not be sufficiently differentiated. At the other extreme, the evaluation can become too complicated and timeconsuming to handle. This leaves the manager responsible with the difficult task to find the best compromise for his special project.

Legal aspects As mentioned in the introduction, this study's task is to remove the distinct separation within V-Modell XT between the requirements engineering being carried out by the customer and the system specification being carried out by the supplier. This differentiation was not a consequence of negligence on the WEIT team's part but of the legal situation of public administration bodies acting as customer in the market18. Both European Union laws as well as German law prescribe a formal bidding process for all service projects with a net worth of more than 200.000 EUR [§ 2 Nr. 3 VgVO19] or more than 130.000 EUR with higher federal authorities, which will be fulfilled by most IT projects. 18

A full legal report on this disputed and complicated matter would definitely go far beyond the scope of this study. Therefore, this part can only give a short overview of the topic. 19

In German law codifications are quoted beginning with the '§' sign and a number for the article, followed by a Roman digit for the paragraph and an Arabian digit for the sentence. In this case there is an enumeration, quoted 'Nr.' for number. At the end stands the abbreviation of the codification in question, here VgVO for the Vergabe-Verordnung (federal allotment decree)

13

Public authorities have a special responsibility regarding expenses towards the tax payers that has two legal consequences. On one hand the selection of a supplier must be determined by the most economical offer, i.e. not necessarily the cheapest, but the one that gives the best value for money [§ 97 V GWB20]. On the other hand state authorities have to act impartially towards their potential suppliers. In consequence there are several legal regulations to ensure exactly that any able supplier gets the chance to make an offer. The point of special interest to this topic is the contents of the submission the public authorities are authorised to publish. § 8 VOL/A21 contains a set of rules to ensure that the submission should be as general as possible, whenever possible without naming a single product explicitly [§ 8 Nr. 3 II–V VOL/A]. V-Modell XT is the official methodology used by the federal administration, therefore it was thought that the customer side should not be bothered with any system design, as they are not allowed to do so anyway. It has already been mentioned that this is a factual error, as most bodies necessarily have to deal with system architecture design decisions all the time. What about the legal doubts? Even in the opinion of Heckmann [2004, p. 34 - 35], who did a critical study on behalf of Microsoft on the legitimacy of German public authorities to explicitly order open source products, the provision of § 8 Nr. 3 III VOL/A clearly opens the possibility to "explicitly prescribe products or procedures when justified by the kind of service required". He insists on a tight interpretation of the clause, with a mandatory two-step review in advance: is there a real business need for such a product, and is this product the one that best fulfills this need? This is the most restrictive interpretation available and in my opinion acceptable. This two-step mechanism sounds somewhat familiar, in my eyes this is nothing but a MoB in legal terms. So, system architecture can be done by public authorities in advance, a MoB makes sense methodically as well as legally.

20

Gesetz gegen Wettbewerbsbeschränkungen (Law against competition restrictions)

21

Verdingungsordnung für Leistungen / Teil A ((roughly) decree on the ordering of services, part A)

14

CHAPTER 3 SOLUTION ALTERNATIVES Having looked at the background to a problem, it is time to go on with finding a solution to it. As with all technical implementations, design has to follow function, so we have to look at the possibilities and limitations the V-Modell XT offers its users first.

Customising V-Modell XT The individual customising of V-Modell XT is possible using a tool that is provided free of cost, the V-Modell XT Editor22 from 4soft GmbH, Munich.

Figure 4: V-Modell XT Editor Tool

The Editor presents a GUI that reflects the component structure of V-Modell XT and allows its user to customise V-Modell XT. The result can be tested for syntactical consistency and is exportable in various formats (pdf, latex or html). The tool is based on Eclipse and Java JRE 1.5. The edited data is an xml-file, the structure is represented by an xsd-file. Customizing is done by editing the interdependencies between its components as well as the components of V-Modell XT itself. The main components 22

Download of the current version 3.1.0 at http://www.kbst.bund.de/doc,-307462/V-ModellXT-Editor.htm (accessed 17 August 2005)

15

have already been described (s.a. chapter 1), the objective here is to consider what makes the single components such as process modules form a coherent project. Components such as a process module or a product are simply collections of texts essentially that can be selected and amended at will within dynamic tailoring. But surely it would not make much sense to integrate e.g. the bidding process into a project without the subsequent selection of the best bidder. This means there has to be a set of rules and corresponding implementations to ensure the factual and logical integrity of the project. The means to reflect such rules are the various kinds of dependencies within V-Modell XT. As products are the main objects with V-Modell XT, product dependencies23 describe the logical connections between products and related process modules, which must be taken account of during tailoring. A factual product dependency24 is defined as the changes of one product triggering changes in another product (e.g. when the requirements get evaluated within the product requirements assessment, the results must be implemented into the requirements specification [VModell XT, 2005, p. 5-150]). A generating product dependency25 triggers a new product instantiation, e.g. whenever the result of a tender document assessment favours the submission of an offer, that product has to be created on the supplier's side [V-Modell XT, 2005, p. 5-141]. A special variant of these product dependencies is the tailoring product dependency, which describes the interdependencies of customising activities within V-Modell XT. In case of a supplier setting up his project this means that his choice of process modules may be influenced (or explicitly specified) by the customer in his submission or the contract [V-Modell XT, 2005, p. 3-65].

Current implementation The MoB process is separated into two parts within the existing V-Modell XT: the market analysis for finished products26 is the sole product within a special

23

German: Produktabhängigkeit (PAH)

24

German: inhaltliche Produktabhängigkeit (iPAH)

25

German: erzeugende Produktabhängigkeit (ePAH)

26

German: Marktsichtung von Fertigprodukten

16

process module named evaluation of finished products27. The make-or-buy decision is a product that belongs to the process module system specification28.

Figure 5: standard implementation of MoB with V-Modell XT

So far, V-Modell XT makes a clear distinction of project tasks between customer and supplier. The customer draws up the requirements specification, which contains only the abstract description of what functionalities are required. Within a requirements assessment these findings are reviewed for reasonableness and are then integrated into the requirements specification in an iterative step. The supplier has the task of building up the system specification29 that includes the selection of components or COTS applications that will be used. This specification is presented to the customer for agreement as the basis of the project contract. The MoB product is seen as an integral part of the SE process module that is to be used in the context of system specification and system design only. The MoB is used to identify system components that have been identified before as possible independent objects, which could be acquired elsewhere. The process module FP is a pre-step to this, it is seen as a step that is not necessarily needed for the MoB and has therefore been excluded from it. In consequence, both these products are accessible only within the project type supplier, it is not available within the customer project. The needed solution would be to make both products available for the supplier as well as the customer.

27

German: Evaluierung von Fertigprodukten (abbreviated FP)

28

German: Systemerstellung (abbreviated SE)

29

German: Gesamtsystemspezifikation

17

Alternative 1: relocating MoB and modifying FP A first option to reach this would be to modify both structural components without removing their separation into different process modules. The MoB as a product could be moved into another process module where it would be accessible for both customer and supplier. To prevent changing the structural attachment of a process module with relation to the project types, it has to be a module that is already accessible from both sides. The only process modules with this characteristic are the modules of the so-called V-Modell core that contain the functionalities obligatory to all project types, i.e. the process modules project management, quality management, change management and configuration management. The only eligible module seems to be the project management module, wherein the MoB could form an integral part. The process module FP must be changed to be accessible from the customer side as well. The resulting process would look like this: based on the requirements specification there is (if necessary) a market analysis for finished products, obligatorily followed by the MoB with the decision on the future development of the project – will it be an individual software development project, simple procurement of COTS components or a mix of both.

Alternative 2: modifying FP and requirements assessment The second solution does without the product MoB, which remains unchanged. Only FP is modified as described above, the task of MoB is integrated into the product requirements assessment by changing the contents of the product accordingly. This alternative uses only one product that is not already available on the customer side.

Alternative 3: integrating MoB into process module FP A better integration of the whole complex market review and MoB would be to combine both market review and MoB into one process module, still as separate products to continue the contextual separation the makers of V-Modell XT had in mind originally. Whenever a MoB would be required, the whole FP process module

18

would be tailored to the project and the users would be free to choose whether to do the MoB with or without a market review.

Alternative 4: a new general evaluation process module The process of evaluation can be broken down into five steps: Derivation of evaluation criteria out of the data available at that time, such as technical criteria like relevance, priority, target dates and financial criteria regarding budget and effectiveness. The market review (with open source products or the review of sourcing and availability in case of software reuse). The MoB with usage of the criteria developed in the first step. Development of a system architecture as a result, defining whether the project consists of 100% individual development, 100% procurement or what mix in between. The architecture's granularity depends on the degree of detail of the data available and the project's progress. A commercial assessment of the identified components. In examining the V-Model XT and the MoB integration one can see several similar scenarios that all have to do with such an evaluation. First of all there is the changed scenario already described above within the supplier project. Basis of the evaluation is the requirements specification, and then comes the review, followed by the MoB and the assessment, and the results are iteratively integrated into the requirements specification. On the supplier's side, there is the same kind of process in evaluating the submission data. The current version starts with the product submission assessment to evaluate the submission on what the supplier wants, how this could be technically produced, whether this would make sense in business terms and what strategy should be used to win the contract. In the conclusion shall be a statement on whether it would make sense for the (would-be) supplier to participate in the bidding process [V-Modell XT, 2005, pp. 5-14 – 5-15]. The requirement for a technical system design does not mention MoB so far and sees this action located at a later stage of the project, after the bid is won and

19

the system specification for the customer is to be created. This means that both the submission assessment as well as the resulting offer to the customer is intended to base on a rough sketch of the system architecture alone. What company would voluntarily take the risk not to calculate the costs before bidding for a contract with exact figures? In addition, how should it be possible to reach at even the sketch without doing at least a rough version of market review and MoB? Therefore, the submission assessment could be changed in analogy to the customer project, implementing an evaluation process including the MoB. The same is true of that system specification. Once more, there is the evaluation process for assessment and selection of COTS products. With three occurrences of identical (or at least very similar) procedures, the question arises, whether it would make sense to implement a standard procedure that could cover all three scenarios. This would mean a new process module 'software selection' that contains the five steps as products as described above and would replace the finished products (FP) process module. The first scenario then could do without the requirements assessment product, the new evaluation process module would be used instead. The same would be true for the submission assessment. The combination of the market review of FP and the MoB from SE would no longer be needed as well, just another instantiation is asked for.

Choice of solution The emphasis on the last alternative makes it evident which alternative is preferred. The solution is systematically sound and pleases the object-oriented mind as well as the database-proficient drive for normalisation. The question is, whether the V-Modell XT is object-oriented and normalised enough to allow for such a solution. The answer is a definite 'no'. V-Modell XT process modules are not objects with methods and attributes that can be instantiated at will within the meta-model. One can do so in instantiating process modules as often as necessary, but they are not as flexible as real objects as there are equivalents neither to methods nor to attributes available. It is not possible to instantiate the object 'software selection' with the attributes (scenario = 'requirements', software_type = 'COTS ERP', base_product

20

= 'requirements specification', target_product = 'requirements specification' etc.). The process module can be instantiated, but not within the methodology's meta-model (you cannot produce an object as the instance of another object). The V-Modell XT is a text-based methodology, the text cannot be changed, has to fit for all contingencies. As with any text, the problem on one hand is to be precise and detailed enough to give the project team a helping hand, and still fit for all scenarios. On the other hand, it must be not too general so still to make any sense. There is one solution that makes V-Modell pseudo-object-oriented. It is possible to define project attributes, which influence tailoring by triggering tailoring product dependencies (tPAH). These tPAHs are the switches to trigger the use of certain product themes (chapters). So in case of using the project attribute 'requirements' there would be one instantiation of 'software selection' with the products using the themes adapted to this scenario. This means that all such parts would have to be written in as many versions as there are scenarios, with three scenarios three complete sets of text have to be customised. Instead of three specific sets of products there is one set of products with n (three) specific and pre-defined permutations build in. Is this really the better solution? I fear it would only make the V-Modell more complicated and more difficult to develop further – as much as I like it object-oriented and normalised. Another argument against this solution is object-oriented as well. For each scenario not only the instantiation of the product changes but different people are involved with them. It would be necessary to assign roles to products dependent on the scenario attributes. This is not possible, only singly defined roles can be used in products. It is impossible to assign role profiles to products that contain a number of roles. The WEIT project team finally produced some parameters for the solution to be found: following the publication of release 1.0 in February 2005, funds are low with the project, so any solutions with grievous changes to the V-Modell XT are not possible. The meta-model of V-Model shall remain unchanged. Alternative no. 4 would violate both limitations, so this is not the solution to implement. Another parameter is the axiom of the systematical separation of customer and system design. Therefore, solution no. 3 is not possible as well, as the MoB is

21

seen as too design specific as to be able to combine with any process module not directly connected with that topic. Alternative no. 1 is a direct violation of this clause too, as the MoB is moved away from system design to a general module without any direct systematical connection left to system design. This leaves us with alternative no. 2.

MoB is neither touched nor moved,

existing modules and products are not essentially modified but extended.

22

CHAPTER 4 IMPLEMENTATION Design The implementation of the selected alternative was not done with one stroke, it was an iterative process. Following the agreement with the WEIT team on the solution, a first implementation was done and presented to the team at the end of May 2005. June and July 2005 were spent with on-going discussions on details, mainly with text changes. In parallel a documentation of all changes30 was kept. The implementation was done using the V-Modell XT Editor31. The similarities of V-Modell XT with OOP have already been mentioned, so it makes only sense to do the implementation likewise. An OOP design process should go two ways: first, a top-down approach to identify the relevant structural changes, then a bottom-up approach with implementation. Accordingly, the necessary structural changes have been identified. The bottom-up approach for implementation is self-evident: before using an attribute with an object (i.e. creating an instance) one first has to define that attribute.

New method reference 'evaluation methods' First comes a very general customising with a new method reference. This is a small compendium of brief summaries on various methods used in IT projects. There has not been a method reference on evaluation methods so far, this is added now. The reference consists of the summary and a selection of sources.

Integration of FP into project type 'customer project' The main structural change is to enable the project team to access the process module 'Finished products' (FP) during tailoring from the customer side. This

30

see Appendix C

31

s.a. p. 15

23

is simple to do, by adding the process module as 'optional process module' to this project type.

Structural changes of the process module FP Within the process module FP itself the selection criteria for the process module have to changed accordingly. Besides the project attribute 'supplier', the project attribute 'customer' is needed. Now that FP is accessible in principle, the structural connections between the process modules have to be customised. Basis of the market review is the requirements specification. This is a part of the process module requirements definition (ANFE), so what is needed is a relation between these two process modules. So far, the relations of FP with other process modules are limited to one mandatory dependence on the process module system specification (SE). This is changed to 'optional', another optional dependence on ANFE is added.

Structural changes of the product market review The product market review is a part of the process module FP. It has to be accessible from both the customer and supplier as well. This is an easy task in principle, just another dependency must be added. In this special case, this will not be sufficient. As already mentioned, the roles attached to products cannot be changed dependent on the calling product. Exactly one lead role and n cooperating roles can be defined, no role profile. In the current product, the lead role is the system architect – a role that is non-existent within the customer project. The lead role for the products on the customer side lies with the requirements analyst. To solve this problem of incompatibility it is necessary to double the product, to produce two different products – one for the customer project, one for the supplier side. The first change is with the current product. It gets renamed 'Marktsichtung für Fertigprodukte (AN)', indicating its connection with the supplier (AN) project.

24

The product text gets slightly adapted and is moved into a text block that is newly defined. The text block is attached to both products. A new product 'Marktsichtung für Fertigprodukte (AG)' for the customer project is created, the customising is identical with the original product. The only difference is the change in the lead role, the requirements analyst is customised for that role. To make the new product accessible in tailoring a new generating product dependency (ePAH) 'execution of a market review (customer)'32 must be customised that leads from the products project handbook or requirements specification to the new product market review (AG). Every product in V-Modell XT is connected with one activity. So there have to be changes corresponding with the ones done with the product. This means changing the current activity into 'executing a market review (AN)' and to create a new activity for the supplier side as well. Both activities get a reference to the new method reference chapter 'evaluation methods'.

Structural changes of the process module ANFE The changes in FP connect it to the customer project. What is still missing is the connection between the products of ANFE and the new product of FP. First there must be a tPAH to make it possible to optionally trigger the product market review (AG) on the basis of the requirements specification. The results shall be assessed similar to a MoB afterwards in the requirements assessment. This means a new iPAH from the market review (AG) to the requirements assessment. To the activity creating the requirements assessment the method reference evaluation methods is added.

Other structural changes The new method reference is added at two more places: within the activity doing the MoB (process module SE) and within the activity creating a criteria

32

German: Durchführung einer Marktsichtung von Fertigprodukten (AG)

25

catalogue for submission assessment (process module order allotment, project support and take over).

Text changes within the part 'V-Modell XT basics' The main efforts with this whole implementation went with the texts of VModell XT. The first change listed here was the most pleasing: the list of limitations of the V-Modell XT could be reduced by the point 'COTS evaluation by the customer not covered'. The description of the project type customer project was changed to contain the optional choice of process module FP.

Text changes within the process module FP The text of the process module FP was adapted to the product changes, especially on the way of how to handle the results of a COTS evaluation. There is now a new paragraph saying that there can be a difference between the results of the COTS evaluation and the requirements, showing either more functionality than required or less. In both cases, the project team then should think about adjusting the requirements accordingly. The evaluation results then will be documented within the product requirements assessment on the customer side or the theme evaluation of finished products within the product MoB on the supplier side. Another new paragraph describes the new process on the customer side: based on the rough system architecture sketched out in the requirements specification a market review (AG) is conducted, within the requirements assessment there is an evolution, whether and which COTS applications could be usable. The results get worked into the requirements specification and determine whether the subsequent submission will be concerning a development project, just procurement or a mix of both. The new ePAH conducting a market review of finished products got a short description, that in case of the possibility of the use of COTS components it could make sense to conduct an evaluation based on a market review. The text for the new activity conducting a market review (AG) describes that the basis is the rough system architecture contained in the requirements specification and how the information on the various products can be acquired.

26

Text changes within the process module ANFE The text for the role requirements analyst (AG) was changed, adding the activities concerning COTS evaluation and MoB. The text for the new tPAH optional procurement of finished products has been done similar as the ePAH described above. The theme sketch of life cycle and system architecture within the product requirements assessment was changed by adding a new paragraph that in case of an evaluation of COTS products the resulting system components should be identified and documented. The text of activity component create evaluation criteria gets a new paragraph on using assessment methods usable with COTS evaluation. The text of activity component assessing requirements describes the need for system architecture activities by the customer through a qualified MoB. The text of activity component integrate assessment results is extended by a paragraph on the possible ways of using the results in the project. The text of component activity create sketch of lifecycle and system architecture is changed by stating that after the requirements assessment the identified COTS components have to be documented.

27

CHAPTER 5 EVALUATION AND IMPROVEMENTS Now that V-Modell XT has been modified, verification is needed that these changes fulfil the expectations connected to them. The modifications have to prove their value in a real life environment. The best possible test for a project management methodology is to use it in a current project and to see what comes out of it. This was planned to do with ITB at Hamburg, but due to unforeseeable changes in their project parameters, this proved to be impossible. The next best thing to do is to ask participants of current projects whether and how they could have used the modified V-Modell XT and what they think of the usability of V-Modell XT in their respective fields. This has been done with responsible project members of three current projects.

Test case 1: ITB, Hamburg - Gewerberegister The author's contact with this public administration body triggered this dissertation. The idea was born that V-Modell XT could be used for small- to medium-sized projects. Soon it was discovered that one feature important for ITB was missing in V-Modell XT: the possibility to evaluate COTS applications when acting as customer. The city of Hamburg is one of sixteen German federal states. Administrative tasks on the communal and regional level are handled by seven Bezirksämter (district administrations). "IT-Angelegenheiten der Bezirksverwaltung" (abbreviated ITB, roughly: IT affairs of district administration) is a newly formed department within the Hamburg public administration responsible for defining and managing all IT projects on this level. ITB takes care of the project management, the responsibility for the contents of the project lies with the administration body the project is done for. The project work as such will be done by suppliers, preferably the state-owned IT company Dataport33.

33

web site: http://www.dataport.de (accessed 26 September 2005)

28

It is ITB’s task to oversee and manage the use of IT applications for their whole lifecycle. There are quite a number of outdated host applications that need to be replaced with up-to-date solutions. There is a general guideline that all new software solutions should be COTS software packets whenever possible, as those are cheaper to procure and maintain than the development of individual software usually. ITB is looking for a way to organize such projects in a uniform manner, with the same methodology usable for all projects. There is a self-developed procedure on what steps to take that could be improved to fulfil this task. The project at hand is to find and implement a solution for the administration of 'Gewerberegister' (business register). This is an official register obligatory for all business in Hamburg, ranging from one-man part-time business to MNE subsidiary. Every data change such as the first registration of a new company and all subsequent changes until its deletion from the register have to be monitored. This is the moment to mention the special problem with eGovernment in Germany that results from the German federal structure – there are far too many independent administrative bodies that simply cannot be ordered to comply with general IT architectures. This starts with the federal level, the federal administration in most cases has little to no influence on state authorities. This will come as a surprise to non-German readers, but for the last 1,100 years34 (even in the first half of the 20th century35), the German federal states have had far-reaching autonomous rights, and this has not been changed so far, more to the contrary. Within the federal states the lowest regional administrative level are the city communities, which enjoy their own autonomy. This means, every community of course has to follow the thousands of federal and state laws, but how it does this cannot be influenced. The Gewerberegister is regulated by federal law and is a task to be taken care of by the communities. Due to the mentioned communal autonomy any of them is free to find an individual way of doing so – and experience shows that they are very innovative in finding dozens of different ways to solve the same problem. The very existence of ITB as a central IT project management provider for all the 34

A little bit exaggerated one could state that to this very day Germany consists of a collection of separate tribes, which speak about the same language. Usually, a German thinks of himself as e.g. a Saxon, Swabian or Bavarian first, German second. 35

Imperial Germany (1871 – 1918) was a rather loose federation of autonomous fiefdoms; all central authority was due to the backing of the biggest single state, Prussia. Even under Nazi rule the party structure reflected the federal tradition, with the infamous Gauleiter as a strong regional leader, who had total power in his area, with little interference from party headquarters.

29

Hamburg authorities at the communal level therefore can be seen as a big step forward towards unified IT strategies. Dataport is another means to reach this target. The company is owned by the federal states of Hamburg, Schleswig-Holstein and Mecklenburg-Vorpommern and is intended to provide their administrative bodies of all levels with standardised IT software and hardware products and services. Another initiative is the so-called 'Metropolregion Hamburg'36 to introduce common procedures and policies within Hamburg and its neighbourhood. It consists of the city of Hamburg and 14 surrounding Landkreise (counties). This means that three federal states are involved, whose different legislations have to be coordinated to enable uniform administration procedures. A common technical base with compatible networks is established. At the moment there is an IT project running to enable citizens to have their cars registered at any communal adminstration in the Metropolregion, independent of where they actually live. So they could do this e.g. during lunch break at their workplace, would not have to do it in the evening at their home community. The IT side has been cleared, as the solution has already been implemented in one of the participating counties, Landkreis Segeberg north of Hamburg, in 2001. One of the remaining (and seemingly unsolvable) problems is the question whose administration's seals will have to be used for documenting the registry in such a case – the seals of the administration documenting the registry or of the body where the citizen lives? And in the latter case: can the documenting administration be authorised to have and to use a seal of another authority in another state? Really grievous and important problems … The Gewerberegister also relates to various levels of government. The register itself is maintained at the communal level, but several other bodies such as the Central Commerce Register37, chambers of commerce, tax offices, factory inspectorates, employment agencies, registrar courts and others have to get more or less regular information (best through EDI transmissions). Within the national

36

Web site: http://www.metropolregion.hamburg.de/ (accessed 26 September 2005, German only) 37

German: Gewerbezentralregister. Website: http://www.bundeszentralregister.de/gzr/ (accessed 26 September 2005, German only)

30

DeutschlandOnline project38 there is a project envisioning workflow support and central EDI transaction broker servers for this purpose39. The final evaluation of the modified V-Modell XT took place at 19 July 2005. The ITB team was informed on the state of changes of V-Modell XT and in return first gave information on the current state of the Gewerberegister project. The project started in March 2005 and is now in the stage of deciding on the application to be procured. In a first round of market review and MoB the offers of Dataport have been evaluated. Dataport turned out to have no fitting application available, so in a second round applications from other possible suppliers were evaluated. The main criterion for choosing products was the certification of the products through the Federal Statistics Office40, which left 18 applications to evaluate. The process was compared with the possibilities of the modified V-Modell XT. The ITB team agreed that the changes to V-Modell XT would have enabled them to do this process using the methodology. They gave one hint for another useful structural change: as it was clear to them from the start that they wanted to look at COTS applications, they did not first formulate the requirements specification and then did the market review, but the other way round. They first (with only a very general idea on the requirements) made a first cursory market review of available COTS application to see what functionality was available in the market. Then they formulated the requirements specification accordingly. What was missed with V-Modell XT was a module to handle project logistics. There is a project module integrated logistic support, but that handles the planning and organisation of logistics prior to go-live only, not doing the real thing after that point. A general critique of V-Modell XT was its complexity. There was the impression that even when massively reduced during tailoring there still was too much overhead for such small to medium sized projects as ITB has to manage. They

38

Website: http://www.deutschland-online.de/Englisch/english.htm (accessed 26 September 2005)

39

Internet: http://www.dzbw.de/servlet/PB/show/1177117/pr1_gewerbeanmeldung_behoerdensp_Juli%2 005_1.pdf (accessed 26 September 2005, German only) 40

German: Statistisches Bundesamt

31

sometimes had that problem even with their own method that they decided to use further on. As a result, ITB sees the main use of V-Modell XT in having a complete check list for projects at hand, they will not use the methodology for anything else.

Test case 2: Brandenburg Ministry of the Interior, Potsdam - BOA The second project team to look at my modifications to V-Modell XT is situated at the Ministry of the Interior of the state of Brandenburg at Potsdam, doing the project 'Brandenburger Online-Amt'41. Mr. Daniel Cutter is responsible for IT strategies and methods, Dr. Reinhard Verch is the project manager for BOA. BOA is a project to build up a statewide Internet portal for all levels of Brandenburg administration, to produce a basis for effective eGovernment. The focus does not lie with contents but mainly with creating the necessary infrastructure. Six areas will be developed in all. There will be a portal server to provide a uniform web platform. A payment platform is planned to ensure secure e-payment / e-billing functionality. A download server holds document forms for download by citizens. A virtual post office delivers services such as secure e-mail and digital signature as well as the integration of the other services with administrative applications, compliant with the OSCI42 standard. A tool called responsibility finder delivers search functionality for citizens who look for who is there to provide a special administrative task. In the end, a so-called state information system with all kinds of information on administration details and services will be build up as an access point for both companies and citizens. The first modules will go online this autumn. There will be no big bang, the modules will go live one-by-one as they are available. Additionally, administrative applications offering services to citizens will get integrated such as an address data service (in Germany citizens are obliged with delivering the authorities with a valid address, so these databases are the most current in Germany).

41

Brandenburg Online Administration, abbreviated BOA. Website: http://www.boa.brandenburg.de (accessed 27 September 2005, German only) 42

The German administration's standard for online service protocols and secure interfacing. Website: http://www.osci.de/ (accessed 27 September 2005, German only)

32

The evaluation of the modified V-Modell XT was done at 3 August 2005 in a workshop meeting at Potsdam. The team had had no time to prepare, so first much time had to be spent on introducing them to the V-Modell XT and the modifications to it. Then the team gave information on their situation. The general project settings are rather similar to those with ITB. The Ministry of the Interior does the overall project management and coordinates the project with all participants. A state-owned IT provider, LDS43, does the IT-specific work when ever possible.

Components are identified as the project progresses and

governmental bids are submitted. So, identification, evaluation and system integration of components is one task of the team. As with ITB, the task does not end with going live, but continues over the whole product life cycle. Therefore, the modified V-Modell XT as presented was regarded as an improvement, but overall V-Modell XT was still found lacking. The non-coverage of system integration through the customer was criticised and the fiction of a project mandatorily ending at go-live was regarded as ridiculous. The efforts needed for acquiring sufficient knowledge of V-Modell XT was regarded as too high. In general, V-Modell XT was seen as too complex and too ambitious to be of use with their projects (at least in the near future).

Test case 3: IABG, Munich - ITAmtBw The closest and most intense cooperation has been done with Mr. HansJürgen Meinhardt of IABG, Munich. Mr. Meinhardt has been my main contact person in the WEIT team, where he and Mrs. Rauh of Siemens are responsible for defining the requirements parts of V-Modell XT. At the same time, he is active in consulting with the Federal Forces Office for Information Management and IT (ITAmtBw)44.

43

Landesbetrieb für Datenverarbeitung und Statistik Brandenburg (state corporation for IT and statistics). Website: http://www.lds-bb.de/cms/detail.php/lbm1.c.203392.de (accessed 27 September 2005, German only)

44

German: Bundesamt für Informationsmanagement und Informationstechnologie der Bundeswehr. Website: http://www.bundeswehr.de/C1256EF4002AED30/CurrentBaseLink/W2652K6C222INFODE (accessed 27 September 2005, German only)

33

IABG45 is a leading European technology company with primary focus on forward-looking applications of high technology and science. The ITAmtBw is the central administration body within the Federal German Forces for everything connected with ICT. Mr. Meinhardt is the responsible consultant with a project at the ITAmtBw concerning ICT equipment (more details are not allowed to be revealed for confidentiality reasons). The project is running for four years already and is scheduled to last until 2012. The project task is the procurement of hardware, embedded system components and the development of minor software components. The current task on the customer side was to convert all the existing project methodology and the appendant documentation to V-Modell XT, if possible. On the supplier's side, an order was placed directly without submission for a system component plus additional development. This part of the project is being done using V-Modell XT too. This task coincided with Mr. Meinhardt's cooperation with me on the necessary changes in V-Modell XT. In parallel with our on-going discussion and my modifications to V-Modell XT Mr. Meinhardt applied the modifications to his project. The project so far had been done using an own internal guideline for conducting IT-projects based on phases and milestones with mandatory phase documents. Following this, the requirements were defined and a market review was done. Due to the narrow specialised market segment, the project team soon had a good overview of the products available and was able to identify the degree of compatibility between the new and older system components. This means, they necessarily had to include system integration assessments into their project. As a result, the need for the individual development of additional system components was identified. For analysing the need of system parts to be procured or developed it was necessary to produce a rough system architecture including all system elements relevant for the target system. The project showed the applicability of the modified V-Modell XT with projects that include not only development but also the procurement of COTS components. The modified V-Modell XT is now usable for those cases, when system integration issues are moved into the project team's responsibility.

45

Website: http://www.iabg.de/unternehmen/index_en.php (accessed 27 September 2005)

34

The project was applying a multi-projecting approach in order to master the complexity of the project due to long duration, funding, budgeting, technical progress etc. The V-Modell XT does not yet consider multi-projecting. Therefore the WEIT team will integrate a multi-project solution within the next version of V-Model XT. According to Mr. Meinhardt the project proved the need for my modifications to V-Modell XT. In his own words, these modifications enabled Mr. Meinhardt to make significantly visible all the advantages and benefits of the modified V-Model XT for successfully conducting such a complex project as described.

Resulting improvements of the implementation The request of ITB for enabling an additional first market review directly after project kick-off was endorsed, discussed with the WEIT team and accepted. It now shall be possible to iteratively do the process of market review and subsequent requirements assessment (as a substitute to a MoB). The results are then added to the requirements specification. To document this new dependency the new generating product dependency (ePAH) 'execution of a market review of finished products' has to be modified. Additional to the product requirements specification there must be a logical connection from the product project proposal leading to the new product market review (AG). To make the new product accessible in tailoring a new tailoring product dependency (tPAH) has to be customised. The tPAH procurement of finished products creates a logical connection between the project proposal and the project handbook, where this dependency is written into the project structure. The text for the product market review (AG) was changed accordingly.

35

CHAPTER 6 CONCLUSION AND RECOMMENDATIONS The aim of this project was to design and implement the changes necessary to enable future V-Modell XT users to evaluate COTS applications and components in the customer role as well. The task was not to implement a one-time ideal solution for one project but to create a general solution that is integrated into the V-Modell XT standard, to modify an acknowledged project management standard equivalent to PRINCE2. With an individual solution, one is free to change an existing model at will. Creating a standard solution means teamwork with the original creators of the VModell XT, means adjusting solutions to systematic influences and doing compromises. The found solution is such a compromise of systematics and resources. As a result, there is a consistent and approved new version of V-Modell XT that is a first step into the direction of making system integration issues such as MoB available to both main kinds of project types, done with the least possible alterations. As usual, with answering one question several new ones have appeared. In consequence of this project there is now an awareness of the problems connected with system integration done by the customer instead of the supplier. Pandora's Box has been opened. The next steps in my opinion will include the major task of modifying the process module system specification (SE) to be compatible with the customer project. This will mean a massive change in the internal structures of V-Modell XT. The project revealed some weaknesses of V-Modell XT: Similar to its predecessor V-Modell 97 the sheer mass of documentation of about 650 pages seemingly is an effective deterrent to many possible users of the methodology. There is now a short teaching module to the model available, but many users it seems have not found that. The scope of a V-Modell XT project must not end with the preparations for golive, but has to encompass the whole software life cycle.

36

V-Modell XT has the very user-friendly feature of enabling the customising of the methodology as such to the user's needs. An organisation-specific version of VModel XT can be created. There is just one major fault with this option in my eyes: the specific version is built as a variant of the current version of the V-Modell XT. Whenever there is a later release update of V-Modell XT, this cannot automatically be implemented into the specific version. With creating such an organisation-specific version V-Modell XT is no longer standardised. What use has such a specific implementation, if it is not updateable over a longer period? Standards are another topic. V-Modell XT is to be a standard in itself and is said to comply with standards such as CMMI and ISO 15288. How can this be guaranteed when you are able to extensively tailor the project to a degree with nothing of a standard left? These topics will have to be dealt with in the future to ensure the acceptance of this new project management methodology.

37

Bibliography Brock, S. & Hendricks, D. & Linnell, S. & Smith, D. (2003) 'A balanced approach to IT project management'. In Proceedings of the 2003 Annual Research Conference of the South African institute of Computer Scientists and information Technologists on Enablement Through Technology (September 17 - 19, 2003). J. Eloff, A. Engelbrecht, P. Kotzé, and M. Eloff, Eds. ACM International Conference Proceeding Series, vol. 47. South African Institute for Computer Scientists and Information Technologists, pp.2 - 10. ACM [Online] Available from http://ezproxy.liv.ac.uk:2289/citation.cfm?id=954015&coll=portal&dl=ACM&CFID=527 76793&CFTOKEN=26035376&ret=1#Fulltext (Accessed 21 August 2005) Broy, M. & Rausch, A. (2005) 'Das neue V-Modell® XT – Ein anpassbares Vorgehensmodell für Software und System Engineering' (English: The new V-Modell XT – an adjustable Process Model for Software and System Engineering). Informatik Spektrum, 28(3) June 2005, pp.220-229 [Online] DOI: 10.1007/s00287-005-0488-z Available from: http://agrausch.informatik.unikl.de/publikationen/repository/journal/jour016/V-Modell-XT-Spektrum-Finale.pdf (Accessed 23 July 2005) Carney, D. & Wallnau. K. (1998) 'A basis for evaluation of commercial software'. Information and Software Technology, 40-14, 1 December 1998, pp. 851 – 860 [Online] Available from: doi:10.1016/S0950-5849(98)00099-8 (Accessed 22 August 2005) Cummins, F. (2002) Enterprise Integration. An Architecture for Enterprise Application and Systems Integration. New York 2002: Wiley Computer Publishing Filss, C. (2005) Vergleichsmethoden für Vorgehensmodelle. (English: Methods to compare process models). Diplomarbeit (Dissertation) at the Technical University Dresden [Online] Available from: ftp://ftp.uni-kl.de/pub/v-modell-xt/Release1.1/Infomaterial/Diplomarbeit-von-Christian-Filss.pdf (Accessed 28 August 2005) Heckmann, D. (2004) Open Source – closed shop? Vergaberechtliche Anforderungen an behördliche IT-Ausschreibungen zugunsten von Open-SourceSoftware. Wissenschaftliches Rechtsgutachten im Auftrag der Microsoft GmbH (English: Legal requisitions on governmental IT bids concerning open source software. Scientific legal report on behalf of Microsoft GmbH) [Internet] Available from: http://www.innrego.de/osvergabegutachten.pdf (Accessed 18 September 2005) Humphreys, P. & McIvor, G. & Huang, G. (2002) 'An expert system for evaluating the make or buy decision'. Computers & Industrial Engineering, 42(2-4), pp.567-585, Science Direct [Online] Available from http://dx.doi.org/10.1016/S03608352(02)00052-9 (Accessed 24 July 2005) Kneuper, R. (2005) Erfüllung der CMMI-Anforderungen mit dem neuen V-Modell XT (English: Fulfilment of CMMI requirements with the new V-Modell XT) in: Entscheidungsfall Vorgehensmodell. 12. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik e.V., Berlin 2005, pp. 59 - 70 Kontio, J. (1996) A Case Study in Applying a Systematic Method for COTS Selection. In: Proceedings of ICSE-18 (1996), pp.201-209 Kranz, M. (2004) A CMMI® Based Evaluation of the V-Modell XT. Diplomarbeit (dissertation) at the Technical University of Munich Lawlis, P.K. et al. (2001) 'A Formal Process for Evaluating COTS-Software Products'. Computer, (May 2001), pp. 58-63. 38

Leishman, T. & Smith, L. (2000) Software Project Management Technology Report [Online] Available from: http://www.stsc.hill.af.mil/resources/tech_docs/PMTRv46.DOC (Accessed 22 August 2005) Lewis, G. & Morris, E. (2004) 'From System Requirements to COTS Evaluation Criteria'. In COTS-Based Software Systems: Third International Conference, ICCBSS 2004, Redondo Beach, CA, USA, February 1-4, 2004. Proceedings. Metapress [Online] Available from: http://ezproxy.liv.ac.uk:2242/openurl.asp?genre=article&issn=03029743&volume=2959&spage=159 (Accessed 22 August 2005) Maiden, N. & Ncube, C. & Moore, A. (1997) 'Lessons learned during requirements acquisition for COTS systems' Communications of the ACM 40(12) 1997, pp. 21 – 25 Maiden, N. & Ncube, C (1998) 'Acquiring COTS software selection requirements' IEEE Software 1998, pp. 46 - 56 McIvor, R. & Humphrey, P. (2000) 'A case-based reasoning approach to the make or buy decision' Integrated Manufacturing Systems 11(5) 2000, pp. 295 - 310 Morisio, M. et al. (2002) 'COTS-based software development: Processes and open issues', Journal of Systems and Software, 61(3), pp. 189-199, Science Direct [Online] Available from: http://dx.doi.org/10.1016/S0164-1212(01)00147-9 (Accessed 24 July 2005) Padillo, J. M. & Diaby, M. (1999) 'A multiple-criteria decision methodology for the make-or-buy problem'. International Journal of Production Research, 37(14), pp.3203-3229, Taylor & Francis [Online] Available from: http://journalsonline.tandf.co.uk/openurl.asp?genre=article&id=doi:10.1080/00207549 9190248 (Accessed 24 July 2005) Port, D. & Chen, S. (2004) 'Assessing COTS Assessment: How Much Is Enough?' In COTS-Based Software Systems: Third International Conference, ICCBSS 2004, Redondo Beach, CA, USA, February 1-4, 2004. Proceedings. Metapress [Online] Available from: http://ezproxy.liv.ac.uk:2242/openurl.asp?genre=article&issn=03029743&volume=2959&spage=183 (Accessed 22 August 2005) Schmietendorf, A. & Dimitrov, E. & Dumke, R. (2002) 'Process models for the software development and performance engineering tasks' In WOSP '02, July 24-26, 2002 Rome, Italy, ACM ISBN 1-1-58113-563-7 02/07 Schuppan, V. (1999) Das V-Modell 97 als Softwareentwicklungsprozess aus der Sicht des Capability Maturity Model (CMM) für Software (English: The V-Modell 97 as software development process in the view of CMM for software). Diplomarbeit (dissertation) at the Technical University of Munich Schwalbe, K. (2004) Information Technology Project Management. Third edition Boston: Thomson Sedigh-Ali, S. & Ghafoor, S. & Paul, R. (2001) 'Software engineering metrics for COTS-based systems' IEEE Computer 2001, pp. 44 - 50 SEI (Software Engineering Institute) (2001) CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development, Version 1.1 Solberg, H. & Dahl, K. (2001) COTS Software Evaluation and Integration issues. Project report at the Norwegian University of Technology and Science, Trondheim. Sommerville, I. (2005) 'Integrated requirements engineering: a tutorial' Software, IEEE, 22(1), pp.16-23, IEEE [Online] Available from:

39

http://ezproxy.liv.ac.uk:2396/iel5/52/30054/01377118.pdf?isnumber=30054&prod=JN L&arnumber=1377118&arnumber=1377118&arSt=+16&ared=+23&arAuthor=Somme rville%2C+I (Accessed 24 July 2005) Sommerville, I. (2001) Software Engineering. Sixth edition Boston: Addison Wesley Standish (1994) 'The CHAOS Report', The Standish Group International [Online] Available from: http://www.standishgroup.com/sample_research/chaos_1994_1.php [Accessed 21 August 2005) Torchiano, M. & Morisio, M. (2004) 'Overlooked aspects of COTS-based development' Software, IEEE, March/April 2004, pp.88 - 93 V-Modell XT 1.01 (2005) as issued by the Federal Ministry of the Interior (BMI) on March 18th, 2005, [Online] Available from: http://www.kbst.bund.de/V-Modell/-,293/VModell-XT.htm (Accessed 23 July 2005) Wang, E.T.G (2002) 'Transaction attributes and software outsourcing success: an empirical investigation of transaction cost theory'. Info Systems Journal, (12), pp.153181 Williamson, O.E. (1975) Markets and Hierarchies. New York: Free Press (quote from Humphreys, 2002)

40

Appendix A V-Modell XT terms used Group

Term

Project Types

Projekttyp

Abbreviation

Project type

Auftraggeber

AG

Customer

Auftragnehmer

AN

Supplier

Organisationsspezifisches V-Modell XT

Project implementation strategies

Milestones

Projectdurchführungsstrategie

Organisation-specific VModell XT

PDS

Project implementation strategy

Systementwicklungsprojekt eines Auftraggebers

System development project of a customer

Projektmerkmal

Project attribute

Ablaufbaustein

Sequence unit

V-Modell-Kern

V-Modell core

Entscheidungspunkte

EP

Anforderungen festgelegt

Modules

English translation

Decision points, milestones Requirements defined

Vorgehensbaustein

VB

Process module

Anforderungsfestlegung

ANFE

Requirements definition

Auftragsvergabe, Projektbegleitung und Abnahme

Order allotment, project support and take over

41

Products

Product

Evaluierung von Fertigprodukten

FP

Evaluation of finished products

Projektmanagement

PM

Project management

Risikomanagement

RM

Risk management

Systemerstellung

SE

System specification

Produkte

Products; the documents to be created

Änderungsstatusliste

Change status list

Anforderungen (Lastenheft)

Requirements specification

Anforderungsbewertung

Requirements assessment

Angebot

Offer

Ausschreibungsbewertung

Submission assessment

Gesamtsystemspezifikation

System specification

Kaufmännischer Projektstatusbericht

Managerial project status report

Make-or-buy-Entscheidung

Make-or-buy decision

Marktsichtung von Fertigprodukten

Market analysis for finished products

Projekthandbuch

Project handbook

Projektplan

Project plan

Projektstatusliste

Project status report

Projektvorschlag

Project proposal

Produktabhängigkeit

PAH

42

Product dependency

dependencies

Roles

Tools

Erzeugende PAH

ePAH

Generating product dependency

Inhaltliche PAH

iPAH

Factual product dependency

Tailoring PAH

tPAH

Tailoring product dependency

Aktivität

Activity

Teilaktivität

Activity component

Rollen Anforderungsanalytiker

Requirements analyst

Systemarchitekt

System architect

Projektassistent

Tailoring tool Project Assistant

V-Modell XT Editor

Customising tool

43

Appendix B Confirmation by WEIT team

J. Prof. Dr. A. Rausch AG Softwarearchitektur Technische Universität Kaiserslautern

Ulrich Birowicz Kieler Str. 12 b D - 21465 Reinbek Deutschland 22.09.2005 Confirmation on the joint work between Ulrich Birowicz and the V-Modell XT development team on the evaluation and integration process of COTS products within a software system development project Topic of the thesis of Mr. Birowicz is, among other things, the improvement of the process for the evaluation and integration of COTS products in the V-Model XT, the new German federal government development standard for IT systems. The V-Model XT supports different project types, i.e. system development projects on the customer's side and on the supplier's side. It has a modular structure, which allows it to be easily adapted to project specific circumstances. In order to achieve this, a separate structuring level, the process modules, was introduced. One of these process modules is dedicated to the evaluation of COTS products. In version 1.0 of the V-Model XT the functionality of this process module was only usable by the supplier's side of a system development project. Because the evaluation of COTS products is, in many cases, an important aspect during requirements elicitation, which is in the V-Model XT in the duty of the customer, it was desirable to make this functionality also available to the customer. Mr. Birowicz analysed the actual version of the V-Model XT and developed alternative solutions for the desired improvement. After an evaluation step one of these solutions was selected and implemented by him. For the implementation detailed know-how of the structure of the V-Model XT was necessary. The implementation was reviewed by the WEIT-team, who developed the V-Model XT. Unfortunately because of lack of time the implementation of Mr. Birowicz couldn't be integrated in version 1.1 of the V-Model XT any more. But in the meantime the new functionality is integrated in the internal model, only available to the WEIT team, and will be released in version 1.2 at end of January 2006. Kind regards, (J. Prof. Dr. A. Rausch)

44

Appendix C Documentation of implementation This is the documentation as presented to and accepted by the WEIT team. Text changes and additions are printed in bold. The text has been in German originally, has been translated by the author for better readability of the whole study to non-German readers.

Integration of process module FP and product MoB within the customer project The target of the implementation is to enable a market review of finished products and subsequently a qualified make-or-buy decision on the customer side. Although there is only a very general idea on the system architecture at this stage of the project, the demand for cost effectiveness and assessable usage of resources for the solution to be procured makes it necessary to evaluate finished products at this point already. As practice shows, more and more frequently there is know how on technical solutions available at the customer side as well. In many cases this is already part of the customer role, especially in the case of IT organisation units that have to handle the project for a department. The market review of finished products and the subsequent decision on their usability within the ensuing requirements assessment are decisive for the further development of the project. On their basis the project can turn into a system development project a procurement project or a mix of both development and procurement. Even in the case of a pure procurement project integration efforts are necessary to bind the finished products into the new system architecture, to make them compatible with neighbouring systems. Therefore, with the appropriate tailoring the V-Modell XT is valid for procurement type projects as well (integration still done by the supplier). The sequence of interdependencies of finished products and the MoB decision (to be fixed within the project specific tailoring in the project handbook)

45

starts within the product requirements specification. There is a tight thematic coherence with the themes “Life cycle and system architecture” and “Scope of delivery”. The results of the market review of finished products at the time of creating the requirements specification are used within the requirements assessment. This results in enabling a meaningful commercial assessment. After the concluding requirements assessment the requirements specifications get adjusted accordingly.

Modification after evaluation round with ITB, Hamburg: In case of the project order including the guideline of using finished products whenever possible, there should be done a first rough market review directly after project kick-off. Its results should be taken over into the requirements specification. Following the further iteration described above then the final selection for the submission can be done.

The following changes must be made with v-Modell XT: (Text changes are marked as bold)

•

V-Modell structure: o

V-Modell basics


Objective and structure of V-Modell •

Limitations of V-Modell Deletion of the item concerning the missing ability of the customer to assess COTS products

•

Basic concepts of V-Modell o

V-Modell core and process modules Addition of FP: The last two of them can be used with the allotment of sub contracts within project type system development project of a supplier too. The central process module for this project type is system specification. Additionally there are the process modules hardware development,

software development, logistics conceptualisation, evolution and migration of generic systems, evaluation of COTS products and usability and ergonomy.

46

•

Project type ‘system development project of a customer’: o

•

Within ‘optional process modules’ addition of attribute process module FP

Abstract modeling elements: o

Additional text module ‘market review of finished goods’: If a Segment or unit of the system to be developed is intended to be realized by using a finished product, a suitable finished product must be found based on the specifications available at that time. In order to get an overview over the finished product candidates available on the market, a Market Survey for Finished Products will be prepared. This document includes information on a variety of suitable finished products. For each candidate additional information such as product sheets, product specifications, performance characteristics and prices are provided. The market survey can be executed at different times during the system development process, both on the customer as well as the supplier side. In case of the project proposal containing hints at or even directly prescribing the use of COTS products, the customer can do a first rough market review based on the project proposal, even before the requirements specification is completed. The assessed results are to be used with the requirements specification subsequently. The market review can also be executed at a later date (repeatedly, if necessary) on basis of the requirements specification to assess whether and to what extent development work will be necessary or whether the system can be created by total or partial use of COTS products. The results of the market review produce important input values for the requirements assessment and thus provide the basis for a later decision on the use of COTS products. At an early stage, the overall system specification (requirements specification) done by the supplier will be used as a basis. These requirements are used as criteria for searching and evaluating finished products. If external units have already been identified in the system architecture, the specification of external units provides the information required for the market review. The search for and assessment of COTS products is mainly based on the contents of the requirements specification. Thus, the market survey is basis and decision-making aid for the Make-or-Buy Decision. The results of the market survey are integrated directly into the decision-making process.

47

•

Process module FP: o

o

Addition of attribute ‘can base on: process module requirements definition’ Change of attribute ‘based on’ to ‘can base on: process module

system specification’ o

Addition of attribute ‘selection criterion: customer: value’

o

Text process module: The process module evaluation of finished products includes a procedure for the market survey and technical evaluation of possible candidates for finished products for the system to be developed or for the support systems required for developing, testing or operating the system. Finished products are completed products or components which may be used as system elements, e.g. software units, hardware units or segments. Examples for finished products include the following: • COTS products, e.g. purchased application software or library programs, test monitors, operating systems, compiler, tools or finished hardware, e.g. processors • Usable software or hardware which was developed within the same company but not with the scope of the current project • Updatable releases of open source products The market review for finished products provides both the requirements analyst as well as the system architect with a survey on the finished products available on the market. The evaluation of finished products evaluates in how far the different finished products fulfil the requirements and if additional adaptations are necessary. Usually there is a discrepancy between the requirements and the actual characteristics of the COTS products. Either they do not fulfil the requirements entirely or they surpass the requirements with their scope of functionalities. In either case there must be an assessment on the necessary adaptations of the requirements specification. The selection of a finished product or the deliberate decision against using finished products depends on the relation between price, performance and effort required for the adaptation. The results of the assessment will be documented in the requirements assessment on the customer side or within the theme evaluation of finished products, contributed to the make-or-buy decision, on the supplier side.

48

The integration into the system to be developed poses a particular difficulty when using finished products. Therefore, it is necessary to select the finished products to be integrated as early as possible. The process module evaluation of finished products supports the following approaches:

• On the customer side the requirements analyst (AG) can initiate and execute a market review of finished products either based on the project proposal or on the rough system architecture sketch done within the requirements specification. This leads to an evaluation within the subsequent requirements assessment, whether and which COTS products could be used. These evaluation results are worked into the requirements specification and decide on the whole system’s nature: the project can be




a system development project a procurement project a mix of both project forms with development and procurement parts.

• On the supplier side candidates for finished products, which were selected based on a market review for finished products, are proposed to the system architect at an early stage of the system architecture development. This market survey is based on the overall system specification (requirements specification) and system architecture design. Based on the results, a further development of the system architecture is possible. … (Further text remains unchanged) o

Product ‘Market review of COTS products’: Rename product to ‘Market review of COTS products (AN)’ (supplier side) Bind in text module (s.a.)

o

New product ‘Market review of COTS products (AG)’ (customer side) Responsible role: requirements analyst (AG) Product group: requirements and analysis Bind in text module (s.a.) Initial product: no External product: no Product sample: yes

o

Generating product dependencies (ePAH): New ePAH ‘Carrying out a market review of COTS products’

49

Text: A market review of COTS products is to be carried out whenever it becomes obvious within the project proposal or during the creation of the requirements specification that the procurement and subsequent use of COTS products could be possible and advisable. The assessed results are to be used with the requirements specification subsequently. From products project proposal and requirements specification to product market review of COTS products o

Factual product dependencies (iPAH): Additional iPAH ‘Consideration of the results of a market review of COTS products’ Broadens the iPAH ‘Assessment of requirements’ (process module ANFE) Products: market review of COTS products (AG)

o

Activities: •

‘Conducting a market review of COTS products (AN)’: Text: When performing the market review for COTS products information(AN) has to be collected about various finished products and then prepared for further use. In a supplier project this is based on the overall system specification (requirements specification), a draft of the system architecture or the specification of an external unit. These specifications contain requirements of the respective typical degree of detail. For obtaining the information the following steps are necessary: • From the requirements criteria have to be derived for searching for and rating COTS products. • A candidate list has to be drawn up. • For all COTS products found and included in the candidate list summaries have to be prepared. • It has to be noted where additional information, such as product sheets, product specifications and performance characteristics, are filed or can be found. The results are to be provided to the process module

system specification. •

Add method reference ‘evaluation methods’

50

•

‘Conducting a market review of COTS products (AG)’: Text: When performing the market review for COTS products information (AG) has to be collected about various finished products and then prepared for further use. In a customer project this is based on the project proposal or the requirements specification (combined with the rough system architecture sketch), depending on the stage of the project. For obtaining the information the following steps are necessary: • From the requirements criteria have to be derived for searching for and rating COTS products. • A candidate list has to be drawn up. • For all COTS products found and included in the candidate list summaries have to be prepared. • It has to be noted where additional information, such as product sheets, product specifications and performance characteristics, are filed or can be found. The results are relevant for the process module requirements definition.

•

•

Add method reference ‘evaluation methods’

Process module ANFE: o

Change of role requirements analyst (AG): After receiving the statement of work, the requirements analyst (AG) will be responsible for the preparation of the products requirements specification and requirements assessment. If appropriate he additionally conducts a market review of COTS products. The results are evaluated within the requirements assessment and implemented accordingly, analogue to a make-or-buy decision. He has to ensure the quality of the requirements and create the prerequisites for tracking the requirements during the entire life cycle. The requirements analyst (AG) shall observe the fundamentals of the special fields of requirements engineering and procurement planning when fulfilling his tasks.

51

•

Change in text paragraph ‘tasks and authorisation’:

… • Knowledge and experience in the areas of requirements engineering (requirements specification and requirements management) and procurement planning, … o New tailoring product dependency (tPAH) ‘optional procurement of COTS products’ Text: A market review of COTS products is to be carried out whenever it becomes obvious within the project proposal or during the creation of the requirements specification that it is not necessary to develop all parts of the project, but instead the procurement and subsequent use of COTS products could be possible and advisable. From product requirements specification to product project hand book

o

New tailoring product dependency (tPAH) ‘procurement of COTS products’ Text: A market review of COTS products is to be carried out in case of the project proposal endorsing or prescribing to use COTS products in the project. From product project proposal to product project hand book

o

New factual product dependency (iPAH) ‘consideration of the results of a market review of COTS products’ Text: When a market review of COTS products was conducted, the results have to be worked into and considered within the requirements assessment. From product market review for COTS products (AG) to product

requirements assessment o

Product requirements assessment: Change of text: … The product requirements assessment documents the evaluation results for the user requirements collected until that time. The requirements assessment is hardly possible unless an outline of the life cycle and the overall system architecture or an overall system architecture have been prepared, i.e. there are already possible

52

approaches. An evaluation of COTS products can be useful in this context. …

o

Theme outline of life cycle and overall system architecture within product requirements specification: The specification of user requirements without consideration of possible solutions entails the great risk of defining unrealistic user requirements. It is useful to specify a coordination frame for the integration, systematization, categorization and prioritization of user requirements, in order to facilitate their visualization. This may be achieved by an overall system architecture which represents the point of view of the user and not the technical point of view of the system analyst or System Architect . This means a functional system architecture embedded in the functional flow of adjacent systems should be prepared. At this early stage, it is hardly possible to develop a technical system architecture. In case of a market review of COTS products having been done the future system components should be identified and written down within the overall system architecture when the requirements specification is adjusted. …

o

Activity do requirements assessment: Add method reference evaluation methods

o

Activity components: •

Activity component draw up evaluation criteria: Text changes: … 10. Possible savings through usage of COTS products. … To reach relevant results with the evaluation of COTS products it can be useful to use weighted evaluation methods such as WSM (weighted scoring model) or AHP (analytic hierarchy process). There should always be the awareness in this context that this formal framework should neither lead to excessive budget expenditures nor should the methodology anticipate or prefers predestined solutions. …

53

•

Activity component evaluate requirements: Text:

The requirements have to be evaluated on the basis of the evaluation criteria developed before. Together with the authors of the requirements specification and supported by experts for system architecture and system design the requirements analyst (AG) performs the following work steps: Analysis of Operational Necessity The stakeholders review the operational necessity of individual requirements. Both the non-functional and the functional requirements have to be reviewed. As a result of the review there are candidates for requirements that are not classified as operational. How relevant the requirements are has to be discussed in each case by the stakeholders. In this process risks and system safety and security aspects of the individual requirements have to be weighed, roughly estimated and possibly reclassified with regard to their importance. It may also be necessary to check to what extent individual requirements can be dropped by merging them with others. Should there be no agreement on the necessity of individual requirements when evaluating the various requirements, the requirements analyst (AG) has to prepare a proposal for the decision maker. Analysis of Technical Feasibility Is the necessity of the requirements specified, the requirements have to be checked for their technical feasibility. When doing this, it is recommended to fall back on rough sketches of technical solutions concerning the realisation of the functional and non-functional requirements. The result is documented in the outline of the life cycle and the overall system architecture. Should the customer be unable to perform this task, the requirements analyst (AG) has to take care that an this is done instead by experts. This outline ("rough system architecture"), where the requirements are already assigned to the respective elements of the architecture, is a valuable basis for describing possibilities for technical solutions. The demand for cost effectiveness and assessable usage of resources for the solution to be procured makes it necessary to evaluate finished products at this point. As practice shows, more and more frequently there is know how on technical solutions available at the customer side as well. In many cases this is already 54

part of the customer role, especially in the case of IT organisation units that have to handle the project for a department. The necessary data is delivered by the market review of COTS products. The structure of the future project can be defined by using predefined weighting evaluation methods. This is analogue to the qualified make-or-buy decision on the supplier side. All results of the technical feasibility studies have to be unambiguously related to the functional and nonfunctional requirements. It is especially important that already at this point a possible use of finished products is evaluated. The approach that is used should be analogous to the activity component evaluating COTS products. Checking the Cost-effectiveness and Affordability of the Requirements …

•

Activity component integrate evaluation results: Text changes: The customer has to document the result of the evaluation of the user requirements in the product requirements assessment and to make it available to all roles participating in the evaluation process. Subsequently the evaluation results have to be integrated in the product requirements specification by changing and supplementing the requirements concerned. The requirements analyst (AG) has to take care that the results achieved in the evaluation process can be understood and reconstructed also by persons not involved in the activity. The resulting consequences for the project can be interpreted in different ways. One option is to not integrate the results into the submission, because the customer awaits from the industry to offer innovative and cost effective solution proposals. The other option is the usage of the results within the definition of the scope of delivery for the later design of the submission concept.

•

Activity component draw up outline of the life cycle and the overall system architecture:

55

Additional text: … The requirements areas that have been found suitable by market review and assessment are identified as potential project components after completion of the requirements assessment.

•

Process module system specification (SE): o

Activity produce make or buy-decision:


•

Process module ordering, project support and delivery acceptance: o

Activitycreate criteria catalogue for offer evaluation::


•

Add method reference evaluation methods

Add method reference evaluation methods

Method references: o

Additional chapter ‘evaluation methods’: This is a short version of the literature survey done on transaction cost analysis, WSM and AHP as described on pages 9 – 13.

•

Sources:

o

Wil75 O.E. Williamson: Markets and Hierarchies, Free Press New York 1975

o

Wan02 E.T.G Wang: Transaction attributes and software outsourcing success: an empirical investigation of transaction cost theory, Info Systems Journal 2002, (12) 153-181

o

Schw04 Kathy Schwalbe: Information Technology Project Management, Thomson, 3. Aufl. 2004

o

Kon96 Jyrki Kontio: A Case Study in Applying a Systematic Method for COTS Selection, Proceedings of ICSE-18 (1996), 201-209

56

o

PD99 Jose M. Padillo, Moustapha Diaby: A multiple-criteria decision methodology for the make-or-buy problem, International Journal of Production Research, 1999, 37(14), 3203-3229

o

LMTC01 Patricia Lawlis, Kathryn Mark, Deborah Thomas, Terry Courtheyn: A Formal Process for Evaluating COTS-Software Products, Computer, (May 2001), 5863

o

AF02 Carina Alves, Anthony Finkelstein: Challenges in COTS Decision-Making: A Goal-Driven Requirements Engineering Perspective, Proceedings of SEKE 2002, 789 – 794

57