Informe Final Andrea&Beatriz

Proyecto de Taller V: Modelado del Proceso de Software de aplicacin en la asignatura Proyecto de Ingeniera de Software
INFORME FINAL PROYECTO DE TALLER V:

MODELADO DEL PROCESO DE SOFTWARE
de aplicacin en la asignatura Proyecto de Ingeniera de Software
Ingeniera de Software - Proyecto de Taller5 Andrea Delgado & Beatriz Prez Pgina 1 de 67 U n i v e r s i d a d de la R e p b l i c a F a c u l t a d de I n g e n i e r a I n s t i t u t o de C o m p u t a c i n
NDICE
1 1.1 1.2 1.3 1.4 2 INTRODUCCIN OBJETIVO Y ALCANCE ORGANIZACIN DEFINICIONES Y SIGLAS REFERENCIAS PRESENTACIN DEL PROYECTO INTRODUCCIN MARCO TERICO DEFINICIN INTRODUCCIN PRODUCTOS A OBTENER PLAN DE TRABAJO INTEGRANTES OBJETIVO 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2
2.1 2.2 2.3 2.3.1 2.3.2 2.4 2.5 2.6 3 3.1 3.2 3.3 4
DESARROLLO DEL PROYECTO ETAPAS ORGANIZACIN CRONOGRAMA PRIMERA ETAPA - ESTUDIO Y RECOPILACIN
4.1 OBJETIVOS 4.2 DESARROLLO 4.2.1 ESTUDIO DE MATERIALES

4.2.1.1 4.2.1.2 4.2.1.3 4.2.1.4 4.2.1.5 Capability Maturity Model (CMM) Software Process Improvement and Capability Determination (SPICE) The Unified Software Development Process Mtrica Versin 3 Plan de Actividades del curso de Taller IV ao 1999
4.2.2
4.2.2.1 4.2.2.2
RECOPILACIN DE LECCIONES APRENDIDAS DEL CURSO DE TALLER IV AO 1999

Cuestionarios Entrevistas
2
2 2
4.3 5
RESULTADOS Y CONCLUSIONES SEGUNDA ETAPA DEFINICIN DEL PROCESO
2 2 2 2 2 2
2 2 2 2
5.1 OBJETIVOS 5.2 DESARROLLO 5.2.1 ELECCIN DE MODELOS A UTILIZAR 5.2.2 MODELO DE PROCESO DEFINIDO
5.2.2.1 5.2.2.2 5.2.2.3 5.2.2.4 Enfoque del Modelo de Proceso Roles del Modelo de Proceso Lneas de Trabajo y sus Actividades, Entregables y Roles Agenda de Actividades y Entregables
5.2.3 PRESENTACIN DEL MODELO DE PROCESO EN EL CURSO 2000 5.3 RESULTADOS Y CONCLUSIONES
2 2
TERCER ETAPA PRUEBAS DEL PROCESO
2 2 2 2 2 2
2 2 2 2 2 2 2 2 2
6.1 OBJETIVOS 6.2 DESARROLLO 6.2.1 MARCO GENERAL 6.2.2 MONITOREO DE ENTREGABLES 6.2.3 AUDITORIAS DEL PROCESO
6.2.3.1 6.2.3.2 6.2.3.3 6.2.3.3.1 6.2.3.3.2 6.2.3.3.3 6.2.3.3.4 6.2.3.4 6.2.3.5 Marco terico Objetivos y Procedimientos Desarrollo de las Auditorias Auditorias de la Fase Inicial Auditorias de la primer iteracin de la Fase de Elaboracin Auditorias de la segunda iteracin de la Fase de Elaboracin Seguimiento y Evaluacin de la Fase de Construccin Cuestionarios Finales para los grupos de Proyecto Cuestionarios Finales para los Directores de Proyecto
6.3 7
RESULTADOS Y CONCLUSIONES CUARTA ETAPA AJUSTES AL PROCESO
2 2 2 2 2 2
2 2 2 2 2 2
7.1 OBJETIVO 7.2 DESARROLLO 7.2.1 ANLISIS Y EVALUACIN DEL MODELO DE PROCESO 7.2.2 PROPUESTA DE AJUSTES AL MODELO DE PROCESO
7.2.2.1 7.2.2.2 7.2.2.3 7.2.2.4 7.2.2.5 7.2.2.6 Incluir un documento de introduccin al Modelo de Proceso Cambios en los documentos de Actividades para cada Lnea de Trabajo Cambios, ajustes y agregados al Modelo de Proceso Definicin de Plantillas para los Entregables Brindar Ejemplos para los Entregables Cambios en la Agenda de Actividades y Agenda de Entregables
7.2.3 7.2.4
7.2.4.1 7.2.4.2 7.2.4.3 7.2.4.4
DEFINICIN DEL MODELO DE PROCESO AJUSTADO ENTORNO REQUERIDO PARA LA APLICACIN DEL MODELO
Estudio del Modelo de Proceso Ajustado Estudio de la Metodologa de Jacobson - Booch - Rumbaugh Eleccin de los roles previo al comienzo del Proyecto Gestin de la Configuracin
2 2
2 2 2 2
7.3 8
RESULTADOS Y CONCLUSIONES QUINTA ETAPA BASES PARA LA MEMORIA ORGANIZACIONAL
2 2 2 2 2
2 2 2
8.1 OBJETIVO 8.2 DESARROLLO 8.2.1 MARCO TERICO

8.2.1.1 8.2.1.2 8.2.1.3 Gestin del Conocimiento Aprendizaje Organizacional Memoria Organizacional
8.2.2
8.2.2.1 8.2.2.2
IMPLEMENTACIN DE LA MEMORIA ORGANIZACIONAL

Sitio Web Base de Datos relacional
2
2 2
8.2.3 PASOS A SEGUIR EN LA MEMORIA ORGANIZACIONAL 8.3 RESULTADOS Y CONCLUSIONES 9 9.1 9.2 EVALUACIN Y CONCLUSIONES EVALUACIN CONCLUSIONES
2 2 2 2 2
INTRODUCCIN
El presente documento contiene la informacin relativa a la realizacin del Proyecto de Taller V de la Carrera de Ingeniera en Computacin Plan 1987, correspondiente al Modelado del Proceso de Software" de aplicacin en la asignatura Proyecto de Ingeniera de Software de la Carrera de Ingeniera en Computacin Plan 1997. En este captulo se brinda una introduccin al documento de forma que el lector obtenga una visin global de su estructura y de los Captulos que lo componen. Est organizado de acuerdo al siguiente detalle: en el punto 1.1 Propsito y Alcance, se describe el objetivo y se establece la informacin que contiene este documento, en el punto 1.2 Organizacin, se muestran los Captulos en los que se encuentra estructurado, en el punto 1.3 Definiciones y Siglas, se detallan las definiciones y siglas que sern utilizadas en el resto del documento y en el punto 1.4 Referencias se brindan las referencias de la bibliografa utilizada.
1.1
Objetivo y Alcance
Este documento de Informe Final del Proyecto de Taller V detalla las actividades realizadas y los documentos generados durante el desarrollo del Proyecto desde su inicio hasta su finalizacin. En cada Captulo se describe una etapa del Proyecto haciendo referencia a la documentacin correspondiente. De este modo, si se desea profundizar en algn tema en particular del Proyecto, es posible recurrir al documento que trata dicho tema especficamente.
1.2
Organizacin
La estructura de este documento est dada en 9 Captulos los cuales siguen un orden cronolgico de acuerdo a las etapas que componen el Proyecto. En este Captulo 1 se realiza la presentacin del Informe Final del Proyecto de Taller V de Modelado del Proceso de Software" de aplicacin en el curso Proyecto de Ingeniera de Software. En el Captulo 2 Presentacin del Proyecto, se brindan la Definicin y el Plan de trabajo del Proyecto y se introduce el contexto tanto en la Carrera de Ingeniera en Computacin como en el rea de Ingeniera de Software en el cual se enmarca. Se presentan las personas involucradas en la realizacin del Proyecto y se definen los objetivos del mismo. En el Captulo 3 Desarrollo del Proyecto, se comentan las etapas identificadas para el desarrollo del Proyecto, as como la organizacin del grupo de trabajo y el cronograma planteado para la realizacin de las mismas. En los Captulos 4, 5, 6, 7 y 8 se presentan las distintas etapas que componen el Proyecto. Para cada una se detallan los Objetivos planteados, as como los entregables ms destacables que la misma genera. Se describe el Desarrollo de las actividades previstas para el cumplimiento de la etapa incluyendo los puntos de mayor relevancia. Finalmente se describen los Resultados obtenidos y las Conclusiones que correspondan. Estos Captulos estn identificados por la siguiente descripcin: Captulo 4 Estudio y Recopilacin, Captulo 5 Definicin del Proceso, Captulo 6 Pruebas del Proceso, Captulo 7 Ajustes al Proceso y Captulo 8 Bases para la Memoria Organizacional. En el Captulo 9 Evaluacin y Conclusiones, se realiza la evaluacin de los productos obtenidos y finalmente se brindan las conclusiones del Proyecto.
1.3
Definiciones y Siglas
En esta seccin se brindan las Definiciones y Siglas que sern utilizadas a lo largo de este Informe Final.
PINGSW97 Proyecto de Ingeniera de Software de la Carrera de Ingeniera en Computacin Plan 1997 CMM Capability Maturity Model SPICE - Software Process Improvement and Capability Determination USDP Unified Software Development Process APM Adaptable Process Model RUP Rational Unified Process
UML Unified Modeling Language WFMC - WorkFlow Management Coalition http://www.wfmc.org.
1.4
Referencias
En esta seccin se brindan las Referencias a la bibliografa que ser nombrada a lo largo de este documento. Estas referencias corresponden en el primer caso a libros y materiales consultados durante el Proyecto, en el segundo caso a la documentacin generada en este Proyecto. En aquellos casos en que el material se encuentra disponible en Internet se brindan las direcciones correspondientes indicando fecha de ltimo acceso. Bibliografa
[Ghezzi91] Fundamentals of Software Engineering, C.Ghezzi-M.Jazayeri-D.Mandrioli, Prentice-Hall,Inc.,
1991, ISBN 0-13-820432-2, edicin en Ingls.

[USDP99] The Unified Software Development Process, I.Jacobson-G.Booch-J.Rumbaugh, Addison
Wesley Longman, Inc., 1999, ISBN 0-201-57169-2, edicin en Ingls.

[JACOB93] Object-Oriented Software Engineering:
a Use Case Driven Approach, I.JacobsonM.Christerson-P.Jonsson-G.vergaard, Addison Wesley Longman, Inc., 1992 (Cuarta Edicin revisada en 1993), edicin en Ingls.
[PRES98] Ingeniera de Software - Un enfoque prctico, R.Pressman, McGraw-Hill,1997 Cuarta Edicin ISBN 84-481-1186-9, edicin en Espaol. [HUMP97] Managing Technical People, W.Humphrey, Addison-Wesley Pub.Co., 1996 (Cuarta Edicin
revisada en 1997), ISBN 0-201-54-597-7, edicin en Ingls.

[CMM93] Capability Maturity Model for Software,Versin 1.1 - CMU/SEI-93-TR-024,M.C.Paulk-C.Weber-
S.Garca-M.Chrissis-M.Bush, Software Engineering Institute (SEI), 1993. www.sei.cmu.edu/publications/documents/93.reports/93.tr.024.html ltimo acceso mayo 2001
[CMMKP93] Key Practices of the Capability Maturity Model, Versin 1.1 - CMU/SEI-93-TR-025, M.C.Paulk-C.Weber-S.Garca-M.Chrissis-M.Bush, Software Engineering Institute (SEI), 1993. www.sei.cmu.edu/publications/documents/93.reports/93.tr.025.html ltimo acceso mayo 2001 [SPICE99] Software Process Improvement and Capability Determination, Versin 3.3 - ISO/IEC-TR15504, International Organization for Standardization e International Electrotechnical Commission (ISO/IEC), 1999. www.seg.iit.nrc.ca/spice ltimo acceso mayo 2001 Ingeniera de Software - Proyecto de Taller5 Andrea Delgado & Beatriz Prez Pgina 5 de 67 U n i v e r s i d a d de la R e p b l i c a F a c u l t a d de I n g e n i e r a I n s t i t u t o de C o m p u t a c i n
Proyecto de Taller V: Modelado del Proceso de Software de aplicacin en la asignatura Proyecto de Ingeniera de Software [MV300] Mtrica Versin 3, Consejo Superior de Informtica, Madrid-Espaa, 1999-2000.
www.map.es/csi/metrica3 ltimo acceso abril 2001

[IEEE-STD-610] Estndard 610 de la IEE [PATIV99] Plan de Actividades del curso de Taller IV Ao 1999, Ingeniera de Software-Instituto de
Computacin (IN.CO.)-Facultad de Ingeniera-Universidad de la Repblica, 1999.

[TRI00] Descripcin del Proyecto de Taller V Modelado del Proceso de Software de aplicacin en la
asignatura Proyecto de Ingeniera de Software, Ing. Jorge Trianes, Ingeniera de Software-Instituto de Computacin (IN.CO.)-Facultad de Ingeniera-Universidad de la Repblica, 2000.
[APM00] Adaptable Process Model R. Pressman & Associates, Inc.,
www.rspa.com/apm ltimo acceso mayo 2001

[RUP00] Rational Unified Model http://www.rational.com ltimo acceso setiembre 2000 [RUP01] Rational Unified Process Versin 2001.03.00 - Rational Software Corporation
http://www.rational.com - http://www.rational.com/products/rup/resource_center ltimo acceso abril 2001

[STEFF98] Presentacin de Sistemas de Workflow Dr. Hermann Steffen, abril 1998 [SEKE99] Proceedings of the Workshop on Learning Software Organizations, Junio 1999, Alemania.
http://www.iese.fhg.de/SEKE99/documents/workshop.html ltimo acceso diciembre 2000

[PAKM98] Proceedings of the 2nd. Int. Conf. On Practical Aspects of Knowledge Management, Octubre
1998, Suecia. http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-13/ ltimo acceso mayo 2001 Documentacin La siguiente documentacin es de la autora de las integrantes de este grupo de Proyecto de Taller V, Andrea Delgado y Beatriz Prez.
[RLATIV99] Recopilacin de lecciones aprendidas en el curso de Taller IV del ao 1999 [MPG00] Modelo de Proceso Genrico 2000 [MPAA00] Modelo de Proceso Agenda de Actividades 2000 [MPAE00] Modelo de Proceso Agenda de Entregables 2000 [MPDA00] Modelo de Proceso Descripcin de la Arquitectura 2000 [MPLTR00] Modelo de Proceso Lnea de Trabajo de Requerimientos 2000 [MPLTA00] Modelo de Proceso Lnea de Trabajo de Anlisis 2000 [MPLTD00] Modelo de Proceso Lnea de Trabajo de Diseo 2000 [MPLTI00] Modelo de Proceso Lnea de Trabajo de Implementacin 2000 [MPLTV00] Modelo de Proceso Lnea de Trabajo de Verificacin 2000 [MPLTCA00] Modelo de Proceso Lnea de Trabajo de Gestin de Calidad 2000 [MPLTCO00] Modelo de Proceso Lnea de Trabajo de Gestin de Configuracin 2000
Proyecto de Taller V: Modelado del Proceso de Software de aplicacin en la asignatura Proyecto de Ingeniera de Software [MPLTGP00] Modelo de Proceso Lnea de Trabajo de Gestin del Proyecto 2000 [MPPRES00] Modelo de Proceso Presentacin en PowerPoint en el curso 2000 [SEEXP00] Seguimiento y Evaluacin de la Experiencia 2000 [MPMED00] Documento de Mediciones de la Experiencia 2000 [AMP00] Anlisis por Fase de la Experiencia 2000 [IMPA01] Introduccin al Modelo de Proceso 2001 [MPAM01] Modificaciones al Modelo de Proceso Inicial 2001 [MPAT01] Plantillas del Modelo de Proceso Ajustado [MPAAE01] Agenda de Actividades y Entregables del Modelo de Proceso Ajustado 2001 [MOINGSW01] Descripcin de la implementacin de la Memoria Organizacional
PRESENTACIN DEL PROYECTO

En este Captulo se introduce al lector en el Proyecto con la intencin de que obtenga una familiarizacin general con la temtica del mismo. En la seccin 2.1 Introduccin, se brinda una breve descripcin del contexto del Proyecto en la Carrera de Ingeniera en Computacin. En la seccin 2.2 Marco terico, se describe el contexto en el rea de Ingeniera de Software en el cual se enmarca la realizacin del Proyecto. En las secciones 2.3 Definicin y 2.4 Plan de Trabajo, se presentan la Definicin del Proyecto y el Plan de Trabajo incluidos en la descripcin del Proyecto dada por el Tutor. En la seccin 2.5 Integrantes, se presentan las personas que estuvieron involucradas en el Proyecto. En la seccin 2.6 Objetivo, se establecen los objetivos planteados para el Proyecto.
2.1
Introduccin
El presente Proyecto de Taller V es el proyecto final de la Carrera de Ingeniera en Computacin Plan 1987. Su temtica pertenece al rea de Ingeniera de Software y es de aplicacin especfica en la asignatura Proyecto de Ingeniera de Software que se dicta en cuarto ao de la Carrera de Ingeniera en Computacin Plan 1997. El ao 2000 fue el primer ao en que se dict la asignatura Proyecto de Ingeniera de Software en la implementacin del nuevo Plan 1997, pero un curso con las mismas caractersticas se dictaba desde hace tres aos con el nombre de Taller IV para el Plan 1987. Este curso tena una duracin anual y estaba separado en dos partes: durante el primer semestre se dictaba el terico de Ingeniera de Software y en el segundo semestre se realizaba un Proyecto de desarrollo de software. En la implementacin actual para el Plan 1997 se dividi el curso de Taller IV en dos asignaturas semestrales: Proyecto de Ingeniera de Software que se dicta en el segundo semestre e Ingeniera de Software que se dicta en el primer semestre y es previa a la realizacin del Proyecto de Ingeniera de Software. En esta ltima asignatura, que es el foco de aplicacin de este Proyecto de Taller V, se debe desarrollar un producto siguiendo un proceso de software establecido.
2.2
Marco terico
La construccin de un producto de software involucra varias etapas y actividades y el orden en que stas se realizan definen el ciclo de vida del software. El proceso seguido para desarrollar, liberar y evolucionar en distintas versiones un producto de software, desde la concepcin de una idea hasta la concrecin de la misma se conoce como el proceso de software. Los procesos de produccin y manufactura son estudiados exhaustivamente en cualquier disciplina cuyo objetivo es obtener determinados productos con caractersticas establecidas. El principal inters de un proceso de produccin es que sea confiable, predecible y eficiente. Un proceso de produccin bien definido, por ejemplo en la produccin de automviles, trae aparejada la obtencin de beneficios como la automatizacin y el uso de componentes y procesos estandarizados. Definiendo un Modelo del proceso de software, se pueden alcanzar los beneficios de los procesos estandarizados. Sin embargo, se deben tener en cuenta dos caractersticas que distinguen al software de los productos industriales tradicionales: en primer lugar la produccin de software es una actividad principalmente intelectual que no puede ser automatizada fcilmente y en segundo lugar el software se caracteriza por su alta inestabilidad en cuanto al cambio en los requerimientos del mismo, lo que trae como consecuencia que los productos deban ser evolucionables, es decir que se puedan cambiar y agregar requerimientos para producir nuevas versiones de los productos. La pregunta est en cmo organizar el proceso de software para permitir la generacin de productos de software de alta calidad, en forma confiable, predecible y eficiente. Se han propuesto varios Modelos del proceso de software basados en el reconocimiento de que el software, como cualquier otro producto industrial, tiene un ciclo de vida que se expande desde su concepcin inicial hasta su
concrecin, y que ese ciclo de vida debe ser anticipado y controlado para asegurar que se alcanzarn las cualidades deseadas para el producto. Entre estos Modelos se pueden destacar el Modelo en Cascada y sus variantes, el Modelo Evolutivo y el Modelo en Espiral. [Ghezzi91] A pesar de los esfuerzos realizados, las promesas de mejora en productividad y calidad a travs de la aplicacin de nuevas tecnologas y metodologas de software no han logrado cumplirse, y las Organizaciones1 se estn dando cuenta de que el problema principal que tienen es su falta de habilidad para gestionar el proceso de software. Los beneficios de la aplicacin de mtodos y herramientas cada vez mejores no siempre se perciben en el marco de un proyecto indisciplinado y catico en el cual, entre otras dificultades, por ejemplo se duplica la agenda prevista para las actividades que componen el proceso de software. En algunos casos, la Organizacin no provee la infraestructura y soporte necesarios para ayudar a prevenir esos problemas. Sin embargo, incluso en las Organizaciones ms indisciplinadas se pueden identificar proyectos de software que producen excelentes resultados. Cuando estos proyectos son exitosos, es en general a travs del esfuerzo de un equipo dedicado ms que por la repeticin de mtodos probados en una Organizacin con un proceso de software maduro. En la ausencia de un proceso de software en la Organizacin, la repeticin de estos buenos resultados depende exclusivamente de poder contar con los mismos individuos para el prximo proyecto. Basar el xito de un proyecto nicamente en la disponibilidad de determinadas personas no provee ninguna base para la mejora de la productividad y calidad a largo plazo en una Organizacin. La mejora continua solamente puede ocurrir a travs del esfuerzo enfocado y sostenido hacia la construccin de una infraestructura de proceso y prcticas de software efectivas. La IEEE define un proceso como una secuencia de pasos realizados para un propsito especfico [IEEE-STD-610] y un proceso de software puede ser definido en forma ms especfica como un conjunto de actividades, mtodos, prcticas y transformaciones que se utilizan para desarrollar y mantener el software y sus productos asociados, por ejemplo, planes, documentos de diseo, cdigo fuente, documentos de pruebas y manual de usuario. A medida que una Organizacin madura, su proceso de software se encuentra cada vez mejor definido y es implementado consistentemente en toda la Organizacin. Este proceso es conocido y difundido entre sus integrantes y las actividades que involucra son desarrolladas siguiendo una planificacin establecida. Los roles y las responsabilidades en el proceso definido estn claramente establecidas en el proyecto y en la Organizacin. La calidad de los productos del software y la satisfaccin del Cliente son monitoreadas y controladas. La planificacin y agenda se basan en registros histricos y son realistas, y los resultados esperados en cuanto a costo, agenda, funcionalidad y calidad del producto son usualmente alcanzados. En general, un proceso disciplinado es seguido en forma consistente porque todos los participantes entienden el valor de hacerlo y existe en la Organizacin la infraestructura necesaria para brindar el soporte requerido. [CMM93]
2.3
Definicin
Como ya se vio en la Seccin 2.1 Introduccin, cada ao se dicta un curso de Ingeniera de Software en el marco de la Carrera de Ingeniera en Computacin, en el cual los grupos participantes desarrollan un producto de software utilizando un proceso de software establecido. En los cursos anteriores al ao 2000, este proceso de software era proporcionado por los Docentes del Curso en la forma de un Plan de Actividades general. Este Plan de Actividades fue evolucionando a medida que era aplicado, pero no existen registros de esos datos.
Aplica la siguiente definicin: Una Organizacin puede definirse, en trminos generales, como una coleccin de personas comprometidas en una actividad conjunta [HUMP97]
En el contexto del Marco terico del Proyecto de Taller V dado previamente en la seccin 2.2, es cada vez ms importante para una Organizacin poder contar con un proceso de software definido, repetible, conocido, utilizado y cuya informacin relevante sea registrada de forma tal que pueda ser utilizada en futuros proyectos.
2.3.1
Introduccin En la carrera parte del aprendizaje de Ingeniera de Software se cumple participando en un proyecto. Desde el punto de vista de los docentes es posible considerarlo como una Organizacin con las siguientes caractersticas especiales: alta volatilidad de sus integrantes, los nicos que permanecen son los docentes los proyectos tienen una duracin fija de 13 semanas la dedicacin semanal de cada integrante del proyecto es relativamente baja aproximadamente unas 15 horas semanales cada grupo de proyecto tiene muchos integrantes en general es difcil concentrar a todo un grupo en el mismo lugar, en el mismo momento la mayor parte del trabajo es descentralizada, de forma individual o en pequeos subgrupos y en distintos momentos la mayor parte de la comunicacin entre los integrantes de un grupo se da por Internet
En esa Organizacin es posible identificar buenas prcticas y lecciones aprendidas para mejorar ao tras ao la productividad de los grupos y la calidad de los productos. Para hacerlo se precisa contar con un proceso definido, con mtricas que permitan evaluar las mejoras y con algn mecanismo que soporte la memoria organizacional para registrar las lecciones aprendidas.[TRI00] Es en este contexto que se hace necesario el modelado de un proceso de software que sea adecuado a la asignatura Proyecto de Ingeniera de Software vista como una Organizacin con las caractersticas especiales descritas en la Definicin del Proyecto, as como el registro de los productos generados y la informacin que surja de la aplicacin del proceso de software definido.
2.3.2
Productos a obtener 1. Recopilacin de lecciones aprendidas a partir de la experiencia del ao 1999. 2. Definicin de un mecanismo para registrarlas 3. Primer versin del proceso de Software, incluyendo: 3.1. identificacin de los distintos roles que participan en el proceso 3.2. definicin de los subprocesos con el flujo de trabajo correspondiente definido en UML 3.3. definicin de entregables indicando Contenido, un Ejemplo y una Plantilla 3.4. las actividades necesarias para generarlos entregables precisando las condiciones que se deben cumplir para poder iniciarla, los elementos de entrada, los de salida y los criterios para darla por terminada, los roles que participan y el tipo de responsabilidad. 3.5. definicin de procedimientos para algunos procesos claves que incluyan la utilizacin de herramientas elementales, en particular e-mail y pginas web. 4. Evaluacin del proceso a partir de la experiencia de su adopcin por parte de grupos de estudiantes en el segundo semestre de 2000. 5. Versin ajustada del proceso a partir de la evaluacin.
2.4
Plan de Trabajo
La descripcin del Proyecto de Taller V inclua una planificacin para el desarrollo del mismo la cual consta de 5 etapas claramente definidas. A continuacin se transcribe el Plan de Trabajo [TRI00] previsto en la descripcin del Proyecto: Ajustes al Plan de Trabajo y asignacin de tareas Estudio y Recopilacin Estudio de tcnicas para definir procesos de software y tipos de modelos Estudio de UML aplicado a la especificacin de procesos Estudio de Modelos de Mejora de Procesos de Software Estudio de antecedentes de procesos definidos Entrevistas a estudiantes que participaron en proyectos de Taller IV en 1999
Definicin del Proceso Eleccin de los modelos a utilizar para especificar el proceso Especificacin del proceso en UML Identificacin de los indicadores relevantes para poder evaluar el proceso respecto al impacto en la calidad de los productos y la productividad Definicin de los procedimientos de medicin Presentacin del proceso definido a los estudiantes que participen en proyectos de Ingeniera de Software en el 2do. Semestre del 2000
Pruebas del proceso Definicin de encuestas de evaluacin Recopilacin de las encuestas Recopilacin de mediciones de los proyectos Realizacin de entrevistas a integrantes de distintos grupos de proyectos Identificacin de las faltas de conformidad del proceso seguido por los grupos con propuesto Anlisis de las causas de las faltas de conformidad, identificacin de ajustes necesarios proceso o necesidad de herramientas que faciliten su adopcin Definicin de criterios de evaluacin de la conformidad del proceso seguido con propuesto, y de la calidad de los productos Evaluacin de los productos Anlisis de la correlacin entre la evaluacin de los productos y la conformidad con proceso
el al el
el
Ajustes al Proceso Evaluacin de las pruebas del proceso Propuesta de ajustes Definicin del proceso ajustado
Posteriormente en la Seccin 3.1 Etapas, en la cual se describen las etapas identificadas para el desarrollo del Proyecto de Taller V, se podr apreciar que las etapas definidas no se corresponden exactamente con las etapas previstas, lo cual ser detallado en dicha seccin.
2.5
Integrantes
De acuerdo a lo establecido en la descripcin del Proyecto de Taller V, el grupo encargado del desarrollo del mismo deba formarse con 2 integrantes. Quienes integran este grupo de Proyecto de Taller V son Andrea Delgado y Beatriz Prez, ambas estudiantes de la Carrera de Ingeniera en Computacin Plan 1987. El docente encargado de la tutora del Taller V es el Ing. Jorge Trianes, quien tambin es el responsable de la asignatura Proyecto de Ingeniera de Software.
2.6
Objetivo
El objetivo principal de este Proyecto de Taller V es obtener un proceso definido y validado que pueda ser utilizado como base para la aplicacin de un proceso de mejora continua de los proyectos de enseanza de Ingeniera de Software. Para alcanzar este objetivo se plantean una serie de objetivos intermedios dados por las etapas del Proyecto. El primer objetivo planteado es el modelado de un proceso de software adecuado a la asignatura PINGSW97. El Modelo de Proceso definido ser aplicado en el dictado de la mencionada asignatura en el segundo semestre del ao 2000. Un segundo objetivo es la realizacin del seguimiento y evaluacin de la aplicacin del proceso por parte de los grupos, registrando los productos generados y la informacin obtenida. En base a este seguimiento se podrn realizar los ajustes que se consideren necesarios al Modelo de proceso aplicado en dicha asignatura. Finalmente, y como tercer objetivo, la informacin relativa al Modelo de Proceso, los productos generados, el seguimiento y evaluacin de la aplicacin del mismo y los ajustes realizados, sern registrados para que dicha informacin pueda ser utilizada en proyectos posteriores. Los productos generados por el Proyecto de Taller V constituirn la base para un proceso de mejora continua de los proyectos de enseanza de Ingeniera de Software.
DESARROLLO DEL PROYECTO

