CiteULike: peppelorum's library [30 articles]

Towards Improved Requirements Practices in Agile Software Development

Hema Srikanth — 2008-05-31T19:42:18-00:00

Traditional software processes, while rich with support for requirements activities, are not especially well suited for rapid software development. Agile software processes have recently received increased attention due to the need to develop software for rapidly changing environments; however they fail to properly support essential requirements engineering practices. This paper proposes a agile approach to software development, ADaPT (Agile Development and Prototyping Technique), which ...

Limitations of Agile Software Processes

D Turk — 2008-04-23T15:13:37-00:00

(May 2002)

Software developers and project managers are struggling to assess the appropriateness of agile processes to their development environments. This paper identifies limitations that apply to many of the published agile processes in terms of the types of projects in which their application may be problematic.

Extreme usability: adapting research approaches for agile development

Melissa Federoff — 2008-05-31T15:46:32-00:00

(2008), pp. 2269-2272.

Process Agility and Software Usability: Toward Lightweight Usage-Centered Design

Larry Constantine — 2007-11-26T08:01:17-00:00

No. 110. (2001)

A streamlined and simplified variant of the usage-centered process that is readily integrated with lightweight methods is outlined. Extreme programming and other so-called agile or lightweight methods promise to speed and simplify applications development. However, as this paper highlights, they share with the "unified process" and other heavyweight brethren some common shortcomings in the areas of usability and user interface design. Usage-centered design is readily integrated with these...

Extreme Programming Explained : Embrace Change (2nd Edition)

Kent Beck — 2005-07-20T19:48:44-00:00

(16 November 2004)

Kent Beck's eXtreme Programming eXplained provides an intriguing high-level overview of the author's Extreme Programming (XP) software development methodology. Written for IS managers, project leaders, or programmers, this guide provides a glimpse at the principles behind XP and its potential advantages for small- to mid-size software development teams. The book intends to describe what XP is, its guiding principles, and how it works. Simply written, the book avoids case studies and concrete details in demonstrating the efficacy of XP. Instead, it demonstrates how XP relies on simplicity, unit testing, programming in pairs, communal ownership of code, and customer input on software to motivate code improvement during the development process. As the author notes, these principles are not new, but when they're combined their synergy fosters a new and arguably better way to build and maintain software. Throughout the book, the author presents and explains these principles, such as "rapid feedback" and "play to win," which form the basis of XP. Generally speaking, XP changes the way programmers work. The book is good at delineating new roles for programmers and managers who Beck calls "coaches." The most striking characteristic of XP is that programmers work in pairs, and that testing is an intrinsic part of the coding process. In a later section, the author even shows where XP works and where it doesn't and offers suggestions for migrating teams and organizations over to the XP process. In the afterword, the author recounts the experiences that led him to develop and refine XP, an insightful section that should inspire any organization to adopt XP. This book serves as a useful introduction to the philosophy and practice of XP for the manager or programmer who wants a potentially better way to build software. --Richard Dragan Topics covered: Extreme Programming (XP) software methodology, principles, XP team roles, facilities design, testing, refactoring, the XP software lifecycle, and adopting XP. Software development projects can be fun, productive, and even daring. Yet they can consistently deliver value to a business and remain under control. Extreme Programming (XP) was conceived and developed to address the specific needs of software development conducted by small teams in the face of vague and changing requirements. This new lightweight methodology challenges many conventional tenets, including the long-held assumption that the cost of changing a piece of software necessarily rises dramatically over the course of time. XP recognizes that projects have to work to achieve this reduction in cost and exploit the savings once they have been earned. Fundamentals of XP include: * Distinguishing between the decisions to be made by business interests and those to be made by project stakeholders. * Writing unit tests before programming and keeping all of the tests running at all times. * Integrating and testing the whole system-several times a day. * Producing all software in pairs, two programmers at one screen. * Starting projects with a simple design that constantly evolves to add needed flexibility and remove unneeded complexity. * Putting a minimal system into production quickly and growing it in whatever directions prove most valuable. Why is XP so controversial? Some sacred cows don't make the cut in XP: * Don't force team members to specialize and become analysts, architects, programmers, testers, and integrators-every XP programmer participates in all of these critical activities every day. * Don't conduct complete up-front analysis and design-an XP project starts with a quick analysis of the entire system, and XP programmers continue to make analysis and design decisions throughout development. * Develop infrastructure and frameworks as you develop your application, not up-front-delivering business value is the heartbeat that drives XP projects. * Don't write and maintain implementation documentation-communication in XP projects occurs face-to-face, or through efficient tests and carefully written code. You may love XP or you may hate it, but Extreme Programming Explained will force you to take a fresh look at how you develop software.

