You are on page 1of 7

Universidad de Chile

Facultad de Ciencias Físicas y Matemáticas
Departamento de Ciencias de la Computación

Análisis de problemas de especificación
de procesos de desarrollo de software
Propuesta de Tesis para Optar al Grado de

Magíster en Tecnologías de la Información

Christian Avendaño Jeldres
Profesores Guía
Daniel Perovich
Jocelyn Simmonds
Santiago de Chile
Enero de 2016

1

....................... 6 REFERENCIAS ................ 5 PLAN DE TRABAJO ............. 5 OBJETIVOS DE LA TESIS ..................................................................................................... 3 SOLUCIÓN AL PROBLEMA ............ 3 PROBLEMA A RESOLVER ..................................................... 4 DEFINICIÓN DE LA PROPUESTA.................................................................................................................................................................................................................................................................... 7 2 .............................................Tabla de contenido INTRODUCCIÓN .................................................................................................................................................................... 5 METODOLOGÍA ..................................................................................................................................................................................................................................................................................................................................................................................... 3 CONTEXTO ...........................................

Esto es considerado como una sobrecarga del rol. muchas compañías han llevado a cabo especificación de procesos de software y mejora como proyecto prioritario. demandando menos experiencia. 1 Tutelkán: Logrando alta alta calidad en la industria nacional de software mediante la aplicación de procesos de referencia (www. Pero ninguno de ellos es fácil de identificar. Algunos de ellos debido a errores conceptuales en el diseño del proceso y otros errores introducidos durante el proceso de especificación. no es requerido por ninguna tarea y tampoco es un entregable final. un ingeniero de procesos sólo necesita analizar los elementos resaltados. Otro ejemplo sería un rol que tiene demasiadas tareas asignadas con respecto al resto de tareas asignadas a los otros roles. estamos en presencia de desperdicio ya que estamos solicitando un entregable innecesariamente. Estándares como ISO/IEC15504 [1] y modelos de madurez como CMMI [2] son generalmente usados como guías para definir estos procesos. Contando con esta herramienta. debido a la enorme cantidad de elementos de proceso involucrados en la especificación de un proceso. se han encontrado que hay algunos errores típicos recurrentes en las especificaciones de los procesos de software. Esto motivó la creación de la herramienta AVISPA2. pero en ningún caso indica las causas y algún tipo de acción ante tal escenario. Por lo tanto. AVISPA en ambos casos indicará gráficamente qué blueprint está sustentando la alerta. menos conocimiento previo para un análisis de modelos de procesos y añadiendo usabilidad. Sin embargo. Durante los últimos años se trabajó en ayudar a las PyMEs de software en Chile para definir sus procesos de desarrollo en un esfuerzo de mejorar el estándar nacional de la industria1. conceptualizar el modelo de proceso de software demanda un enorme esfuerzo para hacer explícitas prácticas comunes y definir prácticas que no existen aún dentro de la compañía. y por lo tanto el retorno de la inversión de la definición del proceso de software no es siempre clara. las múltiples vistas que implican y las notaciones informales que algunas veces pueden introducir ambigüedad.INTRODUCCIÓN CONTEXTO Contar con una buena definición de un modelo de proceso de software es determinante para lograr calidad de software y productividad en el proceso.tutelkan. Como parte de esta experiencia práctica.org) 2 AVISPA: Analysis and VIsualization for Software Process Assessment 3 . Los blueprints son representaciones gráficas destinadas para ayudar a los diseñadores de procesos de software para evaluar la calidad de un modelo de proceso de software y para identificar anomalías en un modelo y proveer indicios en cómo solucionarlos. siempre será requerido el conocimiento experto de un ingeniero de procesos. identificando una serie de patrones de error resaltándolos en diferentes blueprints. una herramienta gráfica que analiza la calidad de un modelo de procesos de software. Un ejemplo de blueprint que considera AVISPA: si un artefacto. Pero todavía no hay un estándar generalizado para determinar la calidad del proceso especificado.

es introducido en esta propuesta de tesis basándose en la idea de un Code Smell [4] pero desde la perspectiva de un modelo de proceso de desarrollo de software. .Especificación formal de cada software process smells. . Este nuevo concepto. por lo cual.acciones. El blueprint como tal resulta insuficiente para la mejora de procesos y es necesario el conocimiento experto del ingeniero de procesos en caso de tener que corregir la especificación del proceso. SOLUCIÓN AL PROBLEMA La solución al problema es crear un mecanismo que asista al ingeniero de procesos en la resolución de los potenciales problemas que AVISPA encuentra. es muy difícil explicar al ingeniero de procesos qué significan las distintas alertas que entrega este programa en términos de un modelo conceptual de proceso de software.PROBLEMA A RESOLVER Si bien AVISPA realiza un proceso de detección de potenciales problemas. ya sean por error en la especificación del proceso ó error en el proceso en sí. la solución se compone de los siguientes entregables: . Al contar con estos entregables. . 4 . Además se crearán tablas de correspondencia entre smells . Además el proceso de detección de los potenciales problemas está codificado en la propia herramienta y no hay una especificación de alto nivel de cómo AVISPA toma esas decisiones. Esta recomendación incluirá las causas más frecuentes y las acciones más frecuentes como base de conocimiento usando software process smells. y tampoco sabemos en la práctica qué hicieron los ingenieros de proceso para solucionar el potencial problema. el problema es el desconocimiento de las causas de estos potenciales problemas.Un modelo conceptual de software process smells. En función de los problemas detectados. Difiere de los blueprint incorporados en AVISPA ya que los software process smells incluyen las posibles causas y las acciones necesarias para su resolución. ejecutaremos la herramienta AVISPA con procesos ya especificados en 6 empresas.causas .Definición del procedimiento de especificación de software process smells.Un modelo conceptual de software process. En base a esto. interactuaremos con los ingenieros de procesos para encontrar las causas y las acciones necesarias. obtendremos un mecanismo para ayudar al ingeniero de procesos en la validación de la especificación de su proceso de desarrollo. Para poder especificar software process smells.