En este Captulo se brinda una visin general sobre el desarrollo del Proyecto de Taller V en el tiempo, el cual dio comienzo en marzo de 2000 y finaliz en mayo de 2001. En la seccin 3.1 Etapas, se describen las etapas que componen el Proyecto las cuales fueron identificadas en base a lo establecido previamente en la Seccin 2.4 Plan de Trabajo. En la seccin 3.2 Organizacin, se describe como fue la organizacin del grupo de trabajo durante el desarrollo del Proyecto. En la seccin 3.3 Cronograma, se presenta el cronograma planteado para la realizacin de las distintas etapas.
3.1
Etapas
En esta seccin se describen brevemente las etapas identificadas para el desarrollo del Proyecto las cuales se detallan en profundidad en los Captulos siguientes. En base a lo establecido en la Seccin 2.4 Plan de Trabajo se identificaron inicialmente cuatro etapas para el desarrollo del Proyecto. Si bien el Plan de Trabajo previsto en la descripcin del Proyecto se compona de cinco etapas, la primer etapa identificada como Ajustes al Plan de Trabajo y asignacin de tareas, no se desarroll como una etapa en s misma, sino que la misma se realiz a medida que se desarrollaban el resto de las etapas, asignando las tareas al comienzo y modificando su duracin en caso que fuera necesario. Sobre el final del Proyecto se identific una etapa que si bien no estaba contemplada en forma explcita en el Plan de Trabajo previsto, si lo estaba de hecho en la Definicin del Proyecto. En total las etapas que finalmente se establecieron para el desarrollo del Proyecto son cinco y se describen a continuacin: La primera etapa corresponde al Estudio y Recopilacin en la cual se pretende adquirir el conocimiento necesario para realizar posteriormente la definicin del Modelo de Proceso. El desarrollo de esta etapa se detalla en el Captulo 4 Primera etapa Estudio y Recopilacin. En la segunda etapa se realiza la Definicin del Proceso a ser aplicado en la asignatura PINGSW97 del ao 2000 y presentado a los grupos que lo pondran en prctica. Esta etapa se detalla en el Captulo 5 Segunda etapa Definicin del Proceso. En la tercera etapa se realizan las Pruebas del Proceso lo cual implica el seguimiento y evaluacin de la aplicacin del Modelo de Proceso por parte de los grupos. Las actividades desarrolladas en esta etapa se detallan en el Captulo 6 Tercera etapa Pruebas del Proceso. La cuarta etapa corresponde a la realizacin de Ajustes al Proceso los cuales son identificados a partir de la etapa de Pruebas del Proceso realizada previamente. El desarrollo de esta etapa se detalla en el Captulo 7 Cuarta Etapa Ajustes al Proceso. La quinta etapa es el establecimiento de las Bases para la Memoria Organizacional en la cual se registra la informacin relativa a la aplicacin del Modelo de Proceso por parte de los grupos y los productos generados tanto en el Proyecto de Ingeniera de Software como en este Proyecto de Taller V. La realizacin de esta etapa se detalla en el Captulo 8 Quinta etapa Bases para la Memoria Organizacional. Cada Captulo de los que se corresponden con una etapa del Proyecto est organizado en tres secciones principales las cuales estn dadas en primer lugar por una seccin de Objetivo, en segundo lugar una seccin de Desarrollo y en tercer y ltimo lugar una seccin de Resultados y Conclusiones que correspondan a la etapa. En la seccin de Objetivo se describen los objetivos planteados para la realizacin de la etapa, la segunda seccin de Desarrollo se organiza de acuerdo a la etapa que se est describiendo,
enumerando los puntos relevantes en el desarrollo de la misma en los que se detallan las tareas realizadas. En la ltima seccin de Resultados y Conclusiones se muestran los resultados obtenidos y las conclusiones sobre el desarrollo de la etapa y el cumplimiento de los objetivos marcados.
3.2
Organizacin
El grupo de Proyecto no tuvo una organizacin fija de trabajo lo cual en parte se debe a que est compuesto nicamente por dos integrantes. En general la mayora de las actividades que se realizaron durante el desarrollo del Proyecto se hicieron en base a reuniones diarias en las cuales se definan en lneas generales las tareas, se realizaba una divisin equitativa de las mismas y se establecan las fechas de finalizacin para cada una. Una vez realizadas las tareas asignadas en forma individual, cada integrante revisaba el trabajo que no haba realizado y se llegaba a un acuerdo sobre el producto final en reuniones o utilizando e-mail en el caso de redaccin de documentos. Durante todo el desarrollo del Proyecto se mantuvo contacto diariamente mediante el uso de e-mail. En todo momento hubo un apoyo mutuo para la realizacin de las tareas de forma de lograr la mayor calidad posible en el trabajo realizado. Las reuniones con el Tutor del Proyecto tuvieron una frecuencia semanal durante el primer semestre del Proyecto dadas las caractersticas de las tareas a realizar en esa etapa. Durante el segundo semestre el contacto fue ms espaciado pero se mantena la comunicacin va e-mail para consulta de dudas y envo de documentos. Al momento del inicio de la recuperacin de cursos en Enero de 2001, los cuales haban sido suspendidos por la realizacin de una Huelga Universitaria por Presupuesto a mediados del segundo semestre, se retoma contacto con el Tutor y la frecuencia de las reuniones es quincenal hasta el momento de finalizacin del Proyecto en Mayo de 2001, manteniendo contacto va e-mail en forma semanal.
3.3
Cronograma
Las etapas identificadas para el desarrollo del Proyecto de Taller V tenan claramente definida su ubicacin en el tiempo debido a las actividades que las componen. En la Tabla 1 se muestra el cronograma previsto con la ubicacin inicial de las etapas en el tiempo. Durante el desarrollo del Proyecto fue necesario introducir cambios al cronograma previsto por distintas razones, entre ellas porque desde fines de Octubre hasta fines de Diciembre tuvo lugar una Huelga Universitaria por Presupuesto en la cual se suspendi el dictado de cursos y las actividades curriculares de la facultad. Este hecho afect en forma irremediable el desarrollo del Proyecto, no slo por el corrimiento del calendario sino por las actividades que se vieron truncadas, algunas de las cuales no pudieron realizarse en la forma prevista al iniciarse la recuperacin de cursos una vez finalizada la Huelga.
Etapas del Proyecto

MARZO ABRIL
Meses del ao 2000
MAYO
JUNIO
JULIO
AGO.
SET.
OCT.
NOV.
DIC.
Etapa 1 Estudio y Recopilacin Etapa 2 Definicin del Proceso Etapa 3 Pruebas del Proceso Etapa 4 Ajustes al Proceso Etapa 5 Bases Memoria Organizacional Etapa 6 Informe Final y Presentacin
Tabla 1 Cronograma previsto para el desarrollo del Proyecto
La etapa 1 de Estudio y Recopilacin estaba previsto que finalizara a principios de Junio pero se extendi a Junio y Julio inclusive, debido a que la bibliografa indicada result en algunos casos bastante compleja y tom ms tiempo del esperado adquirir los conocimientos necesarios para realizar las tareas definidas para la etapa 2. La duracin prevista era de dos meses y medio y su duracin real fue de cuatro meses y medio. La etapa 2 de Definicin del Proceso tena fija su finalizacin puesto que el Modelo de Proceso definido deba ser presentado a los grupos que cursaran la asignatura PINGSW97 en el segundo semestre de 2000 cuya fecha de inicio estaba prevista para el 14 de Agosto. Es por eso que esta etapa no poda extenderse ms all de esa fecha y existi una superposicin de actividades de la etapa 1 y de la etapa 2 durante dos meses. La duracin prevista para esta etapa era de dos meses y medio y su duracin real fue la prevista. En el Cronograma final en la Tabla 2 a continuacin, puede observarse que la etapa 3 de Pruebas del Proceso interrumpida por la Huelga, fue retomada cuando se recuperaron los cursos a partir de mediados de Enero de 2001. Sin embargo, las actividades de esta etapa no pudieron realizarse como estaban previstas por distintas razones que se detallan en la Seccin 6.2.2.3.4 Seguimiento de la Fase de Construccin dentro del Captulo 6 Etapa 3 - Pruebas del Proceso. La duracin real de la etapa se correspondi con la duracin prevista para la misma en el Cronograma inicial. La etapa 4 de Ajustes al Proceso se decidi comenzarla en el momento del inicio de la recuperacin de cursos, pues no se tena seguridad sobre el tiempo que podra llevar cumplir con las actividades previstas al haber perdido contacto durante la Huelga con el seguimiento y evaluacin de la aplicacin del Modelo de Proceso por parte de los grupos. Finalmente esta etapa se extendi en un mes y medio ms de lo previsto ya que el curso de PINGSW97 culmin a fines de febrero del corriente y se debi procesar la informacin recopilada al cierre de los proyectos de cada grupo. La duracin prevista para
esta etapa antes de la Huelga era de aproximadamente dos meses y su duracin real fue de tres meses y medio. Tambin se decidi comenzar con la etapa 5 de Bases para la Memoria Organizacional en paralelo con las actividades de la etapa 4 de Ajustes al Proceso debido a que la implementacin que se haba pensado para la misma requera bastante ms tiempo del previsto inicialmente antes de definir esa implementacin. Esta etapa tambin se extendi en duracin debido a que por la complejidad del tema se debieron estudiar varios materiales lo que no estaba previsto inicialmente y tambin, como ya se mencion, a la implementacin de la Memoria Organizacional que se realiz como una Base de Datos Relacional y un Sitio Web. Esta definicin de la Memoria Organizacional involucra varias tareas de extensa duracin relativas al armado del Sitio Web y al diseo de la Base de Datos lo que incluye la definicin de tablas y el llenado de las mismas con toda la informacin relativa a este Proyecto de Taller V y a la Experiencia 2000. La duracin de esta etapa estaba prevista en aproximadamente dos meses y su duracin real fue de cuatro meses y medio. El Cronograma final que fue cumplido en el desarrollo del proyecto se detalla en el siguiente cuadro:
Etapas del Proyecto

MAR. ABR.
Meses del ao 2000 y 2001
MAY.
JUN.
JUL.
AGO.
SET.
OCT.
NOV.
DIC.
ENE. FEB.
MAR.
ABR.
MAY.
Etapa 1 Estudio y Recopilacin Etapa 2 Definicin del Proceso Etapa 3 Pruebas del Proceso Etapa 4 Ajustes al Proceso Etapa 5 Bases Memoria Organizacional Etapa 6 Informe Final y Presentacin
Tabla 2 Cronograma real del desarrollo del Proyecto
La duracin total del desarrollo del Proyecto en meses fue de doce meses teniendo en cuenta el cronograma en el que se encuentran marcados los meses correspondientes a la Huelga y la superposicin existente entre las actividades de las distintas etapas. La duracin prevista en meses para el desarrollo del Proyecto era de aproximadamente nueve meses y medio, la cual se vio extendida por las razones mencionadas previamente. La cantidad de horashombre invertidas en las actividades correspondientes a cada etapa del desarrollo del Proyecto no fueron contabilizadas en forma exacta, pero la estimacin de horas realizada da un promedio de entre 25 y 30 horas Semanales.
En la siguiente grfica se muestra la duracin prevista en meses para las etapas de desarrollo del Proyecto y la duracin real que finalmente tuvo cada una.
Etapas del desarrollo del Proyecto

duracin prevista 5 duracin real
4,5
3,5
3 Meses
2,5
1,5
0,5
0 1 2 3 Etapas 4 5 6
Figura 1 - Grfico de duracin de las etapas de desarrollo del Proyecto en meses previstos y reales.
PRIMERA ETAPA - ESTUDIO Y RECOPILACIN

En este Captulo se describe la primera etapa del desarrollo del Proyecto correspondiente a las actividades de Estudio y Recopilacin. Como primer punto se establecen sus objetivos y actividades previstas en la Seccin 4.1 Objetivos. En la Seccin 4.2 Desarrollo se detallan las actividades realizadas y como primer punto se brinda un breve resumen de la bibliografa estudiada, para aquella considerada como ms relevante para los objetivos planteados. Como segundo punto se describen las actividades de recopilacin realizadas sobre la experiencia del curso de Taller IV del ao 1999. Finalmente en la Seccin 4.3 Resultados y Conclusiones se muestran los resultados obtenidos y las conclusiones de la etapa.
4.1
Objetivos
En esta etapa de Estudio y Recopilacin el objetivo fundamental es obtener los conocimientos necesarios y recabar informacin de utilidad para realizar posteriormente la Definicin del Modelo de Proceso a aplicar en la asignatura PINGSW97 del curso 2000 de acuerdo a lo previsto en las etapas de desarrollo del Proyecto. Se busca lograr una base conceptual sobre modelado de procesos de software y tipos de Modelos, as como de Modelos de Mejora de procesos de software. Tambin se estudian antecedentes de procesos definidos y se obtiene informacin sobre la experiencia del curso de Taller IV del ao 1999. Adems se estudia el lenguaje UML aplicado a la especificacin de procesos de software.
4.2
Desarrollo
Al comienzo del Proyecto no se tena muy claro cual era la bibliografa ms conveniente para comenzar las tareas de estudio que deban realizarse. Consultado el Tutor del Proyecto sugiri comenzar con la bibliografa de Modelos de Mejora de Procesos y proporcion las direcciones en Internet para conseguirla. Esta bibliografa est compuesta por dos Modelos de Mejora de Procesos: Capability Maturity Model - CMM del Software Engineering Institute (SEI) [CMM93] [CMMK93] y Software Process Improvement and Capability Determination SPICE de International Organization for Standardization e International Electrotechnical Commission (ISO/IEC) [SPICE99]. La bibliografa sobre CMM se compone de dos documentos, uno que brinda una visin general del Modelo y otro ms especfico que detalla las caractersticas ms importantes que ste presenta. Estos documentos resultaron bastantes complejos y extensos, por lo que se debieron invertir muchas horas en su estudio y comprensin. La bibliografa de SPICE es un documento especfico en el cual se detallan las caractersticas del Modelo y brindan ejemplos de estudio. Esta documentacin tambin es bastante compleja y extensa, por lo que al igual que con los documentos del CMM se debieron invertir muchas horas en su lectura. Sobre SPICE se asisti a una charla que dict el Ing. Juan Echage en el Saln de Posgrados del Instituto de Computacin (IN.CO) el 4 de Julio de 2000 la cual fue de gran apoyo para lograr la comprensin del mismo. Si bien estos documentos proporcionaron bastante informacin sobre las actividades claves que deben desarrollarse en un proceso de software de calidad, tienen un nivel de abstraccin bastante alto y no contemplan la utilizacin de ningn Modelo de proceso en forma especfica. Como la etapa 2 de Definicin del Proceso tena dada su fecha de finalizacin por el comienzo de cursos del segundo semestre, en el cual se deba presentar el Modelo de Proceso a los grupos participantes en la asignatura donde se aplicara, se haca necesario estudiar modelos de proceso definidos para comenzar a delinear las caractersticas del Modelo de Proceso que se deba definir. En ese momento el Tutor indic un libro que haba sido recientemente publicado en el cual se describe un modelo de proceso adaptable basado en la unin de varias corrientes de desarrollo. El libro The Unified Software Development Process de Jacobson-Booch-Rumbaugh [USDP99] fue adquirido por ambas integrantes del grupo y se comenz con el estudio del mismo.
Para el estudio de otro modelo de proceso adaptable el Tutor proporcion la direccin en Internet de Mtrica Versin 3 del Consejo Superior de Informtica de Espaa [MV300], el cual se compone de varios documentos que presentan en detalle las caractersticas del modelo. Tambin se realiz una intensa bsqueda en Internet de informacin relativa al tema de modelado y definicin de procesos de software, encontrndose como aportes destacables las pginas del Adaptable Process Model-APM de Pressman [APM00] y la del Rational Unified Process-RUP [RUP00]. Como ejemplo de aplicacin de procesos de software se estudi el Plan de Actividades del curso de Taller IV del ao 1999 [PATIV99] el cual ya se conoca debido a que quienes realizan este Proyecto de Taller V haban cursado el Taller IV en ese ao. En la etapa de recopilacin de lecciones aprendidas se deban realizar entrevistas a los estudiantes del curso de Taller IV del ao 1999. Se esperaba que la informacin que se pudiera obtener en dicha actividad sirviera como histrico de la aplicacin del proceso de software dado en forma de Plan de Actividades por los docentes del curso en ese ao. Como ya se mencion quienes realizan este Proyecto de Taller V tambin haban cursado Taller IV en el ao 1999 en distintos grupos y cumpliendo distintos roles: Andrea Delgado en el rol de Responsable de Calidad y Gestin de Configuracin del grupo 11 y Beatriz Prez en el rol de Arquitecto y Asistente de Verificacin del grupo 17. Esto permiti que a partir de la experiencia de cada una en el Taller IV se tuviera una visin personal de la aplicacin del Plan de Actividades mencionado. Debido a los tiempos marcados para la finalizacin de la etapa 2 de Definicin del Proceso a aplicar en el segundo semestre, y al tiempo que estaba llevando el estudio de la bibliografa mencionada previamente se decidi comenzar con la recopilacin de lecciones aprendidas del curso de Taller IV del ao 1999 en paralelo al estudio de la bibliografa que se vena realizando. Frente al avance de los cursos del primer semestre y la posibilidad de que muchos estudiantes no tuvieran disponibilidad horaria para realizar las entrevistas, se decidi disear un cuestionario para enviar por e-mail a dichos estudiantes, en el cual se realizaran preguntas sobre los aspectos ms relevantes del desarrollo del curso. Este cuestionario era fcil de responder y se esperaba que sirviera como base para la realizacin de las entrevistas ya que se podra profundizar en los aspectos ms interesantes de las respuestas de cada persona. A continuacin en la seccin 4.1 Estudio de materiales se brinda una visin general de la bibliografa ms relevante entre toda la documentacin estudiada, y en la seccin 4.2 Recopilacin de lecciones aprendidas del curso de Taller IV ao 1999 se describen en detalle las actividades y procedimientos utilizados para recabar informacin sobre el desarrollo de los proyectos en ese curso.
4.2.1
Estudio de Materiales En las siguientes secciones se describe la bibliografa que aport las bases para adquirir el conocimiento necesario para el desarrollo de la etapa 2 de Definicin del Proceso. En cada caso se intenta brindar una visin general de su contenido destacando los conceptos ms relevantes.
4.2.1.1 Capability Maturity Model (CMM)

