Ilkka Tervonen

Support for quality-based design and inspection

Before software developers can design quality into software, they must agree on the characteristics that denote software quality and the terms that will describe those characteristics. The author suggests an approach that defines quality terms, links them to software development and inspection, and provides for their consistent use by designers and inspectors.

Towards deeper co-understanding of software quality

Abstract The major problem in understanding quality concepts has been explained by the characteristic that people see it quite differently from different perspectives. In the present paper we borrow this explanation for our starting point and broaden the consideration of software quality from the implementation-oriented in the individual and organization-oriented directions. Our main hypothesis is that these ‘soft’ aspects give us a deeper co-understanding of software quality. We proceed with three hermeneutic cycles such that after an introduction to five perspectives we analyse them through Kolbs experiential learning theory and finally deepen the analysis through the team and organization-oriented theory of Nonaka and Takeuchi.

A WWW-based tool for software inspection

Software inspections, although demonstrated to be effective, have some notable drawbacks, especially when the inspection team is geographically scattered, making it difficult or even impossible to arrange meetings. A few computer tools have been introduced to deal with such problems and to ensure cost-effectiveness. Our approach to solving this problem is based on the World Wide Web which is a truly global, easy-to-use environment in which to construct such a tool. The WIP tool introduced provides a set of functions for distributing the document to be inspected, annotating it, searching related documents, choosing the checklist and gathering inspection statistics. Evaluation of the tool indicated that despite some minor deficiencies it was well liked. The idea of online commenting was pleasant and the elimination of tangling with a variety of paper documents and reports made the inspection more effective. Many test users liked the simple statistics and the tool was easy to learn and use.

Object-oriented development as a multiview software construction methodology

The author considers object-oriented development from an abstraction-level perspective and attempts to define more exactly characteristics of objects and classes at different levels of abstraction. These levels of abstraction form the basis for the multiview principle, which is used as the framework of the analysis. The most important perspective in object-oriented development is the structure perspective which considers the class structure of the software; the weakest perspective is the behavior one. The differences in emphasis between the structure and behavior perspectives reflect the difference between conventional and embedded software. Thus, with conventional software a very detailed presentation of the behavior perspective is not necessarily required, but with embedded software it is.<<ETX>>

Improving software inspection process with patterns

Concrete guidelines are often helpful, when planning software process improvement activities. Especially minor companies may have difficulties in implementing full-scale SPI programs. One solution is to focus the improvement on the most effective quality methods. This work introduces a set of patterns to direct the improvement of the software inspection process. Patterns help in setting overall goals for the improvement and describe specific actions that are needed to enhance the process. The patterns have been experimented in a software company that is carrying out a process improvement project. The experiment started with an evaluation of the inspection process capability, after which the process was updated according to determined goals. The process has been performing more effectively after the improvement effort in this case. Results of the experiment show that the pattern approach provides a feasible and quick method for launching SPI activities, although some refinements are needed to fully exploit them.

Using Software Inspection as a Catalyst for SPI in a Small Company

Process improvement activities in small and medium size enterprises (SME) are challenging due to small number of personnel and projects, people have to perform in a variety of roles. Assigning process improvement activities to the overburdened personnel may be seen as a threat to ongoing projects. Both management and staff should become convinced of the benefits of the improvement actions before taking the first step of the process. Even in this situation the software inspection provides a tempting starting point for process improvement. It is a focused and well defined subprocess and enables high return on investment benefits even in short period use. Our experiment in a small software company confirms that software inspection provides the justified starting point for process improvement. By means of the inspection maturity model the company recognises the weak points in their review practice and inspection patterns help in discovery of improvement actions.

A path to virtual software inspection

A number of computer tools have been introduced to overcome the difficulties in traditional software inspection. Actual inspection tools are rarely used, however, as the current tool implementations have some critical inadequacies. The paper briefly summarizes the evolution of computer-supported software inspection and outlines the concept of virtual software inspection, which introduces two important aspects: flexibility and integration of the tools. Paying attention to these dimensions could result in more attractive and comprehensive tools for inspection collaboration.

Peer reviews in real life - motivators and demotivators

Peer reviews are an efficient quality assurance method in software development. Several reviewing methods exist to match the needs of different organizations and situations. Still, peer reviews are not practiced as commonly as one would suppose. This study aims at finding out what types of reviewing methods are in use in software companies, surveying the most important benefits of peer reviews and investigating reasons for not utilizing reviews. The study is carried out in companies locating in the Oulu region, but the results can be generalized to all small software companies. The results show that companies that use reviews have adjusted the process for their own needs. The main motivator for arranging reviews is the decreased amount of defects in products while the other aspects of reviews, such as process improvement or knowledge sharing are not considered as important. The main demotivator for reviews is lack of time and people resources.

Offshoring Test Automation: Observations and Lessons Learned

Offshoring (offshore outsourcing) is increasingly used in software-centric projects, specifically in the development phases of software projects. Using a mixture of onsite local staff and remote offshore staff in business-centric projects, such as business consulting, requirements elicitation and software testing, put many challenges to team organizing, charter definition and offshore personnel skills. This study considers challenges of test automation in a company which has been doing offshoring before. The challenges were studied with three test automation offshoring cases that were carried out by Nokia Oyj. Although the subcontractors fulfilled the expectations set by the customer in all cases, subcontractors’ unfamiliarity with test tools to be used and with software to be tested caused extra meetings and training sessions. Lack of resources in the customer’s side also caused additional maintenance work onshore.

Absorbing Software Testing into the Scrum Method

In this paper we study, how to absorb software testing into the Scrum method. We conducted the research as an action research during the years 2007-2008 with three iterations. The result showed that testing can and even should be absorbed to the Scrum method. The testing team was merged into the Scrum teams. The teams can now deliver better working software in a shorter time, because testing keeps track of the progress of the development. Also the team spirit is higher, because the Scrum team members are committed to the same goal. The biggest change from test manager’s point of view was the organized Product Owner Team. Test manager don’t have testing team anymore, and in the future all the testing tasks have to be assigned through the Product Backlog.