Jarmo J. Ahonen

Impacts of the Organizational Model on Testing: Three Industrial Cases

Quality problems in delivered software systems are causing huge costs to vendors and customers alike. Proper testing is crucial for removing defects and assuring the required reliability of software, but testing tends to be a weak spot in the development process. The problems of testing are often supposed to be mainly technical. However, in our three case studies, the organizational structure of the software engineering organization has shown very significant effects on the testing process and its results. We describe three different organizational models and compare their advantages and disadvantages for testing, according to empirical data.

Software modernization decision criteria: an empirical study

Decisions regarding software evolution strategies such as modernizations are economically important. We present results of our empirical study of the views of decision makers. We have asked their views of the relative importance of 49 software modernization decision criteria. We have gathered data from Finnish software industry. There were 26 experts from 8 organizations involved. They were mainly upper or middle level managers. Our study shows that there is a large set of criteria which should be taken into account, and that those studied by us provide a good coverage of the relevant ones. We list the top-20 criteria. We also performed a cluster analysis which produced two groups of subjects. Views of the decision makers in software user and software supplier organizations were different. We suggest that decision makers work process could be enhanced by taking into account the received lessons.

Software engineering projects may fail before they are started: Post-mortem analysis of five cancelled projects

Context: Software project cancellations are often caused by mistakes made during the project, and such cancellations make a strong economic impact. We analyzed five cancelled software engineering projects. One case was an internal product development project of a company that sells products to its customers. The other four cases were different software engineering projects, and outcomes of these projects were planned to be delivered to external customers. Objective: This study reports a post-mortem analysis of five software engineering projects with the aim of providing more knowledge about the reasons for cancellation decisions and the causes behind those reasons. Methods: The research method is case study. A method for a document-based post-mortem analysis was developed and post-mortem analysis was performed. All project documentation was available for analysis. Results: The reasons for the cancellation decisions were well-known ones. In four cases of five, the outcome of the project was to be delivered to an external customer, but in these cases the causes of the cancellation reasons were not found from the normal project documentation. In these cases the cause of the cancellation originated in a phase before the start of the project and therefore the project was doomed before it was started. Conclusion: It is reasonable to suggest that a remarkable portion of project cancellations are due to mistakes made before the project is started in the case of contract-based software engineering projects.

A case study on quality-affecting problems in software engineering projects

Software engineering projects normally have many different problems related to all phases of the project. In addition to technical problems, the projects normally suffer from problems caused by management practices and conflicts of interests. We concentrated on quality affecting problems in one software company. The experts of the studied organization agreed on 22 such problems. Almost all of those problems were related to management or human issues, only three had clearly technical causes. We describe those problems and their symptoms, causes and effects.

LAPPI: A light‐weight technique to practical process modeling and improvement target identification

Understanding the current state of the software processes and their problem points is important. Without this understanding, software process improvement (SPI) resources may be allocated to less meaningful targets. SPI work can be challenging to initiate especially in small companies where resources and knowledge of SPI are often limited. The aim of the developed technique, LAPPI (A Light‐weight Technique to Practical Process Modeling and Improvement Target Identification), is to provide an easy to use, lightweight tool for process modeling and improvement target identification. The technique provides a suitable method that integrates with various SPI initiatives. The method used in the development of LAPPI is a nonformal variation of constructive research. LAPPI has been incrementally developed in multiple academia‐industry collaboration projects and by industry actors themselves. Our evaluation of the LAPPI technique in 42 studies conducted in 31 companies indicates that the technique is suitable for modeling the current process and identifying the points of improvement in the process. Practical experience shows that LAPPI provides a cost‐effective technique for process modeling and improvement target identification especially in small and medium‐sized enterprises. It is most useful in the diagnosing phase of SPI. It helps the company to understand the current processes and the organizational interactions, and to create a process description baseline. Copyright

SPI with lightweight software process modeling in a small software company

In small growing software companies, it is important to pay attention to software process improvement (SPI) in order to be successful and competitive in both domestic and foreign markets. However, limited resources and lack of knowledge about process culture may hinder the improvement efforts in small companies. In this paper, we present development activities done in a small growing software company in order to establish basis for SPI. Familiarizing to processes and SPI is done by modeling companys processes using a lightweight software process modeling technique. The modeling combined with external consulting provides the company with capability to visualize their processes and to identify the problems in the processes. The improvement activities have been triggered by pointing out the problems. In the presented case, the company has independently implemented quite significant improvements for identified problems by acquiring needed knowledge and by implementing new tools to support workflows.

Group Decision-Making Processes in Industrial Software Evolution

Software evolution decision-making is important. Decisions can be made by an individual or a group. Currently it is not known how decision-making is organized in software industry. However, that knowledge is needed to improve the decision-making processes. Therefore, we have studied 29 decision making experts, who were involved in software evolution decision-making. The study was performed with qualitative methods, which enabled the gathering of versatile information concerning the views of the decision-makers. The study revealed group decisions are widely used both in private and public organizations and attitudes towards them are generally positive or neutral. The study provided information about usage of groups in the preparation phase of the decisions and in the actual decision-making phase. In most cases groups were used in the preparation phase. The revealed decision-making process is related to two theoretical process models. The findings help to understand industrial decision-making in this important, but empirically surprisingly scarcely studied area.

Big Improvements with Small Changes: Improving the Processes of a Small Software Company

Majority of software companies are small. They have understood that it is crucial for their business to improve their software processes but they often do not have the knowledge and resources to do it. In this paper one way of introducing a process culture and improving the processes of a small company is presented. The problems that a small company has with its efforts towards better processes are also discussed and simple but working solutions to them are introduced.

Empirical study of industrial decision making for software modernizations

This paper describes the results of an empirical study focusing on software modernization decision making in software industry. 29 decision making experts were interviewed. The main aim was to gather versatile information about their views by posing 26 questions concerning decision making. Topics of interest of these questions included: decision makers, decision making process, used and needed methods and tools, confirmation of decisions, and decision criteria. Six important themes were identified and discussed: role of intuition, economical evaluation, confirmation of the decisions, group decision making, tool support, and success and limitations of the conducted empirical study. The most important findings include the following: use of intuition in decision making is polarized, economical evaluation is important and pursued but reliable estimation of benefits is hard fo achieve, decisions are seldom confirmed, group decision support aspects appear to be important, and tool support for expert judgment needs to be improved.

A case study on the success of introducing general non-construction activities for project management and planning improvement

The creation of a proper work breakdown structure (WBS) is essential in performing successful project effort estimation and project management. The use of WBS is required on the level 1 of CMMI. There is, however, no standard WBS available. In this paper, the results of a pilot project in which new activities were introduced into the TietoEnators WBS are reported. The activities were non-construction activities which are necessary but not directly related to the actual software construction. The study shows that the success of the introduction of such activities very much depends on the naming of the activities and how they are introduced to the employees. Additionally, it turned out that the pre-thought set of non-construction activities included activities that should not have been in the set at all as individual activities.