[CMM93] [CMMKP93]
CMM establece un marco de referencia comn tanto para realizar evaluacin de procesos de software en la Organizacin como para evaluar las capacidades del proceso de software de terceros al seleccionar empresas para su contratacin. Establece un marco de trabajo que representa un camino evolutivo de mejoras recomendado para incrementar las capacidades del proceso de software en una Organizacin. Provee una gua para seleccionar las estrategias de mejora de procesos adecuadas a la Organizacin, determinando la madurez actual de los procesos aplicados e identificando las caractersticas crticas de la calidad del software y de la mejora de procesos.
La mejora continua de procesos que plantea CMM est basada en la realizacin de varios pasos pequeos en forma evolutiva, los cuales estn organizados en cinco niveles de madurez de forma tal que las mejoras realizadas en cada etapa provean las bases sobre las cuales se realicen las mejoras en la etapa siguiente. Estos cinco niveles definen una escala para medir la madurez del proceso de software de la Organizacin y para evaluar las capacidades del mismo, ayudando a establecer la prioridad de los esfuerzos que deben realizarse. Cada nivel de madurez est compuesto por varias reas claves del proceso que indican las reas en las cuales se debe enfocar el esfuerzo de mejora y que identifican un conjunto de actividades relacionadas que al realizarse colectivamente logran un conjunto de objetivos definidos para ese nivel. Al ir avanzando en cada nivel de madurez, un componente distinto en el proceso de software se vuelve estable, resultando en un incremento en la capacidad del proceso de la Organizacin. Los cinco niveles de madurez del proceso de software se describen a continuacin:
Nivel 1: Inicial
En este nivel, la Organizacin tpicamente no provee un entorno estable para desarrollar y mantener el software. El proceso de software est caracterizado como ad hoc ya que se cambia o modifica continuamente a medida que el trabajo avanza. La Agenda, presupuestos, funcionalidad y calidad del producto son generalmente impredecibles. Pocos procesos son estables y definidos y el xito depende del esfuerzo individual de las personas ms que de las capacidades de la Organizacin. La capacidad del proceso de software de una Organizacin en este nivel puede resumirse como impredecible, ya que no se tiene control sobre el proyecto.
Nivel 2: Repetible
En este nivel, la Organizacin tiene polticas definidas para la gestin del proyecto y procedimientos establecidos para implementar esas polticas. La planificacin y gestin de nuevos proyectos as como los objetivos definidos para el mismo, se basan en la experiencia y resultados observados en proyectos similares, y en los requerimientos del proyecto en desarrollo. Existen procesos bsicos de gestin del proyecto para controlar el costo, agenda y funcionalidad del proyecto. Los requerimientos del software y los productos desarrollados durante el proyecto son controlados, existen estndares definidos y la Organizacin asegura que sean seguidos. La capacidad del proceso de software de una Organizacin en este nivel es disciplinada ya que la planificacin y seguimiento del proyecto es estable y pueden repetirse xitos anteriores.
Nivel 3: Definido
En una Organizacin en este nivel, el proceso de software para las actividades de ingeniera y de gestin del proyecto est documentado, estandarizado e integrado en un proceso de software estndar para la misma. Todos los proyectos en la Organizacin utilizan una versin aprobada de este proceso de software estndar para desarrollar y mantener el software, el cual es adaptado a cada proyecto especfico para definir su propio proceso de software. Un proceso de software bien definido incluir criterios de preparacin, entradas, estndares y procedimientos para realizar el trabajo, mecanismos de verificacin, salidas y criterios de cumplimiento. La capacidad del proceso de software de una Organizacin en este nivel puede resumirse como estandarizada y consistente ya que tanto las actividades de ingeniera como las de gestin son estables y repetibles. Esta capacidad del proceso est basada en un entendimiento amplio y comn en la Organizacin de las actividades, roles y responsabilidades en el proceso de software definido.
Nivel 4: Gestionado
En este nivel, la Organizacin establece objetivos cuantitativos de la calidad tanto de los productos como del proceso de software. La productividad y calidad son medidas en todos los proyectos, en las actividades importantes del proceso de software como parte de un programa de medidas definido en la Organizacin. Se utiliza una Base de Datos comn para recolectar y analizar la informacin disponible para los procesos de software definidos en cada proyecto. Estos procesos son instrumentados con medidas consistentes y bien definidas las cuales establecen las bases cuantitativas para evaluar los productos y procesos de software de los
proyectos. La capacidad del proceso de software de una Organizacin en este nivel es predecible ya que el proceso es medido y permite predecir tendencias en la calidad de los productos y del proceso en el marco de los lmites cuantitativos definidos. Los productos de software son predecibles de alta calidad.
Nivel 5: Optimizante
En este nivel, la Organizacin est enfocada en el proceso de mejora continua y tiene la habilidad de identificar las debilidades y puntos fuertes del proceso en forma proactiva, con el objetivo de prevenir la ocurrencia de defectos. La informacin sobre la efectividad del proceso de software es utilizada para realizar anlisis de costo-beneficio de nuevas tecnologas y cambios propuestos al proceso de software de la organizacin. Las innovaciones que explotan las mejores prcticas de software son identificadas y transferidas a toda la Organizacin. Los equipos de proyecto analizan los defectos para determinar sus causas, los procesos de software definidos son evaluados para prevenir que tipos conocidos de defectos vuelvan a ocurrir y las lecciones aprendidas se extienden al resto de los proyectos en la Organizacin. La capacidad del proceso de software de una Organizacin en este nivel puede caracterizarse como de mejora continua, ya que estn continuamente intentando mejorar la performance del proceso de software de sus proyectos. Esta mejora ocurre mediante avances incrementales en el proceso de software existente y con innovaciones utilizando nuevas tecnologas y mtodos. CMM es un Modelo descriptivo en el sentido que describe los atributos esenciales o claves que se esperan de un proceso de software para caracterizar a una Organizacin en un nivel de madurez particular y est orientado a Organizaciones que realizan desarrollo de software a gran escala. Se intenta tener un nivel de abstraccin suficiente para no restringir la forma en que es implementado un proceso de software por una Organizacin, sino para describir cuales son los atributos esenciales que se esperan normalmente de un proceso de software. No es prescriptivo ya que no dice como se debe realizar la mejora sino que indica que se debe cumplir en cada nivel para alcanzarla.
4.2.1.2 Software Process Improvement and Capability Determination (SPICE)

[SPICE99]
SPICE provee un marco de trabajo para la evaluacin de procesos de software, para ser utilizado por Organizaciones involucradas en la planificacin, gestin, seguimiento, control y mejora de la adquisicin, provisin, desarrollo, operacin, evolucin y soporte de software. Este marco de trabajo provee un enfoque estructurado para la evaluacin de procesos de software en una Organizacin con el objetivo de entender el estado de sus propios procesos de software, o determinar la adecuacin de sus propios procesos de software a un requerimiento o clase de requerimientos particular, o determinar la adecuacin de los procesos de otra Organizacin para un contrato o clase de contrato particular. El mecanismo que plantea es examinar los procesos utilizados por una Organizacin para determinar donde estos son efectivos en alcanzar los objetivos definidos, caracterizando las prcticas actuales en una unidad de la Organizacin en trminos de la capacidad de los procesos seleccionados. Los resultados pueden ser utilizados para encarar actividades de mejora de procesos o para determinar la capacidad de los procesos analizando los resultados en el contexto de las necesidades de la Organizacin, identificando puntos fuertes, debilidades y riesgos inherentes a los procesos. SPICE consta de una arquitectura definida para establecer el rating de los procesos y para presentar los ratings de la evaluacin, definiendo un modelo de referencia que provee la base para determinar la capacidad de los procesos de acuerdo al cumplimiento de los atributos definidos para el mismo. El modelo de referencia define los objetivos fundamentales que son esenciales para una Ingeniera de software de alto nivel, describiendo que es lo que debe alcanzarse sin establecer como debe hacerse.
La evaluacin de procesos se realiza comparando los procesos seleccionados contra el modelo de evaluacin elegido, el cual debe ser compatible con el modelo de referencia definido en SPICE. Este modelo de referencia tiene un enfoque de dos dimensiones para la evaluacin de la capacidad de los procesos dado por una dimensin que define los procesos que sern evaluados, y otra dimensin que describe la escala para la medicin de la capacidad de los procesos. Esta escala se compone de un conjunto de nueve atributos de procesos, agrupados en niveles de capacidad que representan una evolucin en forma incremental para la mejora de la capacidad de cualquier proceso. Los atributos de los procesos son caractersticas que pueden ser evaluadas en una escala de cumplimiento, proveyendo una medida de la capacidad del proceso. Cada nivel de capacidad se caracteriza por un conjunto de atributos que trabajan juntos para proveer una mejora en la capacidad del proceso. Cada proceso en el modelo de referencia se describe estableciendo el propsito del proceso incluyendo la salida esperada de su implementacin. Las dos dimensiones del modelo de referencia y sus elementos se describen a continuacin:
La dimensin de los procesos

La dimensin de los procesos est dada por la agrupacin de procesos de acuerdo a sus caractersticas comunes, en las siguientes categoras de procesos: Cliente-Proveedor Este grupo incluye los procesos que impactan directamente en el cliente, soportan el desarrollo y transicin del software al cliente y proveen la operacin y uso correcto del producto de software y/o servicio. Ingeniera Esta categora consiste de los procesos que directamente especifican, implementan o mantienen el producto de software, su relacin con el sistema y su documentacin del cliente. Soporte En este grupo se encuentran los procesos que sern utilizados por cualquier otro proceso incluyendo otros procesos de soporte, en varios puntos del ciclo de vida del software. Gestin En esta categora se agrupan los procesos que contienen prcticas genricas que sern usadas por cualquier persona involucrada en la gestin de cualquier tipo de proyecto o proceso en el ciclo de vida del software. Organizacin Este grupo contiene los procesos que establecen los objetivos del negocio de la Organizacin y del proceso de desarrollo, productos y recursos, que cuando son utilizados por los proyectos en la Organizacin permiten alcanzar los objetivos del negocio definidos.
La dimensin de la capacidad
La dimensin de la capacidad de los procesos est dada por la agrupacin de los atributos de procesos en los siguientes niveles de capacidad: Nivel 0: Incompleto En este nivel, en general no se alcanza el propsito del proceso. Existen pocos productos o salidas del proceso, y son difcilmente identificables. Nivel 1: Realizado En este nivel en general el propsito del proceso es alcanzado. La forma de alcanzarlo no siempre est planificada ni es controlada, pero existen productos del proceso que testifican que se ha logrado el propsito establecido.
Nivel 2: Gestionado En este nivel el proceso libera productos de acuerdo a procedimientos establecidos, y est planificado y controlado. Los productos liberados cumplen con los estndares y requerimientos de calidad definidos y son producidos de acuerdo a una agenda definida y recursos necesarios establecidos. Nivel 3: Establecido En este nivel el proceso es realizado y gestionado utilizando un proceso estndar basado en buenas prcticas de Ingeniera de Software. Las implementaciones especficas del proceso utilizan una versin aprobada y adaptada del proceso estndar para lograr las salidas esperadas y los recursos necesarios para establecer la definicin del proceso estn especificados. Nivel 4: Predecible En este nivel, el proceso es realizado consistentemente en el marco de los lmites de control definidos para alcanzar los objetivos establecidos. Se recolectan y analizan medidas detalladas de performance lo que lleva a un entendimiento cuantitativo de la capacidad del proceso y mejora la habilidad para predecir y gestionar la performance del mismo. La calidad de los productos obtenidos es conocida en forma cuantitativa. Nivel 5: Optimizante En este nivel, la performance del proceso es optimizada para alcanzar los objetivos actuales y futuros de la Organizacin, logrando repeticin en alcanzar sus objetivos definidos. Existen objetivos cuantitativos establecidos tanto para la efectividad como para la eficiencia del proceso. Es posible realizar un monitoreo continuo del proceso contra los objetivos establecidos a travs de la obtencin de feedback cuantitativo, y mejorar el proceso analizando estos resultados. La optimizacin de un proceso involucra probar ideas y tecnologas innovadoras, y cambiar procesos no efectivos para lograr los objetivos definidos.
El modelo de referencia no puede ser utilizado como nica herramienta para realizar la evaluacin de la capacidad de los procesos en forma confiable y consistente, ya que el nivel de detalle no es suficiente. La descripcin de los propsitos y atributos de la capacidad de los procesos en el modelo de referencia deben ser apoyada con un conjunto de indicadores de performance y capacidad de procesos definido en forma especfica.
4.2.1.3 The Unified Software Development Process

[USDP99]
The Unified Software Development Process es un proceso de software que provee un enfoque disciplinado para la asignacin de tareas y responsabilidades en una Organizacin. Su objetivo es asegurar la produccin de software de alta calidad que cumpla con las necesidades de los usuarios finales, a travs de una agenda predecible. La especificacin del desarrollo se realiza utilizando el lenguaje formal UML, el cual permite la comunicacin clara de los requerimientos, arquitectura y diseo tanto entre los integrantes del equipo de desarrollo como de ste con los usuarios. Es un proceso configurable en el entendido de que no existe un nico proceso de software que sea adecuado para todos los desarrollos de software, por lo que puede ser adaptado tanto para equipos pequeos de desarrollo como para Organizaciones que desarrollan software de gran escala. Est basado en una arquitectura de proceso simple y clara de dos dimensiones con elementos bien definidos, que puede acomodarse a distintas situaciones. Incorpora varias de las mejores prcticas identificadas en el desarrollo de software moderno comnmente usadas en la industria por Organizaciones exitosas. Entre estas buenas prcticas se encuentra el desarrollo iterativo incremental que permite un entendimiento progresivo de los requerimientos del Sistema a travs de sucesivos refinamientos y el crecimiento incremental de una solucin efectiva al problema planteado. Este enfoque iterativo incremental tambin permite
que los riesgos del proyecto sean identificados en cada etapa del desarrollo, reducindolos significativamente. El desarrollo est basado en la nocin de Casos de Uso y escenarios para capturar los requerimientos funcionales y asegurar que stos guan el diseo, implementacin y verificacin del software, con lo que ser ms probable que el Sistema final cumpla con las necesidades del Cliente. Este desarrollo se realiza utilizando el lenguaje de modelado visual UML, que permite la comunicacin de los distintos aspectos del software en forma clara y sin ambigedades. Tambin se basa en el desarrollo y construccin de una arquitectura robusta en etapas tempranas del proyecto que sea confiable, flexible, adaptable al cambio, entendible en forma intuitiva y promueva la reutilizacin del software. El proceso de software se describe en dos dimensiones, una dimensin que representa el tiempo y muestra el aspecto dinmico del proceso y otra dimensin que representa el aspecto esttico del proceso dado por: actividades, artefactos (artifacts), trabajadores (workers) y workflows. La dimensin del tiempo est divida en ciclos cada uno de los cuales se compone de cuatro Fases que son: Inception, Elaboration, Construction y Transition, que a su vez se dividen en iteraciones de la misma o distinta duracin segn el proyecto. La dimensin esttica del proceso est compuesta por los elementos mencionados anteriormente que son: los workflows de Requerimientos, Anlisis, Diseo, Implementacin y Verificacin, las actividades y artefactos de cada una y los trabajadores que participan. Para cada workflow se definen las actividades a realizar y se describe su contenido indicando los artefactos de entrada y salida, y los trabajadores involucrados en las mismas. En cada Fase e iteracin hay objetivos definidos que deben ser alcanzados al finalizar la misma, con actividades y artefactos claves definidos para cada Lnea de Trabajo.
4.2.1.4 Mtrica Versin 3 [MV300] Mtrica V3 es una metodologa para la planificacin, desarrollo y mantenimiento de Sistemas de Informacin que presenta una estructura genrica de desarrollo de software la cual debe ser adaptada en funcin del Proyecto y la Organizacin en la que va a ser aplicada, aunque su enfoque es hacia los Organismos que componen la Administracin Pblica de Espaa, intentando ser un estndar de proceso de software a ser seguido por los proyectos de software que se desarrollan en esos Organismos. La estructura propuesta ofrece un marco para la sistematizacin de las actividades que dan soporte al ciclo de vida del software, y cubre tanto desarrollos estructurados como desarrollos orientados a objetos. Utiliza como referencia el Modelo de Ciclo de Vida de Desarrollo de Software propuesto en la norma ISO12.207 Information Technology Software life cycle processes la cual se centra en la clasificacin y definicin de los procesos del ciclo de vida del software, pero no indica ningn ciclo de vida a ser utilizado en particular, por lo que puede aplicarse con el que sea elegido en cada caso especfico. La estructura propuesta incluye 3 Procesos principales que son: Planificacin, Desarrollo y Mantenimiento de Sistemas de Informacin, incluyendo en el Proceso de Desarrollo 5 procesos relacionados con las actividades tradicionales del desarrollo de software que son: Estudio de viabilidad, Anlisis, Diseo, Construccin e Implantacin y Aceptacin del Sistema de Informacin. Se incluye tambin un conjunto de procesos identificados como Intefaces dados por: Gestin de Proyectos, Seguridad, Gestin de la Configuracin y Aseguramiento de la calidad los cuales se componen de una serie de actividades que se realizan en paralelo a las actividades principales del ciclo de vida. Para cada uno de los Procesos propuestos se definen las actividades a realizar y se describe su contenido indicando sus principales tareas, productos que se obtienen, tcnicas que se emplean y participantes involucrados en las mismas.
4.2.1.5 Plan de Actividades del curso de Taller IV ao 1999

[PATIV99]
Este Plan de Actividades propone un modelo de ciclo de vida incremental e iterativo y est diseado para su aplicacin especfica en el curso de Taller IV del ao 1999 de la Carrera Ingeniera en Computacin Plan 1987. Este curso, como ya se mencion tena una duracin de trece semanas y su dictado corresponda al segundo semestre. La primer semana en el Plan de Actividades se dedica a la Organizacin del proyecto. Las doce semanas restantes se dividen en tres Fases de cuatro semanas cada una, las cuales son identificadas como Fase I, Fase II y Fase III, cada una de las cuales est dividida a su vez en dos iteraciones de dos semanas cada una. Cada iteracin resulta en la implementacin de una versin del producto de la Fase la cual se realiza mediante la aplicacin del modelo en cascada durante el perodo de desarrollo establecido para la iteracin. Para las actividades tradicionales de desarrollo de software se utiliza la metodologa de Jacobson que se encuentra detallada en [JACOB93] la cual se basa en la nocin de Casos de Uso para capturar los requerimientos funcionales a partir de los cuales se realizan las siguientes actividades de anlisis, diseo e implementacin. Se proponen roles para las reas de desarrollo dadas por Anlisis de Requerimientos, Diseo, Implementacin y Verificacin. Tambin se incluyen roles para las reas de Software Quality Assurance (SQA), Software Configuration Management (SCM) y Administracin del proyecto. Se propone una asignacin de roles para un grupo de 11 personas que tienen la forma de roles combinados, los cuales se cumplen de acuerdo al avance del proyecto. El Plan de Actividades brinda tambin la Agenda de Actividades y Entregables correspondiente a cada semana de desarrollo del proyecto. La coordinacin del grupo con el Director del Proyecto se realiza semanalmente mediante Revisiones Administrativas y Revisiones Tcnicas. La coordinacin interna del grupo se basa en reuniones quincenales en las cuales se deben realizar actividades de evaluacin, planificacin y anlisis de riesgos.
4.2.2
Recopilacin de lecciones aprendidas del curso de Taller IV ao 1999 En la Seccin 2.1 Introduccin se estableci el contexto en la Carrera de Ingeniera en Computacin en la cual se enmarca la realizacin de este Proyecto de Taller V. Como se indic en dicha seccin a partir del ao 1997 est vigente un nuevo Plan de Estudios en la Facultad de Ingeniera para todas sus carreras y en general existe una correspondencia entre las nuevas asignaturas definidas para este nuevo Plan y las que componen el Plan 1987 que se encontraba vigente anteriormente. En el ao 2000 se dicta por primera vez la asignatura PINGSW97 que como se mencion es equivalente a un semestre del curso de Taller IV del Plan 1987. En ese curso, los grupos que participaban realizaban un proyecto de desarrollo de software siguiendo un proceso de software dado en forma de Plan de Actividades por los Docentes del curso el cual se encuentra descrito en la Seccin 4.2.1.5 Plan de Actividades del curso de Taller IV ao 1999 [PATIV99]. Los proyectos realizados por los grupos participantes en los aos anteriores al 2000 tenan las caractersticas descritas en la Seccin 2.3 Definicin del Proyecto de este Taller V, pero no existen registros de stos proyectos. El conocimiento adquirido quedaba en los docentes y en cada estudiante los cuales cambiaban cada ao. La finalidad principal en esta etapa del Proyecto es la recopilacin de lecciones aprendidas como forma de recuperar parte del conocimiento adquirido por los estudiantes que cursaron Taller IV en el ao 1999 en el cual el desarrollo de software realizado fue una herramienta OLAP. Esta recopilacin es solamente una parte del conocimiento adquirido en el curso, ya que no era posible obtener, por ejemplo, los productos de software generados por los grupos durante el desarrollo del proyecto, ni
la visin de todos los docentes del curso, por lo que la informacin obtenida es la visin de algunos estudiantes que aceptaron contestar a las preguntas formuladas. A continuacin en la Seccin 4.2.2.1 - Cuestionarios se describe el cuestionario que fue enviado a los estudiantes de Taller IV como primer forma de realizar la recopilacin de informacin prevista y en la Seccin 4.2.2.2 - Entrevistas se detallan las entrevistas realizadas a los estudiantes con los que se pudo coordinar.
4.2.2.1 Cuestionarios En la Seccin 2.4 Plan de Trabajo de este documento se estableca que la recopilacin de lecciones aprendidas se realizara por medio de entrevistas a los estudiantes del curso de Taller IV del ao 1999. En el momento en que se dio comienzo a las tareas para la definicin y realizacin de las entrevistas a principios de Mayo de 2000, los cursos del primer semestre estaban avanzados y el perodo de parciales se encontraba prximo. En esta situacin exista la posibilidad de que muy pocos estudiantes tuvieran disponibilidad horaria para acceder a realizar la entrevista que se necesitaba para recopilar la informacin definida. En esa coyuntura se evalu que la cantidad de estudiantes que podran aceptar tener una entrevista sera bastante menos que la cantidad de estudiantes que podran contestar a un cuestionario va e-mail por una razn de tiempo, disponibilidad horaria y comodidad. Para salvar la situacin se decidi disear un cuestionario sobre el desarrollo del proyecto de Taller IV en el ao 1999 en el cual se incluyeron preguntas sobre los aspectos ms relevantes del curso. Esta estrategia permiti asegurar la recuperacin de la mayor cantidad posible de informacin a travs de las respuestas del cuestionario, la cual podra ser complementada posteriormente con la informacin que se obtuviera en las entrevistas a aquellos estudiantes que pudieran realizarlas. Para el diseo del cuestionario se tuvo en cuenta el documento [PATIV99] y la visin personal que cada una tena de la aplicacin del mismo, a partir del rol desempeado y del grupo en el que particip. Esto permiti identificar los aspectos claves en la recopilacin de la informacin ms relevante sobre los proyectos realizados. En el cuestionario se definieron 7 secciones cada una de las cuales se compone de preguntas especficas con opciones para marcar y observaciones y/o comentarios. Las secciones definidas se corresponden cada una con uno de los aspectos claves identificado y se detallan a continuacin: Seccin Seccin Seccin Seccin Seccin Seccin Seccin Seccin 1: 2: 3: 4: 5: 6: 7: 8: Sobre Sobre Sobre Sobre Sobre Sobre Sobre Sobre los roles y sus actividades el material que corresponda entregar a cada rol la comunicacin y coordinacin en el grupo el rol del director del proyecto el rol del usuario el producto obtenido el proceso propuesto la entrevista personal
Esta ltima seccin era opcional y estaba planteada para que aquellos estudiantes que quisieran y pudieran acceder a tener la entrevista personal anotaran sus datos y disponibilidad horaria para contactarlos y combinar da y hora de realizacin de la misma. Estos datos fueron de uso interno ya que se defini al momento de enviar los cuestionarios a los estudiantes, que el registro de los cuestionarios y de las entrevistas solicitadas se hiciera en forma annima. Los cuestionarios fueron enviados por e-mail a las direcciones de los estudiantes que cursaron Taller IV en 1999 las cuales fueron facilitadas por el Tutor del Proyecto.
4.2.2.2 Entrevistas La realizacin de entrevistas a los estudiantes que cursaron Taller IV en el ao 1999 estaba prevista en el Plan de Trabajo del Proyecto de Taller V como forma de recopilar parte del conocimiento adquirido en el desarrollo del proyecto de software de ese ao. Los cuestionarios fueron respondidos por 45 estudiantes de distintos grupos de los cuales solamente se logr coordinar la entrevista con 13 estudiantes de los que respondieron afirmativamente en la Seccin 8 - Sobre la entrevista personal. Luego de realizar la coordinacin de horarios para realizar las entrevistas se defini una agenda de entrevistas las cuales tuvieron lugar durante la semana del 26 al 30 de junio de 2000. Para el registro de las entrevistas se dise un documento en el cual se definieron tres secciones que deban ser llenadas durante el desarrollo de la misma. En la primer seccin se indicaba como dato relevante de la persona entrevistada el rol que haba desempeado en el proyecto, y se registraba el nmero de entrevista y la fecha en la cual se realizaba. En la segunda seccin se anotaban las preguntas que se deban realizar a la persona entrevistada y la tercera seccin se dejaba en blanco para el registro de las respuestas y dems datos relevantes que pudieran surgir. Las preguntas definidas eran de dos tipos: preguntas generales basadas en el rol que se entrevistaba y los aspectos claves identificados en el cuestionario, y preguntas especficas formuladas a partir de las respuestas al cuestionario de la persona en particular. El desarrollo de las entrevistas estaba dado por una charla informal con la persona en la cual se hacan las preguntas definidas y se registraban las respuestas dadas en el documento de registro de entrevistas, as como los distintos aspectos conversados en forma espontnea. Los roles entrevistados cubrieron todos los roles definidos para el Taller IV: Administrador, Analista-Documentador de Usuario-Asistente de Verificacin, Analista-Implementador, ArquitectoAsistente de Verificacin, Responsable de Verificacin, SQA-SCM, Especialista TcnicoImplementador, Implementador-Documentador Tcnico. Este hecho fue un aspecto muy importante para la validez de la informacin recopilada ya que permiti contar con la visin de los distintos aspectos del curso que se tena segn el rol desempeado e identificar las reas en las cuales los aciertos y/o los problemas detectados eran comunes. En la carpeta [RLATIV99] se adjuntan el cuestionario definido y los documentos de registro de las entrevistas realizadas as como los cuestionarios con las respuestas de los estudiantes del curso de Taller IV del ao 1999. Estos documentos forman parte de la Memoria Organizacional implementada descrita en el Captulo 8 y estn accesibles en el Sitio Web del Proyecto de Taller V en la direccin http://www.fing.edu.uy/~t5ingsw.
4.3
Resultados y Conclusiones
En esta etapa era de suma importancia adquirir los conocimientos que permitieran realizar la etapa 2 de Definicin del Proceso la cual constitua el primer objetivo intermedio determinado para el Proyecto. El conocimiento que era necesario adquirir estaba planteado en dos formas distintas, por un lado estudiando la bibliografa indicada en los temas definidos y por otro lado recopilando informacin sobre el desarrollo del curso de Taller IV del ao 1999. En cuanto al estudio de la bibliografa se debe destacar que finalmente se cubrieron ms materiales de los indicados y se lograron obtener los conceptos ms significativos sobre los temas de estudio planteados. En cuanto a la recopilacin de informacin sobre el desarrollo del curso de Taller IV del ao 1999, adems de la realizacin de las entrevistas a los estudiantes del curso que estaban previstas en el Plan de Trabajo del Proyecto, se dise un cuestionario previo a la realizacin de las mismas que permiti obtener una cantidad considerable de informacin, incluso ms de la que se esperaba. Como conclusin de la etapa se considera que los objetivos de la misma fueron cumplidos, si bien la duracin prevista para su desarrollo debi ser extendida, se entiende que esta decisin fue acertada ya que se lograron sentar las bases para el correcto desarrollo del Proyecto.
SEGUNDA ETAPA DEFINICIN DEL PROCESO

