Overview
Documentation
Project Documentation
First International IEEE Conference on Global Software Engineering, 2006(ICGSE 06)
Abstract:
In global software projects, informal communication across sites is severely hampered, making it difficult to disseminate implicit
knowledge. Participants have a partial view of the overall organization, do not have access to the complete rationale behind decisions,
and when changes arise, participants from other sites are surprised. Consequently, issues that could be clarified almost immediately
require days until the relevant stakeholders are identified, the issues are understood, and a resolution is agreed upon.
We focus on the specific problem of externalizing issues with their context, stakeholders, and organizational roles in distributed settings. The challenge is to capture sufficient knowledge as a side effect of development, while structuring it for long-term use. We describe Sysiphus, a distributed environment providing a uniform framework for system models, collaboration artifacts, and organizational models. Sysiphus encourages participants to make communication and issues explicit in the context of system models and become aware of relevant stakeholders.
Proceedings of the International Workshop on Distributed Software Development, 2005(DiSD 05)
Abstract:
Traceability is the ability to follow the life of a requirement, both in forward and backward directions. Traceability facilitates dealing with change, by identifying which components may be impacted and by identifying which stakeholders may need to be consulted when specific requirements are revised. Rationale is the justification behind decisions, including alternatives explored, evaluation criteria, arguments, and decisions. In typical projects, little traceability or rationale is explicitly documented, because of the overhead and cost of capturing and maintaining this information. Instead, this information is often exchanged among stakeholders informally and during peer review activities or reconstructed when changes or issues arise. In distributed projects, opportunities such information exchanges are significantly reduced, resulting in even less traceability and rationale being captured. However, this information is critical when assessing the impact of changes, as few participants in a distributed setting have a complete overview of the system and the stakeholders involved.
In this paper, we propose a model and tool support for uniformly representing and integrating system models and rationale. We support traceability within and across these models. Participants collaborate by attaching annotations, action items, and issues to the system models, providing the relevant collaboration context. By dealing with all three types of information together, we aim to increase their value, to decrease the overhead and cost of capturing and maintaining rationale and traceability, while providing participants an incentive for maintaining their consistency. To follow existing traces and dependencies across system models and rationale, we provide alternate graphical user interfaces that focus on clear and simple design and on desired tasks.
Software Engineering im Unterricht der Hochschulen. Aachen, 2005(SEUH05)
Abstract:
An der Universität Heidelberg wurde die Veranstaltung "Software Engineering" im Bachelor-Studiengang "Angewandte Informatik"
erstmals mit einem großen Anteil praktischer übungen durchgeführt. Die Herausforderung war, in Vorlesung und übung eines
Semesters mit 6 Semesterwochenstunden die Studierenden zu befähigen an einem Softwaresystem realistischer Größe systematisch
änderungen durchzuführen.
Die innovative Kernidee unseres Vorgehens ist, dass sich die Studierenden in der ersten Hälfte durch Reverse-Engineering in ein existierendes, komplexes Softwaresystem einarbeiten, und letzteres dann in der zweiten Hälfte mit einem systematischen Entwicklungsvorgehen erweitern. In diesem Beitrag stellen wir unsere Vorgehensweise, das bearbeitete Softwaresystem und die verwendeten Werkzeuge, sowie unsere Erfahrungen vor.
13th International Conference on Intelligent & Adaptive Systems and Software Engineering, July 1-3, 2004, Nice, France (IASSE'04)
Abstract:
The Rationale-based Analysis Tool (RAT) supports analysts, developers, clients and end users during the object-oriented requirements
analysis activity. The tool enables different stakeholders to create, generate and refine a consistent and traceable analysis model,
from a use case model. The analysis model consists of UML classes and sequence diagrams. The tool uses traceability links to propagate
modifications by automated actions and to enable users to navigate through different models and to detect their interrelations.
Moreover, RAT integrates requirements analysis with rationale information to support and capture model negotiations consisting of
alternatives, assessments, arguments and justifications. RAT is a location independent multi-user tool that supports synchronous and
asynchronous group collaboration.
Requirements Engineering Journal, Vol. 7, No. 1, pp. 3--9, 2002.(Springer)
Abstract:
The requirements specification - as outcome of the requirements engineering process - falls short of capturing other useful information
generated during his process, such as the justification for selected requirements, trade-offs negotiated by stakeholders and alternative
requirements that were discarded. In the context of evolving systems and distributed development, this information is essential. Rationale
methods focus on capturing and structuring his missing information. In this paper, we propose an integrated process with dedicated guidance
for capturing requirements and their rationale, discuss its tool support and describe the experiences we made during several case studies
with students. Although the idea of integrating rationale methods with requirements engineering is not new, few research projects so far
have focused on smooth integration, dedicated tool support and detailed guidance for such methods.
7th Internaltional Workshop on Requirements Engineering for Software Quality. (REFSQ'2001), Interlaken Switzerland, June 4-5, 2001.
Abstract:
Few requirements engineering techniques are widely applied in industry. This canbtool support, and technique integration. In this paper,
we describe dedicated tool support and guidance for rationale-based use case specification, which we incrementally derived from several
students experiments. Through this example, we want to promote student experiments as a good basis for developing and improving guidance
material and tool support, hence facilitating technology transfer.
6th Internaltional Workshop on Requirements Engineering for Software Quality. (REFSQ'2000), Interlaken Switzerland, June, 2000.
Abstract:
The requirements specificationbprocessbthis process, such as the justification for selected requirements, trade-offs made by stakeholders,
and alternative requirements that were discarded. In the context of evolving systems and distributed development, this information is essential.
Rationale methods focus on capturing and structuring this missing information. In this paper, we propose an integrated process for capturing
requirements and their rationale, discuss its tool support, and describe planned experiments to evaluate this process. Although the idea of
integrating rationale methods with requirements engineering is not new, few research projects have focused on the use of rationale during later
phases to support the evolution of the system under development.