Software Engineering Research/Developer Collaborations in 2004 (C104)

In 2004, six collaborations between software engineering technology providers and NASA software development personnel deployed a total of five software engineering technologies (for references, see Section 7.2) on the NASA projects. The main purposes were to benefit the projects, infuse the technologies if beneficial into NASA, and give feedback to the technology providers to improve the technologies. Each collaboration project produced a final report (for references, see Section 7.1). Section 2 of this report summarizes each project, drawing from the final reports and communications with the software developers and technology providers. Section 3 indicates paths to further infusion of the technologies into NASA practice. Section 4 summarizes some technology transfer lessons learned. Section 6 lists the acronyms used in this report

Mejora del proceso de elicitación de requisitos en proyectos GSD

La tendencia constantemente en alza de la globalización de empresas, y especialmente de los negocios relacionados con la producción de tecnologías de software, ha producido un profundo impacto tanto en las estrategias de marketing y distribución, como en la manera en que los productos son concebidos, diseñados, construidos, probados y entregados a los clientes [13]. Ejemplo de ello es que cada vez es más común el desarrollo de software en forma distribuida, o desarrollo global de software (GSD según las siglas en inglés), donde quienes participan del proceso de desarrollo (usuarios, clientes, desarrolladores) se encuentran localizados en países distintos. El principal motivo del crecimiento del GSD es que permite a las empresas disminuir los costos de desarrollo mientras se mantiene el nivel de calidad del proceso [5], contando con profesionales a lo largo y ancho del mundo sin necesidad de afrontar el costo de su traslado [16], o bien producir software para clientes remotos sin necesidad de trasladar el equipo de desarrolladores. También permite aumentar la productividad, por medio de jornadas de trabajo más extensas teniendo programadores distribuidos en sitios con amplia diferencia horaria [10]. Sin embargo, por su característica distribuida, los proyectos de GSD enfrentan varios problemas ocasionados por la distancia entre los participantes. Estos problemas son provocados por [9]: - la diferencia cultural, que comprende la variedad de lenguajes nativos de los participantes así como su comportamiento, - las dificultades en la comunicación, que se ve limitada por la tecnología utilizada - la diferencia horaria, que obstaculiza la interacción sincrónica, - la dificultad que representa gestionar el conocimiento en un entorno con fuentes de información variadas y distribuidas. Al analizar la literatura existente sobre el desarrollo global de software, hemos notado que la investigación anterior se centraba en determinar las limitaciones de la comunicación interpersonal y la gestión del conocimiento en entornos distribuidos, con el objetivo de definir su implicación en el proceso de desarrollo de software, pero que por lo general estos trabajos se dedican a las etapas más avanzadas de la ingeniería de requisitos (como la negociación y la especificación) y son muy pocos los trabajos referidos a las etapas iniciales. Por ello decidimos enfocar nuestro trabajo en la etapa de “elicitación de requisitos”, donde se necesita una interacción fluida entre desarrolladores, clientes, usuarios, y otros miembros de la organización para obtener información sobre el sistema que se desea construir [21]. Nuestro objetivo, por lo tanto, es proponer una metodología que minimice los problemas que puedan presentarse en la fase de recolección de requisitos en entornos distribuidos para obtener requisitos más precisos. A continuación presentamos un breve resumen de la revisión de conocimientos para cada área involucrada y finalmente hablaremos del estado actual de nuestra investigación.Eje: Ingeniería de Software y Base de DatosRed de Universidades con Carreras en Informática (RedUNCI

Mejora del proceso de elicitación de requisitos en proyectos GSD

La tendencia constantemente en alza de la globalización de empresas, y especialmente de los negocios relacionados con la producción de tecnologías de software, ha producido un profundo impacto tanto en las estrategias de marketing y distribución, como en la manera en que los productos son concebidos, diseñados, construidos, probados y entregados a los clientes [13]. Ejemplo de ello es que cada vez es más común el desarrollo de software en forma distribuida, o desarrollo global de software (GSD según las siglas en inglés), donde quienes participan del proceso de desarrollo (usuarios, clientes, desarrolladores) se encuentran localizados en países distintos. El principal motivo del crecimiento del GSD es que permite a las empresas disminuir los costos de desarrollo mientras se mantiene el nivel de calidad del proceso [5], contando con profesionales a lo largo y ancho del mundo sin necesidad de afrontar el costo de su traslado [16], o bien producir software para clientes remotos sin necesidad de trasladar el equipo de desarrolladores. También permite aumentar la productividad, por medio de jornadas de trabajo más extensas teniendo programadores distribuidos en sitios con amplia diferencia horaria [10]. Sin embargo, por su característica distribuida, los proyectos de GSD enfrentan varios problemas ocasionados por la distancia entre los participantes. Estos problemas son provocados por [9]: - la diferencia cultural, que comprende la variedad de lenguajes nativos de los participantes así como su comportamiento, - las dificultades en la comunicación, que se ve limitada por la tecnología utilizada - la diferencia horaria, que obstaculiza la interacción sincrónica, - la dificultad que representa gestionar el conocimiento en un entorno con fuentes de información variadas y distribuidas. Al analizar la literatura existente sobre el desarrollo global de software, hemos notado que la investigación anterior se centraba en determinar las limitaciones de la comunicación interpersonal y la gestión del conocimiento en entornos distribuidos, con el objetivo de definir su implicación en el proceso de desarrollo de software, pero que por lo general estos trabajos se dedican a las etapas más avanzadas de la ingeniería de requisitos (como la negociación y la especificación) y son muy pocos los trabajos referidos a las etapas iniciales. Por ello decidimos enfocar nuestro trabajo en la etapa de “elicitación de requisitos”, donde se necesita una interacción fluida entre desarrolladores, clientes, usuarios, y otros miembros de la organización para obtener información sobre el sistema que se desea construir [21]. Nuestro objetivo, por lo tanto, es proponer una metodología que minimice los problemas que puedan presentarse en la fase de recolección de requisitos en entornos distribuidos para obtener requisitos más precisos. A continuación presentamos un breve resumen de la revisión de conocimientos para cada área involucrada y finalmente hablaremos del estado actual de nuestra investigación.Eje: Ingeniería de Software y Base de DatosRed de Universidades con Carreras en Informática (RedUNCI

Two techniques for preventing domain knowledge transfer problems in requirements for high-confidence software

Inadequate communication of domain knowledge in natural language (such as English) has been implicated as a major source of requirements defects in high-confidence software. Such defects can lead to loss of lives and property. This thesis develops two techniques that offer partial solutions to the requirements defects problem. First, the thesis describes a technique for resolving requirements confusion, a problem that has been observed repeatedly during testing and operations of complex, high-confidence software, and a source of requirements defects. The technique defines requirements patterns for recurring sets of requirements confusion, and then uses these patterns to create formal specifications of the correct behavior. This approach allows the user to identify and explore any gaps between the expected and the correct behavior using the specification tool\u27s simulation capabilities. The thesis illustrates and evaluates the technique on real-world sets of requirements confusion involving watermarks. The second major contribution of this thesis is to describe a technique for preventing some timing requirements defects caused by communication gaps during domain knowledge transfer between system experts and software engineers. The technique applies timing constraints on software inputs and relies on data-age, a variable that must be defined for each input to the software. The thesis defines the guidelines for specifying the behavior of data-age variables, as well as how to use them in setting the timing constraints of the corresponding inputs. The technique is applied to a Mars Polar Lander (MPL) software module through formal specification of the module. Analysis shows how this technique could have been used to prevent a requirement defect due to the gaps in domain knowledge communication, perhaps preventing the MPL accident

Aus Fehlern in der Softwareentwicklung lernen. Wie durch Fehleranalysen die Prozesse der Anforderungsanalyse und der Qualitätssicherung verbessert werden können

Softwarefehler existieren, seit Menschen Software entwickeln. Fehler können mitunter zu erheblichen wirtschaftlichen Verlusten und im schlimmsten Fall zum Verlust von Leben führen. Viele Fehler können auf Mängel im Prozess der Anforderungsanalyse zurückgeführt werden. Je später ein Anforderungsfehler entdeckt und behoben wird, desto aufwändiger wird die Korrektur. Die vorliegende Arbeit beschreibt, wie aus Fehlern in der Softwareentwicklung gelernt werden kann. Sie beschreibt ein Verfahren zu Fehleranalyse, auf dessen Basis insbesondere Prozesse der Anforderungsanalyse und der Qualitätssicherung verbessert werden können. Ziel der Verbesserungen ist es, Anforderungsfehler und mögliche Folgefehler im Entwurf und der Implementierung zu vermeiden oder zumindest früher zu finden. In dieser Arbeit wird zunächst ein Modell hergeleitet, das erklärt, warum Anforderungsfehler entstehen. Für bestimmte Typen von Anforderungsfehlern werden auf der Grundlage empirische Befunde konkrete Ursachen im Prozess der Anforderungsanalyse aufgezeigt. Dieses Erklärungsmodell ist Bestandteil eines Verfahrens zur Fehleranalyse, das den Anspruch erhebt, über die Auswertung von Fehlern Rückschlüsse über mögliche Ursachen im Prozess zu ziehen. Das Verfahren ist eine Weiterentwicklung der Orthogonal Defect Classification, kurz ODC. ODC wird in der Arbeit ausführlich dargestellt und auf der Grundlage empirischer Befunde kritisch gewürdigt. Das weiterentwickelte Verfahren zur Fehleranalyse wurde im Rahmen einer einjährigen Fallstudie bei dem IT-Dienstleister einer großen deutschen Versicherung erfolgreich angewandt. Hierbei wurden nachträglich reale Fehler von zwei Softwareentwicklungsprojekten einer geschäftskritischen Anwendungssoftware klassifiziert und analysiert, um Verbesserungspotenziale zu identifizieren. Das in der Arbeit entwickelte Verfahren zur Fehleranalyse leistet einen unmittelbaren Beitrag zur Lösung des aufgezeigten Praxisproblems: sie ist ein Instrument, um Prozessmängel der Anforderungsanalyse zu identifizieren, die systematisch Anforderungsfehler und Folgefehler verursachen

Resolving Requirements Discovery in Testing and Operations

This paper describes the results of an investigation into requirements discovery during testing and operations. Requirements discovery includes both new requirements and new knowledge regarding existing requirements. Analysis of anomaly reports shows that many of the anomalies that occur during these phases involve requirements discovery. Previous work by the authors ident@ed four common mechanisms for requirements discovery and resolution during testing. The results reported here extend that work in two ways: (I) to show that very similar requirements-discovery mechanisms are at work in both testing and operations, and (2) to evaluate the requirements-discovery mechanisms against experience with seven additional systems. The paper discusses the consequences of these classijications and results in terms of reducing requirements-based defects in critical, embedded systems. Keywords: requirements discovery, requirements evolution, defect analysis, safety-critical systems, testing, operations. 1