Catálogo de publicaciones - libros

Much has been written and many discussions have taken place on the causes and cures of IT projects. This introspection is not a new phenomenon. It has been going on as long as industrial size IT systems became into being. The continuing reliance of businesses, government and society on such systems coupled to the realisation that only a little progress has been made in the last 20–30 years in delivering effective and efficient systems are sufficient motivations for continuing this debate. This paper is the product of such a public debate by the authors during the 2004 International Conference on Enterprise Information System. The paper focuses on four topics: ecological complexity, product complexity, project management and education.

We examine how to improve our understanding in stating and managing successfully requirements for large systems, because the current concept of a system requirement is ill suited to develop true requirements for such systems. It regards requirements as goals to be discovered and solutions as separate technical elements. In consequence, current Requirements Engineering (RE) theory separates these issues and reduces RE to an activity where a technical solution is documented for a given set of goals (problems). In contrast, we advocate a view where a requirement specifies a set of mappings between problem and solution spaces, which both are socially constructed and negotiated. Requirements are emergent and need to be discovered through a contracted process, which likens to a “garbage-can” decision-making. System requirements thereby embrace an emergent functional ecology of requirements. This leads to equate requirements engineering with heterogeneous engineering. The admitted heterogeneity of technological activity avoids a commitment to social (or technological) reductionism. Requirements engineers need to be seen as “heterogeneous engineers” who must associate entities that range from people, through skills, to artifacts and natural phenomena. They are successful only, if built socio-technical networks can remain stable in spite of attempts of other entities to dissociate them.

Agile methods need to include stakeholder metrics in order to ensure that projects focus better on the critical requirements, and that projects are better able to measure their achievements, and to adapt to feedback. This paper presents a short, simple defined process for evolutionary project management (Evo), and discusses its key features.

The of modern software is not that much in the size of systems as it is in the “wires” — in the linkages and communication paths between system components. The inter-component linkages create dependencies between distributed components that are difficult to understand and manage. The difficulty is inflated by the fact that components are frequently developed and managed by separate teams and by various component providers.

This paper identifies main issues for successful management of complexity in large software projects. It uses the hypothesis to explain that all complex systems of a stable but evolvable character display hierarchic organization. The paper makes it clear that a complexity-aware paves the way for developing . It makes it also clear that unless implementation is design-conformant and complexity-assured, the initial good intents may still result in an unsupportable system. Without rigorous project management, supported by tools able to compute and visualize , contemporary large software production risks delivering unsupportable systems.

Large product variety in mass customization involves a high internal complexity level inside a company’s operations, as well as a high external complexity level from a customer’s perspective. To cope with both complexity problems, an information system based on agent technology is able to be identified as a suitable solution approach. The mass customized products are assumed to be based on a modular architecture and each module variant is associated with an autonomous rational agent. Agents have to compete with each other in order to join coalitions representing salable product variants which suit real customers’ requirements. The negotiation process is based on a market mechanism supported by the target costing concept and a Dutch auction. Furthermore, in order to integrate the multi-agent system in the existing information system landscape of the mass customizer, a technical architecture is proposed and a scenario depicting the main communication steps is specified.

Most of the software discipline has come to honor the role of architecture to organize software development. The software pattern discipline has taken up the architectural metaphor quite literally, borrowing its key notions from Christopher Alexander, an innovative master builder of houses, neighborhoods, and towns. However, the software industry has missed the obvious: that architecture is a secondary concern that precipitates from the structure of the enterprise that builds it. Getting the architecture right means getting the enterprise structure right: it is certainly a necessary and potentially sufficient condition for achieving most of the goals that software engineering holds out for architectural activity.

Like most metaphors, the architectural metaphor breaks down somewhere. Unlike houses, whose structure tends to reflect the activities of the end users of the product, the structure of software exists more to serve those who build it than those who use it. This parallel has been shifting, but not on the software side: modern buildings, driven more by technology that make it possible to create 100-foot spans on the ground floor of a skyscraper, pay homage to the technology to be used in construction, and to the design techniques used to support that technology. Software, a largely technological field, has had this outlook almost from the beginning. As an industry focused on technology, it is no surprise that our software pattern discipline has taken up a largely technical agenda. Our current direction in patterns avoids the most central foundation of the pattern discipline: to build systems that are beautiful, morally profound, and “habitable” for the people they touch.

Yet there is hope: as a strong parallel to the structural concerns of software that are found in software architecture, give a voice to the crucial structural constructs of software development enterprises. It is these structures of human relationships, rather than the technological underpinnings, that drive architecture. That fact has long been known to the industry as Conway’s Law, but most managers view Conway’s Law more as a Dilbertesque joke than as a sober planning principle.

Organizational patterns are a major stride for creating the generative structure of the business—the structure of the enterprise itself—that gives rise to such other important structures as the system architecture and, by inference, the system’s human interface. The first major pattern language of software organizational structure has been completed after a decade of research. There is much more that can be done—not just by organizational specialists, but also by “software people” of every job and description.

We present an assessment of an empirical study aiming at building effort estimation models for corrective maintenance projects. We show results from the application of the prediction models to a new corrective maintenance project within the same enterprise and the same type of software systems used in a previous study. The data available for the new project are finer grained according to the indications devised in the first study. This allowed to improve the confidence in our previous empirical analysis by confirming most of the hypotheses made and to provide other useful indications to better understand the maintenance process of the company in a quantitative way.

This paper analyzes the evolution of organizational and technological critical success factors along the ERP implementation phases. The identification of factors leading to success or failure of ERP systems is an issue of increasing importance, since the number of organizations choosing the ERP path keeps growing. Our findings suggest that while both good organizational and technological perspectives are essential for a successful ERP implementation project, their importance shifts as the project moves through its lifecycle.

An adaptive caching algorithm, known as Adaptive Caching with Multiple Experts (ACME), has recently been presented in the field of web-caching. We explore the migration of ACME to the database caching environment. By integrating recently proposed database replacement policies into ACME’s existing policy pool, an attempt is made to gauge ACME’s ability to utilise newer methods of database caching. The results suggest that ACME is indeed well-suited to the database environment and performs as well as the best currently caching policy within its policy pool at any particular moment in its request stream. Although execution time increases by integrating more policies into ACME, the overall processing time improves drastically with erratic patterns of access, when compared to static policies.

This paper presents a strategy for applying sampling techniques to relational databases, in the context of data quality auditing or decision support processes. Fuzzy cluster sampling is used to survey sets of records for correctness of business rules. Relational algebra estimators are presented as a data quality-auditing tool.