A Systemic Functional Resonance Analysis of the Alaska Airlines Flight 261 Accident

Rogier Woltjer — 2008-05-31T09:44:52-00:00

(2006)

On January 31, 2000, Alaska Airlines flight 261, an MD-83, crashed into the Pacific Ocean, after airplane pitch control was lost as a result of the in-flight failure of the horizontal stabilizer trim system jackscrew assembly's acme nut threads (NTSB, 2003). Accident investigation revealed a wide range of human, technical, and organizational factors contributing to this tragic event. In his recent book on barriers and accident prevention, Hollnagel (2004) describes a systemic method for barrier analysis and a systemic Functional Resonance Accident Model (FRAM). This paper treats each of the main categories of contributing factors that are identified in the systemic Functional Resonance Accident Model (FRAM): Impaired or missing barriers, latent conditions, technological failures, and human performance variability. It moreover discusses how resonance occurred between the functional entities in the joint system of human, technical, and organizational systems. It thereby aims to facilitate a better understanding of how unexpected consequences of design, certification, limited and inadequate maintenance, negligent safety culture, economic factors, and human performance together can contribute to accidents. In this way it aims to contribute to accident prevention and the engineering of more resilient complex dynamic systems.

Barriers and Accident Prevention

Erik Hollnagel — 2008-05-31T09:18:57-00:00

(2004)

Contextual design

Hugh Beyer — 2006-10-26T13:18:42-00:00

interactions, Vol. 6, No. 1. (1999), pp. 32-42.

Hitting the target: adding interaction design to agile software development

Jeff Patton — 2007-08-28T14:41:30-00:00

(2002), pp. 1-ff.

Extreme Programming vs. Interaction Design

2008-05-10T12:55:26-00:00

(2003)

Getting the right design and the design right

Maryam Tohidi — 2006-10-15T17:00:52-00:00

(2006), pp. 1243-1252.

Towards a Framework for Integrating Agile Development and User-Centred Design

Stephanie Chamberlain — 2007-11-26T08:14:10-00:00

Extreme Programming and Agile Processes in Software Engineering (2006), pp. 143-153.

Due to a number of similarities between user-centred design (UCD) and agile development, coupled with an appreciation that developers are rarely usability experts, it seems attractive to integrate these two approaches. However, although agile methods share some of the same aims as UCD, there are also distinct differences. These differences have made the use of these methods on development projects problematic. This paper reports a field study designed to investigate the use of agile methods alongside UCD in one particular organization. The aim of the study was to develop a framework for use by project teams wishing to integrate UCD practices with agile development. The study, its findings and five principles for integrating UCD and agile development arising from this work are discussed.

Up-Front Interaction Design in Agile Development

Jennifer Ferreira — 2007-11-26T08:26:04-00:00

Agile Processes in Software Engineering and Extreme Programming (2007), pp. 9-16.

In this paper we address how interaction design and agile development work together, with a focus on the issue of interaction design being done “up-front”, before software development begins. Our study method used interviews with interaction designers and software developers on several agile teams. We used the qualitative approach of grounded theory to code and interpret the results. Our interpretation includes appreciation for benefits seen for a certain amount of up-front interaction design, and benefits from some levels of interaction design continuing with the iterations of software development.

When good things happen to bad products: where are the benefits of usability in the consumer appliance market?

Timo Jokela — 2005-01-18T02:45:08-00:00