En este Captulo se detallan las actividades correspondientes a la etapa 2 del Proyecto, de acuerdo a lo establecido en la Seccin 3.1 Etapas. Como primer punto se establecen los objetivos y actividades previstas en la Seccin 5.1 Objetivos. En la Seccin 5.2 Desarrollo se detallan las actividades realizadas de definicin del proceso y de presentacin del Modelo de Proceso definido a los grupos de la asignatura PINGSW97 al comienzo del segundo semestre de 2000. Finalmente en la Seccin 5.3 Resultados y Conclusiones se muestran los resultados obtenidos y las conclusiones de la etapa.
5.1
Objetivos
En esta etapa de Definicin del Proceso el objetivo fundamental es definir el Modelo de Proceso a aplicar en la asignatura PINGSW97 del curso 2000. Se busca lograr un proceso de software adecuado a las caractersticas de la Organizacin identificadas en la seccin 2.3 Definicin, de este documento el cual ser especificado en UML. El proceso definido deber incluir la descripcin de los roles participantes, la definicin de Entregables con una plantilla asociado y el detalle de Actividades necesarias para generar los Entregables definidos, especificando condiciones de entrada, salida y terminacin, roles que participan y responsabilidad asociada. Tambin deber incluirse una Agenda de Actividades y Entregables donde se indique por semana la realizacin de Actividades y los Entregables asociados. La definicin del proceso debe realizarse con anterioridad al comienzo de cursos del segundo semestre en el cual se dicta la asignatura mencionada, y debe presentarse a los grupos que les corresponda seguir el Modelo de Proceso definido.
5.2
Desarrollo
Al iniciar las actividades establecidas para esta etapa todava no se tena muy claro cuales seran exactamente los pasos a seguir para cumplir con los objetivos definidos para la misma, adems de que an se estaba estudiando la bibliografa indicada y realizando la recopilacin de informacin del curso de Taller IV del ao 1999. Se tenan dudas sobre la forma en que se encarara la definicin del proceso en cuanto a los puntos que sera mejor definir inicialmente para no tener que volver hacia atrs a cambiar definiciones del proceso una vez que se avanzara en la construccin del mismo. Si bien se tenan claras en general las actividades que se deban incluir en el proceso para que ste presentara buenas prcticas de software lo cual contribuira a la calidad del mismo, no se tena seguridad sobre los Modelos a utilizar para su definicin. Se plantearon estas dudas al Tutor quin sugiri que se utilizara como Modelo base el definido en el libro [USDP99] cuyas principales caractersticas se encuentran resumidas en la seccin 4.2.1.3 de este documento. Con este punto de partida, se tuvieron los elementos para definir los pasos que seran seguidos para el desarrollo de esta etapa. A continuacin en la Seccin 5.2.1 Eleccin de Modelos a utilizar se comenta el proceso de seleccin que se realiz para definir los modelos que se utilizaran como gua para la definicin del proceso. Luego en la Seccin 5.2.2 Modelo de Proceso definido se describen las caractersticas del proceso definido y finalmente en la Seccin 5.2.3 Presentacin del Modelo de Proceso en el curso 2000 se detalla la presentacin del proceso realizada a los grupos que seguiran el Modelo de Proceso definido.
5.2.1
Eleccin de Modelos a utilizar El modelo utilizado como base para la definicin del proceso [USDP99] presenta como caractersticas destacables que tiene un enfoque iterativo e incremental basando el desarrollo en la identificacin de Casos de Uso a partir de los requerimientos establecidos para el Sistema y en la definicin de la Arquitectura del mismo en forma temprana a partir de los Casos de Uso que se entiendan como ms relevantes para la construccin del mismo. En este Modelo se define el ciclo de vida del Software en Fases e iteraciones y se describen las actividades, entregables y roles para las tareas tradicionales de desarrollo de software dadas por: Requerimientos, Anlisis, Diseo, Implementacin y Verificacin, las que se nombraron como Lneas de Trabajo Bsicas. Sin embargo las tareas tradicionales de desarrollo de software no eran las nicas que se tena pensado incluir en el Modelo de Proceso, ya que deba contener las mismas reas planteadas por el documento [PATIV99], en el cual se incluan actividades de gestin de calidad, gestin de configuracin y gestin del proyecto. Adems en la bibliografa estudiada se pona especial nfasis en la inclusin de estas actividades para la obtencin de un proceso de software bien definido, por lo que se consider necesario identificar otros Modelos en los cuales se pudieran basar las actividades para estas reas, las que se nombraron como Lneas de Trabajo de Gestin. En principio se opt por utilizar los documentos de Interfaces de Gestin definidas en el Modelo [MV300] cuyas caractersticas principales se describen en la Seccin 4.2.1.4 de este documento, ya que se vio que la forma en la que se definan las actividades, entregables y roles en este modelo, segua el enfoque utilizado en el modelo de referencia para la definicin de las Lneas de Trabajo Bsicas. Al comenzar con las actividades de definicin del Modelo de Proceso basado en los modelos elegidos, se identificaron reas en las cuales las propuestas de estos modelos deban ser adaptadas de forma que se adecuaran a las caractersticas identificadas en la Organizacin para la cual se estaba definiendo el proceso. En este sentido, el Plan de Actividades [PATIV99] as como la informacin recopilada en los cuestionarios y entrevistas realizadas a los estudiantes de dicho curso, se utilizaron como referencia para realizar las adaptaciones necesarias. Para profundizar en las descripciones de las actividades y lograr un completo entendimiento de las caractersticas que se queran incluir en el Modelo de Proceso, se utilizaron tambin los Modelos de Mejora continua CMM y SPICE cuyas principales caractersticas se dan en las Secciones 4.2.1.1 y 4.2.1.2 de este documento. De estos modelos se tom el conjunto mnimo de actividades que se requieren en cada Lnea de Trabajo de Gestin para considerar que el proceso cubre estas reas. Para estas Lneas de Trabajo tambin se utiliz como referencia el Modelo APM.
5.2.2
Modelo de Proceso definido En esta seccin se describen las caractersticas principales del Modelo de Proceso definido, comentando el proceso realizado para llegar a las definiciones del mismo y fundamentando las decisiones tomadas en caso necesario. La definicin del Modelo de Proceso consta de varios documentos: Modelo de Proceso Genrico [MPG00] Documento de Actividades de la Lnea de Trabajo de Requerimientos [MPLTR00] Documento de Actividades de la Lnea de Trabajo de Anlisis [MPLTA00] Documento de Actividades de la Lnea de Trabajo de Diseo [MPLTD00] Documento de Actividades de la Lnea de Trabajo de Implementacin [MPLTI00] Documento de Actividades de la Lnea de Trabajo de Gestin de Calidad [MPLTCA00] Documento de Actividades de la Lnea de Trabajo de Gestin de Configuracin [MPLTCO00] Documento de Actividades de la Lnea de Trabajo de Gestin del Proyecto [MPLTGP00] Documento de Descripcin de la Arquitectura [MPDA00] Documento de Agenda de Actividades [MPAA00] Documento de Agenda de Entregables [MPAE00]
En el documento de Modelo de Proceso genrico [MPG00] se describen las caractersticas relevantes del mismo, as como los elementos que lo componen y los roles que lo integran. En los documentos de Actividades de cada Lnea de Trabajo definida se detallan las Actividades que se realizan indicando sus condiciones de entrada, cumplimiento y salida, identificadas por los Entregables definidos en cada caso, y la descripcin de las tareas asociadas a la realizacin de la Actividad. Tambin se detallan para cada Actividad los roles participantes y las responsabilidades asociadas. Sobre el tema del Diseo de la Arquitectura del Sistema se proporciona el documento Descripcin de la Arquitectura [MPDA00]. Finalmente se incluyen los documentos que contienen la Agenda de Actividades [MPAA00] y la Agenda de Entregables [MPAE00] definidas por Fase, iteracin y semana para la aplicacin del Modelo en el curso del ao 2000. Estos documentos que constituyen la definicin del Modelo de Proceso forman parte de la Memoria Organizacional implementada y se encuentran accesibles en el Sitio Web de este Proyecto de Taller V en la direccin http://www.fing.edu.uy/~t5ingsw. A continuacin se comentan brevemente los elementos que componen el Modelo de Proceso propuesto. En la Seccin 5.2.2.1 se describe el enfoque dado al Modelo de Proceso, luego en la Seccin 5.2.2.2 se da la definicin de roles y en la Seccin 5.2.2.3 se describen las Lneas de Trabajo que lo componen y las Actividades, Entregables y Roles que participan en cada una. Finalmente en la Seccin 5.2.2.4 se describe la Agenda de Actividades y Entregables propuesta para el proceso de software de aplicacin en el curso 2000.
5.2.2.1 Enfoque del Modelo de Proceso El Modelo de Proceso propuesto sigue un enfoque iterativo incremental en el cual se divide el trabajo en miniproyectos que son ciclos completos de desarrollo, donde cada uno es una iteracin que da como resultado un incremento en el producto. En segundo lugar el flujo de actividades en el desarrollo est guiado por Casos de Uso los cuales especifican funcionalidades identificadas a partir de los requerimientos planteados para el Sistema. Finalmente y en tercer lugar est centrado en la Arquitectura la cual especifica la estructura del Sistema y se define en etapas tempranas del desarrollo en base a los Casos de Uso ms significativos. La decisin de utilizar un enfoque de desarrollo iterativo incremental est basada no solo en que es el enfoque propuesto en el modelo de referencia [USDP99], sino tambin en la experiencia del curso de Taller IV del ao 1999 que utiliz ese mismo enfoque y cuyos resultados eran conocidos. En base a la participacin de las integrantes de este grupo de Proyecto de Taller V en el curso de Taller IV del ao 1999 y de la informacin obtenida sobre el desarrollo de dicho curso en la etapa1 de Estudio y Recopilacin de este Proyecto, se entendi que dada la duracin fija del curso en semanas y la inexperiencia en este tipo de desarrollo que tienen en general los participantes del proyecto, el enfoque iterativo incremental era el ms adecuado por las ventajas que presenta. El enfoque de desarrollo iterativo incremental permite que la comprensin del problema se realice en forma creciente mediante sucesivos refinamientos de los requerimientos planteados, y que se construya una solucin efectiva al problema, en forma incremental a travs de mltiples iteraciones. Ayuda a que la identificacin y prevencin de los riesgos del proyecto sea realizada en cada etapa del ciclo de vida y facilita la incorporacin de cambios en los requerimientos del Sistema al ir iterando sobre stos. En la medida en que cada iteracin resulte en la liberacin de un ejecutable, en forma interna o externa, y de productos claves en el desarrollo, se propicia el control por parte del grupo del estado del proyecto y de la calidad de los productos generados. Tambin se obtiene un mayor involucramiento del Cliente lo que se traduce en la obtencin en forma continua de retroalimentacin del mismo. Sobre este ltimo punto se tenan dudas respecto a la disponibilidad del Cliente, pero se decidi definir este tema bajo la suposicin de que el Cliente podra participar en las validaciones de productos marcadas. La aplicacin de este enfoque est dada por la divisin del ciclo de vida del software en distintas Fases las cuales se dividen a su vez en iteraciones del tamao que se determine en cada caso. Del modelo de referencia [USDP99] se tomaron solamente las tres primeras Fases ya que en la Organizacin en la cual se aplica no se realiza la liberacin del producto al Cliente, que es el objeto
de la ltima de las Fases que este modelo propone. Las Fases seleccionadas se nombraron como Fase Inicial, Fase de Elaboracin y Fase de Construccin. En la Fase Inicial se propone una sola iteracin ya que se entiende que es suficiente para alcanzar los objetivos definidos para la misma. Para las Fases de Elaboracin y de Construccin se proponen dos iteraciones en cada una, definiendo as objetivos intermedios que conducirn a la concrecin de los objetivos planteados para cada Fase. El flujo de actividades a travs de las Fases e iteraciones definidas, est guiado por Casos de Uso los cuales especifican las funcionalidades del Sistema que se identifican a partir de los requerimientos planteados. Partiendo de los Casos de Uso identificados en la etapa de requerimientos, se va refinando el problema a medida que estos Casos de Uso son analizados y diseados, definiendo la Arquitectura del Sistema y los elementos necesarios para la implementacin del mismo. La utilizacin de UML Unified Modeling Language es la base para realizar el modelado del software en forma visual, lo que permite la comunicacin libre de ambigedades entre los participantes del proyecto. El desarrollo est enfocado hacia la definicin e implementacin temprana de una Arquitectura del Sistema que sea robusta, confiable y flexible, diseada para el cambio y entendible para todos los participantes del proyecto. A la definicin de la Arquitectura del Sistema se le llam Lnea Base de la Arquitectura, estableciendo en la definicin del Modelo de Proceso la importancia de su obtencin en las primeras iteraciones del proyecto, proporcionando el documento Descripcin de la Arquitectura [MPDA00] para profundizar sobre este tema.
5.2.2.2 Roles del Modelo de Proceso La definicin de roles en el modelo de referencia [USDP99] se entendi que era demasiado compleja para su inclusin en el Modelo de Proceso que se estaba definiendo, ya que la granularidad con que estaban dados los roles en las distintas Lneas de Trabajo resultaba demasiado fina para la cantidad de integrantes que tendran los grupos que cursaran la asignatura PINGSW97 en la cual se aplicara el proceso. En general se asocian a cada uno de estos roles actividades especficas y de corta duracin, por lo cual la identificacin de una buena combinacin de roles para el proceso sera una actividad por dems compleja y posiblemente el resultado sera una combinacin de roles confusa que introducira dificultades al momento de su aplicacin. En base a la experiencia personal de las integrantes de este grupo de Proyecto de Taller V, y de la informacin obtenida sobre el desarrollo del curso de Taller IV del ao 1999 en la etapa 1 de Estudio y Recopilacin de este Proyecto, se entendi que la definicin de roles combinados dada en el Plan de Actividades [PATIV99] era adecuada a las caractersticas que presenta la Organizacin en la que se aplicara el Modelo de Proceso definido. Por esta razn la definicin de roles en el Modelo de Proceso sigue la especificacin dada en el documento [PATIV99] con la modificacin de que el rol Implementador/Responsable de Documentacin Tcnica planteado en dicho Plan fue eliminado y sus responsabilidades se repartieron entre los roles que cumplan tareas similares. Los roles combinados definidos para el Modelo de Proceso propuesto se describen a continuacin: Cantidad de Integrantes del grupo: Analista Implementador Analista Asistente de Verificacin Doc.de Usuario Arquitecto Asistente de Verificacin Especialista Tcnico Implementador Responsable de Verificacin Responsable de SQA Responsable de SCM Administrador 10 2 1 1 3 1 1 1 11 3 1 1 3 1 1 1 12 2 2 1 4 1 1 1
Una descripcin ms detallada de los roles y roles combinados propuestos y sus tareas asociadas se encuentra en el documento [MPG00].
5.2.2.3 Lneas de Trabajo y sus Actividades, Entregables y Roles Las Lneas de Trabajo definidas en el Modelo de Proceso [MPG00] se dividen en dos grandes grupos Lneas de Trabajo Bsicas y Lneas de Trabajo de Gestin, de acuerdo a las reas que las integran. Las Lneas de Trabajo Bsicas estn dadas por las reas de desarrollo de software tradicionales que son: Requerimientos, Anlisis, Diseo, Implementacin y Verificacin. Las Lneas de Trabajo de Gestin se integran con las reas tambin llamadas de cubrimiento que son: Gestin de Calidad, Gestin de Configuracin y Gestin del Proyecto. Para cada Lnea de Trabajo existe un documento en el cual se incluye toda la informacin correspondiente a la misma. En cada documento de Lnea de Trabajo se indican al comienzo del mismo las actividades que componen esa Lnea de Trabajo y se brinda un diagrama en UML donde se establece el flujo de actividades y los roles involucrados en las mismas. En cada uno de estos documentos se definen las actividades que componen a la Lnea de Trabajo de que se trata, estableciendo para cada Actividad los Entregables de entrada y salida, as como una descripcin para su realizacin en general, particularizando en el grado en que debe ser realizada por Fase e iteracin. Esto es debido a que las actividades en cada Lnea de Trabajo tienen distinta intensidad de acuerdo al grado de avance del proyecto, o sea a la Fase e iteracin en la que se encuentre el desarrollo del mismo. En estos documentos se brinda tambin un diagrama que da una visin del movimiento en el tiempo del trabajo en esa rea. Para cada actividad que integra la Lnea de Trabajo se indican los roles que participan en la misma y sus responsabilidades, existiendo siempre un rol responsable de que la Actividad sea realizada y sus Entregables sean generados y liberados. En cada descripcin de actividad se indican tambin con un diagrama en UML los Entregables de entrada y salida para la misma as como los roles participantes y sus responsabilidades. A continuacin se muestran las actividades que componen cada Lnea de Trabajo y los roles que participan en las mismas:
Lnea de Trabajo de Requerimientos [MPLTR00] Participantes en mayor grado: Analistas, Arquitecto. Otros participantes: Especialista Tcnico, Resp. de Verificacin, Resp. de SQA, Administrador Actividades que se realizan: R1 Asistir a reuniones de Requerimientos R2 Listar Requerimientos candidatos R3 Analizar los Requerimientos R4 Encontrar un vocabulario comn R5 Encontrar Actores y Casos de Uso R6 Priorizar Casos de Uso R7 Detallar cada Caso de Uso R8 Disear la Interface de Usuario R9 Estructurar el Modelo de Casos de Uso R10 Capturar los Requerimientos No funcionales R11 Definir el Alcance del Sistema R12 Revisar la consistencia de los Requerimientos
Lnea de Trabajo de Anlisis [MPLTA00] Participantes en mayor grado: Analistas, Arquitecto. Actividades que se realizan: A1 A2 A3 A4 A5 Definir la Arquitectura del Anlisis Analizar cada Caso de Uso Analizar cada Clase de Anlisis Analizar cada Paquete de Anlisis Realizar la Especificacin de Requerimientos
Lnea de Trabajo de Diseo [MPLTD00] Participantes en mayor grado: Analistas, Arquitecto. Otros participantes: Especialista Tcnico, Implementador. Actividades que se realizan: D1 D2 D3 D4 D5 Definir la Arquitectura del Diseo Disear cada Caso de Uso Disear cada Clase de Diseo Disear cada Subsistema de Diseo Verificar la trazabilidad de los Modelos
Lnea de Trabajo de Implementacin [MPLTI00] Participantes en mayor grado: Implementadores Otros participantes: Especialista Tcnico, Arquitecto, Resp. de Verificacin. Actividades que se realizan: I1 I2 I3 I4 I5 I6 I7 Investigar, evaluar y definir la herramienta de desarrollo Definir la Arquitectura de la Implementacin Planificar la Integracin de la iteracin Implementar cada Clase Implementar cada Subsistema Hacer Revisin por Pares Realizar la Integracin
Lnea de Trabajo de Verificacin [MPLTV00] Participantes en mayor grado: Responsable de Verificacin Otros participantes: Asistente de Verificacin, Implementador. Actividades que se realizan: V1 Preparar el Plan de Verificacin V2 Planificar las Pruebas de la iteracin V3 Disear las Pruebas de la iteracin V4 Realizar las Pruebas Unitarias V5 Realizar las Pruebas de Integracin V6 Realizar las Pruebas del Sistema V7 Verificar cada Documento V8 Evaluar la Verificacin de la iteracin V9 Realizar Evaluacin y Ajustes al Plan de Verificacin V10 Realizar la Evaluacin Final de la Verificacin
Lnea de Trabajo de Gestin de Configuracin [MPLTCO00] Participantes en mayor grado: Responsable de SCM Otros participantes: Especialista Tcnico. Actividades que se realizan: SCM1 SCM2 SCM3 SCM4 SCM5 SCM6 SCM7 Preparar el Plan de SCM Definir / Construir el Ambiente Controlado Identificar los Productos a ser puestos bajo SCM Controlar las Versiones Controlar los Cambios Auditar la Lnea Base del Software Realizar la Evaluacin Final de la Gestin de Configuracin
Lnea de Trabajo de Gestin de Calidad [MPLTCA00] Participantes en mayor grado: Responsable de SQA Otros participantes: integrantes del grupo que participen en RTF. Actividades que se realizan: SQA1 SQA2 SQA3 SQA4 SQA5 SQA6 SQA7 SQA8 Preparar el Plan de SQA Identificar las propiedades de la Calidad Revisar cada Producto Revisar el Ajuste al Proceso Realizar Revisin Tcnica Formal (RTF) Realizar la Evaluacin Final de la Gestin de Calidad Asegurar que las desviaciones son documentadas Realizar la Evaluacin Final de la Gestin de Calidad
Lnea de Trabajo de Gestin del Proyecto [MPLTGP00] Participantes en mayor grado: Administrador Otros participantes: todos los integrantes del grupo en actividades especficas. Actividades que se realizan: GP1 Preparar el Plan del Proyecto GP2 Preparar la Reunin del Equipo del Proyecto GP3 Realizar la Reunin del Equipo del Proyecto GP4 Definir el Entorno de Desarrollo GP5 Entender el Proceso de Desarrollo GP6 Realizar las Estimaciones del Proyecto GP7 Analizar y Evaluar los Riesgos del Proyecto GP8 Registrar las Actividades Semanales GP9 Realizar el Seguimiento y Control del Proyecto GP10 Realizar Evaluacin y Ajustes al Plan del Proyecto GP11 Reunin con el Director del Proyecto GP12 Validacin con el Cliente GP13 Realizar la Evaluacin Final de la Gestin del Proyecto
5.2.2.4 Agenda de Actividades y Entregables Como se indic en la Seccin 5.2.2.1 Enfoque del Modelo de Proceso, el ciclo del software definido para el Modelo de Proceso propuesto est dividido en tres Fases denominadas Fase Inicial, de Elaboracin y de Construccin, las cuales tienen una cantidad de iteraciones establecida cuya duracin puede ser definida en forma especfica segn las caractersticas del proyecto. Para la aplicacin del proceso en el curso 2000 se estableci la duracin de las iteraciones definidas para cada Fase de acuerdo al siguiente detalle: la Fase Inicial tiene una nica iteracin de 2 semanas de duracin, la Fase de Elaboracin tiene dos iteraciones de 2 semanas de duracin cada una y la Fase de Construccin tiene 2 iteraciones, la primera es de 3 semanas y la segunda de 4 semanas de duracin. Cada una de estas Fases e iteraciones tiene objetivos definidos, y el cronograma de Actividades y Entregables claves para la obtencin de los mismos se encuentra detallado por Fase, iteracin y semana en los documentos de Agenda de Actividades [MPAA00] y Agenda de Entregables [MPAE00] del proceso definido. Estas definiciones se basaron en la experiencia de la aplicacin del Plan de Actividades [PATIV99] de la cual se tena la experiencia personal y la informacin recopilada en la etapa 1 de Estudio y recopilacin. La segunda iteracin de la Fase de Construccin tiene una semana ms que est pensada para que sea dedicada exclusivamente a realizar la verificacin del Sistema y finalizar la documentacin del proyecto que se debe entregar al Cierre del mismo. En la definicin de Actividades y Entregables indicados en cada Fase e iteracin de las Agendas correspondientes, se tuvieron en cuenta los desfasajes ms significativos que se haban dado en el calendario en dicha experiencia, aunque se intent que las actividades y entregables indicados marcaran el ritmo del proyecto para que ste no se moviera demasiado hacia el final del mismo.
5.2.3
Presentacin del Modelo de Proceso en el curso 2000 La presentacin del Modelo de Proceso en el curso 2000 se realiz en la primer semana del comienzo del segundo semestre a mediados de Agosto de 2000. Esta presentacin tuvo lugar en el Saln de Postgrados del Instituto de Computacin (IN.CO.) y a la misma asistieron los grupos 1, 2 y 3 que seguiran este Modelo de Proceso, como se describe en la Seccin 6.2.1 Marco general. La actividad se apoy en una presentacin con diapositivas realizada en Microsoft PowerPoint 2000 [MPPRES00] en la que se daba una visin general de las caractersticas ms relevantes del Modelo de Proceso, la forma de trabajo y los elementos que lo componen, indicando la descripcin de roles combinados a asignar en el equipo de proyecto, para grupos de 10, 11 y 12 participantes de forma de cubrir las posibilidades en cuanto a cantidad de integrantes por grupo. La duracin de la presentacin fue de aproximadamente una hora y media, y en sta se coordin con los grupos el envo de los Entregables a la direccin de e-mail del Proyecto de Taller V dada t5ingsw@fing.edu.uy as como la realizacin de dos clases de consulta para la semana siguiente de forma que los integrantes de los grupos tuvieran tiempo de leer los documentos del Modelo de Proceso y plantear luego sus dudas. Todos los documentos del Modelo de Proceso se pusieron a disposicin del pblico en general en la pgina del Proyecto de Taller V www.fing.edu.uy/~t5ingsw a partir del da de la presentacin, y en particular de los integrantes de los grupos a los que les corresponda seguirlo. A cada Director de Proyecto se le entreg en forma de libro impreso los documentos que componen el Modelo de Proceso, y en particular con los Directores de Proyecto de los grupos 1 y 2, Ing. Rodolfo Paiz e Ing. Ral Ruggia respectivamente, se mantuvieron reuniones para conversar sobre el material entregado. El Director de Proyecto del grupo 3 era el Ing. Jorge Trianes quin como ya se indic es el Tutor de este Proyecto de Taller V.
5.3
Los resultados de esta etapa se evalan como positivos ya que se logr definir el Modelo de Proceso para ser aplicado en la asignatura PINGSW97 del curso 2000 en fecha para ser presentado a los grupos que participaban en dicho curso, la cual tuvo lugar al comienzo del segundo semestre a mediados de Agosto de 2000. El Modelo de Proceso definido incluye el detalle de Actividades en cada Lnea de Trabajo necesarias para generar los Entegrables establecidos, y en cada una se indican las condiciones de entrada, salida y terminacin as como los roles participantes y la responsabilidad asociada. Se presenta la descripcin de roles participantes y roles combinados definidos. Se incluyen las especificaciones en UML de los flujos y subflujos de actividades necesarios por Lnea de Trabajo y Actividad. Se estableci la Agenda de Actividades y la Agenda de Entregables del Modelo de Proceso, donde se indica por Fase, iteracin y semana la realizacin de Actividades y los Entregables asociados. No se pudieron incluir las plantillas ni los ejemplos indicados por una cuestin de tiempo, solamente se present una plantilla para el Plan del Proyecto y se brindaron los estndares de la IEEE para la realizacin de los Planes de SQA, SCM y Verificacin, as como para la realizacin de la Especificacin de Requerimientos, referencias para el estudio de la metodologa Jacobson-Booch-Rumbaugh y documentos de apoyo. Se realiz una pgina Web en la cual se puso todo el material a disposicin de los grupos y del pblico en general, la cual se sigui actualizando durante el desarrollo del curso. Se estableci contacto con los grupos va e-mail a travs de la direccin del usuario de Taller V y se coordin con los mismos el envo de Entregables. Se realizaron reuniones con los Directores de Proyecto de los grupos. Algunas de las actividades realizadas en el desarrollo de esta etapa no estaban indicadas especficamente sino que surgieron a travs de las reuniones de este grupo de Taller V y consultando con el Tutor del mismo, como por ejemplo la realizacin de un documento por cada Lnea de Trabajo y la pgina Web con toda la documentacin que corresponde al Modelo de Proceso definido. Se considera que los principales objetivos de la etapa fueron cumplidos, el objetivo principal de definicin del Modelo de Proceso se alcanz en forma satisfactoria cumpliendo con lo establecido para su definicin. La duracin prevista para el desarrollo de la etapa tambin fue cumplida.
TERCER ETAPA PRUEBAS DEL PROCESO

