NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET HOVEDOPPGAVE

Transcription

1 NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET FAKULTET FOR INFORMASJONSTEKNOLOGI, MATEMATIKK OG ELEKTROTEKNIKK HOVEDOPPGAVE Kandidatens navn: Joachim Lund Fag: Systemutvikling, Datateknikk Oppgavens tittel (norsk): Konfigurering av Prosessmodeller Oppgavens tittel (engelsk): Customization of Process Models Oppgavens tekst: This thesis aims at developing documentation for customization of ConsultIT s process model based on the properties of projects. To support the development of this documentation it aims to investigate the current process model, and how it is used within the company. Informal interviews and a survey can be conducted to achieve this. The development of the documentation for customization is concerned with three main objectives: The first is a study of existing material on general adjustments to a process model. The second objective is to suggest project properties to evaluate when customizing. The third is to suggest variations in a process model due to the value of these properties. Oppgaven gitt: 27. januar 2003 Besvarelsen leveres innen: 23. juni 2003 Besvarelsen levert: 23. juni 2003 Utført ved: NTNU, Gløshaugen, Trondheim / ConsultIT, Trondheim Veileder: Reidar Conradi Trondheim, 23. juni 2003 Faglærer Reidar Conradi

2

3 Abstract Background: ConsultIT has today an own framework for project execution based upon the Rational Unified Process (RUP) from Rational Software. Currently we have customized the framework to some extent, but we are seeking deeper customization and to develop concrete process configurations adjusted to our types of project. To be able to customize we search to identify project properties that are of importance to the activities used in the project process and develop different development cases based on these properties. Thesis objectives: The objective of this thesis is exploration of the domain of project properties that should affect the configuration of a system engineering process. Within the word exploration, lies in this context identification, grouping and examination of the effects. As these properties are to be used as basis for the tailoring of process models in ConsultIT, the thesis aims to propose changes to a RUP based development framework based on the values of these properties. The objectives can be summarized as follows: 1) To study the state-of-the-art of process models in general and process model customization in specific. 2) To explore the current status on development in ConsultIT and the staff s attitude versus a process model based on customization. 3) To identify and explore important project properties and their impact on the engineering process. 4) To suggest changes to a RUP based process model with background in the properties from 3). In retrospect: All the objectives have been reached. Objective 2) has been reached through a survey. Although not statistically valid due to a low sample, the survey provided useful indications for the rest off the work in the thesis and for further improvement in ConsultIT. The work on 3) and 4) have produced initial suggestions that have been improved through a small and simple case study indicating improvements and further work. Master Thesis - I - Spring 2003

4 Master Thesis - II - Spring 2003

5 Preface This Master Thesis is the final part of my Master of Computer Science study at Norwe gian University of Science and Technology (NTNU). The main part of the thesis focuses on how we can and should customize the used process model according to the properties of a given project. ConsultIT s urge to explore this area has been the background for the thesis and I have tried to capture general results with specific appliance to ConsultIT. I would especially like to thank my external advisor at ConsultIT, Frode Stortiseth and my head supervisor at NTNU, Professor Reidar Conradi for help and advic es through the production of this thesis. In addition, I would like to thank Bjørn Bjanger at ConsultIT, for stepping in for Frode, providing valuable suggestions to the last parts of the thesis. I would also like to thank Hans Jørgen Grimstad from Consu ltit, for giving some very concrete feedback in the last phase, as well as Rolf Nergaard for providing input on project management in ConsultIT. Trondheim, June 23 rd, Joachim Lund Master Thesis - III - Spring 2003

6 Master Thesis - IV - Spring 2003

7 Table of contents Abstract... I Preface...III Chapter 1. Introduction Motivation Thesis Context Thesis structure Reading guide...5 Chapter 2. Background Process models Fundamentals of development processes Lifecycle models Process Improvement Summary...22 Chapter 3. Background - The Rational Unified Process The Rational Unified Process Introduction Development cases Tailoring the RUP Summary and indications to further work...38 Chapter 4. Background - Project properties Problem How do we customize? Identifying properties Remaining work...46 Chapter 5. Context - ConsultIT General guidelines and overview Project execution The ConsultIT Unified Process Challenges and areas of i mprovements...54 Chapter 6. Research agenda Research problem Research methods...59 Chapter 7. Survey of process models in ConsultIT Survey execution Questions about process models Questions about support in the process models Questions about process configuration Questions about the CUP Evaluation of the hypotheses Evaluation of validity Conclusion and further work in the thesis...76 Chapter 8. Project properties Identifying dimensions Project Context Application Domain Criticality Exploration and Creativity Summary of chapter Master Thesis - V - Spring 2003

