Ingeniería de Requisitos del Proceso Unificado en Pequeñas Organizaciones Desarrolladoras de Software

Ingenier´ıa de Requisitos del Proceso Unificado en Peque˜nas Organizaciones Desarrolladoras de Software Jhon J. Alvarez Londo˜no

Julio A. Hurtado Alegr´ıa

Grupo IDIS Universidad del Cauca email: [email protected]

Grupo IDIS Universidad del Cauca email: [email protected]

Resumen—La norma de calidad ISO 29110 ha sido elaborada ˜ con el fin de brindar soporte a las pequenas organizaciones a estandarizar sus procesos de desarrollo de software. Las ˜ organizaciones aun consideran dif´ıcil la adopci´on de pequenas ˜ y por ende a su est´andares de calidad debido a su tamano capacidad sobre recursos financieros y humanos. Con el objetivo de disminuir la dificultad de interpretaci´on, en este trabajo se ilustran los primeros avances de un modelo de ciclo de vida basado en el Proceso Unificado (UP-VSE) implementando pr´acticas de la Ingenier´ıa de Requisitos del perfil b´asico de la ˜ entidades un caso norma ISO 29110-5-1 otorgando a las pequenas ilustrativo y reutilizable que permitan mejorar su interpretaci´on e implementaci´on de esta norma. Esta propuesta ha sido filtrada a trav´es de un estudio de caso aplicado a un grupo de investigaci´on y desarrollo en autom´atica industrial concluyendo que, para esta primera aproximaci´on, la propuesta UP-VSE cubre los aspectos mas importantes de la norma en el a´ mbito de la elicitaci´on de requerimientos de software. ˜ Palabras Clave—Mejora de Procesos de Software, Pequenas Organizaciones, ISO 29110, Proceso Unificado, Ingenier´ıa de Requisitos. Abstract—In an attempt to increase the competitiveness of small organizations, the ISO has developed a standard, the ISO 29110. Due to its recent emergence, the high rates of the unknowledge about its implementation and associated costs, it is still difficult for small organizations to take this standard into practice. In order to reduce the conceptual gap, in this paper has been purposed a software process model (UP-VSE) bassed on the Unified Process, which implements the requirements engineering practices of ISO 29110-5-1-1 in order to companies can have an illustrative and reusable case allowing them to increase the standard interpretation and implementation. This proposal has been empirically evaluated defining PRODIGIA software process in the context of a research and development group of industrial automation. This initial approach established that UP-VSE accomplish the main ISO 29110 issues. Index terms—Software Process Improvement, Very Small Entities, ISO 29110, Unified Process, Software Requirements Engineering.

´ I. I NTRODUCCI ON Una industria de software competitiva es una industria capaz de hacer la diferencia con productos de calidad y proyectos productivos. Estos dos aspectos se pueden lograr a partir de muchas estrategias t´ecnicas y de gesti´on. Una de e´ stas es la mejora del proceso de software, basada en la premisa que

los procesos determinan la calidad de los productos [1] y la productividad de los proyectos [2]. As´ı, la industria de software ha venido considerando el proceso de software como un activo muy importante dentro de las organizaciones. Un proceso es un “conjunto de actividades relacionadas que conducen a la creaci´on de un producto software” [3], [4]. Seg´un I. Jacobson et al. “Un proceso define el qui´en est´a haciendo qu´e, cu´ando y c´omo construir un producto software o mejorar uno existente” [5]. Como la calidad del proceso afecta directamente la calidad del producto, se han creado est´andares de calidad para el desarrollo de software con el fin de realizar la mejora de los procesos de las empresas. En efecto, las peque˜nas organizaciones desarrolladoras de software o Very Small Entities (VSE) tambi´en invierten esfuerzos para obtener certificaciones y como consecuencia lograr m´as competitividad. Sin embargo, lo hacen a trav´es de est´andares como ISO/IEC 12207 o CMMI, que no est´an dise˜nadas para empresas de este tama˜no [6], [7]. El grupo de trabajo SC7-WG24 ha desarrollado la norma ISO/IEC 29110, un modelo de referencia para la mejora de procesos (SPI) de las VSE [8] que en su totalidad hacen el 75% de las empresas de desarrollo de software a nivel mundial [6]. Sin embargo, su reciente aparici´on como est´andar internacional, sus altos costos de implementaci´on y evaluaci´on al interior de las VSE, as´ı como su inherente complejidad, se convierten en las principales barreras para su adopci´on [9]. O’Connor et al. [6] reconocen la necesidad de las VSE en la definici´on de un est´andar de software que soporte el ciclo de vida y los procesos al interior de estas organizaciones argumentando que, a pesar de contar con pr´acticas de software probadas de est´andares como ISO/IEC 12207 o CMMI, no cuentan con el suficiente nivel de soporte para grupos de ingenier´ıa de software menores a 25 personas, en efecto, es inevitable tratar de aplicar en las configuraciones de los modelos de ciclo de vida de estas normas con un alto nivel de dificultad. Este trabajo toma en cuenta el amplio recorrido en la industria de desarrollo de software y en la ense˜nanza del UP para tratar de abordar la implementaci´on de la norma ISO/IEC 29110, usando la disciplina del ingenier´ıa de re-

quisitos del Proceso Unificado y as´ı reducir el esfuerzo de entendimiento e implementaci´on en las VSE. UP es un modelo de proceso reutilizable y adaptable de software bien conocido por la industria y ampliamente aceptado por la comunidad acad´emica [10]. La implementaci´on de la norma respecto al UP se realiza bajo la evaluaci´on de los elementos tomados de los subprocesos de requisitos de la ISO/IEC 29110-5-1-1 respecto de los elementos presentes en el flujo de trabajo de la disciplina de requerimientos del Proceso Unificado, apoyado en las plantillas de los artefactos del RUP (Proceso Unificado de Rational) presentes en el flujo de trabajo propuesto por I. Jacobson et al. [5]. Para evaluar la aplicabilidad de la propuesta se ha realizado con un estudio de caso en una VSE con un grupo de investigadores en el a´ rea de software de robotica quir´urgica del grupo AI de ingenier´ıa autom´atica industrial de la Universidad del Cauca que llevan a cabo proyectos que involucran el desarrollo de software, los cuales siguen PRODIGIA (Proceso de Desarrollo Industrial del Grupo de Ingenier´ıa Autom´atica) una metodolog´ıa basada en el Proceso Unificado. El resto de este art´ıculo se ha organizado de la siguiente forma. La secci´on II introduce trabajos relacionados, as´ı como la definici´on del Proceso Unificado, la norma ISO/IEC 29110, sus relaciones y aplicaciones en la industria. La secci´on III presenta el marco de evaluaci´on que es utilizado en el resto del art´ıculo. La secci´on IV presenta una evaluaci´on te´orica del cumplimiento del Proceso Unificado respecto a la norma ISO 29110-5-1-11 mostrando el respectivo proceso que ha sido llevado a cabo, la secci´on V ilustra la disciplina de ingenier´ıa de requisitos del modelo de procesos UP-VSE, la secci´on VI presenta la misma evaluaci´on pero desde una perspectiva emp´ırica usando el proceso PRODIGIA. Finalmente, la secci´on VII presenta las conclusiones, limitaciones y trabajos futuros. II. A NTECEDENTES Y T RABAJOS R ELACIONADOS A. El Proceso Unificado El Proceso Unificado se describe como “un marco de trabajo gen´erico que puede especializarse para una gran variedad de sistemas software, para diferentes a´ reas de aplicaci´on, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tama˜nos de proyecto” [5]. El proceso unificado posee 3 caracter´ısticas fundamentales: est´a dirigido por casos de uso2 , est´a centrado en la arquitectura de software3 y es iterativo e incremental4 . El ciclo de vida del proceso unificado consta de 4 fases (inicio, elaboraci´on, 1 Ha sido seleccionada esta parte de la norma dado que este perfil contiene todos los aspectos que una VSE debe tener para cumplir la evaluaci´on del est´andar 2 Cuando ”un proyecto est´ a dirigido por casos de uso significa que progresa a trav´es de una serie de flujos de trabajo que se inician a partir de los casos de uso” [5]. 3 La arquitectura da una clara perspectiva de la construcci´ on del software, por este motivo la construcci´on gira en torno a la arquitectura [5] 4 La divisi´ on del esfuerzo de trabajo en el Proceso Unificado se hace por iteraciones en donde al final de cada una se presentan incrementos del producto software. [5]

construcci´on y transici´on) en donde cada una termina con un hito y contiene un n´umero finito de iteraciones. A lo largo del ciclo de vida se ejecutan los 5 flujos de trabajos fundamentales (requisitos, an´alisis, dise˜no, implementaci´on y pruebas) [5]. El proceso unificado es una metodolog´ıa de desarrollo de software compleja en sus artefactos y en sus procesos, por tanto, es necesario adaptar el proceso unificado a las necesidades particulares de una entidad desarrolladora de software. El trabajo de Hanssen et. al. [11] concluye que el proceso unificado, a pesar de ser una metodolog´ıa de desarrollo, sigue siendo un proceso que est´a en alto nivel y por lo tanto necesita ser adaptado al contexto de las organizaciones y de los proyectos. B. La norma ISO/IEC 29110 Para apoyar las peque˜nas empresas en la mejora de sus procesos organizacionales, ISO, a trav´es del grupo de trabajo SC7-WG24 ha creado la norma ISO 29110. C. Laporte et al. [6] ilustran los inicios del desarrollo de la norma ISO/IEC 29110 aproximada por el grupo de trabajo WG24 tomando aspectos de la norma ISO/IEC 12207 y adapt´andolos al contexto VSE y la necesidad de las peque˜nas organizaciones desarrolladoras de software en su intento por estandarizar sus modelos de ciclo de vida. La norma establece un marco com´un para describir perfiles evaluables del ciclo de vida de software para ser usados en las VSE. • Visi´ on General (TR ISO 29110-1): Introduce los conceptos principales necesarios para la comprensi´on de la norma ISO 29110, aspectos de negocio, caracter´ısticas y requisitos de las VSE. Esta secci´on de la norma aclara la raz´on de ser de los perfiles espec´ıficos, documentos, est´andares y gu´ıas de VSE e introduce los conceptos de proceso b´asico, ciclo de vida y estandarizaci´on, y la familia de documentos ISO 29110. • Perfiles (ISP): Permite empaquetar referencias a y/o partes de otros documentos de manera formal con el fin de adaptarlos a las necesidades y caracter´ısticas de las VSE, lo que implica producir 2 tipos de documentos para esta norma: – Marco de trabajo y taxonom´ıa (ISP 29110-2) – Especificaciones de perfil (29110-4-m) • Gu´ıas: Contienen directrices de aplicaci´ on (de dominio espec´ıfico) sobre c´omo realizar los procesos para alcanzar los niveles de madurez (por ejemplo, actividades recomendadas, medidas, t´ecnicas, plantillas, modelos, m´etodos, entre otros). Hay 2 tipos de gu´ıas: – Gu´ıa de evaluaci´on (TR29110-3): Describe el proceso a seguir para realizar una evaluaci´on que determine las capacidades de proceso y/o madurez organizacional. – Gu´ıa de ingenier´ıa y gesti´on (TR29110-5-m-n, donde m es el numero del perfil anteriormente ilustrado y n el numero de la gu´ıa de ingenier´ıa y gesti´on.) Espec´ıficamente, El perfil 29110-5-1-1 (Gu´ıa de ingenier´ıa y gesti´on - Perfil B´asico) se compone de 2

