Ingenierıa de Requisitos del Proceso Unificado enPequenas Organizaciones Desarrolladoras de

SoftwareJhon J. Alvarez Londono

Grupo IDISUniversidad del Cauca

email: jjalvarezl@unicauca.edu.co

Julio A. Hurtado AlegrıaGrupo IDIS

Universidad del Caucaemail: ahurtado@unicauca.edu.co

Resumen—La norma de calidad ISO 29110 ha sido elaboradacon el fin de brindar soporte a las pequenas organizacionesa estandarizar sus procesos de desarrollo de software. Laspequenas organizaciones aun consideran difıcil la adopcion deestandares de calidad debido a su tamano y por ende a sucapacidad sobre recursos financieros y humanos. Con el objetivode disminuir la dificultad de interpretacion, en este trabajose ilustran los primeros avances de un modelo de ciclo devida basado en el Proceso Unificado (UP-VSE) implementandopracticas de la Ingenierıa de Requisitos del perfil basico de lanorma ISO 29110-5-1 otorgando a las pequenas entidades un casoilustrativo y reutilizable que permitan mejorar su interpretacione implementacion de esta norma. Esta propuesta ha sido filtrada atraves de un estudio de caso aplicado a un grupo de investigaciony desarrollo en automatica industrial concluyendo que, para estaprimera aproximacion, la propuesta UP-VSE cubre los aspectosmas importantes de la norma en el ambito de la elicitacion derequerimientos de software.

Palabras Clave—Mejora de Procesos de Software, PequenasOrganizaciones, ISO 29110, Proceso Unificado, Ingenierıa deRequisitos.

Abstract—In an attempt to increase the competitiveness ofsmall organizations, the ISO has developed a standard, theISO 29110. Due to its recent emergence, the high rates of theunknowledge about its implementation and associated costs, it isstill difficult for small organizations to take this standard intopractice. In order to reduce the conceptual gap, in this paperhas been purposed a software process model (UP-VSE) bassedon the Unified Process, which implements the requirementsengineering practices of ISO 29110-5-1-1 in order to companiescan have an illustrative and reusable case allowing them toincrease the standard interpretation and implementation. Thisproposal has been empirically evaluated defining PRODIGIAsoftware process in the context of a research and developmentgroup of industrial automation. This initial approach establishedthat UP-VSE accomplish the main ISO 29110 issues.

Index terms—Software Process Improvement, Very SmallEntities, ISO 29110, Unified Process, Software RequirementsEngineering.

I. INTRODUCCION

Una industria de software competitiva es una industria capazde hacer la diferencia con productos de calidad y proyectosproductivos. Estos dos aspectos se pueden lograr a partir demuchas estrategias tecnicas y de gestion. Una de estas es lamejora del proceso de software, basada en la premisa que

los procesos determinan la calidad de los productos [1] yla productividad de los proyectos [2]. Ası, la industria desoftware ha venido considerando el proceso de software comoun activo muy importante dentro de las organizaciones.

Un proceso es un “conjunto de actividades relacionadas queconducen a la creacion de un producto software” [3], [4].Segun I. Jacobson et al. “Un proceso define el quien estahaciendo que, cuando y como construir un producto softwareo mejorar uno existente” [5].

Como la calidad del proceso afecta directamente la calidaddel producto, se han creado estandares de calidad para eldesarrollo de software con el fin de realizar la mejora delos procesos de las empresas. En efecto, las pequenas orga-nizaciones desarrolladoras de software o Very Small Entities(VSE) tambien invierten esfuerzos para obtener certificacionesy como consecuencia lograr mas competitividad. Sin embargo,lo hacen a traves de estandares como ISO/IEC 12207 o CMMI,que no estan disenadas para empresas de este tamano [6], [7].

El grupo de trabajo SC7-WG24 ha desarrollado la normaISO/IEC 29110, un modelo de referencia para la mejora deprocesos (SPI) de las VSE [8] que en su totalidad hacenel 75% de las empresas de desarrollo de software a nivelmundial [6]. Sin embargo, su reciente aparicion como estandarinternacional, sus altos costos de implementacion y evaluacional interior de las VSE, ası como su inherente complejidad, seconvierten en las principales barreras para su adopcion [9].

O’Connor et al. [6] reconocen la necesidad de las VSEen la definicion de un estandar de software que soporte elciclo de vida y los procesos al interior de estas organizacionesargumentando que, a pesar de contar con practicas de softwareprobadas de estandares como ISO/IEC 12207 o CMMI, nocuentan con el suficiente nivel de soporte para grupos deingenierıa de software menores a 25 personas, en efecto,es inevitable tratar de aplicar en las configuraciones de losmodelos de ciclo de vida de estas normas con un alto nivelde dificultad.

Este trabajo toma en cuenta el amplio recorrido en laindustria de desarrollo de software y en la ensenanza delUP para tratar de abordar la implementacion de la normaISO/IEC 29110, usando la disciplina del ingenierıa de re-

quisitos del Proceso Unificado y ası reducir el esfuerzo deentendimiento e implementacion en las VSE. UP es un modelode proceso reutilizable y adaptable de software bien conocidopor la industria y ampliamente aceptado por la comunidadacademica [10]. La implementacion de la norma respecto alUP se realiza bajo la evaluacion de los elementos tomadosde los subprocesos de requisitos de la ISO/IEC 29110-5-1-1respecto de los elementos presentes en el flujo de trabajo de ladisciplina de requerimientos del Proceso Unificado, apoyadoen las plantillas de los artefactos del RUP (Proceso Unificadode Rational) presentes en el flujo de trabajo propuesto por I.Jacobson et al. [5]. Para evaluar la aplicabilidad de la propuestase ha realizado con un estudio de caso en una VSE con ungrupo de investigadores en el area de software de roboticaquirurgica del grupo AI de ingenierıa automatica industrialde la Universidad del Cauca que llevan a cabo proyectosque involucran el desarrollo de software, los cuales siguenPRODIGIA (Proceso de Desarrollo Industrial del Grupo deIngenierıa Automatica) una metodologıa basada en el ProcesoUnificado.

El resto de este artıculo se ha organizado de la siguienteforma. La seccion II introduce trabajos relacionados, ası comola definicion del Proceso Unificado, la norma ISO/IEC 29110,sus relaciones y aplicaciones en la industria. La seccion IIIpresenta el marco de evaluacion que es utilizado en el restodel artıculo. La seccion IV presenta una evaluacion teoricadel cumplimiento del Proceso Unificado respecto a la normaISO 29110-5-1-11 mostrando el respectivo proceso que ha sidollevado a cabo, la seccion V ilustra la disciplina de ingenierıade requisitos del modelo de procesos UP-VSE, la seccionVI presenta la misma evaluacion pero desde una perspec-tiva empırica usando el proceso PRODIGIA. Finalmente, laseccion VII presenta las conclusiones, limitaciones y trabajosfuturos.

II. ANTECEDENTES Y TRABAJOS RELACIONADOS

A. El Proceso Unificado

El Proceso Unificado se describe como “un marco de trabajogenerico que puede especializarse para una gran variedadde sistemas software, para diferentes areas de aplicacion,diferentes tipos de organizaciones, diferentes niveles de aptitudy diferentes tamanos de proyecto” [5].