8 Chapter 9. Influence in the RUP Using the model Disciplines Summary of chapter Chapter 10. Case study - Development case Case study description Work method for development case Proposal to development case Execution of the project Evaluation of proposed development case Chapter 11. Evaluation of Case study Case study validity Discussion of project model Discussion of proposed changes to process model Changes and proposals to process components Chapter 12. Conclusion and further work Bibliography Appendices: Appendix A: Key Process Areas in CMM Appendix B: Software Engineering Techniques Appendix C: Example Development Case [Rup02] Appendix D: Workflows and activities from CUP [Cit 1] Appendix E: Questionnaire Master Thesis - VI - Spring 2003

9 List of figures Figure 1.1 Relationship between various stages of process models...2 Figure 2.1 Workflow expressed with activity diagram [Rup02]...10 Figure 2.2 The Waterfall process [Roy70]...12 Figure 2.3 Iterative development cycle...13 Figure 2.4 The Deming Cycle (PDCA cycle)...17 Figure 2.5 QIP Project organization [Bas93][Sør97]...21 Figure 3.1 The RUP Phases and Disciplines [Rup02]...28 Figure 3.2 The RUP Phases and Milestones [Rup02]...30 Figure 3.3 Organization specific customization...35 Figure 3.4 Project specific customization...36 Figure 3.5 Screenshot from RUP Builder...38 Figure 4.1 Customizations and updates to the RUP Framework...41 Figure 4.2 Relation between control elements and numbers of people involved [Coc97]...44 Figure 6.1 Work agenda for Area 2 and Figure 9.1 Requirements workflow [Rup02] Figure 9.2 A and D workflow [Cit 1] Figure 9.3 Implementation workflow [Rup02] Figure 9.4 Deployment workflow[rup02] Figure A 1 Sales workflow from the CUP Figure A 2 Workflow from the Project Management discipline of the CUP Master Thesis - VII - Spring 2003

10 List of tables Table 2.1CMM maturity levels...18 Table 4.1 Roadmap to support customization of processes...42 Table 5.1 Actions for improvement for ConsultIT...55 Table 8.1 Properties to consider regarding Project Context...85 Table 8.2 Software types...86 Table 8.3 Success factors for CIS [Jon00]...87 Table 8.4 Success factors for Systems Software [Jon00]...89 Table 8.5 Success factors for Commercial Software [Jon00]...91 Table 8.6 Success factor of End User software...93 Table 8.7 Properties to consider in the Application Domain...95 Table 8.8 Properties to consider in the Criticality Dimension...99 Table 8.9 Properties to consider regarding Exploration and Creativity Table 9.1 Impact from the dimensions on the Requirements discipline Table 9.2 Elements to alter in the Requirements discipline Table 9.3 Impact from the dimensions on the Business Modeling discipline Table 9.4 Impact from the dimensions on the Analys is and Design discipline Table 9.5 Elements to alter in the Analysis and Design discipline Table 9.6 Impact from the dimensi ons on the Implementation discipline Table 9.7 Elements to alter in the Implementation discipline Table 9.8 Impact from the dimensions on the Test discipline Table 9.9 Elements to alter in the Test discipline Table 9.10 Impact from the dimensions o n the Deployment discipline Table 9.11 Elements to alter in the Deployment discipline Table 9.12 Impact from the four dimen sions on the Environment discipline Table 9.13 Elements to alter in the Environment discipline Table 9.14 Impact from the d imensions on the Configuration Management discipline Table 9.15 Elements to alter in the CCM discipline Table 9.16 Impact from the dimensions on the Project Management discipline Table 9.17 Elements to alter in the Project Management discipline Table 10.1 Project properties Table 11.1 Frequency of used properties in development case Table A 1 Key Process Areas for CMM Levels Table A 2 Activities in Requirements in the CUP Table A 3 Activities in A&D in the CUP Master Thesis - VIII - Spring 2003

11 Chapter 1. Introduction 1.1. Motivation - If you believe that one size fits all, you are living in a panty-hose commercial. P.J. Plauger Computer Language Magazine [Pla93] Software projects have for long suffered from high costs, delays and high failure rates. Although there has been an improvement the last years, still there are a large number of projects that suffer from cost overrun and time overrun [Rub03]. In order to address these issues it is natural to investigate the process used in software projects. Adapting a definition of process from Ian Sommerville s book Software Engineering [Som95] a software process is A set of activities and associated results that leads to the production of Software products. To investigate and discuss software processes we use process models. A process model is an abstract representation of the software process [Som95]. Process improvement assesses the process model and aims to improve it, assuming that this in turn will lead to a better process. There are a variety of topics regarding process improvement, and this thesis will have focus on one in particular: Customization of the process model. A process model could exist in various stages. It could initially be quite generic, having a universal core. Then it could emphasize further customization into more suited stages dependent on the development organization and the type of project. This thesis will have a special focus on customization based type of project. The working theory for this thesis is that the properties of a project should dictate customization of the project s process model. This customization should support that the process is optimized according to the properties of the project. Master Thesis Spring 2003

