Keynote Speaker : Colette ROLLAND - University Paris 1 Panthéon Sorbonne, France

Presentation : Fitting System Functionality to Business Needs : Exploring the Fitness Relationship

Abstract :

One of the major concerns in System Engineering is to establish that the ‘whys’ of the system to be developed fit the ‘whats’ of the delivered system. The aim is to ensure the ‘best fit’ between organization needs (whys) and system functionality (whats). Aligning information systems to business objectives is equally considered important by professionals. Indeed, there is large corpus of empirical and theoretical evidence that alignment improves organizational performance. Furthermore, studies highlight the lack of alignment as a major cause for business processes failure in providing return on investments.

In the engineering as well as in the management community, alignment/fit clearly appears as desirable. However, both communities acknowledge that, despite a considerable amount of efforts carried out, some issues still remain unsolved as for example: (i) the achievement of alignment and, (ii) its management over time, (iii) the identification of non fit and, (iv) its evaluation.

This talk aims to explore those issues involved with both establishing (what we will refer as) the fitness relationship and preserving it in the face of change. Indeed systems, once developed, undergo changes and it is of prime importance that the changed need and the changed system functionality continue to preserve the ‘best fit’. Engineering the fitness relationship requires to understanding it and the talk will first, deal with this topic. It will pursue with an overview of the state-of-the-art and the presentation of the author’s personal position on the two engineering topics, namely establishing and preserving the fitness relationship. Whereas the former (understanding) represents the static point of view, the latter (engineering) follows the dynamic viewpoint.

Keynote Speaker : Antoni OLIVE - UPC, Barcelona, Spain

Presentation : The Challenge of Test-Driven Conceptual Modeling

Abstract :

One of the grand challenges that have been proposed in the information systems research field is the Conceptual Schema Centric Development (CSCD) [4]. In CSCD, conceptual schemas are explicit (that is, once the functions of the information system have been determined there is an explicit, complete, correct and permanently up-to-date schema, written in a formal and declarative language), executable in the production environment, and evolving (meaning that changes to the functions of the information system require the manual change of only its conceptual schema.) A similar approach was called eXtreme Conceptual Modeling (XCM) in [3].

There are many research problems that must be solved before we achieve the CSCD goal. One of them is how to obtain complete and correct conceptual schemas. In CSCD, completeness and correctness are the principal quality goals, and they can be achieved using a very broad spectrum of approaches, including testing and verification. It should be possible to test conceptual schemas to at least the same degree that has been achieved with software.

Test-Driven Development (TDD) [1, 2] is an emerging eXtreme Programming (XP) development method in which an information system is developed in short iterations. In each iteration, the developer:
- Writes a test for the next bit of functionality that he or she wants to add;
- Writes the functional code until the test passes; and
- Refactors both new and old code to make it well structured.

Given that in CSCD conceptual schemas are executable the question naturally arises: can we develop conceptual schemas using TDD? In this talk we explore what would be this conceptual schema development method, which we call “Test-Driven Conceptual Modeling” (TDCM) and that we define as a development method in which a system's conceptual schema is obtained by performing three kinds of tasks:
- Write a test the system should pass.
- Change the schema to pass a test.
- Refactor the schema to improve its qualities.

We recall that a conceptual schema of an information system is the general knowledge that the system needs to know to perform its functions [5] and we show that, therefore, the starting point of TDCM must be the specification of the functionality of that system. According to the standard practice, such specification is given by use cases. We show that TDCM can start once we know some or all of the use cases and have a partial or complete conceptual schema of the domain.

We illustrate our vision of a future TDCM method by means of the development of a conceptual schema example, which involves the iterative definition of entity and relationship types, constraints, derivation rules, domain events and queries. The example is defined in the UML and OCL languages.

Even if it is necessarily simple, the example illustrates the need for methodological guidance in several key issues. What are test objectives, test cases and test fixtures in TDCM, and how do they relate to use cases? How do they relate to the UML Testing Profile [6]? Which is the precise relationship between test objectives, test cases and the structural and behavioral parts of a schema? Can we automatically derive a minimum set of test cases from (a part of) a schema? Given a set of use cases, which is the best order to deal with them in order to minimize the effort of changing the conceptual schema and its associated tests and of their refactoring? When is testing complete and which are the tests that remain to be done at any time? Can we automatically detect the need for schema or test refactoring, and can it be automatically done (at least in part)?

