Navegación

Búsqueda

Búsqueda avanzada

El autor John W. Castro ha publicado 2 artículo(s):

1 - A HCI Technique for Improving Requirements Elicitation

Human computer interaction (HCI) uses development processes and techniques to assure that software product usability complies with minimum requirements. The Personas technique [3] gathers, analyses and synthesizes information related to the users that are to interact with the software system. This technique helps to focus software analysis and design on end user features and goals. However, it shares the shortcomings of other HCI techniques: it has no detailed definition of activities and products. These problems make the introduction of Personas into the software engineering (SE) requirements stage overly complex and unclear for developers. In order to design and implement a usable system, there should, according to HCI, be an understanding not only of users’ needs and goals but also of their characteristics and capabilities. The understanding of the people that interact with the system should constitute the groundwork for software development. The SE requirements activity could be improved by incorporating Personas technique tasks to understand the user. The goal of our research is to modify Personas to readily build the technique into the requirements stage of regular SE developments.
We studied Cooper’s version of the Personas technique [3] and set out to apply this technique in a case study [2]. From the very outset, we had trouble applying the technique. For example, the first step of the technique recommended by Cooper is Identify Behavioural Variables, that is, Cooper assumes that users have already been researched and the gathered data have been roughly organized. This task is not however explicitly mentioned in his description of Personas. The user study necessary to extract behavioural variables is not an altogether straightforward step and should be specified rather than implied as the technique’s first activity. Additionally, some technique activities, like Identify Significant Behaviour Patterns and Check for Completeness and Redundancy, fail to specify any output product. Finally, the final technique outputs are not related to the software engineering requirements stage. To be able to build Personas into routine SE developments, it is necessary to define activities and products associated with each activity. For each of the identified limitations, we devised an improvement to be built into Personas. We opted to incorporate these improvements into the latest version of the Personas technique published by Cooper et al. [3]. The grounds for this choice were: (i) Cooper made the original proposal; (ii) this proposal was the groundwork for research by other authors; and (iii) this proposal has been successfully used in a number of real projects. In [1], we incorporated these improvements into a SE version of Personas. Our proposal is composed of a group of activities and their associated inputs and outputs that, together, lead to the creation of personas [1]. As part of the first new activity, State Hypotheses for Personas, for example, a List of Hypotheses for the Personas to be created should be generated, and interviews should be designed and held with potential users. The responses from the Transcribed Interviews should then be used to gather the information required to carry out other activities. Second, as part of the Identify Behavioural Variables activity, we propose a new activity for synthesizing each response to the interviews held in the previous activity as behavioural variables. Third, we have defined a new activity that links the user research using Personas with the remainder of the requirements stage: Build Use Cases. This activity should output an Annotated Use Case Diagram. This diagram is based on the traditional use case diagram, to which we add a brief description of each persona involved in the use case. We applied our proposed technique to several case studies for validation [1]. Additionally, we designed and implemented a prototype tool to support the proposed Personas technique.
The improved Personas avoids the obstacles encountered by an average software developer unfamiliar with HCI techniques applying the original Personas. We think it is worthwhile adapting Personas for integration into SE development process. The integration of Personas into the SE requirements stage could improve the understanding of what the software product should do and how it should behave. The Personas technique appears to help focus the software analysis and design activities on end user characteristics and goals. We have enriched the SE requirements process by incorporating Personas activities into requirements activities. Requirements elicitation and requirements analysis are the requirements engineering activities most affected by incorporating Personas.
Acknowledgements. This work has been funded by the Spanish Ministry of Science and Innovation as part of the Tecnologías para la Replicación y Síntesis de Experimentos en IS (TIN2011-23216) and Go Lite (TIN2011-24139), and by Community of Madrid R&D program e-Madrid project (S2009/TIC-1650).

Autores: John W. Castro / Silvia T. Acuña / Natalia Juristo / 
Palabras Clave:

2 - Diferencias entre las Actividades de Mantenimiento en los Procesos de Desarrollo Tradicional y Open Source

Antecedentes. La creciente importancia del Open Source Software (OSS) ha llevado a los investigadores a estudiar cómo los procesos OSS difieren de los procesos de la ingeniería del software tradicional. Objetivo. Determinar las diferencias y similitudes entre las actividades del proceso de mantenimiento seguido por la comunidad OSS y el establecido por el estándar IEEE 1074:2006. Método. Para conocer las actividades que conforman el proceso de desarrollo OSS realizamos un Systematic Mapping Study. Posteriormente, realizamos un emparejamiento entre las actividades del estándar IEEE 1074:2006 con las actividades del proceso OSS. Resultados. Encontramos un total de 22 estudios primarios. De estos estudios, el 73% contaban con actividades relacionadas con el proceso de mantenimiento. Conclusiones. El proceso de mantenimiento tradicional del software no encaja con lo que ocurre en la comunidad OSS. En su lugar, puede ser mejor caracterizar la dinámica general de la evolución OSS como reinvención. Esta reinvención emerge continuamente de la adaptación, aprendizaje, y mejora de las funcionalidades y calidad del OSS. Los proyectos OSS evolucionan a través de mejoras menores donde participan tanto usuarios como desarrolladores.

Autores: John W. Castro / Silvia T. Acuña / Oscar Dieste / 
Palabras Clave: Open Source Software - Proceso de Mantenimiento - Systematic Mapping Study