12 An important factor for companies and developers today is to reduce the time to market when developing software systems. Our goal is documentation of advices and suggestions for customization to support project managers when configuring the final process model. This documentation should be developed in advance of a project and have general appliance in order to be useful to several projects. Hopefully existence of such documentation will reduce the start-up time and also contribute to better customized processes. Predefinition of a process model, involves that the model is tailored in advance of projects to fit general project properties. This is a variant of such documentation. An example is a predefined process model, for small projects. Another variant is smaller process components that contain information of how to tailor a specific part of a process model with background in certain properties. A project manager might then add such components to the process model to better adjust it to the specific project. The relationship between the various stages of process models shown in Figure 1.1 Figure 1.1 Relationship between various stages of process models Master Thesis Spring 2003

13 1.2. Thesis Context This thesis is written at the Norwegian University of Science and Technology, Faculty of Information Technology, Mathematics and Electrical Engineering. The thesis will be done in cooperation with ConsultIT in Trondheim. ConsultIT is a consulting company which uses Rational Unified Process (RUP) as the framework 1 for project execution. The company s desire to explore project properties of importance for their process models has been the background of the thesis. ConsultIT has adjusted the RUP to fit to their organization, as described in 3.3. The list represents the final objectives of this thesis: 1) To study the state-of-the-art of process models in general and process model customization in specific. 2) To explore the current status on development in ConsultIT and the staff s attitude versus a process model based on customization. 3) To identify and explore important project properties and their impact on the engineering process. 4) To suggest changes to a RUP based process model with background in the properties from 3). This thesis is focused on iterative, use case based development with references to the Rational Unified Process. As the thesis will propose project properties as factors for customizing a process model, it will not focus very much on exploration of organization-based customization. 1 In this thesis a development framework could be described as a process model and the mechanisms for support of the execution of this model. Those mechanisms could include documentation, tool support, experience capturing, examples and guidelines. Master Thesis Spring 2003

14 1.3. Thesis structure The thesis is structured as follows: o Background Development processes This is the first part of the literature study, including process models basics and overview of work related to process improvement. o Background The Rational Unified Process This is the second part of the literature study, providing an overview of the Rational Unified Process. o Background Project properties This is the third part of the literature study, providing an overview of the work and suggestions in the field of extracting properties of importance for a project. o Context - ConsultIT This chapter contains a description of development in ConsultIT together with challenges and areas of improvement. o Research agenda This chapter describes the problems to be solved. o Survey of process models in ConsultIT This chapter describes the survey conducted in ConsultIT o Project properties This chapter describes my proposed project model for further study and discussion. It also contains a discussion concerning the effects of the different project properties. o Influence in the RUP This chapter sums up the effects of the properties explored in the previous chapter and evaluates means of handling them within the RUP. o Case study - Development case This chapter shows how the results from the two previous chapters were applied to configure a process model for a real project in ConsultIT. o Evaluation of case study In this chapter the results from the case study is evaluated and further work suggested. o Conclusion and further works o Bibliography o Appendices Master Thesis Spring 2003

15 1.4. Reading guide This thesis can be read in several ways: Chapter 2 provides an overview of fundamental concepts of development processes and process models. Experienced readers could skip this part. However, the chapter discusses several paradigms for process improvement that are used later in the thesis. Chapter 3 provides an overview of the Rational Unified Process. Users with experience from this development framework could skip the first part but should read subchapter 3.2. Chapter 4 is very relevant and should not be skipped as it draws the red line for the rest of the thesis. Readers familiar with ConsultIT and the CUP could skip the first three subchapters of chapter 5 but should in all cases, read the last one. The rest of the thesis should not be left out as it presents the given contribution. First the research agenda and methods are presented. Then the results from the survey are presented in chapter 7. The project model proposed in chapter 8 is relevant for the rest of the work in the thesis, as it provides a frame for discussion and exploration. In chapter 8 general changes to a process model are discussed, while chapter 9 suggests changes that could be executed to a RUP process. These parts should be regarded documentation for customization of a process model. The case study and results discussed in chapter 10 and 11 updates the results from the previous chapters. Master Thesis Spring 2003

