Méthode agile | EPFL Graph Search

vignette|Daily stand-up, rituel quotidien des méthodes agiles. En ingénierie logicielle, les mettent en avant la collaboration entre des équipes auto-organisées et pluridisciplinaires et leurs clients. Elles s'appuient sur l'utilisation d'un cadre méthodologique léger mais suffisant centré sur l'humain et la communication. Elles préconisent une planification adaptative, un développement évolutif, une livraison précoce et une amélioration continue, et elles encouragent des réponses flexibles au changement. Cette approche a été popularisée à partir de 2001 par le Manifeste pour le développement agile de logiciels. Les quatre valeurs et les douze principes adoptés dans ce manifeste sont issus d'un large éventail de méthodes dont Scrum et eXtreme Programming . Depuis lors, les méthodes ou les approches qui s'inscrivent dans la philosophie de ce manifeste sont appelées « méthodes agiles ». Les méthodes agiles se veulent plus pragmatiques

Limits of Seamlessness in Object-Oriented Software Development

Seamlessness is a promise often used to promote object orientation, and the use of object orientation in the different domains and in the different stages of the software development process has brought great improvements in seamlessness. Where can we find seamlessness? And are there different kinds of seamlessness? In this paper we look at seamlessness starting with the different models found in large software developments. To give a common base for the discussion a model architecture is presented and different aspects of seamlessness are defined. We then show on a general level, where object orientation has already brought some seamlessness, where it will hopefully bring a higher degree of seamlessness in the future and where it cannot bring seamlessness due to restrictions inherent to the model architecture. The emphasis of the discussion is not to present a complete theoretical treatment but rather to help software developers to judge the many claims about seamlessness.

1994

The Goals of the Analysis Model

When developing an analysis model, the notation itself does not suffice for determining the content of the analysis model and the end of the analysis process. For this, the goals and intents of the analysis model are used, either implicitly or explicitly. In this report we take a look at various possibilities to define the term analysis and the goals of the analysis model. We start with considering the reference model of the problem solving cycle. We examine the definitions that refer to analysis as the "what" in opposite to the "how", or as the problem definition phase of a problem solving cycle. We then continue with a discussion of various criteria (like technology independence, real word model, unambiguous or essential model) that are often used to specify the goals of an analysis model. Difficulties that arise with these criteria are that they cannot be combined arbitrarily and that some of them are very vague; we propose therefore also some more concrete formulations. In the last part of the report we take a closer look at some misconceptions and intent clashes that are due to a too idealistic model of the software development process. Objective real world models, analysis models that are stable after the analysis phase and analysis models that are equal to the high-level view of the final software system are often attempted, but are normally not realistic. This leads to intent clashes with the desire for a seamless and easy controllable development process. We explain these intent clashes and we also describe the three different approaches taken by software development methods to cope with these intent clashes.

1996

Processus métier et composants logiciels pour la gestion intégrée des eaux en milieu urbain

Vincent Mottier

Water management in urban areas is a complex task because of the several interactions that exist between the different facets of the urban water system (surface and subsurface water, sewer system, water supply system, water and wastewater treatment plant, etc) and the many stakeholders in this context. It is necessary to reconsider current practices in order to shift from a sectored approach towards an integrated and global one. Such an approach implies that for each decision that has to be taken or each operation that has to be planned, numerous parameters must be considered and huge amounts of data have to be handled. Software tools offer in this context very interesting potentialities because of their ability to store, manage and exploit large volumes of spatial, thematic and temporal data. However, it turns out that such tools are not so easy to put into practice : exchange of information remains difficult, a lack of functions specific to water management has been stated, and the complexity of the domain itself makes the construction of dedicated software systems difficult and costly. The objectives of the present study are thus to develop concepts and a methodology allowing the development of software systems that support the management of urban water in an integrated and sustainable way. First, an identification of the criterions that must be fulfilled by such systems is carried out. It is shown that they must be: 1°) able to evolve in the same direction as water management practices; 2°) adaptable to the specific needs of their users; 3°) deployable on various computer systems configurations; 4°) able to interact with third party software systems; 5°) built and modified easily ; 6°) user friendly; and 7°) affordable. This research, taking into account these requirements, proposes to build software systems by assembling business components. Business components are reusable autonomous groups of software components that allow the handling of business objects, which are themselves high granularity objects that represent things active in the business domain. Indeed, such components allow the construction of software systems that exactly match users' requirements while taking advantage of the integration of preexisting parts : rapid development processes, cost reduction and increased quality. From a theoretical point of view, the proposal is built on three main principles : the complexity inherent to the domain of urban water management is tackled by segmentation. Each business component allows the handling of a coherent, limited and clearly defined set of concepts. A software tool can be built by integrating such business components and then be customized, thus recreating the complexity of the domain, but in a controlled manner; "real world" entities act as points of articulation between the businesses of the stakeholders : in the field of urban water management, the different actors handle, in the context of their business processes, abstractions of the same "real world" entities. Specific business components support the handling of these abstractions, submitting them to each user in a form that fits their needs. In this way, a business component, implementing a well defined set of concepts, will be used by the group of users concerned by these concepts, allowing an integrated approach of the different business processes; business components must be conceived in order to maximise their reusability potential in different software applications. Indeed, if this potential is high it is more worthwhile to develop the concerned business component. From a technical perspective, the proposal is based on : object orientation, which allows a direct mapping from the real world to the software system, and facilitates the development of systems that are modular, evolutive and easy to understand; software components, which allow the grouping of logically correlated functions and concepts into autonomous units. Such components are, with regards to their reusability, of an adequate level of granularity ; interoperability among components realised through a clear distinction between interfaces (the definition of the services offered) and implementations (the way of carrying out these services), associated with a standardisation of these interfaces. This research presents a way to identify, characterize and develop a set of business components specifically for urban water management software systems. The structure of such components is described. Two main kinds of business components are distinguished : entity components, which allow the handling of real world entities; and process components, which are designated to support specific business processes, and offer for this aim the adequate functions. Designated to be reused, business components must be constructed very meticulously, and the use of a software development method is for this purpose unavoidable. A method, dedicated for the development of business components in the domain of urban water management, is presented, whose characteristics are : 1°) to be based on the analysis of the business processes of the stakeholders; 2°) to allow rapid, iterative cycles, each of them leading to a set of operational business components; 3°) to allow the stepwise definition of a global reference mode1 of the urban water management domain that supports the development of coherent and non redundant business components; and 4°) to offer a technique that maximises the reusability potential of these components. The presented concepts, as well as the development method, are validated through prototyping. It is shown that a business component based approach of software systems offers a real opportunity to improve the business processes in the field of urban water management. Such components also offer possibilities to easily implement software systems that will help the monitoring and management of the urban water system. The enhancement of the value of the available data and the information exchange between stakeholders is facilitated. Thus, the development and use of business component based approaches must be encouraged. For this reason, this research concludes with the proposal of an organisational process aimed to stimulate and coordinate the setting up of a "business component market" for urban water management systems.

EPFL2001