En este Captulo se detalla el desarrollo de la etapa 3 del Proyecto, de acuerdo a lo establecido en la Seccin 3.1 Etapas. En la seccin 6.1 Objetivos, se establecen los objetivos y actividades previstas para su cumplimiento. En la Seccin 6.2 Desarrollo, se detallan las actividades realizadas de seguimiento y evaluacin de la aplicacin del Modelo de Proceso definido por parte de los grupos que cursaban la asignatura PINGSW97 en el segundo semestre de 2000. Finalmente en la Seccin 6.3 Resultados y Conclusiones se muestran los resultados obtenidos y las conclusiones de la etapa.
6.1
Objetivos
En esta etapa el principal objetivo est dado por la realizacin del seguimiento y evaluacin de la aplicacin del Modelo de Proceso propuesto, por parte de los grupos que cursaban la asignatura Proyecto de Ingeniera de Software en el segundo semestre de 2000. Este seguimiento deba ser llevado a cabo teniendo en cuenta dos actividades fundamentales que se deban realizar, en primer trmino se deban recolectar, almacenar y analizar los Entregables que los grupos generaran por semana en el desarrollo del proyecto, y en segundo lugar se realizaran entrevistas a integrantes de los distintos grupos para identificar las faltas de conformidad del proceso seguido con el propuesto. En base a este seguimiento realizado se podran analizar las causas de los desvos encontrados identificando los ajustes que sera necesario realizar al Modelo de Proceso propuesto as como los elementos que permitieran mejorar su aplicacin en futuros proyectos.
6.2
Desarrollo
Al inicio del desarrollo de esta etapa se debieron definir los procedimientos que se utilizaran para realizar las actividades que estaban previstas como parte de la misma. Como ya se mencion en la Seccin 5.2.3 Presentacin del Modelo de Proceso en el curso 2000, en oportunidad del primer contacto con los grupos que seguiran el Modelo de Proceso propuesto se coordin el envi de los Entregables que seran generados cada semana, mediante el uso del e-mail t5ingsw@fing.edu.uy, el cual sera utilizado para todas las comunicaciones relacionadas con el Proyecto de Taller V. Si bien en ese momento todava no se haba establecido en forma definitiva el procedimiento que se utilizara para realizar las entrevistas a los integrantes de los grupos durante el desarrollo del proyecto, si se haba definido que estara basado en el concepto de Auditoria, el cual se encuentra en la bibliografa estudiada en la etapa 1 de Estudio y Recopilacin y se detalla en la Seccin 6.2.3.1 Marco terico de este Captulo. El desarrollo de esta etapa se detalla a continuacin comenzando con la Seccin 6.2.1 Marco general en la cual se brinda el contexto del curso 2000 de la asignatura PINGSW97, los grupos que la cursaban y el Sistema que deban construir. En la Seccin 6.2.2 Monitoreo de Entregables se describe como fue realizada esta actividad y en la Seccin 6.2.3 Auditorias del Proceso se detallan los procedimientos y desarrollo del seguimiento de la aplicacin del Modelo de Proceso por parte de los grupos que lo utilizaron.
6.2.1
Marco general El curso 2000 de la asignatura Proyecto de Ingeniera de Software contaba con cinco grupos participantes los cuales tenan una cantidad de integrantes de entre 10 y 12 personas por grupo. Este Proyecto de Taller V se estaba desarrollando en forma paralela por dos grupos de Taller V con el mismo Tutor de Proyecto, por lo que existan dos Modelos de Proceso definidos para ser aplicados en el curso 2000 de la asignatura PINGSW97. En esta situacin se deban definir los grupos que seguiran cada uno de los Modelos de Proceso lo cual fue establecido en la clase de presentacin de dicho curso a los grupos dictada por el Tutor del Proyecto. Tres de los cinco grupos participantes del curso seguiran el Modelo de Proceso descrito en la Seccin 5.2.1 Modelo de Proceso definido de este documento, a solicitud de las integrantes de este grupo de Proyecto de Taller V. En ese momento tambin se estableci que docentes tomaran el rol de Director de Proyecto para cada grupo, los cuales se indican en la Tabla 3 junto a la integracin de cada grupo. Tambin se indic que el docente que tomara el rol de Cliente sera el Dr. Hermann Steffen y se describi en forma general el Sistema que se deba construir. Este Sistema sera un Workflow genrico que se puede definir como una herramienta para la optimizacin de procesos administrativos [STEFF98]. El Workflow desarrollado sera genrico en el sentido de que no se modelaran los procesos de ninguna Organizacin en particular sino que permitira realizar las actividades tpicamente identificadas en estos Sistemas, de forma que sea adaptable para su utilizacin en casos especficos. Los grupos que seguiran el Modelo de Proceso definido en la Seccin 5.2.1 de este documento fueron identificados con los nmeros 1, 2 y 3 y su conformacin est dada por la siguiente tabla:
Caractersticas del Grupo Cantidad de Integrantes Asignacin de Roles combinados: Arquitecto Asistente de Verificacin Analista Implementador Analista Asistente de Verificacin Doc. de Usuario Especialista Tcnico Implementador Responsable de Verificacin Responsable de SQA Responsable de SCM Administrador Director de Proyecto
GRUPO 1 12 1 2 2 4 1 1 1 Rodolfo Paiz
GRUPO 2 11 1 3 1 3 1 1 1 Ral Ruggia
GRUPO 3 12 1 2 2 4 1 1 1 Jorge Trianes
Tabla 3: Caractersticas de los grupos de la asignatura Proyecto de Ingeniera de Software Las reuniones de los grupos con el Director del Proyecto se realizaran todas las semanas, en la cual se presentaran los Entregables generados correspondientes a la semana de acuerdo a lo establecido en los documentos Agenda de Actividades [MPAA00] y Agenda de Entregables [MPAE00]. La relacin con el Cliente estara dada por la realizacin de dos clases de requerimientos y luego el contacto se realizara mediante e-mail ya que el docente se encontrara fuera del pas. En este contexto las validaciones con el Cliente planteadas en el Modelo de Proceso se prevea que seran difciles de realizar.
6.2.2
Monitoreo de Entregables El procedimiento definido para realizar el seguimiento de las entregas de los grupos al Director del Proyecto estaba dado por el envo por parte de cada grupo, de los Entregables que le haban sido enviados al Director en cada semana. Estos Entregables eran archivados en el directorio de Taller V del que se dispona, ordenados por grupo y por semana. En la Agenda de Entregables definida para el Modelo de Proceso se realizaba el registro de los Entregables presentes y de los que no haban sido recibidos, indicando la semana de entrega en el caso que existiera algn desfasaje con lo indicado en dicha Agenda. Luego se revisaba el contenido de los Entregables presentes para ver si se correspondan con lo definido para los mismos en el Modelo de Proceso, ya que si bien no existan plantillas para los Entregables, si se daba una gua de su contenido en la descripcin de la Actividad que generaba cada Entregable. El monitoreo de Entregables por semana era una actividad bsica para la posterior realizacin de las Auditorias de cada Fase e iteracin como se indica en la Seccin 6.2.3.2 Objetivos y Procedimientos. Es importante notar que los Entregables con que se cuenta son los enviados por los grupos, por lo tanto no se puede tener la seguridad de que sean todos los entregables que fueron generados ni que se correspondan exactamente con la entrega realizada al Director de Proyecto. Los Entregables de cada semana de cada uno de los grupos 1, 2 y 3 que seguan este Modelo de Proceso definido, forman parte de la Memoria Organizacional implementada y estn accesibles en el Sitio Web de este Proyecto de Taller V en la direccin http://www.fing.edu.uy/~t5ingsw.
6.2.3
Auditorias del Proceso En esta seccin se describe de que forma fue realizado el seguimiento y evaluacin de la aplicacin del Modelo de Proceso por parte de los grupos 1, 2 y 3 del curso 2000, as como las dificultades que se presentaron en el cumplimiento de esta actividad. En la Seccin 6.2.3.1 Marco terico se establece el marco terico que define el concepto de Auditoria utilizado, a partir del cual se definieron los procedimientos para realizar el seguimiento y evaluacin mencionado previamente. En la Seccin 6.2.3.2 Objetivos y Procedimientos se describen los objetivos definidos para las Auditorias y los procedimientos utilizados para realizarlas. En la Seccin 6.2.3.3 Desarrollo de las Auditorias se detallan las Auditorias realizadas para dar cumplimiento a los objetivos de esta etapa.
6.2.3.1 Marco terico La IEEE define una Auditoria como la revisin independiente de un producto o de un conjunto de productos para evaluar el cumplimiento con las especificaciones, estndares, acuerdos contractuales u otros criterios [IEEE-STD-610]. Una Auditoria tiene como principal propsito la revisin de las actividades de Ingeniera de Software para verificar su ajuste al proceso de software definido, verificando que las desviaciones del proceso y los productos del software se documenten y gestionen de acuerdo con un procedimiento establecido, aplicndose en varias etapas del proceso de Software. Una Auditoria o Revisin Formal debe ser preparada por adelantado convocando para la realizacin de la misma entre 3 y 5 personas. La preparacin para la Auditoria que deban realizar quienes fueron convocados, no debe requerir ms de dos horas de trabajo por persona y la duracin de la reunin de Revisin o Auditoria debe ser menor a 2 horas. Esto es debido a que cada Auditoria debe dirigir su atencin hacia una parte especfica del desarrollo de software total, de esta forma la probabilidad de encontrar desviaciones es mayor.
Para la convocatoria a la Revisin o Auditoria se establece una agenda de los temas a tratar en la misma la cual es enviada a los participantes, indicando el lugar, da y hora de la reunin. La Auditoria es dirigida por el grupo de auditores externos, registrando todos los sucesos importantes que se produzcan durante la revisin y una vez finalizada la reunin se realiza un informe donde se detallan todos los aspectos de la Auditoria. Es importante tener en cuenta al momento de conducir una Auditoria que debe revisarse el producto y no a quin lo produce, el ambiente debe ser distendido y constructivo, moderndose la reunin para garantizar que se mantiene un tono y una actitud adecuada. La agenda debe mantenerse y no se debe permitir que los temas se desven de lo agendado, limitando el debate y las impugnaciones. Deben enunciarse las reas donde se identifiquen problemas pero sin intentar resolverlos. El desarrollo de listas de chequeo para cada producto a ser revisado sirve de gua durante la reunin y es de gran apoyo para realizar la revisin [PRES98].
6.2.3.2 Objetivos y Procedimientos En base al Marco terico descrito en la seccin anterior las Auditorias que se definieron tenan como objetivo principal contrastar el Modelo de Proceso propuesto con el desarrollo real del Proyecto de Ingeniera de Software de los grupos 1, 2 y 3. En estas Auditorias se intentaba conocer el grado de apego al Proceso que presentaban los grupos, la causa de los desvos que pudieran ocurrir y las actividades que no estaban contempladas en el modelo pero que el grupo realizaba. El procedimiento definido por este grupo de Proyecto de Taller V para la realizacin de las Auditorias, tena como primer paso la identificacin de las Lneas de Trabajo o reas que seran auditadas en la Fase e iteracin a la que corresponda la Auditoria. Esta identificacin se realizaba teniendo en cuenta las actividades claves que estaban establecidas para cada Lnea de Trabajo en cada Fase e iteracin y teniendo en cuenta la Agenda de Actividades y la Agenda de Entregables del Modelo de Proceso definido. Se tom la definicin de que en principio, la presencia de los Entregables de salida de una actividad indicaba la realizacin de la misma, lo cual sera corroborado posteriormente en la Auditoria. De todas formas el hecho de que existiera el Entregable no garantizaba que la actividad se hubiera realizado siguiendo la descripcin de la misma, aunque su contenido daba una idea de las tareas realizadas para su generacin. Para cada Auditoria, una vez establecidas las Lneas de Trabajo o reas se identificaban los integrantes del Equipo que tenan asignados los roles involucrados y se realizaba un documento de convocatoria a la Auditoria en el cual se detallaba la temtica de la misma y las preguntas a realizar. Este documento de convocatoria era enviado previamente por e-mail a los participantes. Para coordinar con cada rea de cada grupo los das y horas de las Auditorias, se defina una agenda tentativa que se publicaba en la pgina de este grupo de Proyecto de Taller V. Los participantes de cada grupo luego de coordinar entre ellos se anotaban segn su preferencia y en el caso que no les sirviera ninguna de las opciones propuestas se coordinaba en forma particular con ese grupo. Una vez que se haban realizado todas las Auditorias correspondientes a la Fase e iteracin, se procesaba la informacin obtenida y se realizaba un informe de Auditoria por cada rea de cada grupo auditada, que inclua el chequeo de Entregables presentes, las respuestas de los grupos dadas en la Auditoria y las conclusiones a las que se llegaba una vez realizada la evaluacin correspondiente. Este informe de Auditoria se enviaba a los participantes de las mismas para que confirmaran que la informacin incluida estaba de acuerdo con la Auditoria realizada, y si exista alguna
discrepancia en algn punto se trataba con los involucrados hasta llegar a un acuerdo sobre el informe realizado. Una vez que los informes de Auditoria tenan la conformidad de todos los participantes en las mismas, se publicaban en la pgina de este grupo de Proyecto de Taller V en la Seccin correspondiente a Auditorias del Proceso, ordenadas por grupo, Fase, iteracin y rea auditada. Los informes que se publicaban tenan una contrasea por grupo para evitar que integrantes de distintos grupos accedieran a la informacin sobre la evaluacin de grupos que no fuera el que integraban. Esta decisin se tom basada en que no era de inters fomentar la competencia entre los distintos grupos que podra darse mediante la comparacin de avance en el proyecto y conclusiones de las Auditorias. A los Directores de Proyecto se les enviaban los informes de Auditorias de todos los grupos ya que se entendi que era de inters que los Directores de Proyecto tuvieran una visin global del desarrollo de los proyectos por parte de todos los grupos que seguan el Modelo de Proceso definido.
6.2.3.3 Desarrollo de las Auditorias En esta seccin se describen las Auditorias realizadas en cada Fase e iteracin detallando las Lneas de Trabajo o reas auditadas en cada caso y los participantes de las mismas. Para cada etapa se establecen los objetivos planteados para la Auditoria y los aspectos ms relevantes en el desarrollo de las mismas. El desarrollo de las Auditorias est ordenado en forma cronolgica segn la Fase e iteracin a la que corresponden, dadas por las siguientes secciones: Seccin 6.2.3.3.1 Auditorias de Fase Inicial, Seccin 6.2.3.3.2 Auditorias de la primer iteracin de la Fase de Elaboracin, Seccin 6.2.3.3.3 Auditorias de la segunda iteracin de la Fase de Elaboracin y Seccin 6.2.3.3.4 Seguimiento y Evaluacin de la Fase de Construccin. En el documento Seguimiento y Evaluacin de la Experiencia 2000 [SEEXP00] se adjuntan todos los productos generados en esta etapa del Proyecto de Taller V. 6.2.3.3.1 Auditorias de la Fase Inicial En la Fase Inicial del proceso, los objetivos definidos apuntan principalmente al cumplimiento de las actividades establecidas para la Lnea de Trabajo de Requerimientos en cuanto al entendimiento del problema y un primer anlisis de los requerimientos planteados, y para las Lneas de Trabajo de Gestin y de Verificacin en cuanto a la planificacin inicial de las reas del proyecto y las estimaciones iniciales del mismo. En base a estos objetivos planteados, se realizaron las Auditorias correspondientes a las Lneas de Trabajo que se indican a continuacin:
Auditoras de Gestin
Lneas de Trabajo auditadas: Gestin del Proyecto, Gestin de Calidad, Gestin de Configuracin y Verificacin. Participantes: Administrador, Responsable de SQA, Responsable de SCM y Responsable de Verificacin.
Auditoras de Requerimientos
Lneas de Trabajo auditadas: Requerimientos. Participantes: Analistas En este caso definimos que solo participaran los Analistas ya que aunque el Arquitecto tambin participaba de estas actividades, su trabajo ms importante se desarrollaba en la Fase de Elaboracin y sera durante esa Fase que participara de las Auditorias.
El desarrollo de las Auditorias tena lugar en un tono semi-formal, en la cual se realizaban las preguntas definidas para la misma, anotando las respuestas de los participantes y las observaciones que correspondieran tanto sobre los Entregables como sobre las Actividades realizadas y la forma en que se realizaban las mismas. Tambin se contestaban dudas que tenan los participantes sobre la realizacin de alguna actividad en especial o algn concepto que no les
quedaba claro sobre el Modelo de Proceso definido por lo que en estas Auditorias el intercambio de informacin fue en ambos sentidos.
6.2.3.3.2
Auditorias de la primer iteracin de la Fase de Elaboracin En la Fase de Elaboracin primer iteracin del proceso, los objetivos definidos apuntan principalmente al cumplimiento de las actividades establecidas para las Lneas de Trabajo de Anlisis, Diseo e Implementacin en cuanto a la definicin de la Lnea Base de la Arquitectura y del Alcance del Sistema, y para las Lneas de Trabajo de Gestin y de Verificacin en cuanto a la planificacin final de las reas del proyecto, actividades de seguimiento y control, mediciones, actividades de Verificacin, revisiones de calidad y definicin del ambiente controlado. En base a estos objetivos planteados, se realizaron las Auditorias correspondientes a las Lneas de Trabajo que se indican a continuacin:
Auditoras de Gestin
Lneas de Trabajo auditadas: Gestin del Proyecto, Gestin de Calidad, Gestin de Configuracin y Verificacin. Participantes: Administrador, Responsable de SQA, Responsable de SCM y Responsable de Verificacin.
Auditoras de Lnea Base de la Arquitectura

Lneas de Trabajo auditadas: Anlisis, Diseo e Implementacin. Participantes: Arquitecto y Especialistas Tcnicos. En este caso se defini que los Analistas no participaran ya que aunque tambin realizaban estas actividades, ya se haba realizado una Auditoria con ellos en la Fase Inicial.
Estas Auditorias se realizaron en la misma forma que las Auditorias de la Fase Inicial, mediante reuniones con los integrantes del Equipo que desempeaban los roles involucrados en las actividades de las Lneas de Trabajo identificadas para la Auditoria.
6.2.3.3.3
Auditorias de la segunda iteracin de la Fase de Elaboracin En la Fase de Elaboracin segunda iteracin del proceso, los objetivos definidos apuntan principalmente al cumplimiento de las actividades establecidas para las Lneas de Trabajo de Requerimientos, Anlisis, Diseo e Implementacin en cuanto a la definicin e implementacin de la Lnea Base de la Arquitectura, para la Lnea de Trabajo de Gestin de Calidad en la realizacin de Revisiones Tcnicas Formales y para la Lnea de Trabajo de Verificacin en la realizacin de las pruebas unitarias, de integracin y del sistema para el Ejecutable de la Lnea Base de la Arquitectura. En esta etapa no se pudieron realizar las Auditorias de la misma forma que las anteriores ya que para ese momento se estaba manejando la posibilidad de que hubiera una Huelga Universitaria, por lo que se disearon cuestionarios que se enviaron va e-mail a los integrantes de los grupos que cumplan los roles involucrados en las actividades identificadas en cada rea, de acuerdo al siguiente detalle:
Cuestionario para Analistas y Arquitecto