Estos fueron satisfactoriamente usados para identificar un número de defectos en la industria de modelos de procesos. Task Blueprint y Work Product Blueprint) son aplicados a modelos de procesos de software. se definen los siguientes objetivos específicos:   Especificar los blueprints que AVISPA detectando sus causas y acciones frecuentes. 5 . Software Process Smells: Es un nuevo concepto introducido en esta propuesta de tesis. Definir modelo conceptual de un proceso de software. Los tres blueprints considerados (Role Blueprint. recursos humanos y computarizados. Blueprints: Es un medio para visualización y análisis de diferentes perspectivas de un modelo de procesos de software. En esta actividad se estudiarán los diferentes blueprints detectados por la herramienta AVISPA y su fórmula de cálculo en función del modelo conceptual. Fase Preeliminar 1. 2. El término fue acuñado por primera vez por Kent Beck [4]. Revisar blueprints de AVISPA. En esta actividad se definirá la estructura de un modelo de proceso de software. Se basa en la idea introducida por Kent Beck respecto a un “Code Smell” pero desde la perspectiva de un modelo de proceso de desarrollo de software. Desde entonces se han descubierto un conjunto de patrones recurrentes que van desde concepción errónea y mal especificación del proceso [6]. Para lograr este objetivo. Code Smells: Son una indicación superficial que por lo general corresponde a un potencial problema más profundo en el sistema. Construir las tablas de implicancia para dar una recomendación al ingeniero de procesos. estructura organizacional y restricciones. destinados a producir y mantener los entregables requeridos de software [7].  Crear un procedimiento de agregación cuando surjan nuevos software process smells. pero mucha experiencia del ingeniero de procesos es requerida para identificar estos defectos. Software Process: Es un conjunto de pasos parcialmente ordenados. Software Process Model: Es una representación abstracta de un proceso. para simplificar la interacción con el ingeniero de procesos. DEFINICIÓN DE LA PROPUESTA OBJETIVOS DE LA TESIS El objetivo general es proveer a los ingenieros de procesos de un mecanismo que los asista en la especificación de sus procesos de software.MARCO TEÓRICO Los conceptos fundamentales para la comprensión de esta propuesta de tesis son los siguientes. Los procesos blueprints permiten la identificación de entidades excepcionales [3]. METODOLOGÍA A continuación se detallan las actividades a realizar. con artefactos relacionados. Esto presenta una descripción de un proceso desde una perspectiva particular [5].

Evaluar resultados.3. En esta actividad se construirá el documento que contiene el nombre del smell. la lista de causas. Definir modelo conceptual de un software process smell. Revisar procesos de desarrollo. 7. Validar fichas de software process smells. Realizar las entrevistas. En esta actividad se realizará la validación con un ingeniero de procesos. Confeccionar procedimiento de agregación. acciones y la tabla de frecuencias. Fase de Validación 11. En esta actividad se ejecutará AVISPA sobre todos los procesos recopilados. 8. Fase de Análisis 4. 6 . Confeccionar ficha de software process smells. 5. En esta actividad se construirá el documento que contiene el procedimiento para agregar nuevos smells a nuestra base de conocimiento. En esta actividad se recopilarán los procesos de desarrollo que ya fueron especificados por los ingenieros de procesos y se estudiarán que elementos contienen. 6. Fase de Construcción 9. 10. Ejecutar AVISPA sobre los procesos recopilados. En esta actividad se definirá la estructura de un smell. utilizando como base los software process smells descubiertos en menos 2 de las empresas participantes. En esta actividad se elaborarán las entrevistas a los ingenieros de procesos para recopilar sus experiencias en relación a los resultados que AVISPA entregó. En esta actividad se realizará la tabulación de los datos obtenidos y análisis. En esta actividad se aplicarán las entrevistas a los ingenieros autores de los procesos de desarrollo. la fómula de cálculo. Elaborar entrevistas.

2011. A Structured Conceptual and Terminological Framework for Software Process Engineering. Analyzing software process models with AVISPA. 7 . 28-29. [5] Ian Sommerville.PLAN DE TRABAJO A continuación se detalla el cronograma de actividades a realizar: Actividad Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6 Mes 7 Mes 8 1 2 3 4 5 6 7 8 9 10 11 REFERENCIAS [1] ISO. Technical Report CMU/SEI-2006-TR-008. USA. Bastarrica. [7] J. Martin Fowler. A. L. 1993.2.com/bliki/CodeSmell. Software process validation: quantitatively measuring the correspondence of a process to a model. [3] J.html Último acceso en Noviembre del 2015. 1998. Wolf. NY.C. ICSSP ’11. Version 1. In Proceedings of the 2011 International Conference on Software and Systems Process. Cook and A. 23–32.E. [4] “Code Smell”. 41–53. CMMI for Development. Software Engineering Institute. M. Lonchamp. 1999. [2] SEI. 8(2): 147-176. [6] J. Software Engineering. Bergel. Hurtado. ACM: New York./IEC 15504: Information technology – software process assessment and improvement. 2006. Second International Conference on the Continuous Software Process Improvement. Int Organization for Standardization. ACM Transactions On Software Engineering Methodology. Kent Beck http://martinfowler. Technical report. 2011. 9th edition.