16 Master Thesis Spring 2003

17 Chapter 2. Background Process models This chapter contains: o Overview of process models fundamentals o Approaches to process improvement This thesis is a part of ConsultIT s project versus process improvement. As customization is an important element of such improvement, the thesis started with an initial study of processes and improvement paradigms. This study provided a fine and useful fundament for further studies and evolvement. This chapter deals with three topics. First, it will provide an overview of the fundamental activities of a process model and the different schools of timing for carrying out those activities. Then it will address approaches to process improvement. Master Thesis Spring 2003

18 2.1. Fundamentals of development processes In order to discuss development processes and process models, it would be appropriate to define similarities and taxonomy Common factors Although development processes differs in several dimensions there are some factors that are common to all of them. These four fundamental process actions should be addressed in all development processes [Som95]: o Software Specification o Definition of functionality and scope of operation. o Software Development o Production of the software. o Software Validation o Validation versus the customers needs. o Software Evolution o Further evolution to meet changing needs Taxonomy Different process models decompose these actions in different ways. They emphasize different factors and the timing of the accomplishment of these activities differs. In order to understand processes we need taxonomy for description: Process models A process model is a description of how to execute the development process. Process models vary in formality and detail level. Some processes just briefly describes the actions of the process, while other contains detailed and formal descriptions To be able to define and describe the actions of a process model, we need four key concepts; Roles, Activities, Artifacts and Workflows. Master Thesis Spring 2003

19 Roles A role is a definition of the behavior and responsibilities of an individual, or a team of individuals in a software engineering organization. Connected to a role is a certain type of artifact. If an individual possesses a role, the individual is responsible for the production of the connected artifacts. It is common that an individual possesses several different roles. Example of a role: System Analyst: A system analyst leads and coordinates requirements elicitation and use case modeling by outlining the system's functionality and delimiting the system. For example, establish what actors and use cases exist, and how they interact. Activities An activity of a specific role describes the unit of work which an individual in that role may perform. Activities are meant to be units of planning and progress. For that reason they should neither be too small, nor too large to be used as a meaningful unit. Example of an activity: Find use cases and actors: Performed by the System Analyst Artifacts Artifacts are the intermediate and finished products of a project. They are used as input to and output from activities. A common-language description of most artifacts would be deliverables. Note that an artifact could consist of other artifacts. Examples of artifacts: o A model, such as the use case model o Source code o Executables Workflows A workflow is a sequence of activities that produces an observable result. A workflow is often expressed as a type of activity diagram. The purpose of a workflow is to describe important sequences of activities and also interaction between roles. The Master Thesis Spring 2003

20 workflows are utterly broken down in workflow details to provide more detailed information about groupings of activities that are performed together. Figure 2.1 shows the workflow of requirements elicitation in the RUP. Figure 2.1 Workflow expressed with activity diagram [Rup02] So far we have presented taxonomy for describing the activities of a process model. A model that describes how the process model schedules its activities is referred to as a lifecycle model. In subchapter 2.2 two fundamental lifecycle models will be described. Master Thesis Spring 2003

21 2.2. Lifecycle models Although process models vary in detail and formality they often have a fundamental description of the high level stages a development team goes through. Such description is here referred to as a lifecycle model Simply spoken there are two fundamentally different lifecycle model types; sequential models and evolutionary models. Sequential models are here described through the waterfall approach, while the iterative approach represents the aspects of evolutionary modeling The sequential Model - The Waterfall approach Early approaches suggested performing the development activities in sequence [Roy70]. Most software development projects followed a classical sequential lifecycle model, also called the waterfall life cycle. The project is broken down into phases, each formed by a single and homogeneous type of activity. The model emphasized that the next phase should be started when the former is completed and approved, meaning that one activity type should be performed at a time, following a preset order. Actually this is more a principal demand than a practical one. The approach emphasizes to complete and approve phases before moving on to the next one, but often the need to go back is unavoidable. As a result of this, the waterfall model can best be described as in Figure 2.2 with flows going back to earlier phases. The model consists of five different activity types, planning, design, implementation, integration and maintenance. Planning is similar to Sommerville s specification while design and implementation goes under development. Integration and testing goes under validation while evolution corresponds to maintenance. 2 For further reading on more specialized models please refer to [Som95] Master Thesis Spring 2003

