Relating Problem Oriented Engineering to Current Development Processes: a Research Agenda Dariusz W. Kaminski
Jon G. Hall
Michel Wermelinger
Centre for Research in Computing The Open University, UK
Centre for Research in Computing The Open University, UK
Centre for Research in Computing The Open University, UK
[email protected] [email protected] ABSTRACT
[email protected]
1. INTRODUCTION
By software design (shortly, design), we refer to the creative, iterative and often open-ended process of conceiving and developing software systems. Design processes by necessity include the identification and clarification of requirements, the understanding and structuring of the context into which the software system will be deployed, the specification of a design for the software that can ensure satisfaction of the requirements in context, and the construction of arguments, convincing for all validating stakeholders, that the engineered system will provide the functionality and qualities that are needed. Software design therefore spans all activities from requirements (or goals) to code. Software processes used in industry vary enormously, but can be placed within a ‘process development continuum’ with agile approaches on one side and plan-driven on the other [2]. Many of these processes focus on the software solution space, to the detriment of problem analysis. Not staying long enough in the problem space in order to understand the real world problem to be solved has been observed by many as one reason why software development undertakings can fail [6]. Problem Frames provide a problem space focus for software developers and specifically encourage them to remain in the problem space for as long as is necessary for problem Categories and Subject Descriptors understanding. To problem frames, the Problem Oriented D.2.1 [Software Engineering]: Requirements/Specifications— Software Engineering (POSE) approach ([5]), adds iteration Methodologies; D.2.2 [Software Engineering]: Design Tools between problem and solution so that realistic software deand Techniques—Object-oriented design methods sign process can be modelled. This research proposes the capture of modern object oriented processes in POSE, with the intent of bringing modern software development proGeneral Terms cesses within a problem oriented framework with two goals: Design, Documentation, Management 1) so that POSE can be related to such processes; 2) so that such processes can be related to other techniques found in POSE, i.e., those that exist in the problem space. Keywords Moreover, as POSE is currently being generalised to enProblem Oriented Software Engineering (POSE), Objectcompass other engineering design disciplines, such as orOriented Analysis and Design (OOAD) ganisational engineering, in Problem Oriented Engineering (POE) [4], we hope that modern software development will, through its embedding in POSE, be available to those who design socio-technical systems. Various technology-centric undertakings exist that address the transition from requirePermission to make digital or hard copies of all or part of this work for ments to design in solving a software problem, e.g., Objectpersonal or classroom use is granted without fee provided that copies are Oriented Programming (OOP) [8] combined with techniques not made or distributed for profit or commercial advantage and that copies focussing on models and automation. While code generation bear this notice and the full citation on the first page. To copy otherwise, to can greatly improve the software production process, as prerepublish, to post on servers or to redistribute to lists, requires prior specific sented in [3], we suggest that the problem space and problem permission and/or a fee. IWAAPF’08, May 10, 2008, Leipzig, Germany. analysis should not be neglected. In this position paper, we propose research into expressing software development processes in terms of one generic theory, namely Problem Oriented Engineering (POE). Our aim is to relate the POE process to those available in the Rational Unified Process (RUP), and initially we will propose tentative mappings between RUP and POE entities. By doing it, we would investigate the feasibility of applying similar mapping methodology to other Object-Oriented Analysis and Design (OOAD) processes. This approach should provide insights on whether (and how) RUP separates problems from solutions, and also how to enrich RUP with traceability and POE with concepts that cover state-of-practice. The research agenda we propose in this paper addresses the problem space in the state-of-practice: being the first research attempt to bind the POE process with the OOAD processes, it could be a further contribution to the foundation for normalising object-oriented enterprise systems. While the steps towards normal design in software engineering could be captured as problem frames, patterns and architectures, we extend these ideas further onto the software development processes, which might help close the gap between software engineering and normal design.
Copyright 2008 ACM 978-1-60558-020-3/08/05 ...$5.00.
78
3. THE POE PROCESS PATTERN
Many approaches and methods address various software engineering activities, and many of them use model representations of software. However, there is little methodological support in the state-of-practice for the capture and use of traceability relations stemming from the transition from requirements to code, so called design rationale. Access to the design rationale – essentially the explanation why design elements appear or not – provides powerful means when software system validation is required, as stakeholders can access the design to the extent they wish, and understand why decisions were made, what other possible design options were assessed for applicability, and how a requirement turned into a design. The research agenda we propose in this paper intends to be effective in bringing a problem focus to the state-ofpractice – one of the original goals of Problem Frames. It will be achieved through exploration of the binding of PO(S)E with OOAD processes. In this paper, we propose the investigation into the existence of non-trivial mappings between the Rational Unified Process (RUP) [7] and the POE process pattern [4]. The intent is to explore and specialise the POE process pattern to be applicable to RUP. This will be carried out in an incremental manner, i.e., by starting at the top level of RUP entities, we will adjust mappings progressively upon unsuccessful or negative results, and identify whether there are any missing abstractions in the POE and/or RUP processes. The paper is structured as follow. Sections 2 and 3 provide a brief overview of RUP and POE terminology. Section 4 presents our research agenda and the example of a tentative mapping. Section 5 concludes the paper with remarks on current and future work. In the rest of this paper we will refer to POE and POSE interchangeably, also designated as PO(S)E, unless we use specific terms.
2.
The POSE framework, which extends Problem Frames [6] into the solution space so that iterative development can be undertaken, makes it possible to express a process of finding a software solution to a given problem, where all steps are documented in a Gentzen-style sequent calculus notation, forming a tree structure [5]. All decisions, in order to enhance traceability, are accompanied by their respective justifications. In this way the POSE framework is capable of tracing problems and their respective solution candidates. POSE is the first instance of POE, “a ‘natural’ framework for engineering design” [4]. Assurance-driven development (essentially, when the needs of a customer drive the development process) leads to a simple, fractally applicable pattern in POE, in which problem and solution spaces are visited in sequence and assurance of their form gathered through appeals to stakeholder validation, before continuing. More detail of the POE Process Pattern (Figure 2) can be found in [4]). Briefly, it consists of two activities: Partial Candidate Problem Exploration (PCPE) and Partial Candidate Solution Exploration (PCSE). Both are validated in the Partial Candidate Problem Validation (PCPV) and Partial Candidate Solution Validation (PCSV) steps, respectively. Figure 2 presents the POE Process Pattern without showing stakeholder responsibilities; the complete illustration can be found in [4]. The dashed arrows depict backtracking in case when the validation steps are unsuccessful, this can be local (as shown in our simplified figure, or global as in the full process).
Figure 2: POE Process Pattern
RUP AS AN OOAD PROCESS
Validation in the POE process is assumed to take place through two collective roles: those responsible for validating the exploration results of the problem through PCPE, and those responsible for validating the solution through PCSE: roles that we term Problem Owning Stakeholder (POSH) and Solution Owning Stakeholder (SOSH), respectively.
The OOAD process is incremental and iterative, and the lifecycle spans over four phases, forming the macro process: Inception, Elaboration, Construction, and Transition [2]. The transitions between lifecycle phases (I, E, C, and T ) are guarded by their respective milestone validations (decision points in Figure 1), where the dashed arrows represent backtracking due to unsuccessful milestone validations.
4. RESEARCH AGENDA The aim of this research is to support software design by iteration between problem and solution spaces, including the capture of design rationale for a particular software development. One of our goals for this research is to relate the POE process, i.e., the theory, to those available under RUP, i.e., the state-of-practice, confirming whether it is practical to bind the POE process with any of the OOAD processes. Provided we successfully confirm such a relation, this research could further benefit the OOAD processes by adding features that are exclusive to the POSE framework and the POE Process Pattern. With a number of practical development approaches from the industry, and the POE theory attempting to capture the whole development in the form of one pattern, a further goal of this research agenda is to investigate whether it is possible to express various software development processes in terms of one generic theory: POE. Such an investigation cannot, of course, be completed by simple enumeration of examples;
Figure 1: RUP phases and milestone validations This paper focusses on RUP, which represents a concrete but manageable instance of an OOAD process. By referring to the top level entities, we mean the lifecycle phases, which are the same for the OOAD process and RUP. Each phase consists of purposes, activities, workflows, work products, and milestones [1]. By moving towards lower levels, i.e., deeper in the hierarchy of RUP entities, we encounter other entities (RUP artefacts), e.g., test cases, documents, classes, etc. While in this paper we use ‘RUP’ and ‘the OOAD process’ interchangeably, we are aware that there is a subtle difference: RUP is a concrete instance of the OOAD process (defined in [2] as the macro and micro process), which in turn could be generalised to an OOAD process, i.e., any other process from the plan-driven/agile continuum that employs object-orientation to some extent.
79
however, it can be disproven quite simply by identifying a mismatch of some kind, such that an embedding of OOAD into POE is not possible. Only further investigation will either provide the proof or rebut this conjecture. It should also let us gain an insight into any missing abstractions and ambiguous process concepts both in POE and RUP. The mismatch would drive proposals to enrich both the theory and the state-of-practice. This research benefits the theory by checking whether (and how) the methods used in the industry fit under the POE Process Pattern. At the same time the practice would be enriched by the separation of problems from solutions, while retaining all aspects of traceability and accountability, and by the rigour of validation. By expressing RUP in terms of the POE Process Pattern, we would demonstrate that it might be worthwhile to extend and generalise the approach to other development processes, thereby introducing the benefits exclusive to PO(S)E. This will help answer the following question, and might provide further views on the state-of-practice development processes. Question: Is the theory of POE rich enough to cope with concrete processes from the state-of-practice? The investigation into the relations between the POE and the OOAD processes will help test the following hypothesis: Hypothesis: The PO(S)E process provides a good explicative and predictive framework for OOAD processes. In general, the approach to be taken is an iterative mapping of the RUP entities to the POE Process Pattern elements. Upon the initial and tentative mapping of the high level RUP entities, this research will proceed towards mapping of RUP entities from lower levels. The POE Process Pattern is explicative in that each element of OOAD has its existence explained by the pattern, as are the interrelationships between elements and the elements of the process. The POE Process Pattern is predictive in that disadvantages and benefits of OOAD are explained by the way in which problem solving under PO(S)E should happen. An arbitrary (and large enough) number of RUP entities will be mapped to the POE Process Pattern, explaining choices and features that make them fit. The outcome will help establish whether it is sensible for the above hypothesis to be explored further.
under POE. Exploring and proving whether the suggested approach extends over to other plan-driven processes, and also agile processes, is out of scope at the moment.
4.2 Preliminary Exploration For each RUP entity we want to decide whether it belongs to a problem or a solution description. This can be done by answering the question: Whose real concern is it and why? In this way we can assign the role responsible for validating, being either POSH or SOSH. In our preliminary exploration we have already identified ambiguous situations: a combination of the two roles is possible, and there are two types of that, designated as AMB1 and AMB2. AMB1 occurs when both POE roles are concerned and there is a clear dominance of one role over the other, i.e., while both roles are to some extent concerned, one of them is more than the other. AMB2 occurs when both POE roles are equally responsible, i.e., when an entity at hand can be considered as a part of PCPE and PCSE at the same time. To answer the question above, we define a mapping ERU P → RP OE that assigns to each RUP entity (activity, purpose, milestone, etc.) a POE role. Formally, the mapping is defined by a set of assignments x → y < J > where x ∈ ERU P and y ∈ RP OE and J is one or more justifications explaining the reason for the mapping. For the Inception phase (Fig. 1) we identified the following eight mappings:
Mapping 1: Purpose: ensuring that the project is both valuable and feasible (scope and business value) → POSH Mapping 2: Purpose: ensuring business value and technical feasibility → AMB2 Mapping 3: Activity: understanding the key risks associated with building the system → AMB2 Mapping 4: Activity: selecting a process that is appropriate for the project → AMB1 Mapping 5: Work Product: initial risk list → AMB2 Mapping 6: Work Product: the development environment → AMB1 Mapping 7: Milestone item: an understanding of the relative priority of requirements, and a strong business reason for building the system → [POSH] Mapping 8: Milestone item: there is an agreement between the customer and the development organisation on the scope of the system and the overall timeline for delivery → [AMB2]
4.1 Limitations in the agenda Our focus is currently limited to OOAD processes. Nevertheless, we consider it worthwhile, as it is an approach that is widely used in the industry, especially for enterprise software development, where the OOAD benefits are often overshadowed by problems accompanying software development in general that are not necessarily related to the fact of using object-orientation. We will not deal directly with addressing the shortcomings of the OOAD process, i.e., applicability of use cases, the need for various models, incompatibilities related to UML versions, etc. Moreover, we will limit ourselves to an arbitrarily chosen configuration, namely the RUP for Small Projects [1], as it sufficiently represents all the disciplines encountered under OOAD. While IBM Rational Method Composer tool allows for tailoring a process according to project specific requirements and needs, this readily available configuration will be enough for the purposes of our explorations. Other alternatives do exist (e.g., plan-driven Enterprise Unified Process, or agile XP and Scrum), but our objective is to map only one instance of a commonly used OOAD process to the process defined
The above concrete example allowed us to identify that RUP entities ERU P could be mapped onto any of the responsibilities RP OE , not necessarily always in a form of oneto-one mapping: when AMB1 and AMB2 are the case, we observe a dual responsibility, and to some extent it depends on the context and the entity at hand. For example, a customer, being a typical POSH role, might also be interested in some solution-specific aspects: what technical environments should be chosen, what tools should be used, etc. Since the POE theory does not allow roles to overlap [4], this example poses an issue. This implies two options: either to probe
80
RUP entities at a finer-grained level or to adjust the POE Process Pattern to cater for such situations. After having mapped some entities from the RUP Inception phase onto the POE roles (for the sake of brevity, we have only shown eight of the mappings), we can tentatively generalise the following: purposes define which of the POE roles are concerned in the mapping, activities can be mapped onto explorations (either PCPE or PCSE, or both at the same time), and milestones can be mapped onto validations (PCPV or PCSV, or both). We are yet to tackle the other RUP phases, and focus on other entities available at lower levels. The above example is one of the techniques that could help establish whether the fitness of a mapping depends on the level we choose as a starting point. For example, it is clearly rather hard to map the Inception phase as an entity to either one of the POE explorations, which might suggest an impedance mismatch existing at least for some of the levels. It might be necessary to consider the multiplicity of mappings, i.e. one-to-one, one-to-many, etc. As an example, an existence of a one-to-many mapping (one RUP entity to many POE entities) might suggest that the RUP entity mixes up solution and problem together, hence the POE theory would require changing, as it does not predict this, meaning a missing abstraction in the POE process. It could also mean that a mapping for some RUP entities at a certain level does not make sense, and we should try to decompose such entities, i.e., proceed to a lower level.
5.
looking beyond RUP is initially out of scope for this research agenda. By combining the rigour of PO(S)E with RUP, we take advantage of one of the benefits of Problem Frames, namely postponing the solution until analysis and validation have been completed. Knowing and accepting that neither Problem Frames nor any derived techniques should be perceived as panacea to solve known problems, we only hope that combining RUP with PO(S)E will enrich the former by introducing the academic rigour present in the latter. The future goal based on this agenda is to generalise the results towards other processes used under OOAD. Upon successful binding of RUP and PO(S)E, it could be worth looking into extending the approach to any development process from the plan-driven/agile continuum. By using this generalisation, we would show that it is possible to treat the PO(S)E process as a meta-process that in turn could be used for describing other processes used during software development. With the benefits of the POSE framework, a common ground could be established for describing, reasoning, and manipulating various development processes. This could contribute to research on software development processes. It might find its applications in measuring and comparing various development processes, and that, as a result, could simplify the selection task of a development process methodology. This agenda is also relevant to certain aspects of software evolution, where by expressing elements of the OOAD process in terms of POSE, and at the same time by introducing additional mechanisms for traceability to OOAD, the tangible link between the problem and the solution spaces would be established, which could be an effective means to reason about problem and design co-evolution. This particular notion of these co-evolving artefacts is interesting, because to our knowledge there is not much research in this specific area that addresses these aspects of requirements engineering and OOAD process together with an equal importance.
CONCLUDING REMARKS
We have proposed to explore the mappings between RUP and POE entities as an initial step towards showing that the POE theory fits the processes used in the industry, at least partially. Future research might confirm that such a relation between state-of-practice processes and the POE theory could benefit the OOAD processes by adding features that are exclusive to PO(S)E. In this way, the agenda we propose addresses the problem space and brings it closer to the industrial setting. Therefore it could contribute towards research introducing normal design to the state-of-practice, i.e., investigation into configuring/arranging software development process entities, so that they could be considered as normal – not requiring further decomposition. We stay in the problem space, i.e., we focus on the first part of the Problem → Design → Implementation chain, by covering all process entities, as opposed to only software solution specific artefacts, such as classes, components, etc. The results of this research should converge on the goal of providing the evidence that mapping a development process to the PO(S)E process is feasible. This approach would make benefits of POSE, i.e., its process, the linking of problem and solution artefacts, the audit trail, etc., available to RUP. Having such a means of traceability at one’s disposal would be beneficial during object-oriented software development, and it would further enrich the OOAD process, which, as described in [2], does not offer such thorough and rich traceability mechanisms for problem solving and documenting design rationale. With RUP as a rich and a plan-driven representative of OOAD processes, i.e., located on one end of the process continuum, we hope that this research will provide concrete examples on how to map PO(S)E with other processes that are placed along the continuum (plan-driven to agile). However,
6. REFERENCES [1] IBM Rational Method Composer version 7.2 (tool). http://www-306.ibm.com/software/awdtools/rmc/, 2007. [2] G. Booch, R. A. Maksimchuk, M. W. Engle, B. J. Young, J. Conallen, and K. A. Houston. Object-oriented analysis and design with applications. Pearson Education, Inc., 3rd ed., 2007. [3] K. Czarnecki and U. Eisenecker. Generative programming: methods, tools, and applications. ACM Press/Addison-Wesley, 2000. [4] J. G. Hall and L. Rapanotti. Assurance-driven development in problem oriented engineering. Technical Report 2007/15, Computing Department, The Open University, 2007. [5] J. G. Hall, L. Rapanotti, and M. Jackson. Problem-oriented software engineering: solving the package router control problem. IEEE Trans. Software Eng., 2008. [6] M. Jackson. Problem frames: analyzing and structuring software development problems. Addison-Wesley, 2001. [7] P. Kruchten. The Rational Unified Process: An Introduction. Addison-Wesley, 3rd ed., 2003. [8] B. Meyer. Object-Oriented Software Construction. Prentice Hall PTR, 2000.
81