procesos: Administraci´on del Proyecto y Desarrollo de Software, de los cuales este estudio s´olo tomar´a la gu´ıa de ingenier´ıa como marco de referencia para la evaluaci´on. Esta secci´on de la norma cuenta con 6 subprocesos (Software Implementation Initiation, Software Requirements Analysis, Software Architectural and Detailed Design, Software Construction, Software Integration and Test, Product Delivery) que sirven de puntos de referencia para el an´alisis del Proceso Unificado.

El trabajo de Motschnig-Pitrik [17] muestra la experiencia del autor al haber aplicado el Proceso Unificado en el desarrollo de una aplicaci´on web en cooperaci´on con una agencia de cuatro personas discutiendo los puntos fuertes y debiles del Proceso Unificado. Este trabajo se concluye que el UP facilita analizar aspectos acerca de c´omo invertir el esfuerzo del proyecto y obtener una temprana retroalimentaci´on del cliente, entre otras. Sin embargo un miembro del equipo debe contar con experiencia en el Proceso Unificado, y los miembros del equipo deben contar con experiencia en el manejo de UML.

C. Los paquetes de despliegue (DP) O’Connor et al. presentan los paquetes de despliegue o Deployment Packages (DP) [9], [12], [13], como mecanismos que facilitan la adopci´on de la norma ISO/IEC 29110 donde se encuentran varios patrones sobre la adopci´on, brindando detalles de la incorporaci´on del est´andar ISO/IEC 29110 a trav´es de los DP. Esta validaci´on se ha llevado a cabo con proyectos piloto en VSE de pa´ıses como Canad´a, Francia, B´elgica y otros m´as participaron en la utilizaci´on de estos paquetes con resultados satisfactorios. Aunque presenta los mecanismos de adopci´on, los paquetes de despliegue no presentan un modelo de proceso concreto que sirva como punto de referencia o caso de estudio para una VSE . D. Implementaci´on de normas de calidad a trav´es de distintas versiones del UP Lutteroth et al. [14] muestran un trabajo sobre la creaci´on de un modelo de flujo de trabajo completo para una compa˜n´ıa TIC con el fin de alcanzar el nivel 3 de CMMI. La compa˜nia utiliz´o el Proceso Unificado como mecanismo de implementaci´on de CMMI resaltando la importancia de esta metodolog´ıa en la implementaci´on de modelos propios de la industria de software. Falbo et. al. [15] trabajan un mapeo de roles a equipos peque˜nos de desarrollo de software que fue aplicado a un estudio de caso de un equipo dentro de una organizaci´on evaluada en CMM nivel 3, definiendo una serie de roles base, en donde, para que sean considerados escenciales deben cumplir una de tres condiciones mencionadas en el trabajo de Monteiro et. al. [16], para luego ser mapeados con los roles del RUP (39 en total), quedando reducidos a 13. De estos roles se ha definido cuales pueden ser integrados entre RUP y los roles base y cu´ales no, indicando en algunos casos (con una “X” en el mapeo) cuales roles deben ser absolutamente restringidos cuando deben ser asignados a una misma persona. E. Casos involucrando el Proceso Unificado en peque˜nas organizaciones Tanto en el ambito acad´emico como en el industrial, se ha utilizado el Proceso Unificado en organizaciones VSE. El trabajo de Halling et. al. [10] ilustra esta metodolog´ıa aplicada a estudiantes de un curso de ingenier´ıa de software orientado a objetos, en el que se mencionan las razones para utilizarlo en la formaci´on de ingenieros de software, entre las cuales resalta su facil comprensi´on.

F. Evaluaci´ones de procesos involucrando al UP El objetivo principal del trabajo realizado por M. Trujillo et. al. [18] es clarificar la brecha que existe entre MoProSoft nivel de capacidad 2 y la ISO/IEC 29110-5-1-2. Ambos modelos de proceso fueron mapeados y evaluados utilizando las metricas mencionadas en la ISO/IEC 15504-2 que determinaron el nivel de capacidad seg´un los resultados de soporte matem´atico de la evaluaci´on de este trabajo. El art´ıculo concluye que MoProSoft nivel 2 cubre el 85% de las tareas y 94% de los productos de trabajo. Esta evaluaci´on abre las posibilidades para obtener una certificaci´on internacional en corto tiempo en las empresas que adopten MoProSoft nivel 2 en sus procesos. ´ PARA INGENIER´I A DE III. P ROCESO DE EVALUACI ON REQUISITOS DE LA ISO/IEC 29110 El Modelo de Evaluaci´on del Proceso que propone la ISO/IEC 29110:20125 es un modelo de capacidad del proceso bi-dimensional. Una es la dimensi´on de los procesos bajo evaluaci´on, la otra, la dimensi´on de la capacidad, define un conjunto de atributos de proceso agrupados en niveles de capacidad. Los atributos de proceso son las caracter´ısticas medibles de la capacidad del proceso. Los indicadores de la capacidad del proceso son los medios para lograr las capacidades direccionadas por los atributos de proceso considerados. La evidencia de los indicadores de la capacidad del proceso soporta el juicio del grado de completitud del atributo de proceso [19]. En el dise˜no de la evaluaci´on se han tomado aportes que pueden ser encontrados en [20], [21]. A. Respecto a la norma ISO/IEC 29110-3 Se ha realizado un plan de evaluaci´on liviano conforme a las especificaciones del modelo de evaluaci´on de la ISO/IEC 29110-3 para los perfiles b´asicos [19]. La subsecci´on 6.3 de esta parte de la norma especifica que: “Los requisitos para el cumplimiento de los perfiles VSE pueden ser derivados de las respectivas partes ISO/IEC 29110-4 e ISO/IEC 291105”. Como m´ınimo, todos los elementos obligatorios del perfil VSE, definidos en la ISO/IEC 29110-4, necesitan ser considerados en la evaluaci´on, as´ı por ejemplo, los procesos evaluados del perfil VSE b´asico necesitan alcanzar el nivel de capacidad 1 definido en la ISO/IEC 15504-2. Esto significa que el proceso implementado logra su prop´osito del proceso y sus salidas definidas”. La figura 1 ilustra como est´an involucrados los 5 Versi´ on

de la norma utilizada por defecto para el resto de este trabajo

