Catálogo de publicaciones - libros

Many companies have to outwit their competitors, in order to survive. The great Finnish company Nokia, one of our clients, is a good example. To engineer a product, especially one with software in it, that works well, and is delivered on time, is an usual feat in itself. Most all software developers fail miserably at this simple task, with 50% total project failure being the international norm, and another 40% partial failure reported.

The traditional way to meet a market demand is to develop a product and sell it to the customers. In some cases all the requirements cannot be addressed with a single product, but a larger system with multiple products is needed. Further, a lot of tailoring takes places to convert these products and systems into solutions that are supposed to meet customer requirements exactly. All of these approaches have been widely used for a long time in mobile communications, and as a result we are surrounded by large amount of products and solutions. But this technology explosion has not necessarily resulted in better customer satisfaction.

Modelling a process using techniques such as Role Activity Diagrams (RADs) [13] can illustrate a large amount of useful information about the process under study. What they cannot show as easily however, are the informal practices during that process. In this paper, we analyse the prototyping process as part of an IS development strategy across five companies. Interview text from project managers, prototypers and other development staff across the five companies was analysed. Interestingly, results point to several key recurring issues amongst staff. These include non-adherence to any prototyping guidelines or standards, sketchy change request procedures, concern over time and cost deadlines and the importance attached to developer experience during the overall process. The notion of prototyping as a simple and easily managed development strategy does not hold. Our analysis provides complementary qualitative data about the opinions of prototyping to inform business process re-engineering of those formal RADs.

Process improvement studies have tended to focus on one technology area at a time, and on process improvement frameworks, like CMMI (Capability Maturity Model Integration), and measurements from the top-down point of view. In addition, the management has been the trigger force of process improvement activities. Much less interest at process level has been shown in cross-technological issues, such as co-design, and on the bottom-up approach. In this paper, we point out the importance of the defined co-design activities and the synchronisation of software and hardware processes. Hardware and software designers are the best experts in this difficult co-design process area and thus the development staff involvement together with a bottom-up approach is a respectable alternative to improving processes and practices along with traditional SPI (Software Process Improvement) frameworks. The study is based on empirical studies carried out in Nokia Networks base station unit ASIC (Application-Specific Integrated Circuit) development and DSP (Digital Signal Processing) software development teams. The bottom-up approach was used to study the processes and the CMMI was used in analysing the findings and linking them to different process areas. We found that, despite the software and hardware, the processes themselves are quite well defined, the deficiencies are related to the invisibility of co-design activities. The technical experience and view was found to be relevant in improving the processes related to the interfaces between two technologies, like hardware and software. Traditional SPI and other process areas improvement work concern themselves typically with their own technology area only, and the process deficiencies close to other technology areas might be blurred. The paper also presents new process improvements for the software and hardware co-work area.

In this paper we describe a framework for classifying possible change approaches according to the stage(s) in the life-cycle where the approach is most applicable. The life-cycle model of the framework is based on an analysis of a number of existing life-cycle models for change from three different domains. The focus of this framework is on the individual improvement project and the palette of available approaches to its project manager.

For real time embedded systems software performance is one of the most important quality attributes. Controlling and predicting the software performance in software is associated with a number of challenges. One of the challenges is to tailor the established and rather general performance activities to the needs and available opportunities of a specific organization. This study presents a qualitative methodology for tailoring process activities to a specific organization. The proposed methodology is used in case study performed in a large company that develops embedded platforms. A number of suggestions for modification and addition of process activities has been brought forward as a result of the study. The result can further be summarized as SPE in embedded platform development holds more opportunities for reuse, but also requires more focus on external stakeholders, continual training and coordination between projects.

Using OTS (Off-The-Shelf) components in software projects has become increasing popular in the IT industry. After project managers opt for OTS components, they can decide to use COTS (Commercial-Off-The-Shelf) components or OSS (Open Source Software) components instead of building these themselves. This paper describes an empirical study on why project decision-makers use COTS components instead of OSS components, or vice versa. The study was performed in form of an international survey on motivation and risks of using OTS components, conducted in Norway, Italy and Germany. We have currently gathered data on 71 projects using only COTS components and 39 projects using only OSS components, and 5 using both COTS and OSS components. Results show that both COTS and OSS components were used in small, medium and large software houses and IT consulting companies. The overall software system also covers several application domains.Both COTS and OSS were expected to contribute to shorter time-to-market, less development effort and the application of newest technology. However, COTS users believe that COTS component should have good quality, technical support, and will follow the market trend. OSS users care more about the free ownership and openness of the source code. Projects using COTS components had more difficulties in estimating selection effort, following customer requirement changes, and controlling the component’s negative effect on system security. On the other hand, OSS user had more difficulties in getting the support reputation of OSS component providers.

Content adaptable applications are often used in ubiquitous computing environment, and it aims to service the adaptable contents to users. In this environment, the services are dynamically selected and provided, the contexts are changed frequently. Then, the application services are to be modeled to derive the adaptable service effectively and to reuse the model. Modeling with software features and product line concepts may support for making service decision strategy. In this paper, we propose a service decision modeling technique for content adaptable applications in ubiquitous environment. It consists of defining variation points and their variants, finding out the dependencies between them, and then building the variant selection strategies. These can accomplish to define the decision model based on content adaptable service, and the definition templates help the reuse more effective.

Software development processes such as the Waterfall process and Extreme Programming are project management methods (PMMs) which are well known and widely used. However, conventional project management (PM) lacks the process concepts expressed in PMMs, and the connection between PMMs and PM is not much explored in the literature.

We present data models for PM and PMM, in a framework that can articulate the PM–to–PMM relationship, illustrating with simple examples. A java/XML implementation of this framework can create and then revise a “PMM–aware” project, conforming to a specified PMM. In terms of the framework, we describe a simple project data visualization and associated method that can be used to synthesize a PMM for a project instance that was initially created without reference to any PMM.

This paper provides a study of several process metrics of an industrial large-scale embedded software system, the Lucent product Lambda-Unite MSS. This product is an evolutionary hardware/software system for the metropolitan and wide-area transmission and switching market. An analysis of defect data is performed, including and comparing all major (i.e. feature) releases till end of 2004. Several defect metrics on file-level are defined and analyzed, as basis for a defect prediction model. Main analysis results include the following. Faults and code size per file show only a weak correlation. Portion of faulty files per release tend to decrease across releases. Size and error-proneness in previous release alone is not a good predictor of a file’s faults per release. Customer-found defects are strongly correlated with pre-delivery defects found per subsystem. These results are being compared to a recent similar study of fault distributions; the differences are significant.