interactions, Vol. 11, No. 6. (2004), pp. 28-35.

Spatio-temporal conceptual models: data structures + space + time

Christine Parent — 2006-07-26T10:20:01-00:00

(1999), pp. 26-33.

Topological fisheye views for visualizing large graphs

ER Gansner — 2006-02-21T02:49:33-00:00

Visualization and Computer Graphics, IEEE Transactions on, Vol. 11, No. 4. (2005), pp. 457-468.

Graph drawing is a basic visualization tool that works well for graphs having up to hundreds of nodes and edges. At greater scale, data density and occlusion problems often negate its effectiveness. Conventional pan-and-zoom, multiscale, and geometric fisheye views are not fully satisfactory solutions to this problem. As an alternative, we propose a topological zooming method. It precomputes a hierarchy of coarsened graphs that are combined on-the-fly into renderings, with the level of detail dependent on distance from one or more foci. A related geometric distortion method yields constant information density displays from these renderings.

Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design (Interactive Technologies)

Karen Holtzblatt — 2007-05-08T14:09:30-00:00

(14 December 2004)

Is it impossible to schedule enough time to include users in your design process? Is it difficult to incorporate elaborate user-centered design techniques into your own standard design practices? Do the resources needed seem overwhelming? This handbook introduces Rapid CD, a fast-paced, adaptive form of Contextual Design. Rapid CD is a hands-on guide for anyone who needs practical guidance on how to use the Contextual Design process and adapt it to tactical projects with tight timelines and resources. Rapid Contextual Design provides detailed suggestions on structuring the project and customer interviews, conducting interviews, and running interpretation sessions. The handbook walks you step-by-step through organizing the data so you can see your key issues, along with visioning new solutions, storyboarding to work out the details, and paper prototype interviewing to iterate the designall with as little as a two-person team with only a few weeks to spare! *Includes real project examples with actual customer data that illustrate how a CD project actually works. *Covers the entire scope of a project, from deciding on the number and type of interviews, to interview set up and analyzing collected data. Sample project schedules are also included for a variety of different types of projects. *Provides examples of how-to write affinity notes and affinity labels, build an affinity diagram, and step-by-step instructions for consolidating sequence models. *Shows how to use consolidated data to define a design within tight time frames with examples of visions, storyboards, and paper prototypes. *Introduces CDTools, the first application designed to support customer-centered design.

Visualizing Abstract Objects and Relations: A Constraint-Based Approach (Series in Computer Science)

Tomihisa Kamada — 2007-10-23T08:25:18-00:00

(30 November 1989)

EvoLens: lens-view visualizations of evolution data

J Ratzinger — 2006-05-17T21:39:05-00:00

Principles of Software Evolution, Eighth International Workshop on (2005), pp. 103-112.

Visualizing software evolution is essential for identifying design erosion that has occurred over the past releases. Making evolutionary aspects explicit via visual representations can help the engineer to focus on particular software parts to identify such hot-spots. Although many tools exist that provide zooming-in and -out within the hierarchical decomposition of a software system, only very few allow an engineer to view a system through a kind of lens view. Our approach called EvoLens is a visualization approach for explorations of evolution data across multiple dimensions. EvoLens is based on temporal lens views. But the graphical representation of this visualization integrates enhanced zooming by navigating through software hierarchies with arbitrary selectable groups of software parts across module or package boundaries. EvoLens allows an engineer to define a focal point for the lens view and navigate along the time dimension by user-defined sliding time windows. The comprehension is supported by using color for metrics of classes. The EvoLens prototype tool has been developed and tested on basis of a large Java application consisting of 580000 LOC that was studied over 18 months of its evolution lifetime.

A task oriented view of software visualization

JI Maletic — 2006-01-31T23:59:45-00:00

Visualizing Software for Understanding and Analysis, 2002. Proceedings. First International Workshop on (2002), pp. 32-40.