El proceso unificado posee 3 caracterısticas fundamentales:esta dirigido por casos de uso2, esta centrado en la arquitec-tura de software3 y es iterativo e incremental4. El ciclo de vidadel proceso unificado consta de 4 fases (inicio, elaboracion,

1Ha sido seleccionada esta parte de la norma dado que este perfil contienetodos los aspectos que una VSE debe tener para cumplir la evaluacion delestandar

2Cuando ”un proyecto esta dirigido por casos de uso significa que progresaa traves de una serie de flujos de trabajo que se inician a partir de los casosde uso” [5].

3La arquitectura da una clara perspectiva de la construccion del software,por este motivo la construccion gira en torno a la arquitectura [5]

4La division del esfuerzo de trabajo en el Proceso Unificado se hacepor iteraciones en donde al final de cada una se presentan incrementos delproducto software. [5]

construccion y transicion) en donde cada una termina con unhito y contiene un numero finito de iteraciones. A lo largo delciclo de vida se ejecutan los 5 flujos de trabajos fundamentales(requisitos, analisis, diseno, implementacion y pruebas) [5].

El proceso unificado es una metodologıa de desarrollo desoftware compleja en sus artefactos y en sus procesos, portanto, es necesario adaptar el proceso unificado a las necesi-dades particulares de una entidad desarrolladora de software.El trabajo de Hanssen et. al. [11] concluye que el procesounificado, a pesar de ser una metodologıa de desarrollo, siguesiendo un proceso que esta en alto nivel y por lo tantonecesita ser adaptado al contexto de las organizaciones y delos proyectos.

B. La norma ISO/IEC 29110Para apoyar las pequenas empresas en la mejora de sus

procesos organizacionales, ISO, a traves del grupo de trabajoSC7-WG24 ha creado la norma ISO 29110.

C. Laporte et al. [6] ilustran los inicios del desarrollode la norma ISO/IEC 29110 aproximada por el grupo detrabajo WG24 tomando aspectos de la norma ISO/IEC 12207y adaptandolos al contexto VSE y la necesidad de las pequenasorganizaciones desarrolladoras de software en su intento porestandarizar sus modelos de ciclo de vida.

La norma establece un marco comun para describir perfilesevaluables del ciclo de vida de software para ser usados enlas VSE.• Vision General (TR ISO 29110-1): Introduce los con-

ceptos principales necesarios para la comprension de lanorma ISO 29110, aspectos de negocio, caracterısticas yrequisitos de las VSE. Esta seccion de la norma aclarala razon de ser de los perfiles especıficos, documentos,estandares y guıas de VSE e introduce los conceptosde proceso basico, ciclo de vida y estandarizacion, y lafamilia de documentos ISO 29110.

• Perfiles (ISP): Permite empaquetar referencias a y/opartes de otros documentos de manera formal con el fin deadaptarlos a las necesidades y caracterısticas de las VSE,lo que implica producir 2 tipos de documentos para estanorma:

– Marco de trabajo y taxonomıa (ISP 29110-2)– Especificaciones de perfil (29110-4-m)

• Guıas: Contienen directrices de aplicacion (de dominioespecıfico) sobre como realizar los procesos para alcan-zar los niveles de madurez (por ejemplo, actividadesrecomendadas, medidas, tecnicas, plantillas, modelos,metodos, entre otros). Hay 2 tipos de guıas:

– Guıa de evaluacion (TR29110-3): Describe el pro-ceso a seguir para realizar una evaluacion que de-termine las capacidades de proceso y/o madurezorganizacional.

– Guıa de ingenierıa y gestion (TR29110-5-m-n, dondem es el numero del perfil anteriormente ilustrado yn el numero de la guıa de ingenierıa y gestion.)

Especıficamente, El perfil 29110-5-1-1 (Guıa de in-genierıa y gestion - Perfil Basico) se compone de 2

procesos: Administracion del Proyecto y Desarrollo deSoftware, de los cuales este estudio solo tomara la guıa deingenierıa como marco de referencia para la evaluacion.Esta seccion de la norma cuenta con 6 subprocesos (Soft-ware Implementation Initiation, Software RequirementsAnalysis, Software Architectural and Detailed Design,Software Construction, Software Integration and Test,Product Delivery) que sirven de puntos de referencia parael analisis del Proceso Unificado.

C. Los paquetes de despliegue (DP)

O’Connor et al. presentan los paquetes de despliegue oDeployment Packages (DP) [9], [12], [13], como mecanismosque facilitan la adopcion de la norma ISO/IEC 29110 donde seencuentran varios patrones sobre la adopcion, brindando de-talles de la incorporacion del estandar ISO/IEC 29110 a travesde los DP. Esta validacion se ha llevado a cabo con proyectospiloto en VSE de paıses como Canada, Francia, Belgica yotros mas participaron en la utilizacion de estos paquetes conresultados satisfactorios. Aunque presenta los mecanismos deadopcion, los paquetes de despliegue no presentan un modelode proceso concreto que sirva como punto de referencia o casode estudio para una VSE .

D. Implementacion de normas de calidad a traves de distintasversiones del UP

Lutteroth et al. [14] muestran un trabajo sobre la creacion deun modelo de flujo de trabajo completo para una companıa TICcon el fin de alcanzar el nivel 3 de CMMI. La compania utilizoel Proceso Unificado como mecanismo de implementacionde CMMI resaltando la importancia de esta metodologıa enla implementacion de modelos propios de la industria desoftware.

Falbo et. al. [15] trabajan un mapeo de roles a equipospequenos de desarrollo de software que fue aplicado a unestudio de caso de un equipo dentro de una organizacionevaluada en CMM nivel 3, definiendo una serie de rolesbase, en donde, para que sean considerados escenciales debencumplir una de tres condiciones mencionadas en el trabajo deMonteiro et. al. [16], para luego ser mapeados con los roles delRUP (39 en total), quedando reducidos a 13. De estos roles seha definido cuales pueden ser integrados entre RUP y los rolesbase y cuales no, indicando en algunos casos (con una “X” enel mapeo) cuales roles deben ser absolutamente restringidoscuando deben ser asignados a una misma persona.

E. Casos involucrando el Proceso Unificado en pequenasorganizaciones

Tanto en el ambito academico como en el industrial, seha utilizado el Proceso Unificado en organizaciones VSE. Eltrabajo de Halling et. al. [10] ilustra esta metodologıa aplicadaa estudiantes de un curso de ingenierıa de software orientadoa objetos, en el que se mencionan las razones para utilizarloen la formacion de ingenieros de software, entre las cualesresalta su facil comprension.

El trabajo de Motschnig-Pitrik [17] muestra la experienciadel autor al haber aplicado el Proceso Unificado en el desa-rrollo de una aplicacion web en cooperacion con una agenciade cuatro personas discutiendo los puntos fuertes y debiles delProceso Unificado. Este trabajo se concluye que el UP facilitaanalizar aspectos acerca de como invertir el esfuerzo delproyecto y obtener una temprana retroalimentacion del cliente,entre otras. Sin embargo un miembro del equipo debe contarcon experiencia en el Proceso Unificado, y los miembros delequipo deben contar con experiencia en el manejo de UML.

F. Evaluaciones 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 nivelde capacidad 2 y la ISO/IEC 29110-5-1-2. Ambos modelos deproceso fueron mapeados y evaluados utilizando las metricasmencionadas en la ISO/IEC 15504-2 que determinaron el nivelde capacidad segun los resultados de soporte matematico de laevaluacion de este trabajo. El artıculo concluye que MoProSoftnivel 2 cubre el 85% de las tareas y 94% de los productos detrabajo. Esta evaluacion abre las posibilidades para obtener unacertificacion internacional en corto tiempo en las empresas queadopten MoProSoft nivel 2 en sus procesos.

III. PROCESO DE EVALUACION PARA INGENIERIA DEREQUISITOS DE LA ISO/IEC 29110