Lneas de Trabajo auditadas: Requerimientos, Anlisis y Diseo. Participantes: Analistas y Arquitecto.
Cuestionario para Implementadores

Lneas de Trabajo auditadas: Diseo, Implementacin y Verificacin. Participantes: Especialistas Tcnicos.
Cuestionario para Responsables de Verificacin

Lneas de Trabajo auditadas: Implementacin y Verificacin. Participantes: Responsable de Verificacin.
Cuestionario para Responsables de Calidad

Lneas de Trabajo auditadas: Gestin de Calidad. Participantes: Responsable de SQA.
En estos cuestionarios se definieron secciones cada una de las cuales est compuesta por preguntas especficas con opciones para marcar y observaciones y/o comentarios. En el cuestionario para Analistas y Arquitecto las secciones son generales y contienen preguntas sobre las actividades previstas en el Modelo de Proceso para esta etapa. En los cuestionarios para los roles de Implementador, Responsable de Verificacin y Responsable de Calidad, las secciones definidas se corresponden cada una con una actividad de las previstas en el Modelo de Proceso para esta etapa y para la primera semana de la Fase de Construccin. En todos los cuestionarios se incluye una seccin o las preguntas correspondientes, sobre la participacin de los roles involucrados en las Revisiones Tcnicas Formales que deba realizar el Responsable de Gestin de Calidad, ya que en esta etapa esa actividad era de gran importancia en el Modelo de Proceso propuesto. Tambin se incluye una seccin en la que se pregunta en general por la realizacin de las actividades previstas en el Modelo para esta etapa y de otras que no estuvieran contempladas en el mismo y que se estuvieran realizando. A continuacin se indican las secciones definidas para cada cuestionario diseado:
Cuestionario para Analistas y Arquitecto

Seccin 1: Sobre el Diseo del Sistema Seccin 2: Sobre el Modelo de Proceso Seccin 3: Sobre su prximo rol
Cuestionario para Implementadores

Seccin Seccin Seccin Seccin Seccin 1: 2: 3: 4: 5: Actividad I3 Planificar la Integracin de la Iteracin Actividad I6 Hacer Revisin por Pares Actividad I7 Realizar la Integracin de la Iteracin Actividad SQA5 Realizar Revisin Tcnica Formal (RTF) Preguntas generales sobre el Modelo de Proceso

Seccin Seccin Seccin Seccin 1: 2: 3: 4: Actividad I3 Planificar la Integracin de la Iteracin Actividad V2 Planificar las Pruebas de la Iteracin Actividad V3 Disear las Pruebas de la Iteracin Actividad V4 Realizar las Pruebas Unitarias Actividad V5 Realizar las Pruebas de Integracin Actividad V6 Realizar las Pruebas del Sistema Actividad V7 Verificar cada documento Actividad V8 Evaluar la Verificacin de la Iteracin Actividad SQA5 Realizar Revisin Tcnica Formal (RTF) Preguntas generales sobre el Modelo de Proceso
Seccin Seccin Seccin Seccin
5: 6: 7: 8:
Cuestionario para Responsables de Calidad

Seccin Seccin Seccin Seccin Seccin Seccin 1: 2: 3: 4: 5: 6: Actividad SQA3 Revisar cada producto Actividad SQA4 Revisar el Ajuste al Proceso Actividad SQA5 Realizar Revisin Tcnica Formal (RTF) Actividad SQA6 Realizar Evaluacin y Ajustes al Plan de SQA Actividad SQA7 Asegurar que las desviaciones son documentadas Preguntas generales sobre el Modelo de Proceso
6.2.3.3.4
Seguimiento y Evaluacin de la Fase de Construccin Para la Fase de Construccin no se pudieron realizar las Auditorias por iteracin como se haba planificado, ya que al retomarse los cursos luego de la Huelga no tena sentido realizar las Auditorias correspondientes a la primer iteracin de la Fase de Construccin pues sta haba quedado incompleta en el momento de comenzar la Huelga casi tres meses atrs. Al iniciarse la recuperacin de cursos a mediados de enero de 2001, se defini por parte de los docentes del curso que se tenan cuatro semanas para finalizar el proyecto. Por lo tanto, estas cuatro semanas correspondieron a la segunda iteracin de la Fase de Construccin. Las Auditorias correspondientes a esta segunda iteracin de la Fase de Construccin se haba planificado realizarlas conjuntamente con la evaluacin final del Proyecto, por lo que se defini que en el Cuestionario Final del Proyecto para los roles que correspondiera se incluiran las preguntas de las actividades de la Fase de Construccin, que se haba desarrollado en forma cortada.
6.2.3.4 Cuestionarios Finales para los grupos de Proyecto Para recopilar la informacin de mayor relevancia sobre el desarrollo de las distintas reas del proyecto y los puntos de conformidad del modelo propuesto con el seguido por cada grupo, se dise un cuestionario para cada rol combinado definido en el Modelo de Proceso propuesto, de acuerdo al siguiente detalle:
Cuestionario para Analistas/Implementadores

Lneas de Trabajo auditadas: Requerimientos, Analisis, Diseo e Implementacin. Participantes: Analistas/Implementadores.
Cuestionario para Analistas/Documentador de Usuario/Asistente de Verificacin

Lneas de Trabajo auditadas: Requerimientos, Anlisis, Diseo, Verificacin, Documentacin. Participantes: Analistas/Documentador de Usuario/Asistente de Verificacin.
Cuestionario para Arquitecto/Asistente de Verificacin

Lneas de Trabajo auditadas: Requerimientos, Anlisis, Diseo, Implementacin, Verificacin. Participantes: Arquitecto/Asistente de Verificacin.
Cuestionario para Especialiastas Tcnicos/Implementadores

Lneas de Trabajo auditadas: Diseo, Implementacin, Verificacin. Participantes: Especialistas Tcnicos/Implementadores.

Lneas de Trabajo auditadas: Implementacin, Verificacin. Participantes: Responsable de Verificacin.
Cuestionario para Responsables de SCM/Responsables de SQA

Lneas de Trabajo auditadas: Gestin de Configuracin y Gestin de Calidad. Participantes: Responsable de SCM, Responsable de SQA.
Cuestionario para Administradores

Lneas de Trabajo auditadas: Gestin del Proyecto. Participantes: Administrador. En estos cuestionarios se definieron 6 secciones, cada una de las cuales est compuesta por preguntas especficas con opciones para marcar y observaciones y/o comentarios. Las secciones definidas se corresponden cada una con un aspecto relevante del Modelo de Proceso, del desarrollo del proyecto o del Sistema construido, las cuales se detallan a continuacin:
Seccin Seccin Seccin Seccin Seccin Seccin
1: 2: 3: 4: 5: 6:
Sobre Sobre Sobre Sobre Sobre Sobre
los Roles y sus Actividades los Entregables de su Rol los Requerimientos del Sistema el Producto obtenido el Modelo de Proceso Propuesto las Auditoras externas realizadas al grupo por el Proyecto de Taller 5
Las primeras 2 secciones tenan preguntas especficas segn el rol auditado, y las otras 4 secciones eran comunes a todos los roles. Estos cuestionarios se enviaron a cada integrante de los grupos 1, 2 y 3 que seguan este Modelo de Proceso segn el rol que tenan asignado, y fueron contestados en forma individual. Las respuestas a estos Cuestionarios Finales se ingresaron en la Base de Datos definida como parte de la implementacin de la Memoria Organizacional que se describe en el Captulo 8. 6.2.3.5 Cuestionarios Finales para los Directores de Proyecto Para tener otra visin del desarrollo del Proyecto por parte de cada grupo, se disearon cuestionarios para los Directores de Proyecto similares a los diseados para los integrantes de los grupos pero enfocados a una visin global del grupo, del Modelo de Proceso y del Sistema construido, en los cuales definimos 6 secciones que se detallan a continuacin: Seccin Seccin Seccin Seccin Seccin Seccin 1: 2: 3: 4: 5: 6: Sobre el grupo y sus Actividades Sobre el desarrollo del Proyecto Sobre los Requerimientos del Sistema Sobre el Modelo de Proceso Propuesto Sobre las Auditorias externas realizadas al grupo por el Proyecto de Taller 5 Comentarios, sugerencias, lecciones aprendidas
Las respuestas a estos Cuestionarios Finales tambin se ingresaron a la Base de Datos definida como parte de la implementacin de la Memoria Organizacional que se describe en el Captulo 8.
6.3
Los resultados de esta etapa son difciles de evaluar ya que como se mencion anteriormente, el desarrollo de esta etapa se vio interrumpido por la realizacin de una Huelga Universitaria que trajo aparejada la suspensin del dictado de cursos y dems actividades curriculares de facultad. El seguimiento de la aplicacin del Modelo de Proceso en el curso 2000 fue realizado en forma satisfactoria en las primeras etapas del mismo, esto es hasta la segunda iteracin de la Fase de Elaboracin, momento en el cual se cortaron las actividades de los proyectos debido a la Huelga. En esas primeras etapas el monitoreo de Entregables de los grupos se realiz como estaba previsto insumiendo en algunos casos, ms tiempo del planificado debido a dificultades con las entregas. El desarrollo de las Auditorias a los distintos participantes se evala positivamente, si bien el tiempo dedicado a la planificacin, diseo y realizacin de las reuniones de Auditoria fue mayor del previsto, as como el invertido en la realizacin del Informe Final de cada una. Las Auditorias de la segunda iteracin de la Fase de elaboracin debieron realizarse en forma de cuestionarios ya que la realizacin de la Huelga Universitaria era inminente y no se quera coordinar reuniones con los integrantes de los grupos una vez que la Huelga comenzara. Estos cuestionarios debieron ser diseados, procesados y a partir de las respuestas de los participantes y el monitoreo de Entregables se realiz el Informe Final de cada rea.
El seguimiento de la Fase de Construccin result bastante complejo ya que al retomarse las actividades curriculares a mediados de enero de 2001 no se tena visibilidad sobre el trabajo que los grupos haban realizado durante la Huelga, y les result bastante difcil ponerse nuevamente en ritmo de desarrollo del proyecto. En esta etapa la entrega de los Entregables de los grupos result confusa y desorganizada. Al finalizar los proyectos, se enviaron los cuestionarios finales para los integrantes de los grupos y los Directores del Proyecto los cuales fueron contestados por la mayora de los participantes. Se asisti a las defensas de los proyectos de los cinco grupos que participaron del curso de PINGSW97, de los grupos 1, 2 y 3 que siguieron el Modelo de Proceso definido por este grupo de Proyecto de Taller V y de los grupos 4 y 5 que siguieron el Modelo de Proceso definido por el otro grupo de Proyecto de Taller V. Estas defensas resultaron una experiencia interesante. Finalmente, se considera que los objetivos de la etapa fueron cumplidos a pesar de las dificultades que se dieron por la realizacin de la Huelga, el objetivo principal de realizacin de las Pruebas del Proceso se cumpli en forma satisfactoria de acuerdo a lo establecido para su definicin. La duracin prevista para el desarrollo de la etapa tambin fue cumplida aunque en forma interrumpida.
CUARTA ETAPA AJUSTES AL PROCESO

