Mikael Lindvall

An Introduction to Agile Methods

Abstract Agile Methods are creating a buzz in the software development community, drawing their fair share of advocates and opponents. While some people consider agile methods the best thing that has happened to software development in recent years, other people view them as a backlash to software engineering and compare them to hacking. The aim of this chapter is to introduce the reader to agile methods allowing him/her to judge whether or not agile methods could be useful in modern software development. The chapter discusses the history behind agile methods as well as the agile manifesto, a statement from the leaders of the agile movement. It looks at what it means to be agile, discusses the role of management, describes and compares some of the more popular agile methods, provides a guide for deciding where an agile approach is applicable, and lists common criticisms. It summarizes empirical studies, anecdotal reports, and lessons learned from applying agile methods and concludes with an analysis of various agile methods. The target audiences for this chapter include practitioners, who will be interested in the discussion of the different methods and their applications, researchers who may want to focus on the empirical studies and lessons learned, and educators looking to teach and learn more about agile methods.

Evaluating Software Architectures

Abstract As software systems become increasingly complex, the need to investigate and evaluate them at high levels of abstraction becomes more important. When systems are very complex, evaluating the system from an architectural level is necessary in order to understand the structure and interrelationships among the components of the system. There are several existing approaches available for software architecture evaluation. Some of these techniques, pre-implementation software architectural evaluations, are performed before the system is implemented. Others, implementation-oriented software architectural evaluations, are performed after a version of the system has been implemented. This chapter briefly describes the concepts of software architecture and software architectural evaluations, describes a new process for software architectural evaluation, provides results from two case studies where this process was applied, and presents areas for future work.

Empirical Findings in Agile Methods

In recent years, the use of, interest in, and controversy about Agile methodologies have realized dramatic growth. Anecdotal evidence is rising regarding the effectiveness of agile methodologies in certain environments and for specified projects. However, collection and analysis of empirical evidence of this effectiveness and classification of appropriate environments for Agile projects has not been conducted. Researchers from four institutions organized an eWorkshop to synchronously and virtually discuss and gather experiences and knowledge from eighteen Agile experts spread across the globe. These experts characterized Agile Methods and communicated experiences using these methods on small to very large teams. They discussed the importance of staffing Agile teams with highly skilled developers. They shared common success factors and identified warning signs of problems in Agile projects. These and other findings and heuristics gathered through this valuable exchange can be useful to researchers and to practitioners as they establish an experience base for better decision making.

Linking Software Development and Business Strategy Through Measurement

The GQM+Strategies approach extends the goal/question/metric paradigm for measuring the success or failure of goals and strategies, adding enterprise-wide support for determining action on the basis of measurement results. An organization can thus integrate its measurement program across all levels.

Static evaluation of software architectures

The software architecture is one of the most crucial artifacts within the lifecycle of a software system. Decisions made at the architectural level directly enable, facilitate, hamper, or interfere with the achievement of business goals, functional and quality requirements. Architecture evaluations play an important role in the development and evolution of software systems since they determine how adequate the architecture is for its intended usage. This paper summarizes our practical experience with using architecture evaluations and gives an overview on when and how static architecture evaluations contribute to architecture development. We identify ten distinct purposes and needs for static architecture evaluations and illustrate them using a set of industrial and academic case studies. In particular, we show how subsequent steps in architecture development are influenced by the results from architecture evaluations

Software systems support for knowledge management

Human capital is the main asset of many companies, whose knowledge has to be preserved and leveraged from individual to the company level, allowing continual learning and improvement. Knowledge management has various components and aspects such as socio‐cultural, organizational, and technological. In this paper we address the technological aspect; more precisely we survey available software systems that support different knowledge management activities. We categorize these tools into classes, based on their capabilities and functionality and show what tasks and knowledge processing operations they support.

GQM^+ Strategies -- Aligning Business Strategies with Software Measurement

GQM+Strategies is a measurement approach that builds on the well-tested GQM approach to planning and implementing software measurement. Although GQM has proven itself useful in a variety of industrial settings, one recognized weakness is the difficulty for GQM users to link software measurement goals to higher-level goals of the organization in which the software is being developed. This linkage is important, as it helps to justify software measurement efforts and allows measurement data to contribute to higher-level decisions. GQM+strategies provides mechanisms for explicitly linking software measurement goals, to higher-level goals for the software organization, and further to goals and strategies at the level of the entire business.

Combating architectural degeneration: a survey

As software systems evolve over time, they invariably undergo changes that can lead to a degeneration of the architecture. Left unchecked, degeneration may reach a level where a complete redesign is necessary, a task that requires significant effort. In this paper, we present a survey of technologies developed by researchers that can be used to combat degeneration, that is, technologies that can be employed in identifying, treating and researching degeneration. We also discuss the various causes of degeneration and how it can be prevented.

An Empirically-Based Process for Software Architecture Evaluation

Software systems undergo constant change causing the architecture of the system to degenerate over time. Reversing system degeneration takes extra effort and delays the release of the next version. Improved architecture is intangible and does not translate into visible user features that can be marketed. Due to a lack of representative metrics, technical staff has problems arguing that stopping degeneration is indeed necessary and that the effort will result in an improved architecture that will pay off. We believe that architectural metrics would give technical staff better tools to demonstrate that the architecture has improved. This paper defines and uses a set of architectural metrics and outlines a process for analyzing architecture to support such an argument. The paper reports on a case study from a project where we restructured the architecture of an existing client-server system written in Java while adding new functionality. The modules of the existing version of the system were “library-oriented” and had a disorganized communication structure. The new architecture is based on components and utilizes the mediator design pattern. The goal of the study is to evaluate the new architecture from a maintainability perspective. The paper describes our evaluation process, the metrics used, and provides some preliminary results. The architectural evaluation shows that the components of the system are only loosely coupled to each other and that an architectural improvement has occurred from a maintenance perspective. The process used to evaluate the architecture is general and can be reused in other contexts.

SAVE: Software Architecture Visualization and Evaluation

Fraunhofer SAVE (Software Architecture Visualization and Evaluation) is a tool for analyzing and optimizing the architecture of implemented software systems. SAVE is a joint development between Fraunhofer IESE (Institute for Experimental Software Engineering IESE in Kaiserslautern, Germany) and Fraunhofer Center Maryland (Center for Experimental Software Engineering in College Park, Maryland, USA). In this work we describe the capabilities of the tool to assure compliance of existing systems with their architecture. In particular, we show how compliance checking features of SAVE work to assure compliance with structural and behavioral architectural views, to assure compliance among variants in a product line context, and to incorporate constructive compliance checking to enable built-in compliance during development and evolution.