El Modelo de Evaluacion del Proceso que propone laISO/IEC 29110:20125 es un modelo de capacidad del procesobi-dimensional. Una es la dimension de los procesos bajoevaluacion, la otra, la dimension de la capacidad, define unconjunto de atributos de proceso agrupados en niveles decapacidad. Los atributos de proceso son las caracterısticasmedibles de la capacidad del proceso. Los indicadores de lacapacidad del proceso son los medios para lograr las capaci-dades direccionadas por los atributos de proceso considerados.La evidencia de los indicadores de la capacidad del procesosoporta el juicio del grado de completitud del atributo deproceso [19]. En el diseno de la evaluacion se han tomadoaportes que pueden ser encontrados en [20], [21].

A. Respecto a la norma ISO/IEC 29110-3

Se ha realizado un plan de evaluacion liviano conforme alas especificaciones del modelo de evaluacion de la ISO/IEC29110-3 para los perfiles basicos [19]. La subseccion 6.3 deesta parte de la norma especifica que: “Los requisitos parael cumplimiento de los perfiles VSE pueden ser derivadosde las respectivas partes ISO/IEC 29110-4 e ISO/IEC 29110-5”. Como mınimo, todos los elementos obligatorios del perfilVSE, definidos en la ISO/IEC 29110-4, necesitan ser consider-ados en la evaluacion, ası por ejemplo, los procesos evaluadosdel perfil VSE basico necesitan alcanzar el nivel de capacidad1 definido en la ISO/IEC 15504-2. Esto significa que el pro-ceso implementado logra su proposito del proceso y sus salidasdefinidas”. La figura 1 ilustra como estan involucrados los

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

Figure 1. Elementos de la evaluacion de procesos en VSE adaptado de [19].

Figure 2. Elementos instanciados de la evaluacion en ISO/IEC 15504-2.

elementos en la evaluacion de procesos en las organizacionesVSE.

B. Modelo de evaluacion de la ISO/IEC 15504

1) Generalidades: Conforme a lo mencionado en la seccionanterior es necesario hallar el nivel de capacidad del procesoevaluado, en este caso del Proceso Unificado respecto aISO/IEC 29110-5-1-1 perfil basico. La figura 2 ilustra laconfiguracion de los elementos participan en la ejecucion dela evaluacion [22].

2) Marco de trabajo y alcance de la ISO/IEC 15504: Setomara en cuenta el nivel de capacidad 1 para cumplir con elperfil basico, por lo tanto esta se acota a algunas categorıasy atributos de proceso de la ISO/IEC 15504 y se conserva laescala de evaluacion para los atributos de proceso encontradosen la ISO/IEC 15504-5 [23]:• Dimension 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 analisis y diseno de los requi-

sitos del sistema.∗ ENG.2: Analisis de los requisitos del software.

• Dimension de la capacidad:– Niveles de capacidad: Para efectos de coherencia

conforme a lo mencionado en el modelo de evalu-

acion ISO/IEC 29110-3 (ver seccion III) los nivelesde capacidad a evaluar son 0 y 1

– Escala de calificacion de los atributos de proceso:Se utiliza la escala de la ISO/IEC 15504-2 [22]

3) Descripcion de los niveles de capacidad:a) Nivel 0: “El proceso no esta implementado o falla

en lograr su proposito”, para este trabajo se han tomado losobjetivos de los subprocesos de ingenierıa de requisitos de lanorma.

b) Nivel 1: “El proceso implementado cumple elproposito del proceso de referencia”, asociado a este nivel seencuentra el atributo de proceso:

• PA. 1.1 - Realizacion del proceso: La plena realizacionde este atributo de proceso ofrece como resultado queel proceso logre sus salidas definidas. A continuacion seilustran los respectivos indicadores de proceso a travesde practicas de gestion (MP) [23] que han sido seguidasen esta evaluacion:

– MP 1.1.1 - Identificar los productos de trabajode entrada y salida: aparte de su identificacion seprocede a verificar las caracterısticas que deben tenerestos productos y si cumplen o ayudan a cumplir ono el objetivo del proceso.

– MP 1.1.2 - Se debe asegurar que el alcancedel trabajo se ha identificado para la ejecucionde los procesos y de los productos de trabajoa ser usados y producidos en el proceso: paracada proceso, las practicas base conllevan a lograr elproposito y salidas definidas en el proceso y existeevidencia que las practicas base son llevadas a cabo.

– MP 1.1.3 - Asegurarse que las practicas base sonimplementadas, elaborando productos de trabajoque apoyan el logro de las salidas defenidas delproceso: para cada proceso, el alcance del trabajo esidentificado en el proceso en ejecucion.

4) Medicion en la dimension de la capacidad: Dado que laevaluacion se hara en el primer nivel de capacidad y que por lotanto solo se incluira un solo atributo de proceso (ver seccionIII-B3) se vinculan los respectivos indicadores de capacidaddel proceso mencionados en la seccion B.2.1 del Anexo B dela norma ISO/IEC 15504-5 [23].

5) Medicion en la dimension del proceso: Fue necesariala realizacion de un mapeo entre la ISO/IEC 12207:20085

y la ISO/IEC 29110-5-1-1 para asegurar equivalencias en laevaluacion de la ISO/IEC 15504. (ver tabla I6). Para continuarla evaluacion entre la ISO/IEC 12207 previamente mapeadacon los procesos de la ISO/IEC 29110-5-1-1, se procedea determinar la equivalencia de procesos con el ProcesoUnificado. La tabla II ilustra los subprocesos de captura derequisitos presentes en la norma ISO/IEC 12207 y el UP queentraran en las evaluaciones que conciernen a este trabajo.

6Los nombres de las actividades de estas secciones se han acortado parauna comprension mas rapida del lector, los nombres completos de las tareaspueden ser encontrados en las respectivas normas asociadas.

ISO/IEC 12207 ISO/IEC 29110-5-1-17.1.2.3.1 Analisis de requisitos de software SI. 2 Analisis de requisitos de software

6.3.1.3.2.1 Preparar los planes para la ejecucion del proyecto.6 Subseccion e: asignacionde responsabilidades

SI. 2.1 Asignar tareas a los miembros del equipo de trabajo en conformidad consu rol respectivo basandose en el plan de proyecto concurrente.

7.1.2.3.1.1 Establecer y documentar el reporte de especificacion de requisitos6 (sin lascaracterısticas de calidad mencionadas en este punto de la norma). SI. 2.2 Documentar o actualizar los requisitos de software7.1.2.3.1.2 Evaluar los requisitos de software6 (sin consideracion de los criteriosmencionados en este punto de la norma) SI. 2.3 Validar y obtener aprovacion de la especificacion de requisitos

Table IEQUIVALENCIA ENTRE PROCESOS Y TAREAS INVOLUCRADAS EN EL MAPEO

ISO/IEC 12207 UP I. Jacobson et.al. [5] /PRODIGIA / UP-VSE

7.1.2.3.1 Analisis de requisitos de software 7 Disciplina de ingenierıa de requisitos

Table IISUBPROCESOS DE CAPTURA DE REQUISITOS ENTRE LA NORMA ISO/IEC

12207 Y UP

Valores de cobertura (C) Porcentaje Puntaje asignado (Q)T - Totalmente 85 - 100% 1.0

L - Ampliamente 50 - 85% 0.7P - Parcialmente 15 - 50% 0.3N - No logrado 0 - 15% 0.0

Table IIIRANGOS DE CAPACIDAD Y PUNTAJES ASIGNADOS

En el presente artıculo se realizan 3 evaluaciones basadasen esta estructura, por tanto este mapeo se utiliza en cada unarespecto al modelo de ciclo de vida a evaluar tomando comopunto de partida los resultados de los procesos de la normaISO/IEC 12207 de esta seccion.

6) Metricas y reglas de cobertura: Las metricas definidasen la ISO/IEC 15504-5 fueron usadas para determinar losvalores de cobertura esenciales para este trabajo y basandoseen los niveles de Cobertura (C), a cada valor en C se le ha sidoasignado un puntaje utilizado para definir un nivel Cuantitativo(Q). La tabla III ilustra la relacion entre los valores de laevaluacion segun la ISO/IEC 15504-5 y el puntaje asignado,el cual esta basado en el trabajo de M. Trujillo et. al.[18].