En este Captulo se describen las actividades realizadas correspondientes a la etapa 4 de Ajustes al Proceso, de acuerdo a lo establecido en la Seccin 3.1 Etapas, de este documento. Una vez terminadas las Pruebas del Proceso como fueron descritas en el Captulo 6, se analizaron los datos recopilados y las faltas de conformidad de los grupos con el Modelo de Proceso. Se identificaron los ajustes y el entorno necesarios para mejorar los resultados de su aplicacin. En la seccin 7.1 Objetivo, se describen los objetivos identificados para esta etapa. En la seccin 7.2 - Desarrollo, se detallan las actividades cumplidas para realizar el anlisis y evaluacin del Modelo de Proceso, brindando una propuesta de Ajustes al Modelo de Proceso y la Definicin del Modelo de Proceso Ajustado, as como estableciendo el entorno requerido para la aplicacin del mismo. Finalmente, en la Seccin 7.3 - Resultados y Conclusiones, se muestran los resultados obtenidos y las conclusiones sobre el desarrollo de la etapa.
7.1
Objetivo
En esta etapa de Ajustes al Proceso el objetivo fundamental es analizar la informacin recolectada en el Captulo 6, buscando los puntos en donde existieron los principales desvos al Proceso, sus causas y las modificaciones que se deben realizar para obtener un proceso mejorado. Se busca una nueva definicin del Modelo de Proceso a aplicar en la asignatura PINGSW97 del curso 2001, la cual se basa en el Modelo de Proceso inicial con los cambios ajustes y agregados identificados en esta etapa.
7.2
Desarrollo
Para esta etapa, se debi estudiar el formato en que se iba a mantener la informacin a analizar, se vio que tanto los cambios como las conformidades que se describieran en esta etapa no podan quedar expresadas en base al conocimiento subjetivo de las integrantes de este Proyecto de Taller V. Tanto esta etapa como la siguiente se plantea por el Tutor como de investigacin abierta, por lo que la forma en como se realizaran estas etapas deba ser elegida por las integrantes de este Proyecto de Taller V y ms tarde sera aprobado por el Tutor. Como el desarrollo de esta etapa se hizo en paralelo al de la etapa 5 - Bases para la Memoria Organizacional, se lleg a la conclusin que la informacin adquirida durante la etapa 3 de Pruebas del Proceso deba estructurarse en una Base de Datos relacional, de esta forma la informacin se encontrara centralizada y de fcil acceso para realizar el trabajo de esta etapa. Como se explica en la seccin 8.2.2.2 - Base de Datos Relacional, se realiz un prototipo en ACCESS debido a que era el manejador de base de datos al que se tena ms fcil acceso y brinda la posibilidad de utilizar las tablas dinmicas de EXCEL para la visualizacin de las consultas realizadas. En la definicin de esta Base de Datos se invirti la segunda quincena de Enero de 2001 y el ingreso de los datos a la base se realiz en Marzo una vez que los grupos haban terminado el proyecto. El ingreso de estos datos a la base llev ms tiempo del previsto. Esto se debi a que para el ingreso de los datos muchas veces se requera procesarlos previamente, sacando informacin de distintas fuentes. Mientras se realizaba este trabajo, como la informacin procesada provena de las Auditorias, los cuestionarios y de las entregas de los grupos, se iban detectando las principales modificaciones, ajustes y agregados al Modelo de Proceso. A principios de abril de 2001, la base de datos contena toda la informacin que se pudo estructurar y se comenz con la tarea de realizar consultas sobre los datos resultando bastante difcil poder sintetizar cules eran las principales consultas que se deban mostrar para apoyar las decisiones de modificaciones que se haban detectado previamente.
En la Seccin 7.2.1 Anlisis y Evaluacin del Modelo de Proceso, se detallan las actividades realizadas para analizar y evaluar la informacin de que se dispona. En la Seccin 7.2.2 Propuesta de Ajustes al Modelo de Proceso, se detalla la identificacin de los ajustes que se deben realizar la Modelo de Proceso, en la Seccin 7.2.3 Definicin del Modelo de Proceso Ajustado, se describe la nueva versin del Modelo de Proceso obtenida y finalmente en la Seccin 7.2.4 Entorno requerido para la aplicacin del Modelo, se describen aspectos que se deben tener en cuenta en la Organizacin para la aplicacin del Modelo de Proceso.
7.2.1
Anlisis y Evaluacin del Modelo de Proceso La informacin con la que se contaba al llegar a esta etapa para evaluar el Modelo de Proceso se encontraba en la siguientes fuentes: los Entregables generados por cada grupo durante el proyecto, las Auditorias que se realizaron durante el transcurso del proyecto, la informacin recolectada en el cuestionario Final para los integrantes de los grupos, la informacin recolectada en el Cuestionario Final para los Directores del Proyecto, las Mediciones de los proyectos que realizaron los Administradores de cada grupo al Cierre del Proyecto y la visin subjetiva que se tena de cada grupo en base al seguimiento realizado por parte de las integrantes de este Proyecto de Taller V. Parte de esta informacin pudo ser estructurada y se encuentra almacenada en la Base de Datos que se defini como parte de la implementacin de la Memoria Organizacional del proyecto, la cual se describe en el Captulo 8. Dentro de los objetivos que se fijaron en el Plan de Trabajo descrito en la seccin 2.4 de este documento, deban definirse criterios para evaluar la calidad de los Productos y evaluarlos para luego poder realizar un anlisis de la correlacin entre la evaluacin de los productos y la conformidad con el Modelo de Proceso pero este objetivo no pudo cumplirse. Como fue explicado previamente en la Seccin 6.2.1 - Marco general, el producto a construir era un Sistema de Workflow y el docente que cumpli el Rol de Cliente tuvo muy poca participacin en el Proyecto, se realizaron pocas reuniones de requerimientos y los requerimientos se basaron en la documentacin de la WFMC. Existieron pocas instancias de validacin con el Cliente, la mayora de ellas fueron por va e-mail y el Cliente no pudo participar de la validacin final del Producto. Se consider que para definir los criterios para evaluar la calidad de los Productos se necesitaba conocer los requerimientos que el Cliente haba definido, al no contar con la participacin del Cliente para definir dichos criterios, ni para evaluar cada producto, no fue posible cumplir los objetivos estipulados. Se definieron como criterios para evaluar la conformidad de los grupos con el Modelo de Proceso propuesto el cumplimiento con los objetivos definidos para cada Fase, tanto en agenda, como en la realizacin de las actividades y en el contenido de los Entregables. Otro criterio utilizado para la evaluacin fue tener en cuenta las opiniones de los integrantes de cada grupo, las opiniones de los Directores y las opiniones de las intregantes de este grupo de Proyecto de Taller V. Para realizar el anlisis de la evolucin de cada grupo por Fase e Iteracin, se parti de la informacin de las Auditorias, utilizando como apoyo las consultas realizadas a la Base de Datos, y complementando con informacin de los Entregables y de las mediciones finales realizadas por los Administradores de cada grupo registradas en el Documento de Mediciones [MPMED00] cuando fuera necesario. La diferencia de este anlisis con el realizado en las Auditorias de la etapa 3 - Pruebas del Proceso, es en primer lugar que el anlisis de esta seccin se hace teniendo en cuenta los tres grupos, por lo que se los compara y se analizan juntos en el tiempo, el segundo aspecto es que en las Auditorias de la etapa 3 se detectaban desvos pero no se saba si se corregan o no hasta la prxima Auditoria. En el anlisis de esta seccin se detectan los desvos en cada fase y se describe como evolucion ese desvo en el tiempo, teniendo en cuenta la informacin total del desarrollo de los proyectos hasta su finalizacin. Una vez que los proyectos finalizaron se proces la informacin de los Cuestionarios Finales de cada Integrante de los grupos y de los Cuestionarios Finales de los Directores del Proyecto realizando consultas a la Base de Datos. La informacin en estos cuestionarios es, como ya se mencion, la visin subjetiva de los integrantes de los grupos y de los Directores de Proyecto.
El anlisis realizado y las conclusiones a las que se llegaron se encuentra en el documento de Anlisis del Modelo de Proceso 2000 [AMP00], las modificaciones al Modelo de Proceso que se detectaron en ese anlisis se detallan a continuacin:
7.2.2
Propuesta de ajustes al Modelo de Proceso En base a la informacin en el documento [AMP00], y en base al Seguimiento realizado a los grupos durante el desarrollo del proyecto, se definieron las modificaciones y ajustes al Modelo de Proceso que se detallan en las siguientes secciones:
7.2.2.1 Incluir un documento de introduccin al Modelo de Proceso Durante el desarrollo de las Pruebas del Proceso, tanto los integrantes de los grupos como los Directores del Proyecto plantearon la necesidad de tener un extracto del Modelo de Proceso que permitiera una rpida lectura, mostrando una visin general de los objetivos y principales actividades y entregables. El no contar con este documento previo a la aplicacin del Modelo hizo que en las Auditorias de la Fase Inicial se debiera explicar el Modelo, la forma de realizar las actividades y los principales objetivos para cada Lnea de Trabajo, ya que los grupos no entendan los conceptos fundamentales que definan al Proceso a seguir. Esta informacin est dada en el documento de Introduccin al Modelo de Proceso [IMPA01].
7.2.2.2 Cambios en los documentos de Actividades para cada Lnea de Trabajo Se mantienen las actividades que deban realizarse en cada Lnea de Trabajo en el Modelo de Proceso inicial y que estn documentadas en la seccin 5.2.2.3 - Lneas de Trabajo y sus Actividades, entregables y roles. Esto se debe a que las no conformidades encontrados durante las Pruebas del Modelo, no se referan a cmo se realizaban las actividades ni a quienes las deban realizar sino a cmo estas se realizaban en el tiempo para la agenda propuesta. Los cambios realizados a los documentos de actividades son mnimos y se encuentran detallados en la siguiente Seccin 7.2.2.3 - Cambios, ajustes y agregados al Modelo de Proceso.
7.2.2.3 Cambios, ajustes y agregados al Modelo de Proceso Existen distintos cambios y ajustes realizados al Modelo de Proceso, algunos son generales a todas las lneas de Trabajo y se describen en la seccin 7.4.3.1 y otros son referentes a cada Lnea de Trabajo y se detallan de la seccin 7.4.3.2 a la seccin 7.4.3.8. Para cada cambio se brinda una descripcin, el motivo del cambio y el estado de la Modificacin, esto ltimo se debe a que muchos de los cambios quedan planteados pero no se modifican los documentos definidos para el Modelo de Proceso inicial por una cuestin de tiempo y oportunidad, ya que existe un Proyecto de Taller V planteado para este ao que unificar los dos Modelos de Proceso seguidos en el curso 2000, en un nuevo Modelo de Proceso que se aplicar en el curso 2001.
Cambios Generales
La semana de las actividades se corresponde con la semana de los entregables, por ejemplo en la Semana 1 existe la actividad Realizar la Reunin del Equipo del proyecto, la cual tiene como salida el Acta de la reunin del Equipo del proyecto, la cual se pide en la Semana 1 de los Entregables, entendindose que se entrega al fin de la Semana 1 o principio de la Semana 2 dependiendo de cundo el equipo tenga la Reunin de Monitoreo.
Motivo del Cambio: El numerar las semanas en las agendas de actividades y entregables con nmeros distintos hizo que los grupos y los Directores se confundieran en las primeras semanas sobre qu deba entregarse. Estado de la Modificacin: Este cambio se encuentra registrado en el documento Agenda de Actividades y Entregables [MPAAE01] del Modelo de Proceso Ajustado, definido en la seccin 7.2.2.6 de este documento.
Se propone una nueva combinacin de roles, en base a un proyecto de 10 personas:
Cantidad de Integrantes del grupo: Analista Implementador Analista Asistente de Verificacin Doc.de Usuario Arquitecto Asistente de Verificacin Especialista Tcnico Implementador Analista - Responsable de Verificacin Responsable de SQA Responsable de SCM Administrador Asistente de Verificacin
10 2 1 1 3 1 1 1
Motivo del Cambio: El cambio se encuentra en los roles Administrador - Asistente de Verificacin y en el AnalistaResponsable de Verificacin y se debe en el primer caso a que el rol de Administrador en la Fase de Construccin del Proyecto pierde contacto con el grupo por lo que al cumplir el rol de Asistente de Verificacin se involucra en las actividades de desarrollo del Sistema. Con respecto al Responsable de Verificacin se not que uno de las principales dificultades que se tenan para realizar el rol era el no entender el Sistema a construir, por lo que se propone que tambin cumpla el rol de Analista al comenzar el Proyecto conjuntamente con las actividades de verificacin establecidas. Estado de la Modificacin: Este cambio se encuentra en el documento Introduccin al del Modelo de Proceso [IMPA01].
Los entregables: Descripcin Descripcin Descripcin Descripcin Descripcin de de de de de la la la la la arquitectura arquitectura arquitectura arquitectura arquitectura vista vista vista vista vista del del del del del Modelo Modelo Modelo Modelo Modelo de de de de de Casos de Uso Anlisis Diseo Distribucin Implementacin
se unificaron en un solo documento que se llama Descripcin de la Arquitectura. Motivo del Cambio: Durante las pruebas del Modelo los grupos plateaban que la cantidad de documentos que deban generar era excesiva, al finalizar el proyecto reiteraron esto en los cuestionarios finales tanto los integrantes de los grupos como los Directores del Proyecto.
Estado de la Modificacin: El documento Descripcin de la Arquitectura se divide en distintas secciones, una por cada vista, es por esto, que no vemos necesario el cambio en las actividades, ya que si una actividad tiene como salida la Descripcin de la Arquitectura vista del Modelo de Casos de Uso, esto significa que el Documento Descripcin de la Arquitectura ser modificado slo en la seccin correspondiente a la vista del Modelo de Casos de Uso. Se realizaron ajustes a la Agenda de Actividades y Agenda de Entregables por semana del Modelo de Proceso. Se agreg un indicador de la importancia de los Entregables pedidos para cada semana identificado como Prioridad cuya escala est dada por los valores: ALTA: MEDIA: BAJA: Es imprescindible que se entregue en la semana que es pedido. Es recomendable que se entregue en la semana que es pedido, pero, el atraso en su entrega no es un riesgo para el proyecto. Es opcional su entrega en la semana en que es pedido.
Motivo del Cambio: Este cambio se realiza en base al seguimiento y Evaluacin realizado sobre los grupos que siguieron este Modelo y al anlisis realizado documentado en [AFM00]. Estado de la Modificacin: Este cambio se encuentra registrado en la Agenda de Actividades y Entregables [MPAAE01] del Modelo de Proceso Ajustado, definida en la Seccin 7.2.2.6 Cambios en la Agenda de Actividades y Agenda de Entregables.
Cambios en Requerimientos El Entregable Lista de Requerimientos NO Funcionales se encuentra ahora incluido en el Entregable Documento de Requerimientos, en la seccin 4 del mismo. Motivo del Cambio: Centralizar toda la informacin referente a los Requerimientos del Sistema en un solo documento que facilite el manejo de esta informacin.
Estado de la Modificacin: No se modificaron los documentos de Actividades, por lo tanto las actividades: R5 - Encontrar Actores y Casos de Uso R7 - Detallar cada Caso de Uso R10 - Capturar los Requerimientos No Funcionales que tenan como salida la Lista de Requerimientos No Funcionales, tendrn ahora como salida el Documento de Requerimientos, entendiendo que los cambios al mismo sern realizados en su seccin 4. Las actividades: R5 - Encontrar Actores y Casos de Uso R6 - Priorizar Casos de Uso R7 - Detallar cada Caso de Uso R8 - Disear la Interface de Usuario R9 - Estructurar el Modelo de Casos de Uso R10 - Capturar los Requerimientos No Funcionales R11 - Definir el Alcance del Sistema
R12 - Revisar la consistencia de los Requerimientos A1 - Definir la arquitectura del Anlisis A2 - Analizar cada Caso de Uso A5 - Realizar la Especificacin de Requerimeintos D1 - Definir la Arquitectura del Diseo D2 - Disear cada caso de Uso I3 - Planificar la integracin de la Iteracin V2 - Planificar las Pruebas de la iteracin V3 - Disear las Pruebas de la iteracin GP1 - Preparar el Plan del Proyecto que tenan como entrada la Lista de Requerimientos No Funcionales, tendrn ahora como entrada el Documento de Requerimientos que en muchos casos ya figuraba tambin como entrada.
Cambios en Diseo Se crea una nueva actividad D6 - Disear la Base de Datos, la cual tiene como objetivo pasar las clases de entidad del diseo a un modelo de base de datos relacional. Motivo del Cambio: Este cambio fue pedido por los grupos y se observ tambin que dentro de los cambios realizados en el Rational Unified Process (RUP) en su versin 2001, aparece esta actividad que antes no estaba contemplada Estado de la Modificacin: Esta actividad no aparece en los documentos de actividades ni est definida, por lo que es un cambio a realizar
Cambios en Implementacin Se define el Entregable Prototipo de la Lnea Base de la Arquitectura en la primera iteracin de la Fase de Elaboracin, el cual reemplaza al Entregable Ejecutable de la Lnea Base de la Arquitectura que se peda en esta primer iteracin.
Motivo del Cambio: Esto se debe a que si bien consideramos que es importante que se comience la implementacin del Ejecutable de la Lnea Base de la Arquitectura desde el inicio de la Fase de Elaboracin, es probable que los documentos necesarios no estn terminados pero si se tenga una idea de la composicin de la Lnea Base de la Arquitectura. Mediante este prototipo puede explorarse alguna funcionalidad crtica o un escenario relevante a la Arquitectura mientras se profundiza en el anlisis y diseo de la misma. Este prototipo puede realizarse sin necesidad de que la documentacin correspondiente se formalice y aunque seguramente se incluya en el ejecutable de la Fase, podra ser desechado. El Arquitecto es responsable de definir las funcionalidades del prototipo, los Especialistas Tcnicos de implementarlo y el Responsable de Verificacin realizar las pruebas correspondientes. Estado de la Modificacin: La realizacin del prototipo se indica en la Agenda de Actividades y Entregables [MPAAE01] definida en la Seccin 7.2.2.6, no se entiende necesario un cambio en las actividades propuestas ya que la finalidad de este prototipo se encuentra en el documento de Introduccin al Modelo de Proceso[IMPA01]
Cambios en Verificacin Las Actividades de Verificacin: V5 - Realizar las Pruebas de Integracin V6 - Realizar las Pruebas del Sistema V8 - Evaluar la Verificacin de la iteracin fueron desfasadas una semana con respecto al Final de la Iteracin lo cual no quiere decir que se comience a hacer el trabajo de Verificacin con una semana de atraso sino que stas puedan extenderse a la semana o iteracin siguiente. Se mantiene la coordinacin del Responsable de Verificacin con los Implementadores en la Actividad I3 - Planificar la Integracin de la Iteracin en la cual se establecer en qu momento - luego de haber hecho los Implementadores las Revisiones por Pares - le enviarn los mdulos para hacer pruebas unitarias y de Integracin. Al terminar todas las pruebas es cuando el Verificador puede hacer la actividad V8 - Evaluar la Verificacin de la Iteracin, por lo que su ubicacin en el tiempo tambin fue modificada. Motivo del Cambio: En general, no hay tiempo suficiente para terminar las Pruebas de Integracin al final de la Iteracin y las Pruebas del Sistema slo se pueden realizar al tener el ejecutable resultado de la misma, por lo que stas pueden correrse al principio de la siguiente semana. Estado de la Modificacin: Este cambio se encuentra registrado en la Agenda de Actividades y Entregables [MPAAE01] del Modelo de Proceso Ajustado, definida en la Seccin 7.2.2.6 de este documento.
Los Entregables Casos de Prueba y Procedimientos de Pruebas se fusionaron en un solo Entregable llamado Casos y Procedimientos de Prueba Motivo del Cambio: Los entregables estn fuertemente relacionados, por lo que la centralizacin de esta informacin en un solo documento hace que su utilizacin sea ms gil Estado de la Modificacin: No se modificaron los documentos de Actividades, por lo tanto la actividad: V3 - Disear las Pruebas de la Iteracin que tena como salida los Entregables Casos de Prueba y Procedimientos de Pruebas, tendr ahora como salida el Entregable Casos y Procedimientos de Prueba Las actividades: V4 - Realizar Pruebas Unitarias V5 - Realizar Pruebas de Integracin V6 - Realizar Pruebas del Sistema que tenan como entrada los Entregables Casos de Prueba y Procedimientos de Pruebas, tendr ahora como entrada el Entregable Casos y Procedimientos de Prueba
Cambios en Gestin del Proyecto
El Entregable Orden del Da de la Reunin de Equipo del proyecto se encuentra ahora dentro del Entregable Acta de la Reunin de Equipo del proyecto, en la Seccin 1.
Motivo del Cambio: Si bien el Orden del Da de la Reunin de Equipo del proyecto debe ser realizado por el Administrador en forma previa a la realizacin de la Reunin, su inclusin en el Acta de la Reunin de Equipo del proyecto facilita su posterior utilizacin tanto por los grupos como por los Directores de Proyecto. Estado de la Modificacin: No se modificaron los documentos de Actividades, por lo tanto la actividad: GP2 - Preparar la Reunin de Equipo del proyecto que tena como salida el Orden del Da de la Reunin de Equipo del proyecto, tendrn ahora como salida el Acta de la Reunin de Equipo del proyecto, entendiendo que los cambios al mismo sern realizados en su seccin 1. La actividad: GP3 - Realizar la Reunin de Equipo del proyecto que tena como entrada el Orden del Da de la Reunin de Equipo, tendrn ahora como entrada el Acta de la Reunin de Equipo del proyecto en la cual solamente figura la Seccin 1. Los Entregables Lista de Riesgos Priorizados, Lista de Riesgos por rea y Documento de Mitigacin, Monitoreo y Contingencia de Riesgos se fusionaron en un Entregable llamado Documento de Riesgos. Motivo del Cambio: Los entregables estn fuertemente relacionados, por lo que es ms gil para su uso que estn fusionados en un solo documento el cual provea la visibilidad necesaria del tema tanto por parte de los grupos como del Director del Proyecto. Estado de la Modificacin: No se modificaron los documentos de Actividades, por lo tanto las actividades: GP3 - Realizar la Reunin de Equipo del Proyecto GP7 - Analizar y evaluar los riesgos del Proyecto que tenan como salida los Entregables Lista de Riesgos Priorizados, Lista de Riesgos por rea y Documento de Mitigacin, Monitoreo y Contingencia de Riesgos, tendrn ahora como salida el Entregable Documento de Riesgos. Las actividades: GP1 - Preparar el Plan del Proyecto GP3 - Realizar la Reunin de Equipo del Proyecto GP7 - Analizar y evaluar los riesgos del Proyecto que tenan como entrada el Entregable Lista de Riesgos Priorizados, Lista de Riesgos por rea y Documento de Mitigacin, Monitoreo y Contingencia de Riesgos, tendr ahora como entrada el Entregable Documento de Riesgos. En la Actividad GP11 - Reunin con el Director del Proyecto se agrega la siguiente redaccin: "El equipo coordinar con el Director del Proyecto la realizacin de una presentacin del estado del Proyecto que muestre el avance en cada Lnea de Trabajo, cuando se considere
conveniente. De esta forma el Director podr tener visibilidad del trabajo realizado y as brindar directivas de apoyo, tanto correctivas como de trabajo a futuro." Motivo del Cambio: La realizacin de presentaciones al Director result un aspecto muy positivo para obtener visibilidad sobre los grupos y para la organizacin interna de cada grupo Estado de la Modificacin: No se modificaron los documentos de Actividades, por lo que se debe tener en cuenta esta redaccin en el momento de hacer la Actividad.
Cambios en Gestin de Calidad En la Actividad SQA3 - Revisar cada Producto se agrega la siguiente redaccin: "Previamente a realizar la entrega semanal en la Actividad GP11 - Reunin con el Director del Proyecto, el Responsable de SQA revisa que los entregables correspondientes cumplan los estndares definidos de documentacin y presentacin. Se agrega como salida de esa Actividad el documento de Entrega Semanal de SQA en el cual se listan los entregables de la semana y los que no se entregan el motivo y fecha prevista de entrega Por lo tanto se agrega el nuevo Entregable: Entrega Semanal de SQA el cual se entrega al Director del Proyecto todas las semanas como resumen y validacin por parte del Responsable de SQA de los Entregables de la semana. De este documento se brinda la Plantilla correspondiente. Motivo del Cambio: La entrega al Director en un principio result muy desordenada y los productos entregados muchas veces no cumplan los requerimientos mnimos de calidad Estado de la Modificacin: No se modificaron los documentos de Actividades, por lo que se debe tener en cuenta la redaccin en el momento de hacer la Actividad.
Cambios en Capacitacin La actividad CAP2 - Estudiar la Metodologa de Jacobson, cambia su nombre por CAP2 Estudiar la Metodologa de Jacobson-Rumbaugh-Booch y notacin UML. Motivo del Cambio: En un principio los grupos pensaron que el estudio que deba realizarse era sobre el libro
[JACOB93] lo cual no es correcto, ya que se basa en el libro [USDP99] y material de la Metodologa utilizada en este libro se puede encontrar en [RUP01].
Estado de la Modificacin: Este cambio se encuentra registrado en la Agenda de Actividades y Entregables [MPAAE01] del Modelo de Proceso Ajustado, definida en la Seccin 7.2.2.6 de este documento.
7.2.2.4 Definicin de Plantillas para los Entregables
En el anlisis realizado en esta etapa, se vio que para facilitar la aplicacin del Modelo de Proceso, los grupos necesitaban plantillas para los Entregables. Una plantilla define una estructura para el Entregable, pero tambin define la homogeneidad en la Organizacin para obtener la visibilidad entre distintos proyectos. En la experiencia del ao 2000 se observ que los reportes de un mismo entregable en distintos grupos variaba tanto en la estructura, que se haca casi imposible poder compararlos. Las Plantillas definidas para los Entregables de cada Lnea de Trabajo se encuentran en el documento Plantillas del Modelo de Proceso Ajustado [MPAP01]. 7.2.2.5 Brindar Ejemplos para los Entregables Junto con una plantilla debera brindarse un ejemplo, para de esa forma despejar las dudas con respecto al contenido de los entregables. Si bien esto estaba establecido en la Definicin del Proyecto se vio que escapa al mismo, ya que para realizar los ejemplos se deba crear por parte de las integrantes de este grupo de Proyecto de Taller V, un proyecto entero de ejemplo. De todas formas, se encuentran los entregables de los grupos accesibles por semana en el Sitio Web definido en la seccin 8.2.2.1 - Sitio Web.
7.2.2.6 Cambios en la Agenda de Actividades y Agenda de Entregables Como se describi en el Captulo 5 de Definicin del Proceso, el Modelo de Proceso debe adaptarse a Proyectos de 13 semanas de duracin, que es lo que dura el curso del segundo semestre. En base al Modelo de Proceso inicial se definieron las actividades y entregables que los grupos deban realizar en cada semana para el Modelo de Proceso Ajustado. Para realizar esta agenda se utiliz como base la agenda ya probada del Modelo de Proceso inicial y se le introdujeron los cambios mencionados en la seccin 7.2.2.3 - Cambios, ajustes y agregados al Modelo de Proceso. Otro cambio en la Agenda de Actividades y Entregables est dado por su forma de presentacin. En el Modelo de Proceso inicial detallado en el Captulo 5 de este documento, las agendas estaban dadas cada una en un documento en formato pdf. La nueva presentacin de la Agenda de Actividades y Entregables para el Modelo de Proceso Ajustado, se proporciona como un solo documento en forma de Libro EXCEL que contiene la agenda de actividades y entregables del Modelo de Proceso, con filtros por semana y roles, lo que facilita la consulta de la informacin.
7.2.3
Definicin del Modelo de Proceso Ajustado La definicin del Modelo de Proceso Ajustado est dada por los documentos, cambios y ajustes mencionados en las secciones anteriores, incluyendo los datos que conforman la Memoria Organizacional que se define en el captulo 8 de este documento. Los documentos que forman el Modelo de Proceso Ajustado son: Introduccin al Modelo de Proceso [IMPA01] Documento de Actividades de la Lnea de Trabajo de Requerimientos [MPLTR00] Documento de Actividades de la Lnea de Trabajo de Anlisis [MPLTA00] Documento de Actividades de la Lnea de Trabajo de Diseo [MPLTD00] Documento de Actividades de la Lnea de Trabajo de Implementacin [MPLTI00] Documento de Actividades de la Lnea de Trabajo de Gestin de Calidad [MPLTCA00] Documento de Actividades de la Lnea de Trabajo de Gestin de Configuracin [MPLTCO00] Documento de Actividades de la Lnea de Trabajo de Gestin del Proyecto [MPLTGP00] Documento de Modificaciones al Modelo de Proceso Inicial [MPAM01] Documento de Agenda de Actividades y Entregables [MPAAE01]
Para poder aplicar nuevamente el Modelo de Proceso teniendo en cuenta los ajustes realizados, se debe comenzar por leer el documento Introduccin al Modelo de Proceso [IMPA01], luego deben leerse los documentos de Actividades para cada Lnea de Trabajo comenzando por Gestin del Proyecto, ya que en esta Lnea de Trabajo es donde se coordinan todas las actividades del Proyecto y todos los roles realizan actividades de esta Lnea. Las Lneas de Trabajo de Gestin de Calidad y Gestin de Configuracin no necesitan otros documentos previos de lectura, para las otras Lneas de Trabajo se recomienda que sean ledas en el siguiente orden: Requerimientos, Anlisis, Diseo, Implementacin y Verificacin. Para cada Lnea de Trabajo se realizaron modificaciones, estas modificaciones se encuentran en la seccin 7.2.2.3 - Cambios, ajustes y agregados al Modelo de Proceso, por lo que se deben identificar cules son las actividades que sufrieron cambios y tener en cuenta estos cambios en el momento de leer las actividades. En el momento de poner en la prctica el Modelo de Proceso, se debe seguir la agenda de Actividades y Entregables [MPAAE01].
7.2.4
Entorno requerido para la aplicacin del Modelo Para poder aplicar el Modelo de Proceso Ajustado definido en la seccin anterior a otros Proyectos de esta Organizacin, deben tenerse en cuenta las siguientes condiciones previas:
7.2.4.1 Estudio del Modelo de Proceso Ajustado La conclusin de los integrantes de los grupos, de los Directores del Proyecto y de quienes escriben este informe es que cualquier modelo de proceso a aplicar debe ser conocido por los miembros de la Organizacin previo a su puesta en prctica. En particular para aplicar este Modelo de Proceso Ajustado deben ser ledos en profundidad por parte de los integrantes de los grupos, todos los documentos que lo componen de acuerdo a lo establecido en la Seccin 7.2.3 Definicin del Modelo de Proceso Ajustado. Los Directores del Proyecto deben tener una visin general del mismo, la cual se puede alcanzar leyendo el documento de Introduccin al Modelo de Proceso [IMPA01].
7.2.4.2 Estudio de la Metodologa de Jacobson - Booch - Rumbaugh Este punto estara incluido dentro del punto 7.2.4.1 Estudio del Modelo de Proceso Ajustado pero se describe aparte debido a la importancia que tiene el estudio de esta metodologa para la aplicacin del Modelo de Proceso definido. Material para el estudio de esta metodologa se puede encontrar en [RUP01].
7.2.4.3 Eleccin de los roles previo al comienzo del Proyecto Si bien este punto no se considera prioritario, el conocimiento de cada integrante de su rol previo a comenzar con las actividades del mismo permite anticipar el estudio en detalle de las metodologas, tcnicas y herramientas utilizadas en el transcurso del Proyecto.
7.2.4.4 Gestin de la Configuracin Las actividades de Gestin de Configuracin por parte de los grupos que aplicaron este Modelo de Proceso fueron prcticamente nulas, lo que se puede ver en mayor detalle en el documento [AMF00] de anlisis y evaluacin del Modelo de Proceso. Creemos que para que los proyectos puedan realizar una gestin real de la Configuracin del Proyecto, la Organizacin debe brindar un ambiente controlado real a los grupos.
7.3
Los resultados de esta etapa se evalan como positivos ya que se logr realizar el anlisis y evaluacin del Modelo de Proceso a partir de la informacin obtenida en la etapa 3 Pruebas del Proceso. Como el desarrollo de esta etapa se hizo en paralelo al de la etapa 5 - Bases para la Memoria Organizacional, para este anlisis se utiliz la informacin que fue ingresada a la Base de Datos relacional definida como parte de la implementacin de la Memoria Organizacional, a partir de la cual se realizaron consultas. Este anlisis fue documentado en [AMF00]. A partir de las conclusiones a las que se llegaron se definieron los cambios, ajustes y agregados al Modelo de Proceso inicial, definiendo una versin de ste que est compuesto por los documentos que se establecen en la seccin 7.2.3 Definicin del Modelo de Proceso Ajustado, muchos de los cuales se mantienen de su versin inicial. Se estableci la Agenda de Actividades y Entregables del Modelo de Proceso Ajustado, donde se indica por Fase, iteracin y semana la realizacin de Actividades y los Entregables asociados, con las modificaciones realizadas, se definieron las plantillas que no se haban incluido en la versin inicial en los cuales se indica la estructura y contenido de cada Entregable. El objetivo de definicin de criterios para evaluar la calidad de los Productos y evaluarlos para luego poder realizar un anlisis de la correlacin entre la evaluacin de los productos y la conformidad con el Modelo de Proceso no pudo cumplirse, como fue explicado previamente en la Seccin 7.2 Desarrollo ya que se consider que para definir los criterios para evaluar la calidad de los Productos se necesitaba conocer los requerimientos que el Cliente haba definido, al no contar con la participacin del Cliente para definir dichos criterios, ni para evaluar cada producto, no fue posible cumplir los objetivos estipulados. Se considera que el objetivo principal de esta etapa que era la definicin de ajustes al Modelo de Proceso se realiz en forma satisfactoria cumpliendo con lo establecido en la definicin del Proyecto, si bien la duracin prevista para su desarrollo debi ser extendida, se entiende que esta decisin fue acertada ya que en parte esto se debe al ingreso de la informacin en la Base de Datos, lo cual permiti realizar un anlisis basado en informacin ms objetiva.
QUINTA ETAPA BASES PARA LA MEMORIA ORGANIZACIONAL