aci´on ISO/IEC 29110-3 (ver secci´on III) los niveles de capacidad a evaluar son 0 y 1 – Escala de calificaci´on de los atributos de proceso: Se utiliza la escala de la ISO/IEC 15504-2 [22]

Figure 1. Elementos de la evaluaci´on de procesos en VSE adaptado de [19].

3) Descripci´on de los niveles de capacidad: a) Nivel 0: “El proceso no est´a implementado o falla en lograr su prop´osito”, para este trabajo se han tomado los objetivos de los subprocesos de ingenier´ıa de requisitos de la norma. b) Nivel 1: “El proceso implementado cumple el prop´osito del proceso de referencia”, asociado a este nivel se encuentra el atributo de proceso: •

Figure 2. Elementos instanciados de la evaluaci´on en ISO/IEC 15504-2.

elementos en la evaluaci´on de procesos en las organizaciones VSE. B. Modelo de evaluaci´on de la ISO/IEC 15504 1) Generalidades: Conforme a lo mencionado en la secci´on anterior es necesario hallar el nivel de capacidad del proceso evaluado, en este caso del Proceso Unificado respecto a ISO/IEC 29110-5-1-1 perfil b´asico. La figura 2 ilustra la configuraci´on de los elementos participan en la ejecuci´on de la evaluaci´on [22]. 2) Marco de trabajo y alcance de la ISO/IEC 15504: Se tomar´a en cuenta el nivel de capacidad 1 para cumplir con el perfil b´asico, por lo tanto esta se acota a algunas categor´ıas y atributos de proceso de la ISO/IEC 15504 y se conserva la escala de evaluaci´on para los atributos de proceso encontrados en la ISO/IEC 15504-5 [23]: • Dimensi´ on del proceso: Para las siguientes evaluaciones se escogen las categor´ıas del ciclo de vida del proceso – Grupo de procesos de Ingenier´ıa (ENG): ∗ ENG.1: Proceso de an´alisis y dise˜no de los requisitos del sistema. ∗ ENG.2: An´alisis de los requisitos del software. • Dimensi´ on de la capacidad: – Niveles de capacidad: Para efectos de coherencia conforme a lo mencionado en el modelo de evalu-

PA. 1.1 - Realizaci´on del proceso: La plena realizaci´on de este atributo de proceso ofrece como resultado que el proceso logre sus salidas definidas. A continuaci´on se ilustran los respectivos indicadores de proceso a traves de practicas de gesti´on (MP) [23] que han sido seguidas en esta evaluaci´on: – MP 1.1.1 - Identificar los productos de trabajo de entrada y salida: aparte de su identificaci´on se procede a verificar las caracter´ısticas que deben tener estos productos y si cumplen o ayudan a cumplir o no el objetivo del proceso. – MP 1.1.2 - Se debe asegurar que el alcance del trabajo se ha identificado para la ejecuci´on de los procesos y de los productos de trabajo a ser usados y producidos en el proceso: para cada proceso, las pr´acticas base conllevan a lograr el prop´osito y salidas definidas en el proceso y existe evidencia que las pr´acticas base son llevadas a cabo. – MP 1.1.3 - Asegurarse que las pr´acticas base son implementadas, elaborando productos de trabajo que apoyan el logro de las salidas defenidas del proceso: para cada proceso, el alcance del trabajo es identificado en el proceso en ejecuci´on.

4) Medici´on en la dimensi´on de la capacidad: Dado que la evaluaci´on se har´a en el primer nivel de capacidad y que por lo tanto solo se incluir´a un solo atributo de proceso (ver secci´on III-B3) se vinculan los respectivos indicadores de capacidad del proceso mencionados en la secci´on B.2.1 del Anexo B de la norma ISO/IEC 15504-5 [23]. 5) Medici´on en la dimensi´on del proceso: Fue necesaria la realizaci´on de un mapeo entre la ISO/IEC 12207:20085 y la ISO/IEC 29110-5-1-1 para asegurar equivalencias en la evaluaci´on de la ISO/IEC 15504. (ver tabla I6 ). Para continuar la evaluaci´on entre la ISO/IEC 12207 previamente mapeada con los procesos de la ISO/IEC 29110-5-1-1, se procede a determinar la equivalencia de procesos con el Proceso Unificado. La tabla II ilustra los subprocesos de captura de requisitos presentes en la norma ISO/IEC 12207 y el UP que entrar´an en las evaluaciones que conciernen a este trabajo. 6 Los nombres de las actividades de estas secciones se han acortado para una comprensi´on m´as r´apida del lector, los nombres completos de las tareas pueden ser encontrados en las respectivas normas asociadas.

ISO/IEC 12207 7.1.2.3.1 An´alisis de requisitos de software 6.3.1.3.2.1 Preparar los planes para la ejecuci´on del proyecto.6 Subsecci´on e: asignaci´on de responsabilidades 7.1.2.3.1.1 Establecer y documentar el reporte de especificaci´on de requisitos6 (sin las caracter´ısticas de calidad mencionadas en este punto de la norma). 7.1.2.3.1.2 Evaluar los requisitos de software6 (sin consideraci´on de los criterios mencionados en este punto de la norma)

ISO/IEC 29110-5-1-1 SI. 2 An´alisis de requisitos de software SI. 2.1 Asignar tareas a los miembros del equipo de trabajo en conformidad con su rol respectivo basandose en el plan de proyecto concurrente. SI. 2.2 Documentar o actualizar los requisitos de software SI. 2.3 Validar y obtener aprovaci´on de la especificaci´on de requisitos

Table I E QUIVALENCIA ENTRE PROCESOS Y TAREAS INVOLUCRADAS EN EL MAPEO

UP I. Jacobson et.al. [5] / PRODIGIA / UP-VSE 7 Disciplina de ingenier´ıa de requisitos

ISO/IEC 12207 7.1.2.3.1 An´alisis de requisitos de software

Table II S UBPROCESOS DE CAPTURA DE REQUISITOS ENTRE LA NORMA ISO/IEC 12207 Y UP Valores de cobertura (C) T - Totalmente L - Ampliamente P - Parcialmente N - No logrado

Porcentaje 85 - 100% 50 - 85% 15 - 50% 0 - 15%

Puntaje asignado (Q) 1.0 0.7 0.3 0.0

Table III R ANGOS DE CAPACIDAD Y PUNTAJES ASIGNADOS

en donde: – T y W: Es el conjunto de tareas y productos de trabajo del proceso respectivamente. – Ti y Wi : Es la i-esima tarea y el i-esimo producto de trabajo del proceso respectivamente. – |T| y |W|: Es el numero total de las tareas y productos de trabajo del proceso respectivamente. |T | P – QT [CT {Ti }]: Es la suma de cada uno de los i=1

niveles quantitativos (puntajes) de las tareas del proceso. |W P| – QW [CW {Wi }]: Es la suma de cada uno de los i=1

En el presente art´ıculo se realizan 3 evaluaciones basadas en esta estructura, por tanto este mapeo se utiliza en cada una respecto al modelo de ciclo de vida a evaluar tomando como punto de partida los resultados de los procesos de la norma ISO/IEC 12207 de esta secci´on. 6) M´etricas y reglas de cobertura: Las m´etricas definidas en la ISO/IEC 15504-5 fueron usadas para determinar los valores de cobertura esenciales para este trabajo y bas´andose en los niveles de Cobertura (C), a cada valor en C se le ha sido asignado un puntaje utilizado para definir un nivel Cuantitativo (Q). La tabla III ilustra la relaci´on entre los valores de la evaluaci´on seg´un la ISO/IEC 15504-5 y el puntaje asignado, el cual est´a basado en el trabajo de M. Trujillo et. al.[18]. Tomando los indicadores de capacidad de proceso filtrados en la secci´on III-B4 junto a los subprocesos mapeados en la secci´on III-B5 utilizando la ISO/IEC 12207 como un modelo de referencia de procesos intermediario se procede a definir la evaluaci´on: • El nivel de cobertura (C) y el cuantitativo (Q) aplica para las tareas (CT o´ QT ), productos de trabajo (CW o´ QW ) y el proceso (CP o´ QP ) • Para hallar el nivel de cobertura de un proceso se aplica la siguientes formula generales:  |T |  P QT [CT {Ti }]  i=1   CT (QT [T areas]) = CT    |T | y

CW (QW [P roductos de

 |W |  P QW [CW {Wi }]  i=1   trabajo]) = CW    |W |