Tomando los indicadores de capacidad de proceso filtradosen la seccion III-B4 junto a los subprocesos mapeados en laseccion III-B5 utilizando la ISO/IEC 12207 como un modelode referencia de procesos intermediario se procede a definir laevaluacion:• 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 aplicala siguientes formula generales:

CT (QT [Tareas]) = CT

|T |∑i=1

QT [CT {Ti}]

|T |

y

CW (QW [Productos de trabajo]) = CW

|W |∑i=1

QW [CW {Wi}]

|W |

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 |∑i=1

QT [CT {Ti}]: Es la suma de cada uno de los

niveles quantitativos (puntajes) de las tareas delproceso.

–|W |∑i=1

QW [CW {Wi}]: Es la suma de cada uno de los

niveles quantitativos (puntajes) de los productos detrabajo del proceso.

• Un ejemplo de la aplicacion de esta formula puede serencontrado en el trabajo de M. Trujillo et. al.[18].

• Cada puntaje tanto de tareas y productos de trabajo seevaluaron por aparte por lo tanto daran distintas perspec-tivas de CP y QP .

• No se considera el tiempo en la ejecucion tanto de tareascomo de artefactos en la evaluacion.

7) Metodologıa de evaluacion: Basandose en la estructurametodologica propuesta en la ISO/IEC 15504 [24], se hadisenado un modelo de evaluacion siguiendo una serie detareas:• Analisis de los modelos de ciclo de vida: esta actividad

involucra las siguientes tareas: (i) obtener trabajos sobrelos modelos a evaluar, (ii) analizar su estructura y (iii)buscar las plantillas de los productos de trabajo asociadasa cada modelo de ciclo de vida.

• Diseno de la evaluacion: esta actividad involucra lassiguientes tareas: (i) definir la direccion de la evaluacion,(ii) realizar el mapeo de la evaluacion para la ISO/IEC15504, en este caso entre la ISO/IEC 12207 y la ISO/IEC29110-5-1-1 (iii) disenar la plantilla de evaluacion (tareasrelacionadas con la captura de requisitos de la normaISO/IEC 29110-5-1-1 y los distintos modelos de ciclode vida involucrados en conjunto con las plantillas aso-ciadas a cada modelo si existen), (iv) definir escalas deevaluacion y (v) verificar la coherencia y direccion de laevaluacion y de los resultados.

• Ejecucion de la evaluacion: esta actividad involucra lassiguientes tareas: (i) realizar la equivalencia entre pro-cesos de la ISO/IEC 12207 y los modelos de ciclo devida involucrados en las evaluaciones (ii) comparar los

ISO/IEC 29110-5-1-1:2012 UP I. Jacobson et. al.[5]Customer CUS Cliente

Project Manager PM Jefe de proyecto

Work Team WT

Analista de sistemasEspecificador de casos de uso

Disenador de interfaces de usuarioArquitecto

Ingeniero de casos de usoIngeniero de componentes

Ingeniero de pruebasIntegrador de sistemas

Ingeniero de pruebas de integracionIngeniero de pruebas de sistema

Table IVEQUIVALENCIA DE ROLES ENTRE ISO/IEC 29110-5-1-1 Y UP

modelos de ciclo de vida de la evaluacion conforme alas metricas en la seccion III-B6 siguiendo las practicasescogidas en la seccion III-B3, (iii) llenar los campos dela plantilla en blanco con los valores de cobertura men-cionados en seccion III-B6, (iv) resolver discrepanciasentre evaluadores y corregir la evaluacion y (v) verificary validar los resultados obtenidos de esta actividad.

• Presentacion y analisis de las salidas de la evaluacion.Especıficamente, la ejecucion de cada una de las 3 evalua-

ciones ha sido realizada como se describe a continuacion:• Se toman los subprocesos en el orden que aparecen en

la norma para la evaluacion, y por cada subproceso serealizan los siguientes pasos:

– Se asigna un valor de evaluacion (ver seccion III-B5)que indica el nivel alcanzado de la implementacionde las familias y derivaciones del UP propuestas eneste trabajo sobre una tarea o artefacto especıficodel subproceso escogido de la norma siguiendo lasbuenas practicas (MP) mencionadas en la ISO/IEC15504-5 mencionadas en la seccion III-B3 del pre-sente trabajo. Para las tareas se evaluan en base asu significado semantico y los productos de trabajocorroborando su existencia con las plantillas del RUPy las caracterısticas de cada producto de trabajosegun la norma ISO/IEC 29110-5-1-1.

– Al final de la evaluacion de cada subproceso sesocializan y documentan los resultados y se realizantodas las correcciones pertinentes.

• La mayorıa de tareas de algunos subprocesos de lanorma contienen aspectos relacionados con la gestion deproyectos, para este caso, estos subprocesos han tomadoscomo un solo conjunto para la evaluacion y se ejecutanlos 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 unaequivalencia entre los roles de la ISO/IEC 29110-5-1-1 y elProceso Unificado de I. Jacobson et. al.[5] tomando en cuentasus 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 enla seccion de analisis de requisitos de software (SI.2) cada

tarea contiene productos de entrada y de salida, por otro ladola seccion 9 de la presente norma indica la descripcion decada uno de los productos. Con base en estas sentencias,se procede a realizar la evaluacion de cada producto detrabajo mencionado en la ISO/IEC 29110-5-1-1 respecto asu descripcion siguiendo tambien las buenas practicas (MP)de los atributos de proceso de la ISO/IEC 15504-5. Por otrolado, los artefactos involucrados en el proceso de captura derequisitos de la ISO/IEC 29110-5 que se tomaran en cuentapara las evaluaciones son:• Plan de proyecto: Presenta como el proceso y las

actividades se ejecutaran para asegurar la culminacionexistosa del proyecto y la calidad de los productos detrabajo.

• Documento de especificacion de requisitos: Aquı seidentifican los requisitos de software.

Se han omitido los detalles de cada artefacto tomado en cuentapara la evaluacion del UP y sus derivados tomados en cuentaen este trabajo (UP-VSE y PRODIGIA). Mas informacionpuede ser encontrada en la ISO/IEC 29110-5-1-1 [25].

IV. EVALUACION DE DISCIPLINA DE INGENIERIA DEREQUISITOS DEL PROCESO UNIFICADO BAJO LA NORMA

ISO/IEC 29110-5-1-1En esta seccion se presenta una evaluacion entre los subpro-

cesos de captura de requisitos de la norma ISO/IEC 29110-5-1-1 y la disciplina de ingenierıa de requisitos del UP tomandocomo intermediario la ISO/IEC 12207 con el fin de hallarlos elementos de proceso faltantes del UP para cumplir con lanorma, la evaluacion se hace conforme a la guia de evaluacionde la norma y bajo el marco de mediciones en la seccion III.

A. El flujo de trabajo de ingenierıa de requisitosLas actividades de la disciplina de ingenierıa de requisitos

en el trabajo de I. Jacobson et. al. [5] contienen una nu-meracion que se conservara en este artıculo (los detalles decada actividad son omitidos en este aporte). Las actividadesconsisten 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 evalu-acion

Adicionalmente al flujo de actividades de ingenierıa derequisitos del Proceso Unificado la fase de inicio ilustra comosucede la planificacion del proyecto incluyendo la reparticionde roles. La seccion 13.2 del trabajo de I. Jacobson et. al[5] ilustra como sucede la planificacion en el UP dejandoevidencia de cobertura en la asignacion de roles en el que lanorma ISO/IEC 29110-5-1-1 lo enuncia como requisito en lossubprocesos de ingenierıa de requisitos segun lo estipuladoen la ISO/IEC 15504. Las secciones posteriores del trabajoenuncian como se relacionaron estos subprocesos (ver seccionIV-D).