22 Figure 2.2 The Waterfall process [Roy70] The waterfall approach emphasizes several good practices, among them focus on planning and a structured and controlled development process. However, the problem with the approach is that its perception on how things should be does not always correspond to the challenges of real life. If the problem domain is complex enough it is not possible to extract the actual requirements once and forever at the beginning of the planning phase. The model s lack of capability to adjust to changing requirements is a great disadvantage. Nor is it always possible to establish the design of a product without extensive prototyping and testing. Many problems are of such nature that the design overlaps with, and influences on the requirements. With such problems, new requirements emerge out of the design decisions, making it impossible to create a clean separation between requirements and design [McB02]. Another problem is the use of a possible complex project team. While the requirements analyst does his job, the system designer has to sit put waiting for the requirements analyst to complete the requirement list. Of course it is possible for several people to play different roles, but as long as there are overlapping activities it would be more effective to explore several activities at the same time. Master Thesis Spring 2003

23 The last and perhaps most obvious lack of usability of this model, comes with the identification of risks. As the coding and testing are delayed in the waterfall method, the detection of risks may also be delayed. The reason for this is that a lot of risks are more easily detected under coding and testing, and may demand large resources to be detected under a theoretical analysis, if it is possible at all. Delaying risks makes it more costly and sometimes impossible to face them and to neutralize their consequences The Evolutionary Model The Iterative approach The Iterative approach combines elements from the waterfall approach with the explorative and iterative nature of evolutionary prototyping. Evolutionary prototyping is based on developing an initial implementation, and through user input, evolve this through many versions until an adequate system has been developed. Prototyping is described further in [Som95]. Figure 2.3 shows the lifecycle model for the iterative approach. Figure 2.3 Iterative development cycle This approach is built upon Boehm s spiral model [Boe88], [Som95] which in the original form consisted of four phases; planning, risk analysis, engineering and evaluation. The basic concept is to split the development into several cycles or iterations. Further on, we go through the important phases from the waterfall or similar approaches in each of these cycles. The first iteration addresses the most important features of the product, but leaves supplementary features for later iterations. Each iteration ends with a planning of the next Master Thesis Spring 2003

24 iteration whose purpose is to implement more features to the current product in order to better fit the specifications of the customer. The process is repeated until the complete software is finished Comparison Compared to the traditional waterfall approach the iterative process offers several advantages [Kru 1]: 1. Serious misunderstandings are made evident early in the lifecycle, when it is possible and effective to react to them. 2. It enables and encourages user feedback, to explore the system s real requirements. 3. The development team can focus on the most critical objectives first, leaving noncritical features for later. 4. Continuous, iterative testing enables an objective feedback of the project's status. 5. Inconsistencies among requirements, designs, and implementations are detected early. 6. The workload of the team is spread out more evenly throughout the lifecycle. 7. This approach enables the team to leverage lessons learned, and therefore to continuously improve the process. 8. Stakeholders may continually supervise with the project's status throughout the lifecycle. However the use of an iterative process adds complexity for the development team. Effort has to be spent planning the iterations, extracting the most critical features and handling risks to achieve that the product converges against a final release. Although the process assumes that requirements do change, it is still a complex task to achieve that the project team members are able to handle changes in the requirements. The evolutionary models clearly contribute to overhead and for small and simple projects working in iterations might be overkill. Sometimes it clearly is possible to provide a useful requirement specification, outline the design of the system and implement and deploy with success in one iteration, or with minor repeating of activities. A development team working on different projects with variable domains, magnitude and tasks should however, implement the concepts of an iterative development cycle to better Master Thesis Spring 2003

25 cope with changing requirements, continual update, progress measurement and complex tasks. There might be occasions where only one iteration is demanded, and then there is no need to use more. So far the thesis has established taxonomy, fundamental activities and differences in timing. In section 2.3 the thesis will examine the subject process improvement, trying to establish methods for improvement, measurements for quality and requirements for a good development process. Master Thesis Spring 2003

26 2.3. Process Improvement This section provides a brief overview over central approaches for process improvement. The purpose is not to fully describe these methods, but rather to links their main ideologies and points to the topic of this thesis; customization of process models Total Quality Management Total Quality Management (TQM) is a paradigm that lies behind several standards and frameworks for quality improvement. Among those are the IS [Iso03], CMM (see 2.3.2) and Experience Factory (see 2.3.3). TQM is based on the philosophies of several authors. One of them is W. Edwards Deming. One of Deming s main philosophies was that that quality is not determined by the capabilities of the workers, but by the system of work that determines how work is performed. In other words, look at the process model to determine quality. In his book Out of the Crisis [Dem82], he lists 14 points for achieving quality management within an organization. Two of his fourteen points are: - Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs. - Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs. Constant evaluation and improvement of the production is regarded necessary for successful management. Thus developing organization needs to obtain some kind of mean of collecting and capturing knowledge and experiences for process improvement. Deming introduced the Deming cycle. The cycle emphasizes that business processes was placed in a continuous feedback loop. The purpose of the loop was continual identification and change of the parts that needed improvements. The cycle consists of four phases: Master Thesis Spring 2003