niveles quantitativos (puntajes) de los productos de trabajo del proceso. • Un ejemplo de la aplicaci´ on de esta formula puede ser encontrado en el trabajo de M. Trujillo et. al.[18]. • Cada puntaje tanto de tareas y productos de trabajo se evaluaron por aparte por lo tanto dar´an distintas perspectivas de CP y QP . • No se considera el tiempo en la ejecuci´ on tanto de tareas como de artefactos en la evaluaci´on. 7) Metodolog´ıa de evaluaci´on: Bas´andose en la estructura metodol´ogica propuesta en la ISO/IEC 15504 [24], se ha dise˜nado un modelo de evaluaci´on siguiendo una serie de tareas: • An´ alisis de los modelos de ciclo de vida: esta actividad involucra las siguientes tareas: (i) obtener trabajos sobre los modelos a evaluar, (ii) analizar su estructura y (iii) buscar las plantillas de los productos de trabajo asociadas a cada modelo de ciclo de vida. • Dise˜ no de la evaluaci´on: esta actividad involucra las siguientes tareas: (i) definir la direcci´on de la evaluaci´on, (ii) realizar el mapeo de la evaluaci´on para la ISO/IEC 15504, en este caso entre la ISO/IEC 12207 y la ISO/IEC 29110-5-1-1 (iii) dise˜nar la plantilla de evaluaci´on (tareas relacionadas con la captura de requisitos de la norma ISO/IEC 29110-5-1-1 y los distintos modelos de ciclo de vida involucrados en conjunto con las plantillas asociadas a cada modelo si existen), (iv) definir escalas de evaluaci´on y (v) verificar la coherencia y direcci´on de la evaluaci´on y de los resultados. • Ejecuci´ on de la evaluaci´on: esta actividad involucra las siguientes tareas: (i) realizar la equivalencia entre procesos de la ISO/IEC 12207 y los modelos de ciclo de vida involucrados en las evaluaciones (ii) comparar los

ISO/IEC 29110-5-1-1:2012 Customer CUS Project Manager PM

Work Team

WT

UP I. Jacobson et. al.[5] Cliente Jefe de proyecto Analista de sistemas Especificador de casos de uso Dise˜nador de interfaces de usuario Arquitecto Ingeniero de casos de uso Ingeniero de componentes Ingeniero de pruebas Integrador de sistemas Ingeniero de pruebas de integraci´on Ingeniero de pruebas de sistema

Table IV E QUIVALENCIA DE ROLES ENTRE ISO/IEC 29110-5-1-1 Y UP

modelos de ciclo de vida de la evaluaci´on conforme a las m´etricas en la secci´on III-B6 siguiendo las pr´acticas escogidas en la secci´on III-B3, (iii) llenar los campos de la plantilla en blanco con los valores de cobertura mencionados en secci´on III-B6, (iv) resolver discrepancias entre evaluadores y corregir la evaluaci´on y (v) verificar y validar los resultados obtenidos de esta actividad. • Presentaci´ on y an´alisis de las salidas de la evaluaci´on. Espec´ıficamente, la ejecuci´on de cada una de las 3 evaluaciones ha sido realizada como se describe a continuaci´on: • Se toman los subprocesos en el orden que aparecen en la norma para la evaluaci´on, y por cada subproceso se realizan los siguientes pasos: – Se asigna un valor de evaluaci´on (ver secci´on III-B5) que indica el nivel alcanzado de la implementaci´on de las familias y derivaciones del UP propuestas en este trabajo sobre una tarea o artefacto espec´ıfico del subproceso escogido de la norma siguiendo las buenas practicas (MP) mencionadas en la ISO/IEC 15504-5 mencionadas en la secci´on III-B3 del presente trabajo. Para las tareas se eval´uan en base a su significado sem´antico y los productos de trabajo corroborando su existencia con las plantillas del RUP y las caracter´ısticas de cada producto de trabajo seg´un la norma ISO/IEC 29110-5-1-1. – Al final de la evaluaci´on de cada subproceso se socializan y documentan los resultados y se realizan todas las correcciones pertinentes. • La mayor´ıa de tareas de algunos subprocesos de la norma contienen aspectos relacionados con la gesti´on de proyectos, para este caso, estos subprocesos han tomados como un solo conjunto para la evaluaci´on y se ejecutan los mismos pasos del punto anterior. C. Equivalencia de roles entre ISO/IEC 29110-5-1-1 y UP En el orden de completar el mapeo, la tabla IV ilustra una equivalencia entre los roles de la ISO/IEC 29110-5-1-1 y el Proceso Unificado de I. Jacobson et. al.[5] tomando en cuenta sus habilidades y competencias como principal criterio. D. Respecto a los artefactos de la ISO/IEC 29110-5-1-1 Como se menciona en la norma ISO/IEC 29110-5-1-1 en la secci´on de an´alisis de requisitos de software (SI.2) cada

tarea contiene productos de entrada y de salida, por otro lado la secci´on 9 de la presente norma indica la descripci´on de cada uno de los productos. Con base en estas sentencias, se procede a realizar la evaluaci´on de cada producto de trabajo mencionado en la ISO/IEC 29110-5-1-1 respecto a su descripci´on siguiendo tambi´en las buenas pr´acticas (MP) de los atributos de proceso de la ISO/IEC 15504-5. Por otro lado, los artefactos involucrados en el proceso de captura de requisitos de la ISO/IEC 29110-5 que se tomar´an en cuenta para las evaluaciones son: • Plan de proyecto: Presenta como el proceso y las actividades se ejecutaran para asegurar la culminaci´on existosa del proyecto y la calidad de los productos de trabajo. • Documento de especificaci´ on de requisitos: Aqu´ı se identifican los requisitos de software. Se han omitido los detalles de cada artefacto tomado en cuenta para la evaluaci´on del UP y sus derivados tomados en cuenta en este trabajo (UP-VSE y PRODIGIA). M´as informaci´on puede ser encontrada en la ISO/IEC 29110-5-1-1 [25]. ´ DE D ISCIPLINA DE I NGENIER´I A DE IV. E VALUACI ON R EQUISITOS DEL P ROCESO U NIFICADO BAJO LA N ORMA ISO/IEC 29110-5-1-1 En esta secci´on se presenta una evaluaci´on entre los subprocesos de captura de requisitos de la norma ISO/IEC 29110-51-1 y la disciplina de ingenier´ıa de requisitos del UP tomando como intermediario la ISO/IEC 12207 con el fin de hallar los elementos de proceso faltantes del UP para cumplir con la norma, la evaluaci´on se hace conforme a la guia de evaluaci´on de la norma y bajo el marco de mediciones en la secci´on III. A. El flujo de trabajo de ingenier´ıa de requisitos Las actividades de la disciplina de ingenier´ıa de requisitos en el trabajo de I. Jacobson et. al. [5] contienen una numeraci´on que se conservar´a en este art´ıculo (los detalles de cada actividad son omitidos en este aporte). Las actividades consisten en: • 7.4.1. Encontrar los actores y casos de uso. • 7.4.2. Priorizar casos de uso. • 7.4.3. Detallar un caso de uso. • 7.4.4. Prototipar la interfaz de usuario. • 7.4.5. Estructurar el modelo de casos de uso. B. Actividades adicionales del UP involucradas en la evaluaci´on Adicionalmente al flujo de actividades de ingenier´ıa de requisitos del Proceso Unificado la fase de inicio ilustra como sucede la planificaci´on del proyecto incluyendo la repartici´on de roles. La secci´on 13.2 del trabajo de I. Jacobson et. al [5] ilustra como sucede la planificaci´on en el UP dejando evidencia de cobertura en la asignaci´on de roles en el que la norma ISO/IEC 29110-5-1-1 lo enuncia como requisito en los subprocesos de ingenier´ıa de requisitos seg´un lo estipulado en la ISO/IEC 15504. Las secciones posteriores del trabajo enuncian como se relacionaron estos subprocesos (ver secci´on IV-D).

C. Observaciones durante la ejecuci´on de la evaluaci´on Durante la realizaci´on de la evaluaci´on algunas tareas de la norma han requerido de una secci´on de gesti´on de proyectos en el UP, para solucionar este inconveniente, se a˜nadi´o esta disciplina de soporte que contiene todos los aspectos de gesti´on del Proceso Unificado propuestos en [5]. D. Presentaci´on y analisis de los resultados de la evaluaci´on 1) Evaluaci´on de las tareas de UP: La tabla V ilustra el resultado de la evaluaci´on entre estos 2 modelos de ciclo de vida de software contrastando los flujos de trabajo definidos en el UP y las tareas de los subprocesos de la norma ISO/IEC 29110-5-1-1. Obteniendo los resultados de QT se procede a utilizar las formulas en la secci´on III-B5 para hallar la cobertura de las tareas de UP, esto es: |T | P QT [CT {Ti }] i=1 QT [T areas] = |T | QT [T areas] =

1+1+0.3 3