C. Observaciones durante la ejecucion de la evaluacion

Durante la realizacion de la evaluacion algunas tareas de lanorma han requerido de una seccion de gestion de proyectosen el UP, para solucionar este inconveniente, se anadio estadisciplina de soporte que contiene todos los aspectos degestion del Proceso Unificado propuestos en [5].

D. Presentacion y analisis de los resultados de la evaluacion

1) Evaluacion de las tareas de UP: La tabla V ilustra elresultado de la evaluacion entre estos 2 modelos de ciclo devida de software contrastando los flujos de trabajo definidosen el UP y las tareas de los subprocesos de la norma ISO/IEC29110-5-1-1. Obteniendo los resultados de QT se procedea utilizar las formulas en la seccion III-B5 para hallar lacobertura de las tareas de UP, esto es:

QT [Tareas] =

|T |∑i=1

QT [CT {Ti}]

|T |

QT [Tareas] = 1+1+0.33

QT [Tareas] = 0.767

CT (QT [Tareas]) = T = Totalmente alcanzado.

2) Evaluacion de los artefactos de UP: Como se ha men-cionado en anteriores secciones de este trabajo, los artefactosdel RUP han sido descargados para complementar la carenciade plantillas que soporten al UP de Jacobson et. al.[5]. Unaserie de plantillas gratuitas han sido descargadas de [26] ytomadas en cuenta dentro de la evaluacion. La tabla VI muestrala calificacion otorgada a los distintos artefacto de UP. Cadaplantilla ha sido evaluada respecto a la descripcion hecha enla ISO/IEC 29110-5-1-1, esto es:

QW [Productos de trabajo] =

|W |∑i=1

QW [CW {Wi}]

|W |

QW [Productos de trabajo] = 1

CW (QW [Productos de trabajo]) = T = Totalmentealcanzado.

V. DISCIPLINA DE INGENIERIA DE REQUISITOS PARA VSE

A. Reingenierıa, actualizacion e inclusion de las disciplinasde las actividades de captura de requerimientos de la norma

La construccion de la disciplina de ingenierıa de requisitosparte de algunos aspectos tomados en cuenta:• Existen componentes tanto de la norma como de UP que

no se abarcaran completamente debido a que algunoscomponentes del Proceso Unificado pueden cumplir conun nivel de detalle mayor o igual los componentes quela norma requiere que sean llevados a cabo.

• Considerando algunos elementos de proceso que la normamenciona sobre las cuales no se pueden categorizaradecuadamente en las disciplinas se abordaron algunas

fuentes de informacion en donde dichos elementos enotras familias del UP como el AUP (Agile Unified Pro-cess hallado en [27]), el RUP (Rational Unified Processhallado en [28]) y en fuentes de informacion sobre elproceso unificado [5], [29]. Tras este proceso de investi-gacion sobre los elementos de proceso se concluyo:

– Dado a que la propuesta solo abarco aspectostecnicos del desarrollo de software, aspectos de ladisciplina de gestion de proyectos del UP de I.Jacobson et. al. [5] fueron integradas en esta prop-uesta dado a que algunas de las tareas de asignacionencontradas en la norma clasifican adecuadamenteen esta disciplina.

– incluir la disciplina de despliegue dado a que seha hallado la relacion entre la realizacion de losmanuales de software con esta disciplina sin teneren cuenta que se debe contar con algun plan de de-spliegue de software que se encarga de su transicional sitio definido por el cliente realizando pruebasde funcionalidad e integracion de componentes soft-ware.

– incluir la disciplina de gestion de la configuraciondebido a que las actividades sobre el manejo ycontrol de versiones y su documentacion en la lineabase hacen parte de esta disciplina.

– actualizar las disciplinas del Proceso Unificado conalgunos de los elementos de proceso de la norma,conservando las practicas y la filosofıa de este mo-delo de proceso.

B. Un poco acerca de la propuesta UP-VSE

UP-VSE hace parte la familia de las diversas versiones delProceso Unificado en donde difiere de los demas debido a queesta mas orientada a las VSE y su necesidad de estandarizacionbasandose en las tareas de la norma ISO/IEC 29110-5-1-1. Lafigura 3 ilustra el ciclo de vida de esta propuesta, conservalos mismos hitos y fases que el UP de I.Jacobson et. al.[5], sin embargo los procesos que cubren las actividades delsubproceso de ingenierıa de requisitos son distintas. Hay 2subprocesos dentro de UP-VSE que estan involucrados dentrode la evaluacion, el primero nombrado ”Inicializar el proyecto”que contiene pasos como la asignacion de responsabilidadespor roles e ”Identificar Requisitos” que asume los procesosde verificacion y validacion como pasos que en la ISO/IEC29110-5-1-1 se muestran como tareas del proceso de Analisisde Requisitos de Software (SI.2). A continuacion las figuras4 y 5 ilustran la dinamica de flujo sobre las tareas de lasactividades ”Inicializar el proyecto” e ”Identificar Requisitos”respectivamente en donde la numeracion asociada a cadaactividad se conservara para efectos de evaluacion durante elresto de este trabajo.

Todas las tareas mencionadas el los anteriores graficos noentran en la evaluacion, por tanto quedaran exentas: 1.1.1y 1.1.3 dado a que no cubren ninguna de las tareas delsubproceso SI. 2 de la ISO/IEC 29110-5-1-1. Actualmente UP-VSE sigue en su fase de modelado en EPF y refinado respecto

Disciplinas del UPCT

Ingenierıa de requisitosGestion

delproyecto*

Subprocesos ISO/IEC 12207 (ISO/IEC 29110-5-1-1) Tareas ISO/IEC 12207(ISO/IEC 29110-5-1-1) 7.4.1 7.4.2 7.4.3 7.4.4 7.4.5 13.2 QT

7.1.2.3.1 Analisis de requisitos de software (SI. 2)6.3.1.3.2.1 (SI. 2.1) T 17.1.2.3.1.1 (SI. 2.2) T 1

7.1.2.3.1.2 (SI. 2.2, SI. 2.3) P P 0.3

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

Table VEVALUACION DE LAS TAREAS DE UP RESPECTO AL ESTANDAR ISO/IEC 29110-5-1-1:2012 DE LA CAPTURA DE REQUERIMIENTOS

ArtefactosISO/IEC 29110-5-1-1 UP I. Jacobson et. al. [5] CW QW

Plan del proyecto Plan de desarrollo de software T 1

Documento de especi-ficacion de requisitos

Modelo de casos de uso, Doc-umento de casos de uso, Pro-totipo de interfaz de usuario

T 1

Table VIEVALUACION DE LOS ARTEFACTOS DEL UP Y UP-VSE RESPECTO AL

ESTANDAR ISO/IEC 29110-5-1-1:2012 DE LA CAPTURA DEREQUERIMIENTOS

Figure 3. Ciclo de vida UP-VSE.

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

Figure 5. Actividad Identificar Requisitos de UP-VSE.

a los enunciados de la ISO/IEC 29110-5-1-1 y prontamenteestara disponible.

Las tareas de UP-VSE, al igual que el Proceso Unificado deI. Jacobson et. al. [5] no necesariamente deben ser ejecutadasen un orden especifico, pueden ser ejecutadas en paralelo o,en el caso de UP-VSE, modificadas en el orden que determinelos proyectos en particular que deseen incorporar este modelode proceso.

C. Modificaciones y elementos omitidos de UP de I. Jacobsonet. al. [5] en la creacion de UP-VSE