The example also illustrates the need for conceptual schema testing tools, which are not available yet. TDD tools cannot be used for schema testing because they deal with programming-level constructs (classes and operations) while in TDCM we need to deal with schema constructs, which include derivation rules, constraints, events, pre/postconditions, state transition diagrams and many more declarative constructs. Similarly, program refactoring is not the same as conceptual schema refactoring. Current conceptual modeling tools should be extended with the functionalities provided by TDD tools and environments at the programming level.

The talk also discusses the usefulness of TDCM in both the conventional and the CSCD approaches to conceptual modeling. While the full potential of TDCM can be realized in the CSCD context, it may prove also useful when the conceptual schema is only the basis for the design and construction of the information system.

Index Terms—information systems, conceptual schemas, testing, test-driven development.

REFERENCES
[1] D. Astels. Test-driven development. A practical guide. Prentice Hall 2003.
[2] K. Beck. Test-driven development: by example. Addison-Wesley, 2003.
[3] E. Insfrán, V. Pelechano, O. Pastor. Conceptual Modeling in the eXtreme. Information & Software Technology 44(11): 659-669 (2002).
[4] A. Olivé. Conceptual schema-centric development: A grand challenge for information systems research. CAiSE 2005, LNCS 3520:1-15.
[5] A. Olivé. Conceptual modeling of information systems. Springer, 2007.
[6] OMG. UML Testing Profile. Version 1.0 formal/05-07-07. July 2005.

Keynote Speaker : Peri Loucopoulos - Loughborough University, United Kingdom

Presentation : ‘Designing Ethos’ in Requirements Engineering

Abstract :

The value of requirements has long been recognised as a key factor in delivering software systems that are fit for purpose. Consequently, there is a large variety of methods, techniques and tools that continue to be tried out with varying degrees of success, focusing on modelling, and management of requirements. There is a consensus in the underlying thinking of contemporary approaches in that requirements are contextualised in the system’s environment and are considered as a pre-requisite for downstream development activities. Understanding the system’s environment such as organisational and social factors is supposed to provide a more relevant set of functional and non-functional requirements which can then be mapped onto appropriate implementation models and platforms. Whilst this requirements engineering model has bridged the gap between the ‘subject’ and ‘system’ worlds and it was probably relevant until recently, such a model is questionable in today’s business environment in which the most important factors seem to be innovation and differentiation.

We can no longer assume that business objectives are stable, that they are ‘handed down’ to subordinates or that the system does not influence the evolution of these objectives. The traditional idea of an enterprise that creates wealth by getting better at doing the same thing through improvements in its business processes, supply chain management, cost control and customer-centric responsiveness is being challenged by a new thinking in which a combination of research, innovation, and creativity through the deployment of Information Technology are the driving forces. The interplay between the ‘subject’ and ‘system’ worlds is nowadays that much more intricate, complex, dynamic and non-deterministic.

The situation of gathering all the necessary requirements, sorting through the possible alternatives and making the right decision about what will be implemented is no longer easily defendable. It is not defendable because business practices are changing from ‘managing the known’ towards ‘building the unknown’ and in such settings business requirements are fluid, and models are not mere representations of reality but ‘windows’ into possible alternative futures. A requirements engineer then becomes a ‘designer’, alongside organisational agents, in better understanding what may be satisfycing solutions to organisational or societal problems. The term ‘designing ethos’ is used here to indicate that one seeks to reduce the distance between problem and solution through a particular way of thinking, acting and participating in the creation of innovative solutions.

This talk is aimed at exploring the ‘designing ethos’ as seen from a requirements perspective. We will examine the reasons for adopting such a ‘philosophical’ stance, and we will explore four fundamental requirements principles namely those of intertwining, evolution, architecture and complexity. In dealing with these four issues we will examine the contribution and value of domain archetypes, strategic modelling in stakeholders’ negotiation, and reflective reasoning in evaluating scenarios.