En este Captulo se detalla el desarrollo de la etapa 5 del Proyecto, de acuerdo a lo establecido en la Seccin 3.1 Etapas. En la seccin 8.1 Objetivos, se establecen los objetivos y actividades previstas para su cumplimiento. En la Seccin 8.2 Desarrollo, se detallan las actividades realizadas para asentar las Bases para la Memoria Organizacional en la Organizacin definida, brindando un marco terico sobre el tema y los detalles de la implementacin realizada, as como las posibilidades a futuro. Finalmente en la Seccin 8.3 Resultados y Conclusiones se muestran los resultados obtenidos y las conclusiones de la etapa.
8.1
Objetivo
El objetivo de esta etapa es investigar sobre el tema Memoria Organizacional y definir la forma de aplicar los principios de la Memoria Organizacional en la Organizacin definida.
8.2
Desarrollo
Esta etapa se realiz al principio de su desarrollo en paralelo con la etapa 4 - Ajustes al Modelo de Proceso en sus actividades finales. En un primer momento se estudiaron las ideas y conceptos que existen detrs de la Memoria Organizacional, para esto se realizo una extensa bsqueda en Internet y el estudio se bas principalmente en los documentos [SEKE99] y [PAKM98]. Una vez ledo este material se lleg a la conclusin que la implementacin de una Memoria Organizacional real escapaba al alcance de este Proyecto de Taller V, por lo que se opt por dejar la informacin referente a la experiencia del ao 2000 con el valor agregado de que fue clasificada, analizada, estructurada y est accesible en un Sitio Web. En la Seccin 8.2.1 se brinda el Marco Terico de esta etapa introduciendo los conceptos de Memoria Organizacional, Gestin del Conocimiento y Aprendizaje Organizacional. En la seccin 8.2.2 se detalla la Implementacin de la Memoria Organizacional realizada y en la seccin 8.2.3 se describen los objetivos abiertos que pueden ser retomados en el futuro.
8.2.1
Marco Terico En las siguientes secciones se describen los conceptos que hay detrs de la gestin del conocimiento, el aprendizaje organizacional y la memoria organizacional en una Organizacin de Software.
8.2.1.1 Gestin del Conocimiento La idea de gestin implica la organizacin, la planificacin, la direccin y para alcanzar ciertos objetivos. Al hablar de conocimiento se pone organizacin capta informacin, la reconoce, la organiza, la almacena, procurando un resultado. De esta manera, la gestin del conocimiento continua del conocimiento para desarrollar nuevos y diferentes procesos y organizacin. el control de procesos en manifiesto que la la analiza y la evala implica la explotacin productos dentro de la
El conocimiento se encuentra bsicamente en dos fuentes principales: los recursos humanos que intervienen (formacin, capacidades, cualidades personales, entre otras) y la informacin manejada, que capacita a estas personas para incrementar su formacin o habilidades para el desarrollo de sus tareas.
En la medida que la estructura de la Organizacin facilite la sincrona entre persona e informacin se crear un entorno de conocimiento. Este es uno de los objetivos esenciales de la gestin del conocimiento. El problema de la Organizacin consiste en consultar o acceder a la informacin y analizar esta informacin que se maneja, por ejemplo, en datos o bases de datos, documentos diversos tanto en formato como en procedencia o localizacin. La gestin del conocimiento es un proceso, el cual debe formar parte de las actividades cotidianas de la Organizacin. Para gestionar el conocimiento en la Ingeniera de software, se deben cubrir los siguientes aspectos: Apoyar el Ciclo de Vida de los Productos generados: Un sistema para la gestin de conocimiento debe brindar apoyo para el manejo de los productos a lo largo del ciclo de vida, desde su creacin, su mantenimiento, su reutilizacin y la retroalimentacin a partir del uso. Recuperacin basada en similitudes: La recuperacin de productos para la reutilizacin debe estar basada en similitudes, ya que no siempre el resultado de la consulta, dada la especificacin de los requerimientos de reutilizacin, se corresponde exactamente con los productos reusables recuperados. Esto es necesario para la reutilizacin del conocimiento debido a que las caractersticas de los distintos proyectos pueden variar mucho, por eso es deseable que los productos reusables ms relevantes sean caracterizados de forma que puedan ser recuperados para su reutilizacin. Recuperacin basada en informacin incompleta: Las consultas para la recuperacin de los productos a reutilizar no debe requerir de todos los atributos definidos para la consulta, esto es necesario debido a que la recuperacin de conocimiento se hace al comienzo de los proyectos, donde muchas de las caractersticas del proyecto no son conocidas an. Posibilidad de evolucionar la experiencia base: Se debe proporcionar la forma de sumar nuevos productos y agregar o quitar atributos de los productos existentes. Esto es necesario para soportar el aprendizaje y la mejora continua en la ingeniera del Software. Soportar distintos tipos de conocimiento: El conocimiento almacenado puede representarse con diferentes estructuras, diferentes accesos y procesos de uso, as como distintos niveles de madurez y confiabilidad. Representacin precisa de los productos: Los productos deben ser representados y almacenados usando una representacin precisa y formal, esto es necesario para clarificar la semntica del producto y permitir el uso y mantenimiento automatizado del conocimiento. Links entre los productos: Deben definirse los enlaces en forma explcita entre productos relacionados. Esto es necesario para explotar las relaciones durante el mantenimiento y la recuperacin. Requerimientos adicionales: Existen otros aspectos importantes para la realizacin tcnica de la gestin del conocimiento, como por ejemplo acceso a travs de Internet o una intranet, seguridad y acceso a la informacin. 2
"A Knowledge Managment Lifecycle for Experience Packages on software Engineering Technologies"
Birk, Kroschen [SEKE99]
8.2.1.2 Aprendizaje Organizacional Aprender de la experiencia en proyectos pasados es una forma de mejorar la calidad del software en nuevos proyectos. Esto puede implicar la reutilizacin de tcnicas, mtodos, herramientas, procesos, o mtricas usadas en otros proyectos. El aprendizaje no se limita slo a proyectos exitosos, las fallas especialmente las ocurridas en proyectos pasados deben ser cuidadosamente analizadas y documentadas para poder evitarlas en el futuro. Para poder reutilizar las experiencias pasadas stas deben ser recolectadas y almacenadas. Un ingrediente inicial clave para la introduccin de un mecanismo de aprendizaje organizacional en una Organizacin de Software es crear una base de conocimiento que contenga experiencias sobre el desarrollo de software que sta realiza. El enfoque de aprendizaje organizacional basado en el desarrollo de software recolecta informacin relacionada con el proyecto durante la creacin de productos individuales de software. Esta informacin puede ser luego diseminada hacia proyectos subsiguientes para proveer conocimiento basado en la experiencia relativo a temas del desarrollo encontrados en la Organizacin. Este conocimiento est dado por lecciones aprendidas, tips y tcnicas para desarrollar tareas especficas, cdigo reusable, entre otros. A medida que esta informacin se acumula en la base de conocimiento, el contenido se vuelve cada vez ms adaptable a los tipos de problemas que ocurren frecuentemente en la Organizacin, sirviendo no solo para la diseminacin del conocimiento adquirido, sino tambin para ayudar a la Organizacin en el aprendizaje sobre lo que funciona y lo que no funciona en su contexto de desarrollo. Aunque es deseable institucionalizar sistemticamente el conocimiento a medida que es generado por las personas en la Organizacin, este debe ser balanceado con procedimientos que controlen el contenido, estructura y validez de dicho conocimiento. Para alcanzar los beneficios del enfoque de aprendizaje organizacional, se deben proveer guas a las personas involucradas en la Organizacin, sobre el nivel y la calidad de la informacin que es necesario recolectar. El uso de un sistema de aprendizaje organizacional necesita ser formalizado en el sentido de que su utilizacin debe estar establecida en un proceso documentado que asegure que la informacin recolectada es la correcta. Este requerimiento debe ser balanceado cuidadosamente para no agregar tareas de documentacin a las ya existentes, pero la idea de que la base de conocimiento es una obligacin suplementaria con poco o ningn beneficio inmediato debe ser cambiada por mecanismos que hagan que sea un elemento central en la planificacin y documentacin de los proyectos de la Organizacin. Esto previene la duplicacin de esfuerzos y provee a los proyectos de un lugar donde coordinar y documentar su trabajo.3
8.2.1.3 Memoria Organizacional
El trmino Memoria describe un sistema que tiene la habilidad de almacenar lo que fue percibido o experimentado por un perodo de tiempo mayor al de la percepcin o la experiencia y que permite recuperar estas percepciones y experiencias una vez que el tiempo pas. El Aprendizaje no es posible sin una memoria. Los sistemas de Memoria Organizacional estn conectados al concepto de la Gestin del Conocimiento tratado en la seccin 8.2.1.1 ya que es el tipo de sistema utilizado para llegar al nivel de gestionar el conocimiento en la organizacin, tambin est conectado al concepto de Aprendizaje Organizacional tratado en la Seccin 8.2.1.2 pero la distincin con el Aprendizaje Organizacional es que en ste el foco est dado en el aprendizaje a partir de experiencias previas.
Using Software Process to support Learning Software Organizations S. Henninger [SEKE99]
Las principales funciones de un sistema para la Memoria Organizacional son: Dar soporte general a los procesos de aprendizaje dentro de la Organizacin ya sean individuales o colectivos. Divulgacin del conocimiento (por ejemplo, lecciones aprendidas, mejores prcticas, etc.) para que todos los miembros de la organizacin puedan utilizar el conocimiento en el contexto de sus actividades diarias. Esto reduce el costo de aprendizaje y ayuda a la adquisicin y produccin de nuevos conocimientos que a su vez agregan valor a la organizacin. Facilitar la efectiva y eficiente generacin de nuevo conocimiento (por ejemplo, actividades de Investigacin y desarrollo, aprendizaje a partir de casos histricos etc.) Apoyar la adquisicin de conocimiento de fuentes externas y desarrollar la capacidad de asimilarlo y utilizarlo. Asegurarse que el nuevo conocimiento est disponible para aquellas personas en la organizacin que realizan actividades basadas en ese nuevo conocimiento (por ejemplo, distribucin de las lecciones aprendidas). 4
8.2.2
Implementacin de la Memoria Organizacional La implementacin de la Memoria Organizacional realizada est restringida por el alcance del Proyecto de Taller V en cuanto a que no estaba previsto el desarrollo de una herramienta para gestionar el conocimiento adquirido de la aplicacin del Modelo de Proceso en el curso 2000. La construccin de una herramienta con este objetivo es una tarea no trivial que involucra distintas actividades como se mencion en la Seccin 8.2.1 Marco Terico. Se consider que la principal carencia que tena la organizacin era no contar con ningn tipo de memoria, a no ser la que se encontraba en los docentes. En este sentido se identificaron las fuentes de conocimiento con que se cuenta hasta el momento: Los cuestionarios realizados a los grupos que cursaron Taller IV en 1999 El plan de Trabajo seguido en 1999 El Modelo de Proceso seguido en el 2000 Los entregables de los grupos en el 2000 Las Auditorias realizadas a los grupos en el 2000 Los cuestionarios finales realizados a los grupos en el 2000 Los cuestionarios finales realizados a los Directores de Proyecto en el 2000 Las mediciones de los Proyectos del 2000 La evaluacin del Modelo de Proceso seguido en el 2000 El Modelo de Proceso Ajustado Se consider que era de suma importancia que esta informacin estuviera disponible en la Organizacin de forma que pueda ser utilizada por los integrantes de la misma, y que adems pudiera almacenarse en forma estructurada para sentar las bases de un Sistema de Memoria Organizacional. En base a esto, la implementacin de la Memoria Organizacional se compone de un Sitio Web y una Base de Datos relacional. La informacin en el Sitio Web de acceso pblico podr ser consultada por los integrantes de la Organizacin, en este caso los estudiantes que realicen en el ao 2001 el Proyecto de Ingeniera de Software y los docentes de la asignatura. La implementacin y organizacin de este sitio se describe en la seccin 8.2.2.1 de este documento. En la Base de Datos relacional se encuentra gran parte de la informacin que fue posible estructurar, su implementacin y utilizacin se detalla en la seccin 8.2.2.2 de este documento.
Organisational Memory Systems Lehner, Maier, Klosa [PAKM98]
8.2.2.1 Sitio Web En el URL http://www.fing.edu.uy/~t5ingsw se encuentra disponible la informacin de la Memoria implementada para la Organizacin. El sitio se basa en el Proyecto Web que Rational Unified Process (RUP) brinda en su pgina para ser utilizado en forma libre y adaptarlo al Proceso seguido en la Organizacin. Rational Unified Process trae las indicaciones de cmo crear y mantener el sitio Web. Se puede acceder a los distintos contenidos del sitio mediante un TreeBrowser que es un applet que despliega una estructura de directorios similar a la mostrada en el Explorador de Windows. La adaptacin del sitio web realizada organiza el TreeBrowser como se muestra en el documento de Descripcin de la implementacin de la Memoria Organizacional [MOINGSW01].
8.2.2.2 Base de Datos relacional Se modela el conocimiento de la Organizacin mediante una base de datos relacional. Su implementacin se realiza como un Prototipo en ACCESS, ingresando los datos a las tablas y realizando consultas sobre la Base de Datos mediante las Tablas Dinmicas de EXCEL. La informacin obtenida en estas consultas fue una de las fuentes bsicas para realizar las Modificaciones al Modelo de Proceso. La informacin referente a la descripcin de las Tablas de la Base de Datos se encuentra en el documento de Descripcin de la implementacin de la Memoria Organizacional [MOINGSW01].
8.2.3
Pasos a seguir en la Memoria Organizacional Para la mejora continua de la gestin del conocimiento es de gran importancia la retroalimentacin de los usuarios de la Memoria Organizacional y ste debe ser un objetivo en la Organizacin. Debe existir una forma de recuperar, modificar, agregar y analizar la informacin almacenada y la que se genera durante el desarrollo de los proyectos. La base para esto es un sistema de informacin, stos han sido objeto de varias investigaciones, pero la estrategia para utilizarlo o integrarlo en el proceso de desarrollo ha estado limitada a la provisin de facilidades de bsqueda para la recuperacin de informacin relevante. Mientras los motores de bsqueda han sido una parte integral en el diseo de estos sistemas de informacin, existen experiencias que demuestran que esto es insuficiente para la obtencin de resultados satisfactorios. En este sentido, se han realizado investigaciones sobre como el proceso de desarrollo de software puede ser utilizado como base para la recoleccin y diseminacin del conocimiento sobre el desarrollo de software. En estos aspectos no se pudo profundizar y creemos que la Organizacin debe investigar para poder gestionar el conocimiento mediante una Memoria Organizacional real. A continuacin se detallan los puntos que quedan abiertos y una primera aproximacin para resolverlos, como una mejora inicial hacia la construccin de una Memoria Organizacional real. Un primer punto es pasar la Base de Datos realizada como un prototipo en ACCESS a algn DBMS que se encuentre disponible en la Organizacin, por ejemplo Informix. Un segundo punto es realizar una aplicacin que permita tomar los datos generados desde el DBMS, permitiendo realizar consultas, su representacin grfica, comparacin y eventual anlisis. Incluso, estas consultas deberan poder ser generadas bajo demanda a travs de un Web Browser en tiempo real. Un tercer punto se basa en que para poder Gestionar el Conocimiento, se debe permitir la generacin del conocimiento. En la seccin 8.2.2 - Implementacin de la Memoria Organizacional, se trabaja sobre las visiones de las personas involucradas pero acerca de los tpicos sobre los que les fueron consultados. Una persona trabajando en un proyecto puede tener conocimiento que brindar en cualquier momento de su desarrollo por lo que es importante establecer la forma de adquirir ese
conocimiento y procedimientos que controlen su contenido, estructura y validez, as como desarrollar la capacidad de asimilarlo y utilizarlo. Este punto es muy ambicioso y requiere de investigacin.
8.3
Los resultados de esta etapa se evalan como positivos ya que se lograron sentar las bases para una Memoria en la Organizacin. Esta Memoria se implementa por medio de una Base de Datos relacional y un Sitio Web que contiene el conocimiento adquirido durante el desarrollo de este Proyecto de Taller V. Esto es un primer paso en la construccin de la Memoria Organizacional ya que en base a la investigacin realizada se lleg a la conclusin de que la implementacin de una Memoria Organizacional real escapa al alcance de este Proyecto de Taller V. La informacin referente a la experiencia del ao 2000 tiene el valor agregado de que fue clasificada, analizada, estructurada y est accesible en un Sitio Web, donde se encuentran disponibles por semana, grupo y lnea de Trabajo los productos generados durante la aplicacin del Modelo de Proceso. Como esta etapa era exploratoria, se describen los objetivos abiertos que pueden ser retomados en el futuro para mejorar la Memoria Organizacional primaria que se implement. Se considera que los objetivos principales de la etapa fueron cumplidos, si bien la duracin prevista para su desarrollo debi ser extendida, se entiende que esta decisin fue acertada ya que los resultados de esta etapa sern de vital importancia para la aplicacin del proceso de software en los siguientes cursos de la asignatura PINGSW97.
EVALUACIN Y CONCLUSIONES
En este Captulo se realiza la Evaluacin del desarrollo de este Proyecto de Taller V la cual se detalla en la Seccin 9.1 y luego se plantean las Conclusiones del Proyecto en la Seccin 9.2.
9.1
Evaluacin
Esta evaluacin ser realizada tomando como referencia lo establecido en la Definicin de este Proyecto en la Seccin 2.3.2 - Productos a obtener, indicando en cada caso las principales caractersticas del producto logrado. Un primer producto a obtener era la recopilacin de lecciones aprendidas a partir de la experiencia del ao 1999 y la definicin de un mecanismo para registrarlas. Cumplimos con este objetivo y las lecciones aprendidas fueron registradas en cuestionarios y entrevistas realizadas a estudiantes del curso 1999. Uno de los productos ms importantes, sino el principal, que se deba obtener esta dado por la primer versin del proceso de software el cual se gener con el nombre de Modelo de Proceso. Creemos que este producto cumple con sus principales objetivos y requerimientos planteados en cuanto al contenido pedido, en particular los requerimientos mnimos exigidos estaban identificados como: identificacin de los distintos roles que participan en el proceso definicin de los subprocesos con el flujo de trabajo correspondiente definido en UML definicin de entregables indicando Contenido, un Ejemplo y una Plantilla las actividades necesarias para generarlos entregables precisando las condiciones que se deben cumplir para poder iniciarla, los elementos de entrada, los de salida y los criterios para darla por terminada, los roles que participan y el tipo de responsabilidad. definicin de procedimientos para algunos procesos claves que incluyan la utilizacin de herramientas elementales, en particular e-mail y pginas web.
El Modelo de Proceso definido incluye el detalle de Actividades en cada Lnea de Trabajo necesarias para generar los Entregables establecidos, y en cada una se indican las condiciones de entrada, salida y terminacin y se brinda una descripcin de como debe realizarse, indicando los roles participantes y su responsabilidad asociada. Se presenta la descripcin de roles y roles combinados definidos. Se incluyen las especificaciones en UML de los flujos y subflujos de actividades necesarios por Lnea de Trabajo y Actividad. Se estableci la Agenda de Actividades y la Agenda de Entregables del Modelo de Proceso, donde se indica por Fase, iteracin y semana la realizacin de Actividades y los Entregables asociados. No pudimos incluir las plantillas ni los ejemplos indicados por una razn de tiempo ya que el Modelo de Proceso definido deba ser presentado a los grupos que cursaban la asignatura PINGSW97 al comienzo del segundo semestre de 2000. El siguiente producto que deba generarse se refiere a la evaluacin del proceso a partir de la experiencia de su adopcin por parte de los grupos en el curso 2000. Esta evaluacin deba realizarse en base al seguimiento de los grupos, el cual creemos que fue realizado en forma satisfactoria en las primeras etapas del mismo, esto es hasta la segunda iteracin de la Fase de Elaboracin, momento en el cual se cortaron las actividades de los proyectos debido a la Huelga Universitaria por Presupuesto. De todas formas, la informacin que finalmente se obtuvo a partir de este seguimiento consideramos que es de gran valor para la Organizacin y se encuentra accesible en el Sitio Web que forma parte de la implementacin de la Memoria Organizacional definida. Esta informacin tiene como valor agregado que fue clasificada, analizada, estructurada y est disponible para fomentar el aprendizaje organizacional.
El objetivo de definicin de criterios para evaluar la calidad de los Productos no pudo cumplirse ya que debido a la limitacin de disponibilidad de quin desempe el rol de Cliente en esta instancia, se acord con el Tutor del Proyecto dejar de lado la definicin de los criterios de evaluacin de los productos por resultar imposible contrastarlos con la visin del destinatario del producto y para evitar que slo se tomaran en cuenta los aspectos estrictamente tcnicos. El ltimo producto a obtener era la versin ajustada del proceso a partir de su evaluacin, el cual se gener con el nombre de Modelo de Proceso Ajustado. Este producto es una versin mejorada del que fue aplicado en el curso 2000, en el cual se mantienen las caractersticas que evaluamos como positivas e incluimos las modificaciones que consideramos convenientes en base a la informacin analizada. Un punto que se evalu pero que finalmente no fue incluido es la definicin de ejemplos para los Entregables el cual queda planteado como un punto a mejorar. En esta nueva versin del Modelo de proceso, incluimos caractersticas que consideramos facilitarn su aplicacin en futuros proyectos. Entre stas se pueden destacar el agregado de plantillas para los Entregables de todas las Lneas de Trabajo que lo integran, un documento de Introduccin al Modelo donde se brinda una visin general de los conceptos claves que lo definen, un documento sobre las modificaciones realizadas y propuestas, y el Sitio Web donde se integran todos los productos generados en este Proyecto, el cual forma parte de la Memoria Organizacional implementada. Creemos que el objetivo principal definido para este Proyecto que es contar con un proceso definido, validado y ajustado que pueda ser utilizado como base para un proceso de mejora continua de los proyectos de enseanza de Ingeniera de Software, ha sido cumplido.
9.2
Conclusiones
La eleccin del Proyecto fue acertada ya que nos sentimos muy a gusto realizndolo y creemos que pudimos articular los cometidos de las distintas partes que deban trabajar en conjunto. stas estaban dadas por los grupos que seguan el Modelo y deban obtener un Producto, los Directores de Proyecto que deban evaluarlos, nuestro inters en que el Modelo fuera seguido y nuestro Tutor que deba supervisar el desarrollo de nuestro Proyecto de Taller V y del curso de Ingeniera de Software. Evaluamos en forma positiva el haber trabajado en contacto con los grupos participantes, con los cuales se estableci una buena relacin y se dio un apoyo mutuo tanto para la realizacin de las tareas de los proyectos por parte de los grupos como de las actividades de seguimiento y Auditorias que realizamos las cuales fueron evaluadas positivamente tanto por los grupos como por los docentes. De la misma forma, el contacto con los docentes del curso fue una experiencia positiva y muy enriquecedora para nuestro aprendizaje. Como experiencia personal se puede destacar que aprendimos lo difcil que resulta para una Organizacin desde el punto de vista humano la adopcin de un proceso de software pautado y del tiempo que debe ser invertido en capacitacin y en su incorporacin a las actividades cotidianas. Es por esto que creemos que la decisin de extender el tiempo de duracin de la etapa de Bases para la Memoria Organizacional fue acertada, ya que se logr sentar el punto de partida para un proceso de mejora continua en la Organizacin, al brindar fcil acceso a la informacin que se encuentra disponible en el Sitio Web diseado. De todas formas creemos que la Organizacin debe avanzar en la incorporacin de procedimientos para su utilizacin y mantenimiento. La posibilidad de haber investigado en temas como el modelado de procesos de software, procesos de mejora continua y Memoria Organizacional para su puesta en prctica en un curso de la Carrera de Ingeniera en Computacin result un desafo que creemos haber cumplido satisfactoriamente. En base a lo anterior consideramos que el alcance de nuestro Proyecto fue cubierto y que logramos aportar a la construccin del primer escaln en los objetivos de mejora que se plantea la Organizacin.

Informe Final Andrea&amp;Beatriz

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Informe Final Andrea&amp;Beatriz

Enviado por

Direitos autorais:

Formatos disponíveis

Proyecto de Taller V: Modelado del Proceso de Software de aplicacin en la asignatura Proyecto de Ingeniera de Software

INFORME FINAL PROYECTO DE TALLER V:

4.1 OBJETIVOS 4.2 DESARROLLO 4.2.1 ESTUDIO DE MATERIALES

RECOPILACIN DE LECCIONES APRENDIDAS DEL CURSO DE TALLER IV AO 1999

RESULTADOS Y CONCLUSIONES SEGUNDA ETAPA DEFINICIN DEL PROCESO

TERCER ETAPA PRUEBAS DEL PROCESO

RESULTADOS Y CONCLUSIONES CUARTA ETAPA AJUSTES AL PROCESO

RESULTADOS Y CONCLUSIONES QUINTA ETAPA BASES PARA LA MEMORIA ORGANIZACIONAL

8.1 OBJETIVO 8.2 DESARROLLO 8.2.1 MARCO TERICO

IMPLEMENTACIN DE LA MEMORIA ORGANIZACIONAL

UML Unified Modeling Language WFMC - WorkFlow Management Coalition http://www.wfmc.org.

1991, ISBN 0-13-820432-2, edicin en Ingls.

Wesley Longman, Inc., 1999, ISBN 0-201-57169-2, edicin en Ingls.

revisada en 1997), ISBN 0-201-54-597-7, edicin en Ingls.

www.map.es/csi/metrica3 ltimo acceso abril 2001

Computacin (IN.CO.)-Facultad de Ingeniera-Universidad de la Repblica, 1999.

www.rspa.com/apm ltimo acceso mayo 2001

http://www.rational.com - http://www.rational.com/products/rup/resource_center ltimo acceso abril 2001

http://www.iese.fhg.de/SEKE99/documents/workshop.html ltimo acceso diciembre 2000

PRESENTACIN DEL PROYECTO

DESARROLLO DEL PROYECTO

Etapas del Proyecto

Meses del ao 2000

Tabla 1 Cronograma previsto para el desarrollo del Proyecto

Etapas del Proyecto

Meses del ao 2000 y 2001

Tabla 2 Cronograma real del desarrollo del Proyecto

Etapas del desarrollo del Proyecto

PRIMERA ETAPA - ESTUDIO Y RECOPILACIN

4.2.1.1 Capability Maturity Model (CMM)

4.2.1.2 Software Process Improvement and Capability Determination (SPICE)

La dimensin de los procesos

4.2.1.3 The Unified Software Development Process

4.2.1.5 Plan de Actividades del curso de Taller IV ao 1999

SEGUNDA ETAPA DEFINICIN DEL PROCESO

TERCER ETAPA PRUEBAS DEL PROCESO

GRUPO 1 12 1 2 2 4 1 1 1 Rodolfo Paiz

GRUPO 2 11 1 3 1 3 1 1 1 Ral Ruggia

GRUPO 3 12 1 2 2 4 1 1 1 Jorge Trianes

Auditoras de Lnea Base de la Arquitectura

Cuestionario para Analistas y Arquitecto

Cuestionario para Implementadores

Cuestionario para Responsables de Verificacin

Cuestionario para Responsables de Calidad

Cuestionario para Analistas y Arquitecto

Cuestionario para Implementadores

Cuestionario para Responsables de Verificacin

Seccin Seccin Seccin Seccin

Cuestionario para Responsables de Calidad

Cuestionario para Analistas/Implementadores

Cuestionario para Analistas/Documentador de Usuario/Asistente de Verificacin

Cuestionario para Arquitecto/Asistente de Verificacin

Cuestionario para Especialiastas Tcnicos/Implementadores

Cuestionario para Responsables de Verificacin

Cuestionario para Responsables de SCM/Responsables de SQA

Cuestionario para Administradores

Seccin Seccin Seccin Seccin Seccin Seccin

Sobre Sobre Sobre Sobre Sobre Sobre

CUARTA ETAPA AJUSTES AL PROCESO

Se propone una nueva combinacin de roles, en base a un proyecto de 10 personas:

Cambios en Gestin del Proyecto

7.2.2.4 Definicin de Plantillas para los Entregables

QUINTA ETAPA BASES PARA LA MEMORIA ORGANIZACIONAL

8.2.1.3 Memoria Organizacional

Informe Final Andrea&Beatriz

Informe Final Andrea&Beatriz