Con respecto a la ingenierıa de requisitos en ambasmetodologıas, UP-VSE contiene subconjuntos de los elemen-tos de proceso documentados en la literatura sobre el UP, estoes que:• UP-VSE omite el glosario de terminos y el modelo de

negocios como artefactos de entrada para el desarrollo

de software.• Dado a la reciente creacion de UP-VSE se han omitido

detalles sobre el seguimiento realizado por la gestion deproyectos salvo la asignacion de los roles a los integrantesdel equipo de proyecto dado a que es una actividaddefinida en ISO/IEC 29110-5-1-1.

• El prototipado de la interfaz de usuario en UP-VSE serealiza de una forma mas liviana, se utilizan maquetadoselaborados en papel y lapiz en companıa de los princi-pales interesados del modelo final del sistema, o en sudefecto elaborados en base a los requisitos capturados ydocumentados para su posterior verificacion y validacion.

• La actividad de “estructurar el modelo de casos de uso”(seccion 7.4.5) de I. Jacobson [5] se considera un paso enla realizacion del modelo de casos de uso en la actividad“realizar el diagrama de casos de uso” (tarea 1.2.2.3 dela figura 5) de UP-VSE.

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

Para conservar la orientacion a VSE, UP-VSE conserva losmismos roles de la ISO/IEC 29110-5-1-1 con sus habilidadesy competencias repartidos en cada una sus actividades.

E. Evaluacion del UP-VSE respecto al estandar ISO/IEC29110-5-1-1:2012 sobre la captura de requisitos

Siguiendo el mismo proceso de evaluacion mencionado enla seccion III se evalua el UP-VSE respecto a la subseccion dela norma, la ISO/IEC 29110-5-1-1:2012 sobre los subprocesosinvolucrados en la captura de requisitos, la tabla VII ilustra elresultado de la evaluacion.

Aplicando la formula de la seccion III-B5 la calificacion dela cobertura de las tareas alcanzada por UP-VSE:

CT (QT [Tareas]) = T = Totalmente alcanzado.

Debido a que UP-VSE trata de abarcar la mayorıa de loselementos de proceso de la norma ISO/IEC 29110-5-1-1, tomade la norma la documentacion de captura de requisitos y lastraduce a las practicas respectivas del UP y tomando algunasde otras familias como el RUP para actividades de validaciony verificacion y la planificacion del proyecto e involucrandolas disciplinas especificas que aportan en la realizacion de losartefactos. Debido a esto la calificacion de UP-VSE presentamejores resultados que las practicas para la ingenierıa derequisitos del UP de I. Jacobson et. al. [5].

Con respecto a la evaluacion de los artefactos, se hantomado las plantillas del UP descargadas en [26] para comple-mentar a UP-VSE por lo que los resultados de la evaluacionson los mismos para las plantillas, la tabla VI y la seccionIV-D2 ilustran los resultados de esta evaluacion por lo tantola calificacion es la misma que la obtenida por UP en cuantoa nivel de artefactos, esto es:

CW (QW [Productos de trabajo]) = T = Totalmentealcanzado.

VI. ESTUDIO DE CASO: PRODIGIA

A. Metodologıa

El trabajo de Runeson et. al. [30] expone el estudio decaso como una metodologıa de investigacion para ingenierıade software. Los casos de estudio son llevados a cabo en elmundo real, por lo tanto tienen un alto grado de realismo, endonde los datos obtenidos en el estudio deben ser consistentes.La validez de un caso de estudio depende en gran medida delo disciplinado que se maneje el diseno y la ejecucion, asıcomo el analisis de los resultados. Este trabajo ha seguido estametodologıa de investigacion para el desarrollo del estudiode caso PRODIGIA. Siguiendo esta metodologıa el caso deestudio cuya finalidad consiste en evaluar el trabajo realizadoen la seccion IV y V:

B. Diseno

Alcance

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

Objetivo

El objetivo planteado para el desarrollo de PRODIGIAha sido: “Determinar el subconjunto de elementos de lasdisciplinas de ingenierıa de requisitos y gestion de proyectosdel proceso UP (tareas, roles y productos de trabajo) que sonaplicables al contexto VSE a traves de una aplicacion empıricadel UP en una pequena entidad que no cuenta con un procesode desarrollo definido y que permita la implementacion de lanorma.”

Preguntas de investigacion

Este estudio de caso busca responder a las siguientes dospreguntas de investigacion:

• ¿Que elementos del proceso UP (tareas, roles y productosde trabajo) son aplicables a una VSE?

• ¿Que tanto, este conjunto de elementos proceso, satisfacelos subprocesos de ingenierıa de requisitos de la normaISO/IEC 29110-5-1-1?

Criterios de seleccion del estudio de caso

La seleccion de este caso obedece a dos criterios, el primeroes que este es un caso tıpico en el que se requiere definirun proceso utilizando elementos caracterısticos del procesounificado (modelo de casos de uso, modelo de clases y modelode colaboracion). El segundo, es la disponibilidad de unescenario real en el mismo lugar de trabajo, lo que facilitala interrelacion y aporta un trabajo multidisciplinario valiosopara las partes.

Disciplinas de UP-VSECT

Ingenierıa de requisitosGestion

delproyecto

Subprocesos ISO/IEC 12207 (ISO/IEC 29110-5-1-1) Tareas ISO/IEC 12207(ISO/IEC 29110-5-1-1) 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

7.1.2.3.1 Analisis de requisitos de software (SI. 2)6.3.1.3.2.1 (SI. 2.1) T 17.1.2.3.1.1 (SI. 2.2) T 1

7.1.2.3.1.2 (SI. 2.2, SI. 2.3) T 1

Table VIIEVALUACION DE LAS TAREAS DE UP-VSE RESPECTO AL ESTANDAR ISO/IEC 29110-5-1-1:2012 DE LA CAPTURA DE REQUERIMIENTOS

Figure 6. Estrategia de trabajo de los integrantes de PRODIGIA.

Descripcion del caso

La entidad, que en este contexto ha sido asumida comolos integrantes del proceso PRODIGIA, es un grupo de in-vestigacion en el que desarrollan aplicaciones de software desimulacion quirurgica. El grupo de desarrollo se conformoinicialmente por 3 estudiantes de maestrıa, 1 estudiante depregrado y los profesores directores de sus proyectos. El casose refiere a un proyecto “Diseno y construccion de un am-biente virtual para simulador quirurgico utilizando interfaceshapticas”. En este caso el grupo con acompanamiento definesu propio proceso a partir de la especificacion bibliograficadel UP como se muestra en la figura 6. El desarrollo delproducto se realizo en diferentes plataformas utilizando comobase tecnologıas como QT y Virtual Matlab VTK a traves delentorno de programacion Visual Studio, utilizando prototiposde brazos roboticos texturizados a 3D de otros proyectos deinvestigacion llevados a cabo previamente con miras a realizarincisiones internas en los organos del cuerpo humano sinrealizar extensos cortes de la epidermis para acceder a suinterior.

Antecendentes del Proceso PRODIGIA

El desarrollo de software se centra la construccion decodigo, sin haber pasado por una adecuada captura de re-quisitos ni un diseno arquitectonico de software. No hay unaformalizacion en la documentacion de las pruebas y estas serealizan solo bajo la observacion de anomalıas en el flujode ejecucion, sin tomar en cuenta la trazabilidad con losrequerimientos. El grupo IA requiere una organizacion mas

Indicador Medicion Fuentes deInformacion

Herramientas

Grado deCumplimientodel procesoUP respectoa la normaISO/IEC29110-5-1-1.

GAISO - Grado deaplicacion de lapractica ISO/IEC29110-5-1-1 en elproyecto.

Usuariosfinales delsoftware,Desarrolladoresy gestoresdel sistemaquirurgico,El productosoftware.