QT [T areas] = 0.7¯ 67 CT (QT [T areas]) = T = Totalmente alcanzado. 2) Evaluaci´on de los artefactos de UP: Como se ha mencionado en anteriores secciones de este trabajo, los artefactos del RUP han sido descargados para complementar la carencia de plantillas que soporten al UP de Jacobson et. al.[5]. Una serie de plantillas gratuitas han sido descargadas de [26] y tomadas en cuenta dentro de la evaluaci´on. La tabla VI muestra la calificaci´on otorgada a los distintos artefacto de UP. Cada plantilla ha sido evaluada respecto a la descripci´on hecha en la ISO/IEC 29110-5-1-1, esto es: |W P| QW [CW {Wi }] QW [P roductos de trabajo] = i=1 |W | QW [P roductos de trabajo] = 1 CW (QW [P roductos de trabajo]) = T = Totalmente alcanzado. V. D ISCIPLINA DE I NGENIER´I A DE R EQUISITOS PARA VSE A. Reingenier´ıa, actualizaci´on e inclusion de las disciplinas de las actividades de captura de requerimientos de la norma La construcci´on de la disciplina de ingenier´ıa de requisitos parte de algunos aspectos tomados en cuenta: • Existen componentes tanto de la norma como de UP que no se abarcar´an completamente debido a que algunos componentes del Proceso Unificado pueden cumplir con un nivel de detalle mayor o igual los componentes que la norma requiere que sean llevados a cabo. • Considerando algunos elementos de proceso que la norma menciona sobre las cuales no se pueden categorizar adecuadamente en las disciplinas se abordaron algunas

fuentes de informaci´on en donde dichos elementos en otras familias del UP como el AUP (Agile Unified Process hallado en [27]), el RUP (Rational Unified Process hallado en [28]) y en fuentes de informaci´on sobre el proceso unificado [5], [29]. Tras este proceso de investigaci´on sobre los elementos de proceso se concluy´o: – Dado a que la propuesta solo abarc´o aspectos t´ecnicos del desarrollo de software, aspectos de la disciplina de gesti´on de proyectos del UP de I. Jacobson et. al. [5] fueron integradas en esta propuesta dado a que algunas de las tareas de asignaci´on encontradas en la norma clasifican adecuadamente en esta disciplina. – incluir la disciplina de despliegue dado a que se ha hallado la relaci´on entre la realizaci´on de los manuales de software con esta disciplina sin tener en cuenta que se debe contar con alg´un plan de despliegue de software que se encarga de su transici´on al sitio definido por el cliente realizando pruebas de funcionalidad e integraci´on de componentes software. – incluir la disciplina de gesti´on de la configuraci´on debido a que las actividades sobre el manejo y control de versi´ones y su documentaci´on en la linea base hacen parte de esta disciplina. – actualizar las disciplinas del Proceso Unificado con algunos de los elementos de proceso de la norma, conservando las practicas y la filosof´ıa de este modelo de proceso. B. Un poco acerca de la propuesta UP-VSE UP-VSE hace parte la familia de las diversas versiones del Proceso Unificado en donde difiere de los demas debido a que est´a m´as orientada a las VSE y su necesidad de estandarizaci´on bas´andose en las tareas de la norma ISO/IEC 29110-5-1-1. La figura 3 ilustra el ciclo de vida de esta propuesta, conserva los mismos hitos y fases que el UP de I.Jacobson et. al. [5], sin embargo los procesos que cubren las actividades del subproceso de ingenier´ıa de requisitos son distintas. Hay 2 subprocesos dentro de UP-VSE que est´an involucrados dentro de la evaluaci´on, el primero nombrado ”Inicializar el proyecto” que contiene pasos como la asignaci´on de responsabilidades por roles e ”Identificar Requisitos” que asume los procesos de verificaci´on y validaci´on como pasos que en la ISO/IEC 29110-5-1-1 se muestran como tareas del proceso de An´alisis de Requisitos de Software (SI.2). A continuaci´on las figuras 4 y 5 ilustran la din´amica de flujo sobre las tareas de las actividades ”Inicializar el proyecto” e ”Identificar Requisitos” respectivamente en donde la numeraci´on asociada a cada actividad se conservar´a para efectos de evaluaci´on durante el resto de este trabajo. Todas las tareas mencionadas el los anteriores gr´aficos no entran en la evaluaci´on, por tanto quedar´an exentas: 1.1.1 y 1.1.3 dado a que no cubren ninguna de las tareas del subproceso SI. 2 de la ISO/IEC 29110-5-1-1. Actualmente UPVSE sigue en su fase de modelado en EPF y refinado respecto

Disciplinas del UP CT Gesti´on del proyecto*

Ingenier´ıa de requisitos Tareas ISO/IEC 12207 (ISO/IEC 29110-5-1-1) 6.3.1.3.2.1 (SI. 2.1) 7.1.2.3.1.1 (SI. 2.2) 7.1.2.3.1.2 (SI. 2.2, SI. 2.3)

Subprocesos ISO/IEC 12207 (ISO/IEC 29110-5-1-1) 7.1.2.3.1 An´alisis de requisitos de software (SI. 2)

7.4.1

7.4.2

7.4.3

7.4.4

T P

P

7.4.5

13.2

QT

T

1 1 0.3

* El Proceso Unificado de I. Jacobson et. al [5] no contiene una disciplina de gesti´on de proyectos definida formalmente pero se especifica con fines de organizaci´on.

Table V ´ DE LAS TAREAS DE UP RESPECTO AL EST ANDAR ´ E VALUACI ON ISO/IEC 29110-5-1-1:2012 DE LA CAPTURA DE REQUERIMIENTOS

Artefactos UP I. Jacobson et. al. [5] Plan de desarrollo de software Modelo de casos de uso, DocDocumento de especiumento de casos de uso, Proficaci´on de requisitos totipo de interfaz de usuario ISO/IEC 29110-5-1-1 Plan del proyecto

CW T

QW 1

T

1

Table VI ´ DE LOS ARTEFACTOS DEL UP Y UP-VSE RESPECTO AL E VALUACI ON ´ EST ANDAR ISO/IEC 29110-5-1-1:2012 DE LA CAPTURA DE REQUERIMIENTOS

Figure 5. Actividad Identificar Requisitos de UP-VSE.

Figure 3. Ciclo de vida UP-VSE.

a los enunciados de la ISO/IEC 29110-5-1-1 y prontamente estar´a disponible. Las tareas de UP-VSE, al igual que el Proceso Unificado de I. Jacobson et. al. [5] no necesariamente deben ser ejecutadas en un orden especifico, pueden ser ejecutadas en paralelo o, en el caso de UP-VSE, modificadas en el orden que determine los proyectos en particular que deseen incorporar este modelo de proceso. C. Modificaciones y elementos omitidos de UP de I. Jacobson et. al. [5] en la creaci´on de UP-VSE

Figure 4. Actividad Inicializar el Proyecto de UP-VSE.

Con respecto a la ingenier´ıa de requisitos en ambas metodolog´ıas, UP-VSE contiene subconjuntos de los elementos de proceso documentados en la literatura sobre el UP, esto es que: • UP-VSE omite el glosario de t´ erminos y el modelo de negocios como artefactos de entrada para el desarrollo

•

•

•

de software. Dado a la reciente creaci´on de UP-VSE se han omitido detalles sobre el seguimiento realizado por la gesti´on de proyectos salvo la asignaci´on de los roles a los integrantes del equipo de proyecto dado a que es una actividad definida en ISO/IEC 29110-5-1-1. El prototipado de la interfaz de usuario en UP-VSE se realiza de una forma mas liviana, se utilizan maquetados elaborados en papel y l´apiz en compa˜n´ıa de los principales interesados del modelo final del sistema, o en su defecto elaborados en base a los requisitos capturados y documentados para su posterior verificaci´on y validaci´on. La actividad de “estructurar el modelo de casos de uso” (secci´on 7.4.5) de I. Jacobson [5] se considera un paso en la realizaci´on del modelo de casos de uso en la actividad “realizar el diagrama de casos de uso” (tarea 1.2.2.3 de la figura 5) de UP-VSE.

VI. E STUDIO DE C ASO : PRODIGIA A. Metodolog´ıa El trabajo de Runeson et. al. [30] expone el estudio de caso como una metodolog´ıa de investigaci´on para ingenier´ıa de software. Los casos de estudio son llevados a cabo en el mundo real, por lo tanto tienen un alto grado de realismo, en donde los datos obtenidos en el estudio deben ser consistentes. La validez de un caso de estudio depende en gran medida de lo disciplinado que se maneje el dise˜no y la ejecuci´on, as´ı ´ como el an´alisis de los resultados. Este trabajo ha seguido esta metodolog´ıa de investigaci´on para el desarrollo del estudio de caso PRODIGIA. Siguiendo esta metodolog´ıa el caso de estudio cuya finalidad consiste en evaluar el trabajo realizado en la secci´on IV y V: B. Dise˜no

D. Respecto a la relaci´on entre roles de ISO/IEC 29110-5-1-1 y UP-VSE

Alcance

Para conservar la orientaci´on a VSE, UP-VSE conserva los mismos roles de la ISO/IEC 29110-5-1-1 con sus habilidades y competencias repartidos en cada una sus actividades.