27 o Plan Design or reconsider business process to improve results o Do Implement the plan and measure its performance o Check Evaluate the measurements o Act Decide on changes to improve process performance Figure 2.4 The Deming Cycle (PDCA cycle) If organizations are to be effective using this improvement model, they need two things: 1) Knowledge of what measurable goals to aim for with the improvement 2) A mechanism for experience and feedback capturing. The TQM paradigm does not explicitly identify goals to aim for with improvement. In the next subchapter, a model that does, the CMM is reviewed. Master Thesis Spring 2003

28 SEI Capability Maturity Model for Software The Capability Maturity Model for Software (CMM or SW-CMM) from Software Engineering Institute [Sei03] is a reference model helping organizations to understand and improve their software processes. Improvement in CMM is based on a six step model, with clear relations to the Deming circle [Hum89]: 1) Understand the current status of the development process or processes. 2) Develop a vision of the desired process. 3) Establish a list of required process improvement actions in order of priority. 4) Produce a plan to accomplish the required actions. 5) Commit the resources to execute the plan. 6) Start over at step 1. CMM is very general and may be applied in a variety of situations for improvement. In order to support the improvement and help identifying goals in step 2, CMM has established a maturity model. This model characterizes processes in five different maturity levels. Table 2.1 shows the five levels, together with the characteristics of processes at each level: 1 Initial Process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort. 2 Repeatable Basic project management processes are established to track cost, schedule, and functionality. The necessary process model is in place to repeat earlier successes on projects with similar applications. 3 Defined The software process for both management and engineering activities is documented, standardized, and integrated into a standard process model for the organization. All projects use and follow an approved, tailored version of the organization's standard process model. 4 Managed Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled. 5 Optimizing Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies Table 2.1CMM maturity levels Master Thesis Spring 2003

29 In addition each level of the CMM defines a set of principles called Key Process Areas (KPAs). These KPAs describes the qualities an organization needs to stabilize, in order to get to the next level. The KPAs of CMM are listed in Appendix A. The TQM paradigm only described how an improvement process could be conducted without mentioning activities or goals to aim for. The CMM maturity levels together with the KPAs describe what activities to perform in order to improve the organizations capability to develop software. As we can see, defined, repeatable processes are of higher value than ad hoc processes where success is dependent on individual effort. The highest levels included empirical measuring of process quality and the use of these measurements for continually improvement of the process. At level 3 of the CMM, all projects use a tailored version of the organization's standard process model for development and maintenance of software. If we should put the work to be commenced in this thesis in relation to CMM, it would be natural to draw the link from that phrase. Different organizations apply different standard processes, which in turn should be tailored to fit the projects context. The next subchapter is concerned with the Experience Factory which visualizes how process models can be improved through use in regular project execution The Experience Factory The Experience Factory is a framework for quality improvement developed by the Software Engineering Laboratory (SEL) [Sel03]. SEL is a partnership between NASA Goddard Space Flight Center, the University of Maryland Department of Computer Science, and Computer Sciences Corporation. The latter is a contractor for the NASA and uses the EF in its development. The EF has been evolving since [Sør97] The EF focuses on organizational learning and capturing of experience as the main way to continually improve the process models. The EF is focused around the Quality Improvement Master Thesis Spring 2003

30 Paradigm (QIP). QIP is a paradigm that aims to improve quality in processes. It is concerned on using real-life projects as a mean of collecting knowledge for further model improvement. It can be truncated to six points that have similarities to the six points used as base in CMM and also to the Deming cycle. The six points of QIP are [Bas93] 1) Characterize the project and its environment Provide a project context in order to extract possible goals of improvement relevant to this context. The context may also be used to extract experience from similar projects that may be reused [Sør97]. 2) Set measurable goals Using Goal Question Metric 3 ; define quantitative goals of process improvement, relative to the context that one wishes to reach. 3) Choose process models Choose a model fitted or tailored to the project context and the goals. 4) Execute the process Accomplish the project, collecting data as an integrated part of the development process. 5) Analyze the data The data should be analyzed according to the goals. Data could be used to characterize and understand, evaluate and analyze, predict and control and to motivate and improve [Bas93] 6) Package the Models The experience gained should be used to create new or refine and improve existing models. The refined models should then be stored in the Experience Factory in such manner that is available for future use in similar contexts. The relationship between a projects desired organization and the Experience Factory is shown in Figure GQM is not described further in this thesis. For further reading see [Sel03] Master Thesis Spring 2003