Modelo de ProcesoProdigia.Repositorio delproyecto.Protocolo deEvaluacion.

Aplicabilidad E - Esfuerzo. Artefactos deSeguimientodel Grupo deProceso.

Se procesan lasminutas de reuniony se consulta elrepositorio delproyecto.

Table VIIIMEDICIONES ASOCIADAS AL CASO DE ESTUDIO DE PRODIGIA.

adecuada de sus productos y solicita el asesoramiento delgrupo IDIS (Grupo de Investigacion y Desarrollo en Ingenierıade Software adscrito a la Universidad del Cauca) para definirun proceso de desarrollo mas claro y completo.

Marco de medicion

En la tabla VIII, se han definido un conjunto de indicadorese instrumentos de recoleccion que se usaran en el caso deestudio.

C. Ejecucion y seguimiento del caso de estudio sobre lossubprocesos de captura de requisitos

Para el desarrollo del caso se siguio la estrategia definidaen la fig. 6. Para ello el equipo programo y llevo a cabo unconjunto de reuniones semanales para discutir el proceso ypara obtener documentacion acerca del conjunto de aspectosa documentar del software que resulten de valor para laimplementacion del producto.

Tras las discusiones iniciales, el modelo de proceso de re-quisitos preliminar que se obtuvo para PRODIGIA se presentaen la fig. 7.

Durante la ejecucion del proceso, dos estudiantes demaestrıa no pudieron continuar soportando el proyecto. Conrespecto al ultimo estudiante que ha quedado soportando elproceso dado a problemas de administracion de horarios ycompromisos externos no se han logrado concretar reunionesperiodicas y frecuentes (en promedio mas de una semana dereceso de actividades relacionadas con PRODIGIA) lo queha llevado a incluir una estrategia de colaboracion asistida

Figure 7. Proceso acordado de la captura de requisitos en las reuniones conlos integrantes de PRODIGIA.

por computadora en el cual se incluıa el uso de Thinklets7

utilizando la herramienta para el soporte colaborativo parala definicion de procesos de software en MiPymes COLLAB[33], la instancia en funcionamiento del proceso se encuentraen [34].

D. Ejecucion del estudio de caso y datos obtenidos

1) Ingenierıa de requisitos en PRODIGIA: El resultadofinal es el subproceso refinado y basado a partir de lasnecesidades del grupo de investigacion IA8

Las tareas de la captura de requisitos en PRODIGIA estandistribuidas en todas las fases, en la fase de formulacion con laconstruccion del anteproyecto de grado (fig. 8), en la fase deespecificacion, se definen las tareas para formalizar el iniciodel proyecto (fig. 10) y la identificacion y refinamiento encasos de uso de los requisitos de software (fig. 9).

2) Acerca de los artefactos de PRODIGIA: Existen arte-factos que han sido tomados de [26] excepto el anteproyectode grado, que para la ISO/IEC 29110-5-1-1 serıa el plan delproyecto. La plantilla de anteproyecto de grado9 ilustra losapartados mınimos para proyectos academicos investigativos,difiere del plan de proyecto en su contenido principalmenteen la definicion de los roles los cuales recaen unicamente enestudiantes y profesores.

3) Acerca de los roles de PRODIGIA: Los roles de PRODI-GIA, dado a su orientacion a proyectos academicos, son:• Tesista: Toma cada uno de los roles del Proceso Unifi-

cado que sean requeridos para el dewsarrollo del proceso.

7Un Thinklet se define como: “la unidad mas pequena de capital intelectualrequerido para crear un patron de colaboracion simple, repetible y predeciblea traves de personas que trabajan por un objetivo” [31], [32]

8El subproceso final de captura de requisitos de PRODIGIA se encuentradisponible en [35].

9La plantilla “Guia Elaboracion del ANTEPROYECTO.docx”, puedeser encontrada en ftp://ftp.unicauca.edu.co/Facultades/FIET/Ipet/trabajos degrado/Postgrado/

Figure 8. Construccion del anteproyecto en PRODIGIA.

Figure 9. Identificacion y refinamiento de requisitos en PRODIGIA.

Figure 10. Formalizar la iniciacion del proyecto en PRODIGIA.

ISO/IEC 29110-5-1-1:2012 PRODIGIA[5]

Customer CUSStakeholder del es-tudio de caso

Tutor de tesisProject Manager PMWork Team WT Tesista

Table IXEQUIVALENCIA DE ROLES ENTRE ISO/IEC 29110-5-1-1 Y PRODIGIA

• Tutor de tesis: Es el director del proyecto, valida yverifica muchos de los entregables realizados, guıa la re-alizacion de los artefactos y es una fuente de informacionde requisitos.

• Stakeholder10 del estudio de caso: es la principal fuentede obtencion de requisitos organizacionales.

La tabla IX ilustra en detalle la equivalencia de roles entrePRODIGIA y la ISO/IEC 29110-5-1-1.

4) Evaluacion de PRODIGIA respecto al estandar ISO/IEC29110-5-1-1:2012 sobre la captura de requisitos:

Evaluacion de las tareas de PRODIGIA: Al igual que en laseccion V-E se realiza el mismo proceso de evaluacion sigu-iendo el procedimiento ilustrado en la seccion III, se evaluaPRODIGIA respecto a la subseccion de la norma, la ISO/IEC29110-5-1-1:2012 sobre los subprocesos involucrados de lacaptura de requisitos, la tabla X ilustra el resultado de estaevaluacion.

Al igual que en UP y UP-VSE se procede a evaluar lacalificacion aplicando la formula propuesta en la seccionIII-B5, dando como resultado la evaluacion de PRODIGIA:

QT [Tareas] = 0.67

CT (QT [Tareas]) = P = Parcialmente alcanzado.

Evaluacion de los artefactos de PRODIGIA: La tabla XIilustra la evaluacion que ha sido llevada a cabo para cada unode los artefactos.

Tambien es aplicada la formula propuesta en III-B5 paraobtener la calificacion de los artefactos segun la ISO/IEC29110-5-1-1:

QW [Productos de trabajo] = 0.65

CW (QW [Productos de trabajo]) = P = Parcialmentealcanzado.

5) Resultados del caso:Sobre el marco de medicion (Seccion VI-B): Las 2 medi-

ciones ilustradas en el presente trabajo fueron:• Grado de aplicacion de la practica ISO/IEC 29110-5-

1-1 en el proyecto (GAISO): que ha sido extraıda para en-contrar el grado de aplicacion a partir de la evaluacion dePRODIGIA segun la norma ISO/IEC 29110-5-1-1:2012.Se ha encontrado que PRODIGIA carece de metodos deverificacion especıficos de los requisitos hallados perotras reuniones periodicas para el control del progreso

10Stakeholder: persona u organizacion interesada en el progreso de otraorganizacion

del proyecto se verifican indirectamente. (Ver seccionVI-D4).

• Esfuerzo (E): Para la definicion y construccion del sub-proceso de la captura de requisitos de PRODIGIA, con-tando con la construccion de plantillas, la documentacionen EPF y las reuniones de control de la ejecucion delproceso, socializacion del proceso con los directores detesis y sus tesistas, se estima en total aproximadamenteunas 102 horas / hombre.

Analisis de los resultados del caso: Se ha observadoque este subproceso de PRODIGIA indica que el UP es losuficientemente completo como para abarcarlo en aspectoscrıticos como la captura de requisitos debido a la organizaciony tipo de los artefactos generados por las dos metodologıas dedesarrollo de software, sin embargo, la captura de requisitosen PRODIGIA a comparacion con el UP es menos robusta ycon menos artefactos, lo que repercute en un alcance limitadodel proceso hacia otros proyectos de simulacion quirurgica quepuedan surgir en un futuro. A pesar de esta desventaja, se haobservado una mayor facilidad de comprension de este subpro-ceso que la disciplina de Ingenierıa de Requisitos propuesta enel UP dado a experiencias pasadas en exposiciones y charlassobre como hacer captura de requisitos para el desarrollo desimuladores de intervencion quirurgica desarrollados por VSE.