A number of taxonomies to classify and categorize software visualization systems have been proposed in the past. Most notable are those presented by Price (1993) and Roman (1993). While these taxonomies are an accurate representation of software visualization issues, they are somewhat skewed with respect to current research areas on software visualization. We revisit this important work and propose a number of re-alignments with respect to addressing the software engineering tasks of large-scale development and maintenance. We propose a framework to emphasize the general tasks of understanding and analysis during development and maintenance of large-scale software systems. Five dimensions relating to the what, where, how, who, and why of software visualization make up this framework. The focus of this work is not so much as to classify software visualization system, but to point out the need for matching the method with the task. Finally, a number of software visualization systems are examined under our framework to highlight the particular problems each addresses.

Multi-user, multi-display interaction with a single-user, single-display geospatial application

Clifton Forlines — 2006-11-07T11:58:26-00:00

(2006), pp. 273-276.

The Reflective Practitioner: How Professionals Think in Action

Donald Schon — 2005-06-11T05:59:13-00:00

(01 June 1983)

A leading MIT social scientist and consultant examines five professions--engineering, architecture, management, psychotherapy, and town planning--to show how professionals really go about solving problems.

Evaluating Software Complexity Measures

EJ Weyuker — 2006-12-19T22:09:39-00:00

IEEE Trans. Softw. Eng., Vol. 14, No. 9. (September 1988), pp. 1357-1365.

How can we think the complex?

Carlos Gershenson — 2004-11-22T00:17:30-00:00

(1 June 2004)

This chapter does not deal with specific tools and techniques for managing complex systems, but proposes some basic concepts that help us to think and speak about complexity. We review classical thinking and its intrinsic drawbacks when dealing with complexity. We then show how complexity forces us to build models with indeterminacy and unpredictability. However, we can still deal with the problems created in this way by being adaptive, and profiting from a complex system's capability for selforganization, and the distributed intelligence this may produce.

An evaluation of pan & zoom and rubber sheet navigation with and without an overview

Dmitry Nekrasovski — 2006-12-04T01:22:41-00:00

(2006), pp. 11-20.

The challenge of information visualization evaluation

Catherine Plaisant — 2005-02-22T22:19:19-00:00

(2004), pp. 109-116.

A Study of Navigation Strategies in Spatial-semantic Visualisations

Chaomei Chen — 2005-04-05T13:06:14-00:00

(2001), pp. 948-952.

Visualisations of abstract data are believed to assist the searcher by providing an overview of the semantic structure of a document collection whereby semantically similar items tend to cluster in space. Cribbin and Chen (2001) found that similarity data represented using minimum spanning tree (MST) graphs provided greater levels of support to users when conducting a range of information seeking tasks, in comparison to simple scatter graphs. MST graphs emphasise the most salient relationships...

Navigation patterns and usability of zoomable user interfaces with and without an overview

Kasper Hornb&\#230;k — 2006-03-24T23:24:20-00:00

ACM Trans. Comput.-Hum. Interact., Vol. 9, No. 4. (December 2002), pp. 362-389.

Reading of electronic documents: the usability of linear, fisheye, and overview+detail interfaces

Kasper Hornb&\#230;k — 2006-06-13T17:35:20-00:00

(2001), pp. 293-300.

Evaluating visualizations: do expert reviews work?

M Tory — 2006-06-06T21:37:04-00:00

Computer Graphics and Applications, IEEE, Vol. 25, No. 5. (2005), pp. 8-11.

Visualization research generates beautiful images and impressive interactive systems. Emphasis on evaluating visualizations is growing. Researchers have successfully used alternative evaluation techniques in human-computer interaction (HCI), including focus groups, field studies, and expert reviews. These methods tend to produce qualitative results and require fewer participants than controlled experiments. In this article, we focus on expert reviews that we used for the applications. We commonly use expert reviews to assess interface usability. Expert reviews can generate valuable feedback on visualization tools. We recommend i) including experts with experience in data display as well as usability, and ii) developing heuristics based on visualization guidelines as well as usability guidelines. Expert reviews should not be used exclusively, since experts might not hilly predict end-user actions. Furthermore, we encourage more experimentation with this technique, particularly to develop a good set of visualization heuristics and to compare it with other methods.