Este estudio de caso tiene por alcance evaluar los subprocesos relacionados con la captura de requisitos en una VSE de acuerdo a la norma ISO/IEC 29110-5-1-1.

E. Evaluaci´on del UP-VSE respecto al estandar ISO/IEC 29110-5-1-1:2012 sobre la captura de requisitos

Objetivo

Siguiendo el mismo proceso de evaluaci´on mencionado en la secci´on III se eval´ua el UP-VSE respecto a la subseccion de la norma, la ISO/IEC 29110-5-1-1:2012 sobre los subprocesos involucrados en la captura de requisitos, la tabla VII ilustra el resultado de la evaluaci´on. Aplicando la formula de la secci´on III-B5 la calificaci´on de la cobertura de las tareas alcanzada por UP-VSE:

El objetivo planteado para el desarrollo de PRODIGIA ha sido: “Determinar el subconjunto de elementos de las disciplinas de ingenier´ıa de requisitos y gesti´on de proyectos del proceso UP (tareas, roles y productos de trabajo) que son aplicables al contexto VSE a trav´es de una aplicaci´on emp´ırica del UP en una peque˜na entidad que no cuenta con un proceso de desarrollo definido y que permita la implementaci´on de la norma.”

CT (QT [T areas]) = T = Totalmente alcanzado. Debido a que UP-VSE trata de abarcar la mayor´ıa de los elementos de proceso de la norma ISO/IEC 29110-5-1-1, toma de la norma la documentaci´on de captura de requisitos y las traduce a las practicas respectivas del UP y tomando algunas de otras familias como el RUP para actividades de validaci´on y verificaci´on y la planificaci´on del proyecto e involucrando las disciplinas especificas que aportan en la realizaci´on de los artefactos. Debido a esto la calificaci´on de UP-VSE presenta mejores resultados que las pr´acticas para la ingenier´ıa de requisitos del UP de I. Jacobson et. al. [5]. Con respecto a la evaluaci´on de los artefactos, se han tomado las plantillas del UP descargadas en [26] para complementar a UP-VSE por lo que los resultados de la evaluaci´on son los mismos para las plantillas, la tabla VI y la secci´on IV-D2 ilustran los resultados de esta evaluaci´on por lo tanto la calificaci´on es la misma que la obtenida por UP en cuanto a nivel de artefactos, esto es: CW (QW [P roductos de trabajo]) = T = Totalmente alcanzado.

Preguntas de investigaci´on Este estudio de caso busca responder a las siguientes dos preguntas de investigaci´on: • •

¿Qu´e elementos del proceso UP (tareas, roles y productos de trabajo) son aplicables a una VSE? ¿Qu´e tanto, este conjunto de elementos proceso, satisface los subprocesos de ingenier´ıa de requisitos de la norma ISO/IEC 29110-5-1-1?

Criterios de selecci´on del estudio de caso La selecci´on de este caso obedece a dos criterios, el primero es que e´ ste es un caso t´ıpico en el que se requiere definir un proceso utilizando elementos caracter´ısticos del proceso unificado (modelo de casos de uso, modelo de clases y modelo de colaboraci´on). El segundo, es la disponibilidad de un escenario real en el mismo lugar de trabajo, lo que facilita la interrelaci´on y aporta un trabajo multidisciplinario valioso para las partes.

Disciplinas de UP-VSE CT Gesti´on del proyecto

Ingenier´ıa de requisitos

Subprocesos ISO/IEC 12207 (ISO/IEC 29110-5-1-1) 7.1.2.3.1 An´alisis de requisitos de software (SI. 2)

Tareas ISO/IEC 12207 (ISO/IEC 29110-5-1-1) 6.3.1.3.2.1 (SI. 2.1) 7.1.2.3.1.1 (SI. 2.2) 7.1.2.3.1.2 (SI. 2.2, SI. 2.3)

1.2.2.1

1.2.2.2

1.2.2.3

1.2.2.4

1.2.2.5

1.2.2.6

1.1.2

QT

T

1 1 1

T T

Table VII ´ DE LAS TAREAS DE UP-VSE RESPECTO AL EST ANDAR ´ E VALUACI ON ISO/IEC 29110-5-1-1:2012 DE LA CAPTURA DE REQUERIMIENTOS

Indicador

Medici´on

Grado de Cumplimiento del proceso UP respecto a la norma ISO/IEC 29110-5-1-1.

GAISO - Grado de aplicaci´on de la pr´actica ISO/IEC 29110-5-1-1 en el proyecto.

Aplicabilidad

E - Esfuerzo.

Fuentes de Informaci´on Usuarios finales del software, Desarrolladores y gestores del sistema quir´urgico, El producto software. Artefactos de Seguimiento del Grupo de Proceso.

Herramientas Modelo de Proceso Prodigia. Repositorio del proyecto. Protocolo de Evaluaci´on.

Se procesan las minutas de reuni´on y se consulta el repositorio del proyecto.

Table VIII M EDICIONES ASOCIADAS AL CASO DE ESTUDIO DE PRODIGIA. Figure 6. Estrategia de trabajo de los integrantes de PRODIGIA.

Descripci´on del caso La entidad, que en este contexto ha sido asumida como los integrantes del proceso PRODIGIA, es un grupo de investigaci´on en el que desarrollan aplicaciones de software de simulaci´on quir´urgica. El grupo de desarrollo se conform´o inicialmente por 3 estudiantes de maestr´ıa, 1 estudiante de pregrado y los profesores directores de sus proyectos. El caso se refiere a un proyecto “Dise˜no y construcci´on de un ambiente virtual para simulador quir´urgico utilizando interfaces h´apticas”. En este caso el grupo con acompa˜namiento define su propio proceso a partir de la especificaci´on bibliogr´afica del UP como se muestra en la figura 6. El desarrollo del producto se realiz´o en diferentes plataformas utilizando como base tecnolog´ıas como QT y Virtual Matlab VTK a trav´es del entorno de programaci´on Visual Studio, utilizando prototipos de brazos rob´oticos texturizados a 3D de otros proyectos de investigaci´on llevados a cabo previamente con miras a realizar incisiones internas en los o´ rganos del cuerpo humano sin realizar extensos cortes de la epidermis para acceder a su interior. Antecendentes del Proceso PRODIGIA El desarrollo de software se centra la construcci´on de c´odigo, sin haber pasado por una adecuada captura de requisitos ni un dise˜no arquitect´onico de software. No hay una formalizaci´on en la documentaci´on de las pruebas y e´ stas se realizan solo bajo la observaci´on de anomal´ıas en el flujo de ejecuci´on, sin tomar en cuenta la trazabilidad con los requerimientos. El grupo IA requiere una organizaci´on mas

adecuada de sus productos y solicita el asesoramiento del grupo IDIS (Grupo de Investigaci´on y Desarrollo en Ingenier´ıa de Software adscrito a la Universidad del Cauca) para definir un proceso de desarrollo m´as claro y completo. Marco de medici´on En la tabla VIII, se han definido un conjunto de indicadores e instrumentos de recolecci´on que se usaran en el caso de estudio. C. Ejecuci´on y seguimiento del caso de estudio sobre los subprocesos de captura de requisitos Para el desarrollo del caso se sigui´o la estrategia definida en la fig. 6. Para ello el equipo program´o y llev´o a cabo un conjunto de reuniones semanales para discutir el proceso y para obtener documentaci´on acerca del conjunto de aspectos a documentar del software que resulten de valor para la implementaci´on del producto. Tras las discusiones iniciales, el modelo de proceso de requisitos preliminar que se obtuvo para PRODIGIA se presenta en la fig. 7. Durante la ejecuci´on del proceso, dos estudiantes de maestr´ıa no pudieron continuar soportando el proyecto. Con respecto al u´ ltimo estudiante que ha quedado soportando el proceso dado a problemas de administraci´on de horarios y compromisos externos no se han logrado concretar reuniones periodicas y frecuentes (en promedio mas de una semana de receso de actividades relacionadas con PRODIGIA) lo que ha llevado a incluir una estrategia de colaboraci´on asistida

Figure 7. Proceso acordado de la captura de requisitos en las reuniones con los integrantes de PRODIGIA. Figure 8. Construcci´on del anteproyecto en PRODIGIA. 7