31 Project organization Experience Factory Characterize Set Goals Choose Process Project/Environment Characteristics Tailorable goals, processes, tools, products. Etc. from similar projects Execution plans Execute process Data, lessons learned Project analysis, modification Figure 2.5 QIP Project organization [Bas93][Sør97] The desired process in ConsultIT, which is the background for this thesis, is a process similar to the one outlined with the six actions of QIP. The work to be commenced, aims to support the actions of 1) and 3) of these six actions. However, we cannot expect to provide perfect information to support these actions so we also want to make sure that the material can evolve. The concept of storing and evolving the knowledge, supplying with updates from new experiences is an appealing feature and the intention of the material developed later in this thesis. Master Thesis Spring 2003

32 2.4. Summary A development process is the actions and connected results that produce a product. All software development processes include the fundamental actions: specification, development, evaluation and evolution in some form. In order for us to describe a process we use a process model. Process models describe activities to be performed, roles which are responsible for the activity and the outcome of the activity (artifact). It also defines timing of the different activities and the relationship among them. The timing of the activities in a process model is described in a lifecycle model. There exist two fundamental models: the sequential and the evolutionary. A sequential model emphasizes to do the actions one at a time and in sequence, conducting the actions one time at each project. An evolutionary model emphasizes to split the development into several cycles. Each cycle contains one or more of the fundamental activities and aims at solving smaller part problems. More cycles are executed until the whole problem is solved. The sequential model provides less overhead, but has difficulties because it needs to provide an overview over the whole problem domain at once. The evolutionary is more focused on early risk detection and exploration and is most useful on projects on a certain magnitude and with a certain need of exploration during the different process actions. There are several approaches for process improvement. TQM describes a model for improvement of processes, using the Deming cycle. This approach does not specify what to aim for with the improvement. Hence organizations need to define their own goals. The SEI CMM on the other hand, specifies attributes for a mature development process, and could, as a result be used to define those goals if maturity equals quality. The SEI CMM also introduced the concept of customization of process models to fit to the project context, as an indicator of process quality. Master Thesis Spring 2003

33 The last approach for process improvement discussed is the Experience Factory. It focuses on how the process improvement should be an integrated part of project execution and how experiences should be used to improvement after execution. The next chapter is concerned with describing the Rational Unified Process and how project improvement may be commenced within that framework. It also describes how customization and storage of experience may be commenced. Master Thesis Spring 2003

34 Master Thesis Spring 2003

35 Chapter 3. Background - The Rational Unified Process This chapter contains: o Overview of the Rational Unified Process o Overview of customization approaches in the Rational Unified Process The RUP is the basis for the process model used in ConsultIT and this chapter aims to supply basic information about it. This entire chapter contains information taken from [Rup02] and [Kru00]. This chapter is divided into two parts. The first part introduces the RUP and provides overview of the RUP as framework for development and RUP based process models. The second part deals with customization of the RUP, describing development cases and process components. Master Thesis Spring 2003

36 3.1. The Rational Unified Process Introduction The RUP was developed by Rational Software in 1995 under the name Rational Objectory Process, but has since 1998 been marketed under the name Rational Unified Process [Kno00]. The Rational Unified Process (RUP) defines a process model. The model could be viewed as generic, as it emphasizes adding and extraction of elements as needed. It aims to provide guidelines for what tasks and responsibilities that are important in a developing organization. Though RUP is a process model it is marketed as a software product, shipped with a large directory of software development practices. These practices are developed by Rational, based on own experience and experiences from partners and users, and aims to capture the essence of best practices discovered and experienced in different projects over time. The collection of a process model, guidelines and best practices makes the RUP a development framework. From a product point-of-view, the RUP consists of a WEB application. This WEB gives a description of the framework as a web site, with templates for all important documentation. It also includes tool mentors, assisting with process guidance when working with Rational Software Engineering Framework As a framework the RUP is concentrated on six proven software development practices: 1) Develop iteratively 2) Model visually 3) Manage requirements 4) Control changes 5) Continuously verify quality 6) Use component-based architecture Together with the process description defining roles, activities and artifacts, this may be the framework for an organization wanting to define its own developing process. From this point Master Thesis Spring 2003