Con respecto al esfuerzo llevado a cabo para la construcciondel subproceso, ha sido un resultado un poco mayor al espe-rado debido a la cantidad de personas que estaban interesadasen el proceso a las cuales se les ha brindado una charla deinformacion sobre su uso y sus beneficios que traerıa parala construccion de proyectos de software. Sin embargo, elesfuerzo utilizado permite estimar que la aplicabilidad de UP-VSE en una pequena organizacion es viable.

VII. CONCLUSIONES, LIMITACIONES Y TRABAJO FUTURO

Este trabajo muestra como el Proceso Unificado puedeservir de marco de referencia para establecer soluciones deprocesos para las VSEs. Para ello se determino el gradode cumplimiento de la norma 29110-5-1-1 y ası seleccionarun subconjunto de practicas conocidas por la industria ynecesarias para alcanzar la norma. De la misma forma se deter-mino aspectos que el proceso unificado no cubrıa, facilitandorequerimientos de extension al proceso original. El procesoresultante, UP-VSE, fue analizado estaticamente a partir deuna evaluacion basada en la norma ISO/IEC 15504-5 en elcontexto de la norma 29110-5-1-1 mostrando su completitud.Ademas se analizo su aplicabilidad practica a traves de unestudio de caso, que si bien no alcanzo la completitud en laimplementacion de la norma, permitio en un lapso corto y conbajos recursos humanos, la implementabilidad de buena partedel modelo.

Existieron algunas limitaciones que trajeron dificultadesal momento de ejecutar el proceso a nivel de la calidad yprontitud de los artefactos, debido a la falta de autoridad sobrela ejecucion del proceso, que por lo general eran causadas porla delegacion de trabajo entre los participantes del equipo de

Disciplinas de PRODIGIACT

Diseno AnalisisSubprocesos ISO/IEC 12207(ISO/IEC 29110-5-1-1)

Tareas ISO/IEC 12207(ISO/IEC 29110-5-1-1) 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

7.1.2.3.1 Analisis de requistosde software (SI. 2)

6.3.1.3.2.1 (SI. 2.1) N 0.07.1.2.3.1.1 (SI. 2.2) T 1

7.1.2.3.1.2 (SI. 2.2, SI. 2.3) T 1

Table XEVALUACION DE LAS TAREAS DE PRODIGIA RESPECTO AL ESTANDAR ISO/IEC 29110-5-1-1:2012 DE LA CAPTURA DE REQUERIMIENTOS

ArtefactosISO/IEC 29110-5-1-1 PRODIGIA CW QW

Plan del proyecto Anteproyecto P 0.3Documento de especi-ficacion de requisitos

Modelo de casos de uso, Doc-umento de casos de uso

T 1

Table XIEVALUACION DE LOS ARTEFACTOS DE PRODIGIA RESPECTO AL

ESTANDAR ISO/IEC 29110-5-1-1:2012 DE LA CAPTURA DEREQUERIMIENTOS

procesos, ası como la rotacion de personal, lo que implicabavolver a capacitar el personal de apoyo.

A futuro, se pretende completar el proyecto definiendo losflujos de trabajo fundamentales del Proceso Unificado, asıcomo la aplicacion completa en el proceso PRODIGIA, para locual se esta desarrollando una plataforma de gestion de proyec-tos siguiendo el enfoque establecido en dicha metodologıa.

REFERENCES

[1] W. S. Humphrey, Managing the software process, ser. SEI series insoftware 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 Pub-

lishing Company, 2007.[5] I. Jacobson, G. Booch, and J. Rumbaugh, The unified software develop-

ment 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 ProcessImprovement, 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 harnessprocess improvement in very small entities,” in Systems, Software andService Process Improvement, ser. Communications in Computer andInformation 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 informacion,2nd ed. Espana: RA-MA, 2011.

[9] V. Ribaud, P. Saliou, R. O’Connor, and C. Laporte, “SoftwareEngineering 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 unifiedprocess to undergraduate students,” in Software Engineering Educationand 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 toa defined project type : A case study 1 Introduction.”

[12] R. V. O’Connor and C. Y. Laporte, “Software Project Management inVery Small Entities with ISO / IEC 29110,” pp. 330–341, 2012.

[13] R. V. O’Connor and C. Y. Laporte, “Deploying Lifecycle Profiles forVery Small Entities : An Early Stage Industry View.”

[14] B. Day, K.-Z. Sean Chin, L. Lovelock, and C. Lutteroth, “Climbing theLadder: CMMI Level 3,” in Enterprise Distributed Object ComputingConference, 2009. EDOC ’09. IEEE International, 2009, pp. 97–106.

[15] R. d. A. Falbo, L. S. M. Borges, and F. F. R. Valente, “UsingKnowledge Management to Improve Software Process Performance ina 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 SmallSoftware Development Teams,” in Software Quality. Process Automationin Software Development SE - 5, ser. Lecture Notes in BusinessInformation 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 Developinga Web-Based Application - A Case-Study,” in Proceedings of the4th International Conference on Practical Aspects of KnowledgeManagement, 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: Bridgingthe Gap,” CLEI Electronic Journal, vol. 16, pp. 3 – 3, 042013. [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 VerySmall Enterprises (VSE) – Part 3: Assessment Guide, ISO (InternationalOrganization for Standardization) SC7-WG24 Group, 2011.

[20] V. Ribaud and P. Saliou, “Process assessment issues of the iso/iec29110 emerging standard,” in Proceedings of the 11th InternationalConference on Product Focused Software, ser. PROFES ’10. NewYork, 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: Infor-mation Technology – Software Process Assessment Part 5: An Assess-ment Model And Indicator Guidance, Rational Corporation Whitepaper,2000.

[22] ISO/IEC 15504-2: Software Process Improvement and Capability Deter-mination - Performing an Assessment, ISO (International Organizationfor Standardization), 2003.

[23] ISO/IEC 15504-5: Software Process Improvement and Capability De-termination - An Assessment Model and Indicator Guidance, ISO(International Organization for Standardization), 1999.

[24] ISO/IEC 15504: Software Process Improvement and Capability Deter-mination, ISO (International Organization for Standardization), 2007.

[25] ISO/IEC 29110-5-1-1: Software Engineering – Lifecycle Profiles forVery Small Enterprises (VSE) – Part 5.1: Management and EngineeringGuide - Basic Profile, ISO (International Organization for Standardiza-tion) SC7-WG24 Group, 2012.

[26] “Free Rup Templates,” 2014. [Online]. Avail-able: 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 PolytechniqueMontreal, 2011. [Online]. Available: http://upedu.org/

[30] P. Runeson and M. Host, “Guidelines for conducting and reportingcase study research in software engineering,” Empirical SoftwareEngineering, 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 Ameri-cas 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, “RepeatableCollaboration Processes for Mature Organizational Policy Making,”no. i.

[33] W. L. Pantoja Yepez, C. A. Collazos, and V. M. R Penichet, “EntornoColaborativo de Apoyo a la Mejora Procesos de Software en PequenasOrganizaciones de Software (COLLAB),” pp. 40–48, 2013.

[34] “Entorno Colaborativo de Apoyo a la Mejora Procesos de Software enPequenas Organizaciones de Software (COLLAB), herramienta utilizadaen la definicion 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ıaAutomatica (PRODIGIA).” Grupos IDIS - IA, Universidaddel Cauca. [Online]. Available: http://artemisa.unicauca.edu.co/\texttildelowjjalvarezl/PRODIGIA/