Actividad: Determinar tipo de requerimiento |
Entradas: N. A. |
Salidas: N. A. |
Actores Involucrados: Jefe de Proyecto |
Descripción: De esta decisión pueden surgir dos alternativas: 1.- El requerimiento es un Cambio de Requerimiento. El requerimiento es una modificación, corrección o simplemente la eliminación de un requerimiento que pertenece a la Línea Base vigente y aprobada. 2.- El requerimiento es un Requerimiento Nuevo. El requerimiento no ha sido analizado antes, por lo tanto es necesario hacer su estudio detallado. |
Actividad: Ingresar Información del Proyecto y del requerimiento |
Entradas: N. A. |
Salidas: Registro de Requerimientos. |
Actores Involucrados: Jefe de Proyecto |
Descripción: La información de cada requerimiento incluye: Fecha: Fecha en que se realiza este plan. ID Proyecto: Identificación del proyecto. Nombre Proyecto: Nombre completo del proyecto. Responsable GR: Nombre de la persona responsable de la Administración de los Requerimientos. Fase: Número de la fase del mismo proyecto. Se genera un nuevo encabezado por cada fase del mismo proyecto. ID LB: Identificación de la Línea Base vigente de la fase y el proyecto Fecha inicio LB: Fecha planificada del comienzo de esta fase, aprobada por CM. Si está en blanco implica que aun no está definida. Fecha aprobación LB: Fecha de aprobación de LB utilizada cuando hay cambio de LB debido a Control de Cambios, si está en blanco implica que aún no se ha modificado la Línea Base inicial. Se actualiza además el estado del requerimiento como "Ingresado". El Registro de Requerimientos se realiza en el software Enterprise Architect[3]. |
Actividad: Completar o adaptar requerimientos predefinidos según aplican al proyecto |
Entradas: Glosario y Ayuda. 2.7 Forma de llenado del Registro de Requerimientos |
Salidas: Registro de Requerimientos |
Actores Involucrados: Jefe de Proyecto |
Descripción: En base a la forma de llenado de los requerimientos en el Enterprise Architect se actualiza los datos en el sistema, agregando a su vez mayor detalle a cada uno, dependiendo del proyecto y del requerimiento en sí. |
Si existe un control de cambios en algún requerimiento se activa esta actividad, que se modela en la Figura 14
Figura 14: Control de Cambios
Actividad: Evaluar Control de Cambios |
Entradas: Antecedentes Asociados al control de cambio, Registro de Requerimiento |
Salidas: Registro de Requerimiento |
Actores Involucrados: Jefe de Proyecto, Gerente de Proyecto |
Descripción (Ver Figura 15):
Figura 15: Evaluar Control de Cambios El objetivo de esta actividad es evaluar un control de cambios desde el punto de vista de su complejidad para ser implementado. El proceso se inicia registrando la incidencia de realizar el cambio. Si son varios los cambios involucrados en la misma solicitud se debe sumar todo lo que está contenido en ella. Para estimar el esfuerzo se recomienda considerar al menos los siguientes aspectos: – Cantidad de cambios incluidos en la solicitud. – Complejidad en cuanto a si los requerimientos afectan pocas o muchas áreas del proyecto, en cuanto a funciones y a áreas de desarrollo y producción involucradas (cliente, usuarios, ambiente de desarrollo, explotación) - Fase del proyecto en que llega el requerimiento. A mayor avance del proyecto puede ser más complejo incorporar un cambio. Los niveles de complejidad del cambio son tres: Complejo, Medio y Simple. Se define que un cambio es de nivel complejo si se encuentra en alguna de las siguientes situaciones: – El número de cambios a los requerimientos es mayor que cinco. – Es necesario un cambio importante en el diseño. – El esfuerzo para implementar el cambio es superior a dos días. Se define que un cambio de nivel Medio cuando no es Complejo, pero si requiere análisis o especificación detallada durante su ejecución. Se define que un cambio es de nivel Simple si no cumple con la definición de nivel Complejo y el detalle de la especificación se puede realizar durante la especificación inicial del cambio y no requiere análisis o especificación durante su ejecución. El alcance del cambio es acotado y sin ambigüedades. Luego de determinar el nivel de complejidad del cambio se da a conocer al Gerente de Proyecto, y es éste quien decide si realizar o declinar el Análisis de Impacto para un control de cambio. Las opciones que tiene son aprobar, rechazar o postergar el análisis de impacto del cambio, dependiendo del estado del proyecto, de la disponibilidad inmediata de recursos, de la criticidad del cambio o algún otro criterio aplicable para la decisión. En caso de aprobar el análisis de impacto, se definirá también la conveniencia de aplicar el Proceso Formal de Toma de Decisiones dependiendo de la magnitud de los cambios y los riesgos que se visualicen para los objetivos del proyecto. Tomada la decisión se actualiza el estado del requerimiento como Aprobado, Rechazado, Postergado según corresponda. El proceso finaliza al designar un responsable de la incidencia en base a las competencias y disponibilidades existentes. |
Actividad: Analizar Control de Cambios |
Entradas: Antecedentes asociados al Control de Cambios, Registro de Requerimientos |
Salidas: Registro de Requerimientos, Carta Gantt |
Actores Involucrados: Jefe de Proyecto, Analista |
Descripción (ver Figura 16):
Figura 16: Analizar Control de Cambios El objetivo general de esta actividad es analizar en profundidad el alcance de un cambio solicitado, para efectos de estimar el esfuerzo y costos necesarios para implementarlo, así como evaluar los riesgos asociados En base a la decisión tomada en el paso anterior, que depende de la magnitud de los cambios y los riesgos que se visualicen para el cumplimiento de los objetivos del proyecto, se realiza un Proceso Formal de Toma de Decisiones (basado en el área de proceso DAR del modelo CMMI) o se procede como se describirá a continuación. El Analista a cargo del Control de Cambio determinará la necesidad de planificar actividades específicas dependiendo de la complejidad del cambio analizada en la etapa anterior. Esta complejidad determinará también la necesidad de ejecutar las actividades venideras. El Jefe de Proyecto debe actualizar la carta Gantt del proyecto registrando cambios en los cronogramas de las actividades debido al cambio. Se debiesen identificar todos los objetos afectados por el cambio, seleccionar a las personas idóneas para resolver el cambio, definir cuáles serán los artefactos que generará el implementar el cambio e identificar también las eventuales inconsistencias con la solución ya definida que provocará el cambio. Con todas estas actividades resueltas ya se podría actualizar el detalle del control de cambio con su estado, como a su vez mantener un historial y actualizar la trazabilidad de requerimientos. |
Actividad: Calcular tamaño y esfuerzo según metodología y tailoring seleccionados para cada disciplina de la ingeniería. |
Entradas: Work Breakdown Structure (WBS). |
Salidas: Work Breakdown Structure (WBS), Estimación de Esfuerzo, Estimación de Costo. |
Actores Involucrados: Equipo responsable de estimar tamaño, esfuerzo, costos y plazos del proyecto. |
Descripción (Ver Figura 17): El objetivo de esta actividad es efectuar estimaciones de tamaño, esfuerzo y costos del proyecto, de acuerdo a la metodología seleccionada, a datos históricos y supuestos. Se debiesen considerar datos históricos acumulados para ajustar supuestos y validar resultados de estimaciones. Se debiese también fundamentar el uso de estos datos históricos seleccionados para las estimaciones y se debe mantener consistencia en los nombres usados en el Registro de Requerimientos en EA para asegurar trazabilidad. Todas las estimaciones e identificaciones, tamaño, esfuerzo y costo principalmente, deben ser actualizadas en el Work Breakdown Structure (WBS).
Figura 17: Calcular tamaño y esfuerzo según metodología y tailoring seleccionados para cada disciplina de la ingeniería |
Actividad: Ingresar cubicación y evaluar compromisos |
Entradas: Resultado de Cubicación |
Salidas: Registro de Requerimientos, Informe de Control de Cambios al Cliente |
Actores Involucrados: Ejecutivo Comercial, Jefe de Proyecto |
Descripción (Ver Figura 18):
Figura 18: Ingresar cubicación y evaluar compromisos El objetivo de esta actividad es adoptar una posición definitiva ante el cambio solicitado y formalizar la respuesta al cliente. Luego de actualizar la información de esfuerzo y costo correspondiente al requerimiento tratado, se procede a revisar, sobre la base del análisis de impacto realizado y el estado actual del proyecto, los compromisos que deben asumirse por el proyecto para implementar el cambio solicitado. Si no se realiza un cambio por desaprobación del cliente se elabora una propuesta alternativa y se informa al cliente para conseguir la aprobación formal por parte del cliente. Si el cambio es realizado se debe generar la propuesta comercial para el cliente cuando corresponda, y crear una carta de aprobación formal para el cambio, que debe ser enviada al cliente para su aprobación. |
Actividad: Formalizar implementación |
Entradas: Informe de Control de Cambios al Cliente, Carta de Respuesta |
Salidas: N. A. |
Actores Involucrados: Cliente, Jefe de Proyecto |
Descripción (Ver Figura 19)
Figura 19: Formalizar implementación El objetivo de esta actividad es formalizar la implementación del Control de Cambios a un requerimiento. La información del informe de control de cambios preparado para el cliente y la carta de respuesta enviada al Cliente es revisada por éste para su aprobación. Cuando el cambio es aprobado por el cliente se gestionan las líneas bases del proyecto, tanto las correspondientes a los requerimientos como a las de planificación y de entregables. Junto con ello se actualizan los artefactos de gestión que correspondan, de acuerdo a las características e impacto del cambio aprobado y considerando al menos los siguientes: Carta Gantt, Plan de Riesgos, Cálculo de Esfuerzo, WBS y Plan de Proyecto. Finalmente se debe comunicar a todas las partes interesadas el alcance del control de cambios, llámense equipo de proyecto, equipo de pruebas, de aseguramiento de la calidad y de administración de la configuración. Si el cambio no es aceptado por el cliente, se debe escalar el caso al nivel de jefatura correspondiente, ajustando estimaciones de esfuerzo y costos y replanteando las estrategias. |
Luego de atacar algún posible cambio a los requerimientos se realiza la Revisión de Pares, otro de los procesos de apoyo a la metodología de desarrollo de ORDEN Integración que será detallado como proceso aparte más adelante en este documento.
Realizada la Revisión de Pares, se ejecuta la actividad modelada con el diagrama que ya fue presentada y detallada en la Figura 17, para poder realizar estimaciones de tamaño, esfuerzo y costos del proyecto de acuerdo a la metodología seleccionada (típicamente la que se está presentando en este documento), de acuerdo a datos históricos de la organización y a supuestos del proyecto.
Con los datos de las estimaciones de tamaño, esfuerzo y costos se realiza la actividad Ingresar cubicación y comunicar Requerimiento cuyo diagrama se presenta en la Figura 20
Figura 20: Ingresar cubicación y comunicar Requerimiento
Actividad: Planificación |
Entradas: N. A. |
Salidas: N. A. |
Actores Involucrados: Jefe de Proyecto |
Descripción: La planificación realizada para cada requerimiento entrega como resultado las estimaciones de su costo, esfuerzo y tamaño. |
Actividad: Incorporar información de esfuerzo al requerimiento que corresponda |
Entradas: |
Salidas: Registro de Requerimientos |
Actores Involucrados: Jefe de Proyecto |
Descripción: Los datos de cubicación, llámense estimaciones de esfuerzo, tamaño y costo principalmente, son incorporadas al requerimiento correspondiente, siendo a su vez actualizadas en la herramienta Enterprise Architect. |
Actividad: Recopilar información de requerimientos |
Entradas: xxx.PPPYE.Productos y Entregables.xls, xxx.PDP.Plan de Proyecto.doc, xxx.PPCDE.Calculo de Esfuerzo.xls, xxx.PPPAR.Plan Administración de Riesgos.xls |
Salidas: N. A. |
Actores Involucrados: Jefe de Proyecto |
Descripción: Se recopila la información almacenada de los requerimientos en base a las planillas y documentos generadas y al registro de requerimientos almacenado en Enterprise Architect |
Actividad: Enviar Documentación a grupos involucrados |
Entradas: N. A. |
Salidas: QA,CM, Testing, Gerente Proyectos, otros roles identificados. |
Actores Involucrados: Jefe de Proyecto |
Descripción: La información de los requerimientos se envía a las partes involucradas en el desarrollo del proyecto. |
La Revisión de Pares es un técnica de testing estático definido como un proceso metódico, formal y estructurado en el cual se examina un producto intermedio o final, con el propósito de encontrar y corregir defectos en forma temprana, e incluso identificar eventualmente cambios requeridos para optimizar el funcionamiento de un sistema. Esta revisión puede ser conducida por un par o un equipo de pares del autor del producto con roles y tareas específicas.
El proceso consiste en someter un producto de trabajo al escrutinio de uno o más profesionales con un nivel de conocimiento y experiencia equivalente al del autor del artefacto, de tal manera de poder evaluar objetivamente su contenido, detectar eventuales falencias y proponer medidas correctivas. Ejemplos de interlocutores válidos para la revisión de pares pueden ser un jefe de proyecto, un arquitecto de software, un desarrollador u otro rol dependiendo de las características del artefacto seleccionado.
El proceso de revisión de pares consta de dos actividades como se puede apreciar en la Figura 21
Figura 21: Revisión de Pares
Actividad: Preparar revisión de pares | |
Entradas: Checklist de Revisión de Pares, Producto de trabajo a revisar | |
Salidas: N. A. | |
Actores Involucrados: Jefe de Proyecto, Revisor, Autor del producto a revisar | |
Descripción (Ver Figura 22):
Figura 22: Preparar revisión de pares El objetivo de esta actividad es efectuar las actividades preparatorias y generar las condiciones para una revisión de pares. El criterio de entrada es cuando corresponda examinar un artefacto del proyecto con esta técnica. En principio de debe convocar al autor del producto a revisar y al revisor designado a una reunión y en ella se deben exponer brevemente las características del producto a ser revisado y se acuerdan criterios básicos para realizar la revisión de pares, según las características del proyecto y del producto. Algunas de las características que se deben definir son: Criterios de entrada y salida, Reglas de proceso, Plazos de la revisión. Luego de esto se procede a actualizar el checklist de la Revisión de Pares con las definiciones realizadas. El autor debe seleccionar el material de apoyo que se le proveerá al revisor dependiendo del producto de trabajo a revisar y de las definiciones surgidas de la reunión de coordinación y finalmente debe enviar el producto a ser verificado junto con sus antecedentes asociados y cualquier material de apoyo útil para realizar la revisión. | |
Actividad: Ejecutar Revisión de Pares | |
Entradas: Checklist de Revisión de Pares, Producto de trabajo a revisar | |
Salidas: Informe de observaciones | |
Actores Involucrados: Jefe de Proyecto, Revisor(es), Autor(es) | |
Descripción (Ver Figura 23):
Figura 23: Ejecutar Revisión de Pares El objetivo de esta actividad es ejecutar una revisión de pares en el momento en que un revisor ha recibido conforme el artefacto a revisar junto con todo su material de apoyo. Esta actividad comienza verificando que existan las condiciones para efectuar la Revisión de Pares, en cuanto a disponibilidad de artefactos y documentación asociada según los acuerdos alcanzados en la reunión preparatoria. Luego se realiza la revisión del artefacto según la checklist, la aplicación de la metodología y los antecedentes asociados, registrando los defectos encontrados en el Reporte de Observaciones y registrando además el tiempo dedicado a la revisión. Paso siguiente es convocar a reunión al Jefe de Proyecto y al Autor o Autores del artefacto con el objetivo de analizar las observaciones encontradas, unificar criterios, determinar los defectos definitivos, registrarlos en el reporte y de ser necesario definir plazos para nueva revisión. El autor debe responder a las observaciones mencionadas y aclarar los temas que sean necesarios. Si la respuesta satisface al equipo revisor, el problema no se registra. El Jefe de Proyecto registra el resultado de la reunión y entrega al Autor y Equipo Revisor sus conclusiones. Además se debe determinar si las modificaciones requeridas ameritan una nueva revisión de pares; si es así, se planifica una nueva reunión. También se deben registrar métricas asociadas, como lo son esfuerzo, cantidad de defectos encontrados, cantidad de revisión de pares por producto, etc. Luego se debe planificar la incorporación de las correcciones requeridas al artefacto revisado, ingresando los defectos válidos como eventos no planificados. Hecha la planificación, se realizan las modificaciones solicitadas y en base a estas se realiza la evaluación y validación a estas correcciones para determinar si estas corrigen los defectos encontrados en la revisión, para en consecuencia definir si el producto cumple con los criterios de salida definidos, de manera de dar por finalizada la Revisión de Pares. Si las modificaciones no son satisfactorias, se efectúan nuevamente las modificaciones solicitadas hasta que cumplan con los criterios de salida. La revisión de pares culmina con la recolección de métricas generadas en cada una de las etapas del proceso, con la incorporación de nuevas métricas y con la generación de resultados en el informe consolidado del proceso. Se debe verificar que la Revisión de Pares se haya aplicado sobre el producto definido, que los reportes generados se hayan completado, que los productos y métricas hayan sido actualizados según lo acordado, que se haya consolidado y archivado la documentación del proceso. | |
Este proceso tiene por objetivo asegurar que el producto cumple con lo esperado y con los requerimientos definidos. Es un proceso que es transversal a todo el ciclo de vida del proyecto y presenta las siguientes políticas:
La planificación, coordinación y ejecución de pruebas es responsabilidad de la Unidad de Control de Calidad.
Las pruebas son ejecutadas de acuerdo al contenido del Plan de Pruebas de cada proyecto.
Se generan reportes con observaciones y las acciones correctivas son planificadas y controladas.
Todos los productos de software desarrollados en ORDEN Integración son sometidos a Control de Calidad.
La Unidad de Control de Calidad, perteneciente a la PMO, es la instancia encargada de llevar a cabo la verificación del software generado, como resultado de un proyecto de desarrollo, mediante realización de pruebas de diversos tipos. Para tal efecto cada proyecto cuenta con un responsable de dicha unidad, el cual responde por el diseño, planificación y ejecución de las pruebas así como de reportar el resultado de las pruebas al Jefe de Proyecto. La Unidad de Control de Calidad representa una función de apoyo a los proyecto de desarrollo y administra sus actividades como un proyecto independiente, aplicando las prácticas de gestión de proyectos, a saber:
Administración de Requerimientos
Planificación de Proyectos
Control y Seguimiento
Aseguramiento de calidad
Administración de la Configuración
El Proceso de Pruebas de Software se divide en dos actividades o subprocesos que se ejecutan de manera secuencial, las cuales son Preparar Pruebas y Ejecutar Pruebas (ver Figura 24)
Figura 24: Pruebas de Software
Actividad: Preparar Pruebas |
Entradas: Bases de Licitación, Registro de Requerimientos, Informe de Diseño, Metodologías de prueba de software. |
Salidas: Casos de Prueba, Datos de Prueba, Definición de ambientes de prueba, Plan de Pruebas. |
Actores Involucrados: Responsable de Pruebas de Software, Jefe de Proyecto |
Descripción (Ver Figura 25): Esta actividad o proceso tiene como objetivo efectuar actividades preparatorias y generar las condiciones para pruebas de software y se ejecuta cuando hay que verificar el funcionamiento del software construido en un proyecto de desarrollo. El proceso describe las siguientes actividades: 1. Determinar productos de software que serán probados a partir del contenido de las Bases de Licitación y Registro de Requerimientos. Estos pueden ser módulos, funciones, requerimientos, productos y componentes de productos. 2. Definir alcance de las pruebas. Incluye tipos de pruebas, enfoques y restricciones. Los tipos de prueba son funcionales, de seguridad, de rendimiento, de aceptación o de instalación. 3. Definir método de pruebas para productos y componentes de software. Los métodos pueden ser: Caja Negra, Caja Blanca, Partición Equivalente, Análisis de Valor Límite, Comparación, Caja de Cristal, Caja de Pandora, Integración Ascendente, Integración Descendente, Integración Combinada o Integración Big-Bang. 4. Generar casos de prueba y datos de prueba que se utilizarán en la ejecución de pruebas. Los datos de prueba mencionados en el punto 4 pueden ser generados por el equipo de trabajo, el equipo de pruebas o proporcionados por el cliente, lo cual debe quedar establecido en el Plan de Pruebas. 5. Definir ambiente de pruebas. Se debe Registrar todos los detalles técnicos de la creación y todas aquellas consideraciones especiales que sea necesario recordar ante una reconstitución del ambiente para iterar todos o algunos de los casos de prueba. Los datos son registrados en el documento Definición de Ambiente de Pruebas el cual es anexado al Plan de Pruebas. Este documento incluye red, servidor, privilegios, espacio en disco, herramientas de prueba y recurso humano que ejecutarán las pruebas.
Figura 25: Preparar Pruebas 6. Estimar esfuerzo para ejecución de las pruebas. Se debe considerar todas las actividades relacionadas con las pruebas: revisión de documentación, elaboración del Plan de Pruebas, generación del ambiente de pruebas, análisis transaccional, generar escenarios de pruebas, preparación de casos de prueba, generación de datos de prueba, ejecución de las pruebas, seguimiento de las pruebas, consolidar resultados y generar reportes, y generar informe final y métricas. 7. Estimar plazos para ejecución de las pruebas, considerando recursos disponibles para pruebas y estimaciones de productividad individual * Todos los anteriores documentos generados formarán parte del Plan de Pruebas. 8. Informar planificación de pruebas al Jefe de Proyecto para coordinación El Jefe de Proyecto es el encargado de aprobar el Plan de Pruebas analizando su compatibilidad con las eventuales restricciones del proyecto. En el caso de no aprobar el documento se debe revisar los puntos en conflicto. |
Actividad: Ejecutar Pruebas |
Entradas: Plan de Pruebas, Informe de Diseño, Software a probar, Casos de Prueba, Datos de Prueba |
Salidas: Métricas de validación, Reporte de Observaciones |
Actores Involucrados: Responsable de Pruebas de Software, Equipo de Proyecto. |
Descripción (ver Figura 26):
Figura 26: Ejecutar Pruebas Esta actividad o proceso tiene como objetivo verificar el funcionamiento del software construido en un proyecto de desarrollo y alcanzar los criterios de aceptación o de término de pruebas definidos. El proceso contiene las siguiente actividades: 1. Ejecutar pruebas de acuerdo al plan: Se ejecutan las acciones, procedimientos y programas establecidos para cada prueba aplicando los Casos de Prueba definidos y los datos de pruebas generados para tal efecto. 2. En caso de pruebas sobre funciones corregidas se ejecutan pruebas de regresión para asegurar que las correcciones no crearon problemas en otra parte del software. 3. Documentar resultados en el Informe de Observaciones. 4. Analizar resultados de las pruebas determinando: problemas de construcción de software, problema con el método de pruebas seleccionado, problemas del ambiente de pruebas (infraestructura, datos de pruebas, componentes de software faltantes, emitir recomendaciones de mejora si es posible). 5. Determinar criticidad de las observaciones: defectos de forma, defectos de fondo, factibilidad de continuar con otras pruebas a pesar de los defectos detectados. 6. Comunicar resultados de las pruebas al proyecto 7. Acumular métricas del proceso: cantidad de defectos total, cantidad de defectos por categoría (grave, mediana, leve), cantidad de iteraciones. |
Referencias
[Bat95] | Roger Bate, Dorothy Kuhn, Curt Wells, James Armitage, Gloria Clark, Kerinia Cusick, Suzanne Garcia, Mark Hanna, Robert Jones, Peter Malpass, Ilene Minnich, Hal Pierson, Tim Powell, Al Reichner: "A Systems Engineering Capability Maturity Model, Version 1.1", 1995. |
[Chr06] | Mary Beth Chrissis, Mike Konrad, Sandy Shrum; "CMMI® for Development, v1.2", 2006. |
[Gon07] | Gonzalez, Carlos: "Conceptos Generales de Calidad Total", Monografías, 2007. http://www.monografias.com/trabajos11/conge/conge.shtml |
[Inc96] | INCOSE: "Systems Engineering Capability Assessment Model", 1996. http://www.incose.org/ProductsPubs/pdf/SECAM-SysEngCapabilityAssessModel_1996-06.pdf |
[Jac99] | Ivar Jacobson, Grady Booch, James Rumbaugh: "The Unified Software Development Process", 1999. |
[Kul03] | Margaret K. Kulpa, Kent A. Johnson: "Interpreting the CMMI: A Process Improvement Approach", 2003. |
[Pal06] | Palacio, Juan: "Sinopsis de los modelos CMM-SW y CMMI", 2006 |
[Pau93] | Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber: "Capability Maturity Model for Software, Version 1.1", 1993. http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf |
[Rat03] | IBM Staff: "Rational Unified Process Best Practices for Software Development Teams", 2003. |
[Rig06] | Rigoni, Cecilia: "CMMI®: Mejora del proceso en Fábricas de Software", 2006. http://www.mityc.es/NR/rdonlyres/A570B90C-B41A-46E2-BD39-4A31D18BB7FD/0/s01CeciliaRigoni.pdf |
[Sec07a] | © SECAT LLC: "Understanding the SECM (EIA/IS 731.1)", 2007. http://www.secat.com/workshops/731.1_WorkshopDescription.htm |
[Sec07b] | © SECAT LLC: "Integrated Product Development Capability Maturity Model overview briefing", 2007. |
[SEI00] | Software Engineering Institute, Carnegie Mellon University: "ARC, V1.0 Assessment Requirements for CMMI Version 1.0", 2000 http://www.sei.cmu.edu/pub/documents/00.reports/pdf/00tr011.pdf |
[SEI01] | Software Engineering Institute, Carnegie Mellon University: "Standard CMMI Appraisal Method for Process Improvement (SCAMPI) Version 1.1: Method Definition Document", 2001 http://www.sei.cmu.edu/pub/documents/01.reports/pdf/01hb001.pdf |
[SEI06a] | Software Engineering Institute, Carnegie Mellon University: "A Standard CMMI Appraisal Method for Process Improvement (SCAMPI) Version 1.2: Method Definition Document", 2006. http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06hb002.pdf |
[SEI06b] | Software Engineering Institute, Carnegie Mellon University: "Appraisal Requirements for CMMI, Version 1.2 (ARC, V1.2)", 2006. http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr011.pdf |
[SEI07a] | Software Engineering Institute, University Carnegie-Mellon: "Capability Maturity Model® Integration (CMMI), Version 1.2 Overview", 2007. http://www.sei.cmu.edu/cmmi/adoption/pdf/cmmi-overview07.pdf |
[SEI07b] | Software Engineering Institute, Carnegie Mellon University: What is CMMI?, Septiembre 2007. http://www.sei.cmu.edu/cmmi/general/index.html |
[Vil00] | Villate Blanco, José María: "Modelos de calidad en la industria. Situación y perspectivas de futuro en la CAPV", 2000. |
[1] Las áreas de proceso que tienen "+IPPD" al lado derecho contienen metas y prácticas adicionales relacionadas a IPPD (Integrated Product and Process Development) – Desarrollo de Procesos y Productos integrados). Para ver más información acerca de IPPD consultar [Chr06].
[2] Información obtenida de la página Web de la organización: http://www.orden.cl
[3] Enterprise Architect de Sparx Systems. Para consultar información sobre la herramienta visite el sitio: http://www.sparxsystems.com/
Glosario de Términos
Ambiente de integración: Son las herramientas de soporte necesarias para acoplar las diferentes componentes de un producto, puede incluir software y equipos necesarios.
América XXI: Empresa chilena focalizada al desarrollo y mantenimiento de productos Software a medida. Esta empresa se encuentra actualmente certificada por el modelo de calidad CMMI Nivel 3 y además cuenta en su organización con dos especialistas y certificadores del modelo de calidad CMMI que prestan servicios de asesoría y certificación a diversas organizaciones, entre ellas a ORDEN Integración.
Artefacto: Resultado útil de un proceso. Puede incluir archivos, documentos, productos, partes de un producto, servicios, descripciones de proceso, especificaciones y facturas [Chr06].
Casos de prueba: Conjunto de condiciones, las cuales forman la base informativa para que el analista determine si el requerimiento está satisfecho por el Sistema.
Calidad: La capacidad de un conjunto de características inherentes de un producto, de los componentes del producto o de un proceso para satisfacer los requerimientos impuestos por los clientes [Chr06].
Capacidad: Atributo de los procesos. El nivel de capacidad de un proceso indica si sólo se ejecuta, o si también se planifica se encuentra organizativa y formalmente definido, se mide y se mejora de forma sistemática [Pal06].
Conjunto de procesos estándares de la organización: Es una colección de definiciones de los procesos que guían actividades en una organización. Estas descripciones de proceso cubren los elementos fundamentales de proceso (y sus relaciones con otros) que deben ser incorporados en los "procesos definidos" que son implementados en proyectos [Chr06].
Commercial Off The Shelf (COTS): Corresponde a objetos, componentes de productos o productos en sí que pueden ser adquiridos desde un vendedor comercial [Chr06].
Criterios de entrada: Estados de existencias que deben estar presente antes de que un esfuerzo pueda empezar con el éxito [Chr06].
Criterios de salida: Estados de existencias que deben estar presente antes de que un esfuerzo pueda terminar exitosamente [Chr06].
Datos de prueba: Colección de datos que se utilizarán en las pruebas del Sistema.
Disciplinas: Son las etapas, flujos de trabajo o subprocesos del Proceso de Ingeniería de Software. Cada disciplina contiene tareas a realizar, actores involucrados, artefactos producidos y recursos utilizados. Además son transversales a todas las fases del ciclo de vida del proyecto.
Fases: Son la etapas por las que cualquier desarrollo de proyecto de ORDEN integración debiera transitar. Las fases son: Inicio, Elaboración-Construcción y Transición.
Guías de adaptación: Guías organizacionales que permiten a proyectos, grupos, y funciones organizacionales adaptarse apropiadamente a los procesos estándares para sus usos. Las guías de adaptación cubren la selección de procesos estándares, la selección de un apropiado modelo de ciclo de vida, y la adaptación de los procesos estándares seleccionados y modelo del ciclo de vida a las necesidades del proyecto. Guías de adaptación describe que puede o no puede ser modificado e identifica componentes del proceso que so n candidatos a ser modificados [Chr06].
Implementación: Existe evidencia suficiente de que un objetivo (específico) es alcanzado mediante la definición de algún proceso, en este caso se dice que el proceso implementa el objetivo específico.
Institucionalización: Existe evidencia suficiente de que un objetivo (específico) se encuentra arraigado en la forma de hacer el negocio dentro de una organización. Este forma de trabajar se hace rutinariamente y es parte de la cultura organizacional, en este caso se dice que el objetivo específico se encuentra institucionalizado. Los objetivos genéricos ayudan a institucionalizar los objetivos específicos.
Integración ascendente: Se integran incrementalmente las componentes, comenzando con las inferiores. Las nuevas componentes se van probando. Se finaliza cuando se alcance el producto final de software y su respectiva prueba.
Integración Big-Bang: Es un tipo de integración de componentes no incremental. Se combinan todos los módulos y se prueba el programa.
Integración combinada: Tipo de integración de componentes efectuada en forma incremental, es decir se integra en forma controlada conjuntos, previamente especificados, de componentes.
Integración descendente: Es una estrategia de integración incremental a la construcción de la estructura de programas, en cual se integran los módulos moviéndose en dirección hacia abajo por la jerarquía de control comenzando con el módulo principal (Programa principal). Los módulos subordinados al módulo de control principal se incorpora en la estructura, bien, de forma primero-en-profundidad, bien de forma primero-en-anchura [Par07].
Madurez: Atributo de las organizaciones que desarrollan o mantienen los sistemas de software. En la medida que éstas llevan a cabo su trabajo siguiendo procesos, y en la que éstos se encuentran homogéneamente implantados, definidos con mayor o menor rigor; conocidos y ejecutados por todos los equipos de la empresa; y medidos y mejorados de forma constante, las organizaciones serán más o menos "maduras" [Pal06].
Medidas: Medidas de un proceso indican el grado de correctitud en que un proceso está siendo ejecutado.
Modelo de calidad: son sistemas basados en estudios experimentales de mejores prácticas que ayudan a organización a implantar Sistema de Aseguramiento de la calidad.
Nivel de capacidad: Grado que involucra la mejora dentro de una individual área de proceso [Chr06], es decir involucra la mejora de un conjunto de procesos relacionados al área de proceso especificada.
Nivel de madurez: Grado que involucra un conjunto predefinido de áreas de proceso, las cuales todos sus objetivos son alcanzados [Chr06].
Organización: Es una estructura administrativa en que la gente colectivamente maneja uno o más proyectos que comparten un alto directivo y operan bajo las mismas políticas. Organización puede ser también aplicada a una persona quien realiza una función en una pequeña organización que podría ser realizada por un grupo de gente en una gran organización [Chr06].
Partes Interesadas: Ver Stakeholders
Partición Equivalente: Tipo de prueba de caja negra. Divide las entradas de un programa en clases que podrían llegar a derivan casos de prueba.
Proceso: Un conjunto de pasos que ayudan a resolver un problema. Estos pasos deben estar definidos de manera que no sean ambiguos, esto implica que puedan ser fácilmente entendidos y capaces de ser seguidos de manera consistente por cualquier persona que lo utilice. Además un proceso debe tener sus entradas y salidas claras y bien definidas.
Proceso de Desarrollo de Software: Proceso definido por ORDEN Integración referido al proceso o metodología de desarrollo de soluciones software "a medida" para sus clientes.
Project Managment Organization (PMO): Área ejecutiva de ORDEN Integración encargada de la administración de los proyectos.
Pruebas de Aceptación: Pruebas realizadas por el usuario quien comprueba en su ambiente de operación el sistema entregado. Los puede aceptar o rechazar.
Pruebas de Análisis de Valor Límite: Prueba que tiene por objetivo verificar la ejecución de programa analizando los valores límite de los tipos de datos especificados. Para ello se debe probar con valores dentro y fuera de los límites especificados para el tipo de dato.
Pruebas de Caja Blanca: Los objetivos de este tipo de pruebas es garantizar la ejecución por lo menos una vez todos los caminos independientes de cada modulo, la ejecución de todas las decisiones lógicas en sus caminos verdadero y falso, la ejecución de todos los lazos en sus limites, y la ejecución de las estructuras internas de datos para asegurar su validez.
Pruebas Caja de Cristal: Prueban por lo menos una vez todos los caminos en el control de cada componente y todas las decisiones lógicas.
Pruebas de Caja Negra: Las pruebas de caja negra se centran en los requerimientos funcionales. Permiten al ingeniero del software obtener un conjunto de entradas que prueben completamente los requerimientos funcionales de un programa sin importar los detalles internos del programa, a fin de verificar que el programa corra bien.
Pruebas de Caja de Pandora: Consiste en abstenerse de realizar pruebas de depurar bastante bien un proyecto; se deja al cliente que lo ensaye y acepte. El resultado es una bomba de tiempo.
Pruebas de Comparación: Consiste en la comparación de las salidas de las distintas versiones de una misma componente o producto software.
Pruebas Funcionales: Buscan satisfacer los requerimientos funcionales de las componentes del producto o producto final.
Pruebas de Instalación: Pruebas que buscan satisfacer los requerimientos de operación del sistema.
Pruebas de Regresión: Las pruebas de regresión consisten en a realizar pruebas ejecutadas previamente, con el fin de asegurar de que los cambios hecho en el código no ha provocado efectos laterales no deseados.
Pruebas de Rendimiento: Buscan satisfacer los requerimientos no funcionales asociados satisfacer requerimientos de rendimiento del sistema (volumen de datos, tasa de transacciones, etc.)
Pruebas de Seguridad: Buscan satisfacer los requerimientos no funcionales referidos a mantener la integridad del sistema ante cualquier amenaza definida que pueda llegar a tener en su operación.
Prueba de Validación: el producto final se prueba para definir si cumple los requerimientos funcionales y de rendimiento, facilidad de mantenimiento, recuperación de errores.
Requerimientos de operación: Requerimientos provistos por el ambiente en el cual operará el sistema.
Roles: Roles de un proceso se refiere al conjunto de responsabilidades y funciones que deben ser realizadas por los actores del proceso.
RUP (Rational Unified Process): Proceso de desarrollo de software unificado. Provee un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización. El objetivo es asegurar productos software de alta calidad que satisfagan las necesidades de los usuarios finales, dentro de los tiempos y presupuestos previstos [Rat03].
Stakeholders: Se refiere a una persona o un conjunto de persona que son afectadas o responsables por las actividades de un proyecto.
Trazabilidad: Una asociación distinguible entre dos o más entidades lógicas, como requerimientos, elementos del sistema, verificaciones, tareas.
Unidad de Control de Calidad: Unidad de ORDEN Integración encargada de controlar y asegurar la calidad de los productos software producidos por la empresa y liberados a los clientes
Work Breakdown Structure (WBS): El WBS es la descomposición del proyecto en fases, etapas, subetapas, hitos, hasta concluir con los entregables a producir al término de cada hito. Es único para cada proyecto y es preparado en forma general al principio del proyecto y se detalla en la medida que el proyecto avanza en su ejecución. El WBS se actualiza mensualmente y permite reconocer contablemente el avance del proyecto a partir del valor del costo de los artefactos producidos y aceptados como terminados por el Jefe de Proyecto. Cada artefacto indicado en el WBS debe ser presupuestado en términos del Esfuerzo estimado para producirlo y el Costo a incurrir hasta su término. Las cartas Gantt del proyecto que periódicamente debe actualizar el jefe de proyecto deben relacionar en forma explicita cada tarea con uno de los entregables declarados en el WBS. De esta manera, cuando la tarea sea finalizada, se podrán comparar los valores de esfuerzo presupuestado en el WBS con los valores reales informados por los responsables de producir el artefacto.
Nota sobre los Autores
Matías Fuentes Contreras
Estudiante de Ingeniería Civil Informática de la Universidad de Concepción, Concepción, Chile.
Pablo Teuber Henríquez
Estudiante de Ingeniería Civil Informática de la Universidad de Concepción, Concepción, Chile.
Fecha de Publicación:
26 de febrero de 2008
Trabajo realizado en la ciudad de Santiago de Chile.
| Página siguiente |