por computadora en el cual se inclu´ıa el uso de Thinklets utilizando la herramienta para el soporte colaborativo para la definici´on de procesos de software en MiPymes COLLAB [33], la instancia en funcionamiento del proceso se encuentra en [34]. D. Ejecuci´on del estudio de caso y datos obtenidos 1) Ingenier´ıa de requisitos en PRODIGIA: El resultado final es el subproceso refinado y basado a partir de las necesidades del grupo de investigaci´on IA8 Las tareas de la captura de requisitos en PRODIGIA est´an distribuidas en todas las fases, en la fase de formulaci´on con la construcci´on del anteproyecto de grado (fig. 8), en la fase de especificaci´on, se definen las tareas para formalizar el inicio del proyecto (fig. 10) y la identificaci´on y refinamiento en casos de uso de los requisitos de software (fig. 9). 2) Acerca de los artefactos de PRODIGIA: Existen artefactos que han sido tomados de [26] excepto el anteproyecto de grado, que para la ISO/IEC 29110-5-1-1 ser´ıa el plan del proyecto. La plantilla de anteproyecto de grado9 ilustra los apartados m´ınimos para proyectos academicos investigativos, difiere del plan de proyecto en su contenido principalmente en la definici´on de los roles los cuales recaen unicamente en estudiantes y profesores. 3) Acerca de los roles de PRODIGIA: Los roles de PRODIGIA, dado a su orientaci´on a proyectos acad´emicos, son: • Tesista: Toma cada uno de los roles del Proceso Unificado que sean requeridos para el dewsarrollo del proceso. 7 Un Thinklet se define como: “la unidad m´ as peque˜na de capital intelectual requerido para crear un patr´on de colaboraci´on simple, repetible y predecible a trav´es de personas que trabajan por un objetivo” [31], [32] 8 El subproceso final de captura de requisitos de PRODIGIA se encuentra disponible en [35]. 9 La plantilla “Guia Elaboracion del ANTEPROYECTO.docx”, puede ser encontrada en ftp://ftp.unicauca.edu.co/Facultades/FIET/Ipet/trabajos de grado/Postgrado/

Figure 9. Identificaci´on y refinamiento de requisitos en PRODIGIA.

Figure 10. Formalizar la iniciaci´on del proyecto en PRODIGIA.

ISO/IEC 29110-5-1-1:2012 Customer

CUS

Project Manager Work Team

PM WT

PRODIGIA[5] Stakeholder del estudio de caso Tutor de tesis Tesista

Table IX E QUIVALENCIA DE ROLES ENTRE ISO/IEC 29110-5-1-1 Y PRODIGIA

Tutor de tesis: Es el director del proyecto, valida y verifica muchos de los entregables realizados, gu´ıa la realizaci´on de los artefactos y es una fuente de informaci´on de requisitos. 10 • Stakeholder del estudio de caso: es la principal fuente de obtenci´on de requisitos organizacionales. La tabla IX ilustra en detalle la equivalencia de roles entre PRODIGIA y la ISO/IEC 29110-5-1-1. 4) Evaluaci´on de PRODIGIA respecto al estandar ISO/IEC 29110-5-1-1:2012 sobre la captura de requisitos: Evaluaci´on de las tareas de PRODIGIA: Al igual que en la secci´on V-E se realiza el mismo proceso de evaluaci´on siguiendo el procedimiento ilustrado en la secci´on III, se eval´ua PRODIGIA respecto a la subseccion de la norma, la ISO/IEC 29110-5-1-1:2012 sobre los subprocesos involucrados de la captura de requisitos, la tabla X ilustra el resultado de esta evaluaci´on. Al igual que en UP y UP-VSE se procede a evaluar la calificaci´on aplicando la formula propuesta en la secci´on III-B5, dando como resultado la evaluaci´on de PRODIGIA: •

QT [T areas] = 0.¯ 67 CT (QT [T areas]) = P = Parcialmente alcanzado. Evaluaci´on de los artefactos de PRODIGIA: La tabla XI ilustra la evaluaci´on que ha sido llevada a cabo para cada uno de los artef´actos. Tambien es aplicada la formula propuesta en III-B5 para obtener la calificaci´on de los artefactos seg´un la ISO/IEC 29110-5-1-1: QW [P roductos de trabajo] = 0.65 CW (QW [P roductos de trabajo]) = P = Parcialmente alcanzado. 5) Resultados del caso: Sobre el marco de medici´on (Secci´on VI-B): Las 2 mediciones ilustradas en el presente trabajo fueron: • Grado de aplicaci´ on de la pr´actica ISO/IEC 29110-51-1 en el proyecto (GAISO ): que ha sido extra´ıda para encontrar el grado de aplicaci´on a partir de la evaluaci´on de PRODIGIA seg´un la norma ISO/IEC 29110-5-1-1:2012. Se ha encontrado que PRODIGIA carece de m´etodos de verificaci´on espec´ıficos de los requisitos hallados pero tras reuniones periodicas para el control del progreso 10 Stakeholder: persona u organizaci´ on interesada en el progreso de otra organizaci´on

•

del proyecto se verifican indirectamente. (Ver secci´on VI-D4). Esfuerzo (E): Para la definici´on y construcci´on del subproceso de la captura de requisitos de PRODIGIA, contando con la construcci´on de plantillas, la documentaci´on en EPF y las reuniones de control de la ejecuci´on del proceso, socializaci´on del proceso con los directores de tesis y sus tesistas, se estima en total aproximadamente unas 102 horas / hombre.

An´alisis de los resultados del caso: Se ha observado que este subproceso de PRODIGIA indica que el UP es lo suficientemente completo como para abarcarlo en aspectos cr´ıticos como la captura de requisitos debido a la organizaci´on y tipo de los artefactos generados por las dos metodolog´ıas de desarrollo de software, sin embargo, la captura de requisitos en PRODIGIA a comparaci´on con el UP es menos robusta y con menos artefactos, lo que repercute en un alcance limitado del proceso hacia otros proyectos de simulaci´on quir´urgica que puedan surgir en un futuro. A pesar de esta desventaja, se ha observado una mayor facilidad de comprensi´on de este subproceso que la disciplina de Ingenier´ıa de Requisitos propuesta en el UP dado a experiencias pasadas en exposiciones y charlas sobre como hacer captura de requisitos para el desarrollo de simuladores de intervenci´on quir´urgica desarrollados por VSE. Con respecto al esfuerzo llevado a cabo para la construcci´on del subproceso, ha sido un resultado un poco mayor al esperado debido a la cantidad de personas que estaban interesadas en el proceso a las cuales se les ha brindado una charla de informaci´on sobre su uso y sus beneficios que traer´ıa para la construcci´on de proyectos de software. Sin embargo, el esfuerzo utilizado permite estimar que la aplicabilidad de UPVSE en una peque˜na organizaci´on es viable. VII. C ONCLUSIONES , L IMITACIONES Y T RABAJO F UTURO Este trabajo muestra como el Proceso Unificado puede servir de marco de referencia para establecer soluciones de procesos para las VSEs. Para ello se determin´o el grado de cumplimiento de la norma 29110-5-1-1 y as´ı seleccionar un subconjunto de pr´acticas conocidas por la industria y necesarias para alcanzar la norma. De la misma forma se determin´o aspectos que el proceso unificado no cubr´ıa, facilitando requerimientos de extensi´on al proceso original. El proceso resultante, UP-VSE, fue analizado est´aticamente a partir de una evaluaci´on basada en la norma ISO/IEC 15504-5 en el contexto de la norma 29110-5-1-1 mostrando su completitud. Adem´as se analiz´o su aplicabilidad pr´actica a trav´es de un estudio de caso, que si bien no alcanz´o la completitud en la implementaci´on de la norma, permiti´o en un lapso corto y con bajos recursos humanos, la implementabilidad de buena parte del modelo. Existieron algunas limitaciones que trajeron dificultades al momento de ejecutar el proceso a nivel de la calidad y prontitud de los artefactos, debido a la falta de autoridad sobre la ejecuci´on del proceso, que por lo general eran causadas por la delegaci´on de trabajo entre los participantes del equipo de

Disciplinas de PRODIGIA CT An´alisis

Dise˜no Subprocesos ISO/IEC 12207 (ISO/IEC 29110-5-1-1) 7.1.2.3.1 An´alisis de requistos de software (SI. 2)

Tareas ISO/IEC 12207 (ISO/IEC 29110-5-1-1) 6.3.1.3.2.1 (SI. 2.1) 7.1.2.3.1.1 (SI. 2.2) 7.1.2.3.1.2 (SI. 2.2, SI. 2.3)

1.1.1

1.1.2

1.2.3

2.1.1

2.2.2.1

2.2.2.2

2.2.2.3

2.2.2.4

QT

T

0.0 1 1

N T

Table X ´ DE LAS TAREAS DE PRODIGIA RESPECTO AL EST ANDAR ´ E VALUACI ON ISO/IEC 29110-5-1-1:2012 DE LA CAPTURA DE REQUERIMIENTOS

Artefactos ISO/IEC 29110-5-1-1 Plan del proyecto Documento de especificaci´on de requisitos

PRODIGIA Anteproyecto Modelo de casos de uso, Documento de casos de uso

CW P

QW 0.3

T

1

Table XI ´ DE LOS ARTEFACTOS DE PRODIGIA RESPECTO AL E VALUACI ON ´ EST ANDAR ISO/IEC 29110-5-1-1:2012 DE LA CAPTURA DE REQUERIMIENTOS