37 of view, a development process based on the RUP may be as formal or informal as the user wants. It may include guidelines or best practices from other methodologies as for example Extreme Programming [Nød02][Pol 1]. However as will be shown in the following chapters the RUP also provides guidelines regarding the lifecycle of a project and the techniques to be used Process Overview This subchapter provides an overview of the process model proposed in the Rational Unified Process. The RUP process model is a versatile one, meaning that it is highly customizable. The origin is a lifecycle divided into four sequential phases, each one concluded by a major milestone. Within the phases, development is meant to be carried out iteratively with step-wise progress. Hence the phases are further divided into iterations. When the evaluation criteria for passing the milestone at the end of a phase are fulfilled, the project can enter the next phase. Throughout the phases different activities are carried out. Activities related to each other and to a major 'area of concern' are organized in disciplines (see 3.1.3). Figure 3.1 shows the two-dimensional nature of the RUP. The horizontal axis represents time and shows the lifecycle aspects of the process while the vertical axis represents disciplines. The figure also gives a general overview of the intended workload within each discipline with respect to the phases. Master Thesis Spring 2003

38 Figure 3.1 The RUP Phases and Disciplines [Rup02] The RUP is meant to be configurable. Based on the nature of the project different activities will be prioritized, included and excluded. An application of the RUP adjusted for a certain project is called a Development case (see section 3.2) Disciplines The RUP groups related activities into disciplines and this sections aims to give a brief description of the concerns of the different disciplines. Business Modeling The purpose of the business modeling discipline is to explore and understand the organization in which the product is deployed. This is done in order to ensure working communication with stakeholders, foresee special events due to organization structure and possibly find improvements to their requests. Master Thesis Spring 2003

39 Requirements The focus of this discipline is to discover the actual requirements of the system, and to establish a common understanding between all stakeholders of these requirements. Further the discipline aims to explore the boundaries of the system and provide a basis for the further development. Analysis and Design This discipline aims to transform the requirements into the actual design of the system. While designing, developers should focus on a sound and effective architecture adjusted for the deployment environment. Implementation As the name suggests the discipline concerns the transformation from design into actual implementations. In addition the discipline also concerns unit testing of the components as well as integration of part systems into the main system. Test This discipline acts in many respects as a service provider to the other disciplines. Testing focuses primarily on the evaluation of quality realized through a number of core practices, like finding and documenting defects and validate assumptions through demonstrations. Deployment The Deployment discipline organizes the activities associated with ensuring that the software product is available to its end users. Although the deployment phase peak in the Transition phase some activities occur in earlier stages, as preparation to deployment. Configuration and Change Management This discipline concerns the controlling of changes to the projects produced artifacts. Master Thesis Spring 2003

40 Project Management The purpose of this discipline is to provide a framework for the project manager to the control and management of the project. It concerns activates like planning, staffing, progress monitoring and risk control. Environment This discipline includes the activities concerning making a process for the project. Its purpose is to provide the developing organization with the developing environment optimized for support to the development team Phases and Milestones lifecycle description The RUP emphasizes the need of assessing progress during development. The introduction of phases with concluding milestones aims to ensure that a goal is reached before moving to the next level. The development process proposed does indeed have sequential elements. However it brings in the positive flavors of sequential development; control and structure, and is more flexible in its organization than for example the waterfall model. It is flexible in the way that the phases of the RUP contain activities that build upon artifacts that are continually updated during all phases. Indeed the phases have some objective that has to be done before moving to the next phase. However the passing criteria are of such nature that they should be possible and meaningful to complete. They do not include finalization of overlapping activities as is the case in the waterfall approach. Figure 3.2 The RUP Phases and Milestones [Rup02] Master Thesis Spring 2003

41 The Inception phase The Inception phase is the initial phase in the RUP process. An important goal for this phase is to ensure that all stakeholders have a consistent perception of the life-cycle objectives for the project. It is essential to build this common platform before continuing the development. The second purpose is to establish whether the objectives are possible to fulfill to a reasonable cost, or if the project should be stopped. Important disciplines in this phase are Business modeling, to explore the context of the system, Project management, to identify threats to the project, and requirement analysis, to capture and establish a common agreement of the stakeholders demands to the system. The first major milestone is at the end of the Inception phase. This milestone is the life-cycle objective milestone. The evaluation criteria for passing this milestone are: o Stakeholder concurrence on scope definition and cost/schedule estimates o Agreement that the right set of requirements have been captured and that there is a shared understanding of these requirements. o Agreement that the cost/schedule estimates, priorities, risks, and development process are appropriate. o All risks have been identified and a mitigation strategy exists for each. The project can be aborted or rethought if it fails this milestone. The Elaboration phase The focus of this phase is to further analyze the problem domain and establish a valid architectural foundation while continuously eliminating risk elements. An important goal is to establish an architecture that matches the identified demands of the stakeholders. Master Thesis Spring 2003