procesos, as´ı como la rotaci´on de personal, lo que implicaba volver a capacitar el personal de apoyo. A futuro, se pretende completar el proyecto definiendo los flujos de trabajo fundamentales del Proceso Unificado, as´ı como la aplicaci´on completa en el proceso PRODIGIA, para lo cual se est´a desarrollando una plataforma de gesti´on de proyectos siguiendo el enfoque establecido en dicha metodolog´ıa. R EFERENCES [1] W. S. Humphrey, Managing the software process, ser. SEI series in software engineering. Addison-Wesley, 1989. [2] A. Cockburn, “Selecting a project’s methodology,” IEEE Softw., vol. 17, no. 4, pp. 64–71, Jul. 2000. [Online]. Available: http: //dx.doi.org/10.1109/52.854070 [3] I. Sommerville, Software Engineering, 7th ed. Pearson Education, 2004. [4] I. Sommerville, Software Engineering, 9th ed. Addison-Wesley Publishing Company, 2007. [5] I. Jacobson, G. Booch, and J. Rumbaugh, The unified software development process. Addison-Wesley Longman Publishing Co., Inc., 1999. [6] C. Laporte, S. Alexandre, and R. O’Connor, “A Software Engineering Lifecycle Standard for Very Small Enterprises,” in Software Process Improvement, R. O’Connor, N. Baddoo, K. Smolander, and R. Messnarz, Eds. Springer Berlin Heidelberg, 2008, vol. 16, ch. 12, pp. 129–141. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-85936-9\ 12 [7] R. V. O’Connor and C. Laporte, “Using iso/iec 29110 to harness process improvement in very small entities,” in Systems, Software and Service Process Improvement, ser. Communications in Computer and Information Science, R. V. O’Connor, J. Pries-Heje, and R. Messnarz, Eds. Springer Berlin Heidelberg, 2011, vol. 172, pp. 225–235. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-22206-1\ 20 [8] F. J. Pino, M. Piattini, and G. Felix, Calidad en sistemas de informaci´on, 2nd ed. Espa˜ na: RA-MA, 2011. [9] V. Ribaud, P. Saliou, R. O’Connor, and C. Laporte, “Software Engineering Support Activities for Very Small Entities,” in Systems, Software and Services Process Improvement, A. Riel, R. O’Connor, S. Tichkiewitch, and R. Messnarz, Eds. Springer Berlin Heidelberg, 2010, vol. 99, ch. 15, pp. 165–176. [Online]. Available: http: //dx.doi.org/10.1007/978-3-642-15666-3\ 15 [10] M. Halling, W. Zuser, M. Kohle, and S. Biffl, “Teaching the unified process to undergraduate students,” in Software Engineering Education and Training, 2002. (CSEE T 2002). Proceedings. 15th Conference on, 2002, pp. 148–159. [11] G. K. Hanssen, H. Westerheim, and F. O. Bjø rnson, “Tailoring RUP to a defined project type : A case study 1 Introduction.” [12] R. V. O’Connor and C. Y. Laporte, “Software Project Management in Very Small Entities with ISO / IEC 29110,” pp. 330–341, 2012.

[13] R. V. O’Connor and C. Y. Laporte, “Deploying Lifecycle Profiles for Very Small Entities : An Early Stage Industry View.” [14] B. Day, K.-Z. Sean Chin, L. Lovelock, and C. Lutteroth, “Climbing the Ladder: CMMI Level 3,” in Enterprise Distributed Object Computing Conference, 2009. EDOC ’09. IEEE International, 2009, pp. 97–106. [15] R. d. A. Falbo, L. S. M. Borges, and F. F. R. Valente, “Using Knowledge Management to Improve Software Process Performance in a CMM Level 3 Organization,” in Proceedings of the Quality Software, Fourth International Conference, ser. QSIC ’04. Washington, DC, USA: IEEE Computer Society, 2004, pp. 162–169. [Online]. Available: http://dx.doi.org/10.1109/QSIC.2004.38 [16] P. Borges, P. Monteiro, and R. Machado, “Mapping RUP Roles to Small Software Development Teams,” in Software Quality. Process Automation in Software Development SE - 5, ser. Lecture Notes in Business Information Processing, S. Biffl, D. Winkler, and J. Bergsmann, Eds. Springer Berlin Heidelberg, 2012, vol. 94, pp. 59–70. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-27213-4\ 5 [17] R. Motschnig-Pitrik, “Employing the Unified Process for Developing a Web-Based Application - A Case-Study,” in Proceedings of the 4th International Conference on Practical Aspects of Knowledge Management, ser. PAKM ’02. London, UK, UK: Springer-Verlag, 2002, pp. 97–113. [Online]. Available: http://dl.acm.org/citation.cfm? id=645775.668287 [18] M. E. Morales-Trujillo, H. Oktaba, T. Ventura, and R. Torres, “From MoProSoft Level 2 to ISO/IEC 29110 Basic Profile: Bridging the Gap,” CLEI Electronic Journal, vol. 16, pp. 3 – 3, 04 2013. [Online]. Available: http://www.scielo.edu.uy/scielo.php?script= sci\ arttext\&pid=S0717-50002013000100003\&nrm=iso [19] ISO/IEC 29110-3: Software Engineering – Lifecycle Profiles for Very Small Enterprises (VSE) – Part 3: Assessment Guide, ISO (International Organization for Standardization) SC7-WG24 Group, 2011. [20] V. Ribaud and P. Saliou, “Process assessment issues of the iso/iec 29110 emerging standard,” in Proceedings of the 11th International Conference on Product Focused Software, ser. PROFES ’10. New York, NY, USA: ACM, 2010, pp. 24–27. [Online]. Available: http://doi.acm.org/10.1145/1961258.1961264 [21] Assessing the Rational Unified Process against ISO/IEC 15504-5: Information Technology – Software Process Assessment Part 5: An Assessment Model And Indicator Guidance, Rational Corporation Whitepaper, 2000. [22] ISO/IEC 15504-2: Software Process Improvement and Capability Determination - Performing an Assessment, ISO (International Organization for Standardization), 2003. [23] ISO/IEC 15504-5: Software Process Improvement and Capability Determination - An Assessment Model and Indicator Guidance, ISO (International Organization for Standardization), 1999. [24] ISO/IEC 15504: Software Process Improvement and Capability Determination, ISO (International Organization for Standardization), 2007. [25] ISO/IEC 29110-5-1-1: Software Engineering – Lifecycle Profiles for Very Small Enterprises (VSE) – Part 5.1: Management and Engineering Guide - Basic Profile, ISO (International Organization for Standardization) SC7-WG24 Group, 2012. [26] “Free Rup Templates,” 2014. [Online]. Available: http://www.findthatzip-file.com/search-43193485-hZIP/ winrar-winzip-download-free-rup-templates.zip.htm [27] “The Agile Unified Process,” Scott W. Amber and Associates. [Online]. Available: http://www.ambysoft.com/unifiedprocess/agileUP.html [28] “Rational Unified Process - Best Practices for Software,” IBM - Rational. [Online]. Available: http://www.ibm.com/developerworks/rational/ library/content/03July/\\1000/1251/1251\ bestpractices\ TP026B.pdf

´ [29] “The Unified Process for Education (UPEDU),” Ecole Polytechnique Montr´eal, 2011. [Online]. Available: http://upedu.org/ [30] P. Runeson and M. H¨ost, “Guidelines for conducting and reporting case study research in software engineering,” Empirical Software Engineering, vol. 14, no. 2, pp. 131–164, 2009. [Online]. Available: http://dx.doi.org/10.1007/s10664-008-9102-8 [31] R. O. Briggs, G. L. Kolfschoten, G. J. de Vreede, and D. L. Dean, “Defining Key Concepts for Collaboration Engineering,” in 12th Americas Conference on Information Systems, G. Rodriquez-Abitia and A. B. Ignacia, Eds. Acapulco, Mexico: Technologica de Monterrey, 2006, pp. 1–10. [32] J. J. Nabukenya, P. P. V. Bommel, and H. A. E. Proper, “Repeatable Collaboration Processes for Mature Organizational Policy Making,” no. i. [33] W. L. Pantoja Yepez, C. A. Collazos, and V. M. R Penichet, “Entorno Colaborativo de Apoyo a la Mejora Procesos de Software en Peque˜nas Organizaciones de Software (COLLAB),” pp. 40–48, 2013. [34] “Entorno Colaborativo de Apoyo a la Mejora Procesos de Software en Peque˜nas Organizaciones de Software (COLLAB), herramienta utilizada en la definici´on de PRODIGIA.” Grupos IDIS, Universidad del Cauca. [Online]. Available: http://jhon-jairo-alvarez-londono.alwaysdata.net/ COLLAB [35] “Proceso de Desarrollo Industrial del Grupo de Ingenier´ıa Autom´atica (PRODIGIA).” Grupos IDIS - IA, Universidad del Cauca. [Online]. Available: http://artemisa.unicauca.edu.co/ \texttildelowjjalvarezl/PRODIGIA/