Evaluación de procesos de software utilizando EvalProSoft Aplicado a un caso de estudio

Texto completo

(1)ESCUELA POLITÉCNICA NACIONAL FACULTAD DE INGENIERÍA DE SISTEMAS EVALUACIÓN DE PROCESOS DE SOFTWARE USANDO EVALPROSOFT APLICADO A UN CASO DE ESTUDIO.. PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN SISTEMAS INFORMÁTICOS Y DE COMPUTACIÓN. PAREJA QUINALUISA JORGE FERNANDO [email protected]. RIVERA GUEVARA RICHARD PAUL [email protected]. Director: Ing. Carlos Montenegro [email protected]. Quito, Diciembre 2011.

(2) II. DECLARACIÓN. Nosotros, Jorge Pareja Quinaluisa y Richard Rivera Guevara, declaramos bajo juramento que el trabajo aquí descrito es de nuestra autoría; que no ha sido previamente presentada para ningún grado o calificación profesional; y, que hemos consultado las referencias bibliográficas que se incluyen en este documento.. A través de la presente declaración cedemos nuestros derechos de propiedad intelectual correspondientes a este trabajo, a la Escuela Politécnica Nacional, según lo establecido por la Ley de Propiedad Intelectual, por su Reglamento y por la normatividad institucional vigente.. Jorge Pareja Quinaluisa. Richard Rivera Guevara.

(3) III. CERTIFICACIÓN. Certifico que el presente trabajo fue desarrollado por Jorge Pareja Quinaluisa y Richard Rivera Guevara, bajo mi supervisión.. Ing. Carlos Montenegro DIRECTOR DE PROYECTO.

(4) IV. AGRADECIMIENTO. Esta tesis está dedicada a mis padres y hermanos a quienes agradezco de todo corazón. por. su. amor. apoyo. y. comprensión a lo largo de mi vida estudiantil. A Dios porque aunque tuve muchos tropiezos durante el desarrollo de este proyecto siempre me dio la fortaleza para salir adelante.. Jorge.

(5) V. AGRADECIMIENTO. Ya he vivido este momento en mis sueños… gracias Dios por una vez mas haberme dado las fuerzas para no rendirme y seguir luchando por aquello que quiero y hacer realidad mis sueños. A mi Madre por todo el conocimiento, el cariño, la paciencia, la comprensión y el apoyo incondicional que me ha dado siempre. A mi Meluchin por toda la alegría y felicidad y ánimos que siempre me das. A mis abuelitos y a toda mi familia que estuvieron siempre dándome su apoya y teniendo fe en mi. A Verónica por haberme dado en su momento la más grande motivación que fue el verdadero estímulo que me hizo iniciar este proyecto. Richard.

(6) VI. DEDICATORIA. Esta tesis está dedicada a todas las personas que confiaron en mí y me brindaron su apoyo, especialmente para la personita que me ha brindado con su existencia las fuerzas para seguir adelante y llegar a este objetivo mi hija Sarita Nicole.. Jorge.

(7) VII. DEDICATORIA. A mi pequeña familia por todo lo que han hecho por mí por apoyarme cuando soy un soñador y estar ahí cuando cumplo mis sueños.. Richard.

(8) VIII. TABLA DE CONTENIDO RESUMEN ...............................................................................................................XIV INTRODUCCIÓN ......................................................................................................XV Capitulo 1 MOPROSOFT EN EL DESARROLLO DE SOFTWARE.......................... 1 1.1 MODELO DE PROCESOS PARA LA INDUSTRIA DEL SOFTWARE MOPROSOFT. ......................................................................................................... 3 1.1.1 INTRODUCCIÓN ......................................................................................................... 3 1.1.1.1 Alcance de MoProSoft .............................................................................................. 3 1.1.1.2 Criterios empleados por MoProSoft .......................................................................... 4 1.1.2 ESTRUCTURA DEL MODELO DE PROCESOS .......................................................... 5 1.1.2.1 Patrón de Procesos .................................................................................................. 5 1.1.2.1.1 Definición general del proceso ............................................................................ 5 1.1.2.1.2 Prácticas ............................................................................................................ 5 1.1.2.1.3 Guías de Ajuste .................................................................................................. 6 1.1.2.2 Categorías de procesos ........................................................................................... 6 1.1.2.3 Procesos .................................................................................................................. 7 1.1.2.4 Roles ....................................................................................................................... 9 1.1.2.5 Productos............................................................................................................... 10 1.1.3 PROCESO DE MOPROSOFT DESARROLLO Y MANTENIMIENTO DE SOFTWARE 12 1.1.3.1 Definición General del proceso ............................................................................... 12 Entradas ................................................................................................................................... 14 Nombre ..................................................................................................................................... 15 Productos internos .................................................................................................................... 18 1.1.3.2 Prácticas ................................................................................................................ 19 Capacitación ............................................................................................................................. 19 Proyecto Específico................................................................................................................... 19 Ver1 .......................................................................................................................................... 28 Incorporación a la Base de Conocimiento .................................................................................. 31 1.1.3.3 Guías de ajuste ...................................................................................................... 34. 1.2 MÉTODO DE EVALUACIÓN DE PROCESOS PARA LA INDUSTRIA DEL SOFTWARE EVALPROSOFT. .............................................................................. 35 1.2.1 INTRODUCCIÓN ....................................................................................................... 35 1.2.2 ALCANCE DE EVALPROSOFT ................................................................................. 36 1.2.3 USOS DEL MÉTODO DE EVALUACIÓN ................................................................... 36 1.2.3.1 Posibles usos del Método de Evaluación ................................................................ 36 1.2.3.2 Posibles usos de los resultados de las evaluaciones .............................................. 37. Capitulo 2 ANÁLISIS DEL MÉTODO DE EVALUACIÓN DE PROCESOS PARA LA INDUSTRIA DEL SOFTWARE EVALPROSOFT. ..................................................... 38 2.1. DESCRIPCIÓN GENERAL DEL MÉTODO DE EVALUACIÓN................... 38. 2.1.1. MODELO DE CAPACIDADES DE PROCESOS ......................................................... 39.

(9) IX. 2.1.1.1 Descripción de niveles de capacidad y atributos respectivos .................................. 39 2.1.1.2 Calificación de los atributos del proceso ................................................................. 45 2.1.1.3 Calificaciones del nivel de capacidad del proceso................................................... 45 2.1.2 CONDICIONES PARA INICIAR UNA EVALUACIÓN .................................................. 47 2.1.3 PROCESO DE EVALUACIÓN.................................................................................... 48 2.1.4 RESULTADOS DE LA EVALUACIÓN ........................................................................ 49 2.1.5 ROLES INVOLUCRADOS Y RESPONSABILIDADES ................................................ 50. 2.2 CONCEPTOS Y PATRÓN PARA LA DESCRIPCIÓN DEL PROCESO DEL MÉTODO DE EVALUACIÓN. ................................................................................ 52 2.2.1 2.2.2. 2.3. CONCEPTOS ............................................................................................................ 52 PATRÓN DEL PROCESO.......................................................................................... 54. PROCESO DEL MÉTODO DE EVALUACIÓN. ........................................... 55. 2.3.1 DEFINICIÓN GENERAL DEL PROCESO .................................................................. 55 Salidas ...................................................................................................................................... 58 2.3.2 PRACTICAS .............................................................................................................. 61 Abreviatura................................................................................................................................ 61 Capacitación ............................................................................................................................. 61 Actividades................................................................................................................................ 61 Descripción ............................................................................................................................... 61 2.3.3 GUÍAS DE AJUSTE ................................................................................................... 66. Capitulo 3. APLICACIÓN DEL MODELO DE EVALUACIÓN EVALPROSOFT A. UN CASO DE ESTUDIO. .......................................................................................... 67 3.1 HERRAMIENTA AUTOMÁTICA PARA LA APLICACIÓN DEL MODELO DE EVALUACIÓN. ...................................................................................................... 67 3.1.1 3.1.2. 3.2. DESCRIPCIÓN DE LA HERRAMIENTA ..................................................................... 67 UTILIZACIÓN DE LA HERRAMIENTA ....................................................................... 68. DESCRIPCIÓN DEL CASO DE ESTUDIO .................................................. 72. 3.2.1 DESCRIPCIÓN DEL PROYECTO A EVALUAR ......................................................... 73 3.2.1.1 Proceso de desarrollo de software del caso de estudio ........................................... 73 3.2.1.1.1 Fase de Inicio ................................................................................................... 76 3.2.1.1.2 Fase de Requerimientos................................................................................... 76 3.2.1.1.3 Fase de Análisis y Diseño................................................................................. 76 3.2.1.1.4 Fase de Construcción ....................................................................................... 77 3.2.1.1.5 Fase de Integración y Pruebas ......................................................................... 77 3.2.1.1.6 Fase de Cierre ................................................................................................. 77. 3.3. EVALUACIÓN Y ANÁLISIS DE RESULTADOS DEL CASO DE ESTUDIO. 78. 3.3.1 EVALUACIÓN DEL CASO DE ESTUDIO ................................................................... 78 3.3.1.1 A1. PREPARACIÓN ............................................................................................... 78 3.3.1.1.1 Acuerdo de Evaluación ..................................................................................... 78 3.3.1.1.2 Paquete de Evaluación ..................................................................................... 81 3.3.1.2 A2. PLANEACIÓN.................................................................................................. 81.

(10) X. 3.3.1.3 A3. EJECUCIÓN .................................................................................................... 83 3.3.1.3.1 Preguntas Atributo de administración de la realización del proceso, atributo para nivel 1. 85 3.3.1.4 A4. GENERACIÓN DE RESULTADOS ................................................................ 104 3.3.1.4.1 Perfil de Calificación de atributos del proceso de desarrollo ............................ 104 3.3.1.4.2 Reporte de Resultados ................................................................................... 104 3.3.1.5 A5. ENTREGA DE RESULTADOS ....................................................................... 106 3.3.1.6 A6. CIERRE DE LA EVALUACIÓN....................................................................... 109 3.3.2 RESULTADOS DE LA EVALUACIÓN CON LA HERRAMIENTA AUTOMÁTICA. ..... 112 3.3.3 ANÁLISIS DE RESULTADOS DEL CASO DE ESTUDIO.......................................... 112. Capitulo 4 CONCLUSIONES Y RECOMENDACIONES ....................................... 114 4.1. CONCLUSIONES ...................................................................................... 114. 4.2. RECOMENDACIONES .............................................................................. 116. BIBLIOGRAFÍA ....................................................................................................... 118.

(11) XI. ÍNDICE DE TABLAS Tabla 1.1 Diario Oficial de la Federación, 2005 Norma NMX-059-NYCE-2005. [5]..... 2 Tabla 1.2 Entradas para el proceso de Desarrollo de Software ................................ 14 Tabla 1.3 Salidas para el proceso de Desarrollo de Software ................................... 18 Tabla 1.4 Productos Internos para el proceso de Desarrollo de Software................. 18 Tabla 1.5 Roles Involucrados para el proceso de Desarrollo de Software ................ 20 Tabla 1.6 Actividades para el proceso de Desarrollo de Software ............................ 26 Tabla 1.7 Verificaciones y Validaciones para el proceso de Desarrollo de Software 31 Tabla 1.8 Incorporación a la base de conocimiento para el proceso de Desarrollo de Software .................................................................................................................... 32 Tabla 1.9 Recursos de Infraestructura para el proceso de Desarrollo de Software .. 32 Tabla 2.1 Calificación de los atributos de proceso .................................................... 45 Tabla 2.2 Calificación del nivel de capacidad del proceso ........................................ 46 Tabla 2.3 Conceptos de EvalProSoft ........................................................................ 54 Tabla 2.4 Entradas de EvalProSoft ........................................................................... 57 Tabla 2.5 Salidas de EvalProSoft .............................................................................. 60 Tabla 2.6 Roles involucrados y Capacitación para EvalProSoft ................................ 61 Tabla 2.7 Actividades de EvalProSoft ....................................................................... 65 Tabla 3.1 Fases del Desarrollo del sistema SGC [3]. ................................................ 75 Tabla 3.2 Acuerdo de la Evaluación .......................................................................... 80 Tabla 3.3 Roles del Proceso de Evaluación .............................................................. 83 Tabla 3.4 Plan de Evaluación .................................................................................... 83 Tabla 3.5 Perfil de calificación de atributos del proceso de desarrollo .................... 104 Tabla 3.6 Nivel de Capacidad del Proceso de Desarrollo de Software ................... 105.

(12) XII. Tabla 3.7 Resumen de Hallazgos detectados en el proyecto.................................. 105 Tabla 3.8 Reporte de Resultados ............................................................................ 108 Tabla 3.9 Reporte Estadístico ................................................................................. 111.

(13) XIII. ÍNDICE DE FIGURAS Figura 1.1 Diagrama de Categoría de procesos [1]. .................................................... 7 Figura 1.2 Diagrama de relación entre procesos [1]. ................................................... 9 Figura 1.3 Clasificación General de roles [1]. ............................................................ 10 Figura 1.4 Configuración y productos de software [1]. .............................................. 10 Figura 1.5 Clasificación general de productos. [1] ..................................................... 11 Figura 1.6 Flujo de Trabajo del proceso Desarrollo y Mantenimiento de Software.[1] .................................................................................................................................. 27 Figura 1.7 Relación entre los elementos del Método de Evaluación.[2] .................... 35 Figura 2.1 Diagrama de flujo de trabajo de EvalProSoft ........................................... 66 Figura 3.1 Página de Inicio de la Herramienta .......................................................... 68 Figura 3.2 Pagina sobre EvalProSoft ........................................................................ 69 Figura 3.3 Página Sobre MoProSoft .......................................................................... 70 Figura 3.4 Página para iniciar una Evaluación .......................................................... 71 Figura 3.5 Cuestionarios de la Evaluación ................................................................ 72 Figura 3.6 Agenda de Actividades del proceso de Evaluación .................................. 83 Figura 3.7 Reporte de Resultados de la Herramienta ............................................. 112.

(14) XIV. RESUMEN. El presente trabajo tiene como objetivo evaluar el proceso de desarrollo de software utilizando el método de Evaluación para la industria del software EvalProSoft, el mismo que está basado en el modelo de procesos para la industria del software MoProSoft, estándares del gobierno mexicano, adaptando el método de evaluación para aplicarlo en el proceso de desarrollo de software de un proyecto realizado en Ecuador. Con la Evaluación del proceso de desarrollo de software de un proyecto se podrá conocer el perfil del nivel de capacidad del proceso, y el grado de alcance de los atributos de proceso que se evalúen del mismo. Al obtener los resultados se puede analizar cuáles son las prácticas del proceso que requieren más atención para que este pueda empezar a mejorar, el caso de estudio seleccionado permitió conocer las fortalezas y debilidades que existen en el proceso de desarrollo de software así como también las practicas de proceso que se requieren realizar para un modelo de procesos de otro país como MoProSoft, mejorando así la calidad de los proyectos de desarrollo de software realizados en Ecuador..

(15) XV. INTRODUCCIÓN. Conocer la calidad con la que se está realizando el proceso de desarrollo de software de un proyecto mediante una evaluación, es muy importante ya que permite conocer cuáles son las prácticas del proceso que deben mejorar, de acuerdo a la metodología con que se realizó, el modelo de proceso que se utilizó y el tipo de evaluación que se aplicó. En el capítulo 1 se describe el Modelo de procesos para la industria del software MoProSoft, explicando la estructura de este modelo de procesos y específicamente sobre el proceso de desarrollo y mantenimiento de software; se expone también una breve introducción al método de evaluación de procesos para la industria del software EvalProSoft. En el capítulo 2 se realiza un análisis sobre EvalProSoft mediante una descripción general y el detalle de los conceptos que se utilizan. Además se expone en forma detallada el proceso de evaluación. En el capítulo 3 se realiza una evaluación aplicando EvalProSoft a un caso de estudio específico, al cual se lo describe, se evalúa y se analiza los resultados que se obtienen. En el capítulo 4 se da a conocer las conclusiones y recomendaciones del trabajo realizado..

(16) 1. CAPITULO 1 MOPROSOFT. EN. EL. DESARROLLO. DE. SOFTWARE En Agosto de 2005 se desarrolla el documento Modelo de Procesos para la Industria de Software MoProSoft Versión 1.3 a solicitud de la Secretaría de Economía para servir de base a la Norma Mexicana para la Industria de Desarrollo y Mantenimiento de Software bajo el convenio con la Facultad de Ciencias, Universidad Nacional Autónoma de México. Posteriormente el 15 de agosto de 2006 se publica en el Diario Oficial de la Federación la noma mexicana de Tecnología de la Información -Software- Modelo de procesos y de evaluación para el desarrollo y mantenimiento de software (Norma NMX-059-NYCE1-2005), evento que cumple con una de las metas del PROSOFT 2, el contar con un marco legal promotor de la industria del software. Esta norma se conforma de cuatro partes en las que se distribuye el documento de MoProSoft y EvalProSoft, la separación y una breve descripción del contenido de cada documento se muestra en la tabla 1.1. NÚMERO. NOMBRE. CAMPO DE APLICACIÓN. NMX-I-. Tecnología de la. Esta Norma Mexicana tiene por objeto. 059/01-. información – Software -. definir los conceptos y describir los. NYCE-2005. Modelos de procesos y. productos para las demás partes de la. evaluación para desarrollo NMX-I-059-NYCE. y mantenimiento de software - Parte 01: Definición de conceptos y productos. NMX-I-. 1. Tecnología de la. Esta norma tiene por objeto definir. Normalización y Certificación Electrónica A. C. Procesos para la industria del Software de México.. 2.

(17) 2. NÚMERO. NOMBRE. CAMPO DE APLICACIÓN. 059/02-. información – Software -. MoProSoft.. NYCE-2005. Modelos de procesos y. Es aplicable tanto para las. evaluación para desarrollo organizaciones que tiene procesos y mantenimiento de. establecidos, así como para las que no.. software - Parte 02: Requisitos de procesos NMX-I-. Tecnología de la. Esta Norma tiene por objeto proporcionar. 059/03-. información – Software -. a las organizaciones de desarrollo y. NYCE-2005. Modelos de procesos y. mantenimiento de software un ejemplo. evaluación para desarrollo de la implantación del modelo de y mantenimiento de. procesos MoProSoft basado en las. software - Parte 03: Guía. mejores prácticas de ingeniería de. de implantación de. software. Este ejemplo puede servir de. procesos. apoyo para la definición de procesos en las organizaciones sin procesos establecidos o para la actualización de procesos en las que cuenten con ellos.. NMX-I-059/. Tecnología de la. Esta Norma Mexicana tiene por objeto. 04-NYCE-. información – Software -. definir las directrices para la evaluación. 2005. Modelos de procesos y. de procesos para la industria de. evaluación para desarrollo software. Esta norma es aplicable a los y mantenimiento de. organismos de certificación y a las. software - Parte 04:. organizaciones dedicadas al desarrollo y. Directrices para la. mantenimiento de software, que han. evaluación de procesos. utilizado la NMX-I-059/02-NYCE para la implantación de sus procesos. Tabla 1.1 Diario Oficial de la Federación, 2005 Norma NMX-059-NYCE-2005. [5].

(18) 3. 1.1 MODELO. DE. PROCESOS. PARA. LA. INDUSTRIA. DEL. SOFTWARE MOPROSOFT. 1.1.1 INTRODUCCIÓN El Modelo de Procesos para la Industria de Software MoProSoft fomenta la estandarización de su operación a través de la incorporación de las mejores prácticas en gestión e ingeniería de software. Implementar este modelo permite a las organizaciones. ofrecer. cada. vez. servicios. con. mayor. calidad. y. niveles. internacionales de competitividad. MoProSoft proporciona a la industria de software un modelo basado en las mejores prácticas internacionales con las siguientes características: •. Fácil de entender. •. Fácil de aplicar. •. Bajo costo de implementación. •. Servir de base para obtener evaluaciones exitosas con otros modelos o 4. normas, tales como ISO3 9000:2000 o CMM V1.1 1.1.1.1. Alcance de MoProSoft. El modelo de procesos MoProSoft está dirigido a las medianas y pequeñas empresas o departamentos dentro de una empresa grande que se dediquen al desarrollo y/o mantenimiento de software. Las organizaciones, que no cuenten con procesos establecidos ni documentados, pueden usar el modelo ajustándolo de acuerdo a sus necesidades y generando una instancia de cada uno de los procesos tomando en cuenta las consideraciones que plantea el modelo. Mientras que las organizaciones, que ya tienen procesos establecidos, pueden usarlo como punto de referencia para identificar los elementos que les hace falta cubrir y realizar una correspondencia con los procesos que ya cuentan y los del modelo para identificar las coincidencias y las discrepancias.. 3 4. Organización Internacional para la Estandarización. Modelo de Capacidad y Madurez..

(19) 4. 1.1.1.2. Criterios empleados por MoProSoft. La adopción de MoProSoft aplica los siguientes criterios: 1. Generar una estructura de los procesos que esté acorde con la estructura de las organizaciones de la industria de software. 2. Destacar el papel de la Alta Dirección en la planificación estratégica, su revisión y mejora continua como el promotor del buen funcionamiento de la organización. 3. Considerar a la Gestión como proveedor de recursos, procesos y proyectos, así como responsable de vigilar el cumplimiento de los objetivos estratégicos de la organización. 4. Considerar a la Operación como ejecutor de los proyectos de desarrollo y mantenimiento de software. 5. Integrar de manera clara y consistente los elementos indispensables para la definición de procesos y relaciones entre ellos. 6. Integrar los elementos para la administración de proyectos en un sólo proceso. 7. Integrar los elementos para la ingeniería de productos de software en un solo marco que incluya los procesos de soporte (verificación, validación, documentación y control de configuración). 8. Destacar la importancia de la gestión de recursos, en particular los que componen la base de conocimiento de la organización tales como: productos generados por proyectos, datos de los proyectos, incluyendo las mediciones, documentación de procesos y los datos recaudados a partir de su uso y lecciones aprendidas. ®. 9. Basar el modelo de procesos en ISO 9000:2000 y nivel 2 y 3 de CMM V.1.1. Usar como marco general ISO/IEC5 15504 - Software Process Assesment e incorporar las mejores prácticas de otros modelos de referencia tales como PMBOK6, SWEBOK7 y otros más especializados.. 5. Comisión Electrotécnica Internacional Estándar en la Administración de proyectos desarrollado por el Project Management Institute 7 Guía al conocimiento presente en el área de la Ingeniería del Software 6.

(20) 5. 1.1.2 ESTRUCTURA DEL MODELO DE PROCESOS MoProSoft cuenta con tres categorías de procesos: Alta Dirección, Gerencia y Operación, cada categoría de procesos abarca los procesos propios de su categoría que permiten en conjunto representar la estructura de una organización, En cada proceso se definen los roles responsables de la ejecución de las prácticas y actividades. Los roles se clasifican en Grupo Directivo, Responsable de Proceso y otros roles involucrados de acuerdo al proceso. Además se considera al Cliente y al Usuario como roles externos a la organización. Como consecuencia de los objetivos de cada proceso generara productos como el producto de Software, configuraciones de Software, planes, reportes, registros, lecciones aprendidas entre otros. 1.1.2.1 Patrón de Procesos El patrón de procesos es un esquema de elementos que sirve para documentar los procesos. Está constituido por tres partes: Definición general del proceso, Prácticas y Guías de ajuste. 1.1.2.1.1 Definición general del proceso En la Definición general del proceso se identifica su nombre, categoría a la que pertenece, propósito, descripción general de sus actividades, objetivos, indicadores, metas cuantitativas, responsabilidad y autoridad, subprocesos en caso de tenerlos, procesos relacionados,. entradas,. salidas,. productos internos y referencias. bibliográficas. 1.1.2.1.2 Prácticas En las Practicas se identifican los roles involucrados en el proceso y la capacitación requerida, se describen las actividades en detalle, asociándolas a los objetivos del proceso, se presenta un diagrama de flujo de trabajo, se describen las verificaciones y validaciones requeridas, se listan los productos que se incorporan a la base de conocimiento, se identifican los recursos de infraestructura necesarios para apoyar las actividades, se establecen las mediciones del proceso, así como las prácticas.

(21) 6. para la capacitación, manejo de situaciones excepcionales y uso de lecciones aprendidas. 1.1.2.1.3 Guías de Ajuste En las Guías de ajuste se sugieren modificaciones al proceso que no deben afectar los objetivos del mismo. 1.1.2.2 Categorías de procesos Categoría de Alta Dirección (DIR) Categoría aborda las prácticas relacionadas con la gestión del negocio. Proporciona los lineamientos a los procesos de la Categoría de Gerencia y se retroalimenta con la información generada por ellos. Categoría de Gerencia (GER) Categoría las prácticas de gestión de procesos, proyectos y recursos en función de los lineamientos establecidos en la Categoría de Alta Dirección. Proporciona los elementos para el funcionamiento de los procesos de la Categoría de Operación, recibe y evalúa la información generada por éstos y comunica los resultados a la Categoría de Alta Dirección Categoría de Operación (OPE) Categoría que aborda las prácticas de los proyectos de desarrollo y mantenimiento de software. Esta categoría realiza las actividades de acuerdo a los elementos proporcionados por la Categoría de Gerencia y entrega a ésta la información y productos generados..

(22) 7. Figura 1.1 Diagrama de Categoría de procesos [1].. 1.1.2.3 Procesos DIR.1 Gestión de Negocio Establece la razón de ser de la organización, objetivos y condiciones para lograrlos, considerando las necesidades de los clientes, y evaluando los resultados para poder proponer cambios que permitan la mejora continua. GES.1 Gestión de Procesos Establece los procesos de la organización, en función de los procesos requeridos identificados en el plan estratégico. También define, planifica, e implanta las actividades de mejora en los procesos..

(23) 8. GES.2 Gestión de Proyectos Asegura que los proyectos contribuyan al cumplimiento de los objetivos y estrategias de la organización. GES.3 Gestión de Recursos Proporcionar a la organización los recursos humanos, infraestructura, ambiente de trabajo y proveedores. También crea y mantiene la base de conocimiento de la organización. GES.3.1 Recursos Humanos y Ambiente de Trabajo Proporciona los recursos humanos idóneos para cumplir las responsabilidades asignadas a los roles dentro de la organización, así como la evaluación del ambiente de trabajo. GES.3.2 Bienes, Servicios e Infraestructura Proporciona proveedores de bienes, servicios e infraestructura que satisfagan los requisitos de adquisición de los procesos y proyectos. GES.3.3 Conocimiento de la Organización Mantiene disponible y administra la base de conocimiento que contiene la información y los productos generados por la organización. OPE.1 Administración de Proyectos Específicos Establece y lleva a cabo sistemáticamente las actividades que permitan cumplir con los objetivos de un proyecto en tiempo y costo esperados. OPE.2 Desarrollo y Mantenimiento de Software Realización sistemática de las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevo o modificado cumpliendo con los requerimientos especificados..

(24) 9. Figura 1.2 Diagrama de relación entre procesos [1].. 1.1.2.4 Roles Cliente Es el que solicita un producto de software y financia el proyecto para su desarrollo o mantenimiento. Usuario Es el que va a utilizar el producto de software. Grupo Directivo Son los que dirigen a la organización y son responsables por su funcionamiento. Responsable de Proceso Es el encargado de la realización de las prácticas de un proceso y del cumplimiento de sus objetivos. Involucrado Otros roles con habilidades requeridas para la ejecución de actividades o tareas específicas. Por ejemplo: Analista, Programador, Revisor, entre otros..

(25) 10. Figura 1.3 Clasificación General de roles [1].. 1.1.2.5 Productos Producto de Software Es el producto que se genera en el proceso de Desarrollo y Mantenimiento de Software. Los productos de software se clasifican de manera general como Especificación de Requerimientos, Análisis y Diseño, Software, Prueba, Registro de Rastreo y Manual. Configuración de Software Es un conjunto consistente de productos de software.. Figura 1.4 Configuración y productos de software [1]..

(26) 11. Plan Programa detallado de las actividades, responsables por realizarlas y calendario. Reporte Informe del resultado de las actividades realizadas. Registro Evidencia de actividades desempeñadas. Lección Aprendida Experiencia positiva o negativa obtenida durante la realización de alguna actividad. Otro Producto Producto distinto a los anteriores que también es generado en los procesos. Por ejemplo: Contrato, propuestas tecnológicas, documentación de procesos, entre otros.. Figura 1.5 Clasificación general de productos. [1].

(27) 12. 1.1.3 PROCESO DE MOPROSOFT DESARROLLO Y MANTENIMIENTO DE SOFTWARE El proceso que abarca todo el desarrollo de software en el modelo MoProSoft es el segundo proceso de la categoría de procesos de Operación como se indico en la Figura 1.1 Diagrama de Categoría de procesos” se lo nota como OPE.2 Desarrollo y Mantenimiento de Software el cual se detallara en los siguientes puntos. 1.1.3.1 Definición General del proceso Nombre del Proceso: OPE.2 Desarrollo y Mantenimiento de Software. Categoría Operación (OPE). Propósito Realizar sistemáticamente las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevos o modificados cumpliendo con los requerimientos especificados. Descripción El proceso de Desarrollo y Mantenimiento de Software se conforma de uno o más ciclos de desarrollo. Cada ciclo está compuesto de las siguientes fases: ·. Inicio: Revisión del Plan de Desarrollo por los miembros del Equipo de Trabajo para lograr un entendimiento común del proyecto y para obtener el compromiso de su realización.. ·. Requerimientos: Conjunto de actividades cuya finalidad es obtener la documentación de la Especificación de Requerimientos y Plan de Pruebas de Sistema, para conseguir un entendimiento común entre el cliente y el proyecto.. ·. Análisis y Diseño: Conjunto de actividades en las cuales se analizan los requerimientos especificados para producir una descripción de la estructura de.

(28) 13. los componentes de software, la cual servirá de base para la construcción. Como resultado se obtiene la documentación del Análisis y Diseño y Plan de Pruebas de Integración. ·. Construcción: Conjunto de actividades para producir Componente(s) de software que correspondan al Análisis y Diseño, así como la realización de pruebas unitarias. Como resultado se obtienen el (los) Componente(s) de software probados.. ·. Integración y Pruebas. Conjunto de actividades para integrar y probar los componentes de software, basadas en los Planes de Pruebas de Integración y de Sistema, con la finalidad de obtener el Software que satisfaga los requerimientos especificados. Se genera la versión final del Manual de Usuario, Manual de Operación y Manual de Mantenimiento. Como resultado se obtiene el producto de Software probado y documentado.. ·. Cierre: Integración final de la Configuración de Software generada en las fases para su entrega. Identificación y documentación de las Lecciones Aprendidas. Generación del Reporte de Mediciones y Sugerencias de Mejora.. Para generar los productos de cada una de estas fases se realizan las siguientes actividades: ·. Distribución de tareas, se asignan las responsabilidades de cada miembro del Equipo de Trabajo de acuerdo al Plan de Desarrollo.. ·. Producción, verificación, validación o prueba de los productos, así como su corrección correspondiente.. ·. Generación del Reporte de Actividades.. Objetivos O1 Lograr que los productos de salida sean consistentes con los productos de entrada en cada fase de un ciclo de desarrollo mediante las actividades de verificación, validación o prueba. O2 Sustentar la realización de ciclos posteriores o proyectos de mantenimiento futuros mediante la integración de la Configuración de Software del ciclo actual..

(29) 14. O3 Llevar a cabo las actividades de las fases de un ciclo mediante el cumplimiento del Plan de Desarrollo actual. Indicadores I1 (O1) En cada fase de un ciclo se efectúan todas las actividades de verificación, validación o prueba, así como las correcciones correspondientes. I2 (O2) La Configuración de Software está integrada por los productos generados en el ciclo. I3 (O3) Las actividades planificadas en cada fase de un ciclo se realizan conforme a lo establecido en el Plan de Desarrollo. Estos indicadores tienen asociadas unas Metas Cuantitativas que son valores numéricos o rangos de satisfacción por indicador. Responsabilidad y autoridad Responsable: ·. Responsable de Desarrollo y Mantenimiento de Software. Autoridad: ·. Responsable de Administración del Proyecto Específico. Procesos relacionados ·. Administración de Proyectos Específicos. ·. Conocimiento de la Organización. Entradas Nombre. Fuente. Plan de Desarrollo. Administración de Proyectos Específicos. • Descripción del Producto • Entregables • Proceso Específico • Equipo de Trabajo • Calendario Tabla 1.2 Entradas para el proceso de Desarrollo de Software Adaptado por: Los Autores.

(30) 15. Salidas Nombre. Descripción. Destino. Especificación. Se compone de una introducción y una Administración. de. descripción de requerimientos.. de. Requerimientos Introducción:. Proyectos. Descripción general del software y su uso en el Específicos ámbito de negocio del cliente. Descripción de requerimientos: ·. Funcionales:. Necesidades establecidas que debe satisfacer el software cuando es usado en condiciones específicas. Las funcionalidades deben ser adecuadas, exactas y seguras. ·. Interfaz con usuario:. Definición de aquellas características de la interfaz de usuario que permiten que el software sea fácil de entender, aprender, que genere satisfacción y con el cual el usuario pueda desempeñar. su. tarea. eficientemente.. Incluyendo la descripción del prototipo de la interfaz. ·. Interfaces externas:. Definición de las interfaces con otro software o con hardware. ·. Confiabilidad:. Especificación del nivel de desempeño del software con respecto a la madurez, tolerancia a fallas y recuperación..

(31) 16. Nombre. Descripción ·. Destino. Eficiencia:. Especificación del nivel de desempeño del software con respecto al tiempo y a la utilización de recursos. ·. Mantenimiento:. Descripción de los elementos que facilitarán la comprensión. y. la. realización. de. las. modificaciones futuras del software. ·. Portabilidad:. Descripción de las características del software que permitan su transferencia de un ambiente a otro. ·. Restricciones de diseño y construcción:. Necesidades impuestas por el cliente. ·. Legales y reglamentarios:. Necesidades impuestas por leyes, reglamentos, entre otros. Manual. de Documento electrónico o impreso que describe Administración. Mantenimiento la. de. Configuración de Software y el ambiente usado Proyectos para el desarrollo y pruebas (compiladores, Específicos herramientas de análisis y diseño, construcción y pruebas). Este deberá ser redactado en términos. comprensibles. al. personal. de. mantenimiento. Reporte Actividades. de Registro periódico de actividades, fechas de inicio y fin, responsables y mediciones, tales Administración como:. de.

(32) 17. Nombre. Descripción. Destino. ·. tiempo de producción, de corrección, de. Proyectos. ·. verificación y de validación,. Específicos. ·. defectos encontrados en verificación, validación o prueba,. ·. tamaño de productos.. Lecciones. Registro. Aprendidas. recurrentes y experiencias exitosas en la la Organización. de. mejores. prácticas,. problemas Conocimiento de. solución de problemas, encontrados en un ciclo de desarrollo y mantenimiento. Reporte Mediciones. de Registro que contiene: y. ·. Mediciones. de. Administración los. indicadores. del de. Sugerencias de. proceso de Desarrollo y Mantenimiento Proyectos. Mejora. de Software ·. Específicos. Sugerencias de mejora al proceso de Desarrollo y Mantenimiento de Software (métodos,. herramientas,. formatos,. estándares, etc.). Registro Rastreo. de Relación entre los requerimientos, elementos Administración análisis y diseño, componentes y planes de de pruebas.. Proyectos Específicos. Plan. de Identificación de pruebas requeridas para el Administración. Pruebas. de cumplimiento. Sistema. de. los. especificados.. requerimientos de Proyectos Específicos. Reporte. de Registro de participantes, fecha, lugar, duración Administración. Pruebas. de y de defectos encontrados.. Sistema. de Proyectos.

(33) 18. Nombre. Descripción. Destino Específicos. Plan. de Descripción que contiene:. Pruebas. ·. de Integración. El. orden. de. Administración integración. de. los de. componentes o subsistemas, guiado por Proyectos la parte arquitectónica del Análisis y Específicos Diseño. ·. Pruebas que se aplicarán para verificar la interacción entre los componentes.. Reporte. de Registro de participantes, fecha, lugar, duración Administración. Pruebas. de y de defectos encontrados.. Integración. de Proyectos Específicos. Tabla 1.3 Salidas para el proceso de Desarrollo de Software Adaptado por: Los Autores. Productos internos Nombre. Descripción. Reporte(s) de Verificación. Registro de participantes, fecha, lugar, duración y defectos encontrados.. Reporte(s) de Validación. Registro de participantes, fecha, lugar, duración y defectos encontrados.. Tabla 1.4 Productos Internos para el proceso de Desarrollo de Software Adaptado por: Los Autores. Referencias Bibliográficas Se citan todas las referencias que se utilicen para definir el proceso como libros, estándares, guías entre otros..

(34) 19. 1.1.3.2 Prácticas Roles involucrados y capacitación Rol. Abreviatura Capacitación. Responsable de. RAPE. Capacidad de liderazgo con experiencia en. Administración del. la. Proyecto Específico. estratégica,. toma. de. decisiones, manejo. de. planificación personal. y. desarrollo de software. Responsable de. RDM. Conocimiento. y. experiencia. Desarrollo y. desarrollo y mantenimiento de. Mantenimiento de. Software. en. el. en. la. Software Analista. AN. Conocimiento. y. experiencia. obtención, especificación y análisis de los requerimientos. Diseñador de Interfaz DU. Conocimiento en diseño de interfaces de. de Usuario. usuario y criterios ergonómicos.. Diseñador. DI. Conocimiento y experiencia en el diseño de la estructura de los componentes de software.. Programador. PR. Conocimiento programación,. y/o. experiencia. integración. y. en. la. pruebas. unitarias Responsable de. RPU. Pruebas. Conocimiento. y. experiencia. en. la. planificación y realización de pruebas de integración y de sistema.. Revisor. RE. Conocimiento en las técnicas de revisión y.

(35) 20. Rol. Abreviatura Capacitación experiencia. en. el. desarrollo. y. mantenimiento de software. Responsable de. RM. Conocimiento en las técnicas de redacción. Manuales. y. experiencia. en. el. desarrollo. y. mantenimiento de software. Equipo de Trabajo. ET. Conocimiento y experiencia de acuerdo a su rol.. Cliente. CL. Interpretación. del. estándar. de. la. especificación de requerimientos. Usuario. US. Ninguna. Tabla 1.5 Roles Involucrados para el proceso de Desarrollo de Software Adaptado: Los Autores. Actividades Rol. Descripción. A1. Realización de la fase de Inicio (O3) ET. A1.1. Revisar con los miembros del equipo de trabajo el Plan de Desarrollo actual para lograr un entendimiento común y obtener su compromiso con el proyecto.. RDM. A1.2. Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de inicio y fin, responsable por actividad y mediciones requeridas.. A2. Realización de la fase de Requerimientos (O1,O3) RDM AN. A2.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al Plan de Desarrollo actual.. AN. A2.2. Documentar o modificar la Especificación de Requerimientos.. CL. A2.3. Identificar y consultar fuentes de información (clientes, usuarios,.

(36) 21. Rol. Descripción. US. sistemas. previos,. DU. requerimientos.. documentos,. etc.). para. obtener. nuevos. A2.4. Analizar los requerimientos identificados para delimitar el alcance y su factibilidad, considerando las restricciones del ambiente del negocio del cliente o del proyecto. A2.5. Elaborar o modificar el prototipo de la interfaz con el usuario. A2.6. Generar o actualizar la Especificación de Requerimientos. RE. A2.7. Verificar la Especificación de Requerimientos (Ver 1).. AN. A2.8. Corregir los defectos encontrados en la Especificación de. DU. Requerimientos con base en el Reporte de Verificación y obtener la aprobación de las correcciones.. CL. A2.9. Validar la Especificación de Requerimientos (Val1).. US RPU AN. A2.10. Corregir los defectos encontrados en la Especificación de. DU. Requerimientos con base en el Reporte de Validación y obtener la aprobación de las correcciones.. RPU. A2.11. Elaborar o modificar Plan de Pruebas de Sistema.. AN RE. A2.12. Verificar el Plan de Pruebas de Sistema (Ver2).. RPU. A2.13. Corregir los defectos encontrados en el Plan de Pruebas de Sistema con base en el Reporte de Verificación y obtener la aprobación de las correcciones. A2.14. Documentar la versión preliminar del Manual de Usuario o. RM. modificar el manual existente.. RE. A2.15. Verificar el Manual de Usuario (Ver3).. RM. A2.16. Corregir los defectos encontrados en el Manual de Usuario con base en el Reporte de Verificación y obtener la aprobación de las.

(37) 22. Rol. Descripción correcciones.. RDM. A2.17. Incorporar Especificación de Requerimientos, Plan de Pruebas de Sistema y Manual de Usuario como líneas base a la Configuración de Software.. RDM. A2.18. Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de inicio y fin, responsable por actividad y mediciones requeridas.. A3. Realización de la fase de Análisis y Diseño (O1,O3) RDM. A3.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al Plan de Desarrollo actual.. AN DI AN DI. A3.2. Documentar o modificar el Análisis y Diseño: •. DU. Analizar la Especificación de Requerimientos para generar la descripción. de. la. estructura. interna. descomposición. en. subsistemas,. y. del. éstos. sistema a. su. y. su. vez. en. componentes, definiendo las interfaces entre ellos. •. Describir el detalle de la apariencia y el comportamiento de la interfaz con base en la Especificación de Requerimientos de forma que se puedan prever los recursos para su implementación.. •. Describir el detalle de los componentes que permita su construcción de manera evidente.. •. Generar o actualizar el Análisis y Diseño.. •. Generar o modificar el Registro de Rastreo.. RE. A3.3. Verificar el Análisis y Diseño y el Registro de Rastreo (Ver4).. AN. A3.4. Corregir los defectos encontrados en el Análisis y Diseño y en el. DI. Registro de Rastreo con base en el Reporte de Verificación y. DU. obtener la aprobación de las correcciones.. CL. A3.5. Validar el Análisis y Diseño (Val2)..

(38) 23. Rol. Descripción. RPU AN. A3.6. Corregir los defectos encontrados en el Análisis y Diseño con base. DI. en el Reporte de Validación y obtener la aprobación de las. DU. correcciones.. RPU. A3.7. Elaborar o modificar Plan de Pruebas de Integración.. RE. A3.8. Verificar el Plan de Pruebas de Integración (Ver5).. RPU. A3.9. Corregir los defectos encontrados en el Plan de Pruebas de Integración con base en el Reporte de Verificación y obtener la aprobación de las correcciones.. RDM. A3.10. Incorporar Análisis y Diseño, Registro de Rastreo y Plan de Pruebas de Integración como líneas base a la Configuración de Software.. RDM. A3.11. Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de inicio y fin, responsable por actividad y mediciones requeridas.. A4. Realización de la fase de Construcción (O1,O3) RDM. A4.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al Plan de Desarrollo actual.. PR. A4.2. Construir o modificar el(los) Componente(s) de software: ·. Implementar o modificar Componente(s) con base a la parte detallada del Análisis y Diseño.. ·. Definir. y. aplicar. pruebas. unitarias. para. verificar. que. el. funcionamiento de cada componente esté acorde con la parte detallada del Análisis y Diseño. ·. Corregir los defectos encontrados hasta lograr pruebas unitarias exitosas (sin defectos).. ·. Actualizar el Registro de Rastreo, incorporando los componentes construidos o modificados..

(39) 24. Rol. Descripción. RE. A4.3. Verificar el Registro de Rastreo (Ver6).. PR. A4.4. Corregir los defectos encontrados en el Registro de Rastreo con base en el Reporte de Verificación y obtener la aprobación de las correcciones.. RDM. A4.5. Incorporar Componentes y Registro de Rastreo como líneas base a la Configuración de Software.. RDM. A4.6. Elaborar el Reporte de Actividades, registrando las actividades realizadas, fechas de inicio y fin, responsable por actividad y mediciones requeridas.. A5. Realización de la fase de Integración y Pruebas (O1,O3) RDM. A5.1. Distribuir tareas a los miembros del equipo de trabajo según su rol, de acuerdo al Plan de Desarrollo actual.. PR RPU. A5.2. Realizar integración y pruebas. ·. Integrar los componentes en subsistemas o en el sistema del Software y aplicar las pruebas siguiendo el Plan de Pruebas de Integración, documentando los resultados en un Reporte de Pruebas de Integración.. ·. Corregir los defectos encontrados, con base en Reporte de Pruebas de Integración, hasta lograr una prueba de integración exitosa (sin defectos).. · RM. Actualizar el Registro de Rastreo.. A5.3. Documentar el Manual de Operación o modificar el manual existente.. RE. A5.4. Verificar el Manual de Operación (Ver7).. RM. A5.5. Corregir los defectos encontrados en el Manual de Operación con base en el Reporte de Verificación y obtener la aprobación de las correcciones..

(40) 25. Rol RPU. Descripción A5.6. Realizar las pruebas de sistema siguiendo el Plan de Pruebas de Sistema, documentando los resultados en un Reporte de Pruebas de Sistema.. PR. A5.7. Corregir los defectos encontrados en las pruebas de sistema con base en el. Reporte de Pruebas de Sistema y obtener la. aprobación de las correcciones. RM. A5.8. Documentar el Manual de Usuario o modificar el existente.. RE. A5.9. Verificar el Manual de Usuario (Ver8).. RM. A5.10. Corregir los defectos encontrados en el Manual de Usuario con base en el Reporte de Verificación y obtener la aprobación de las correcciones.. RDM. A5.11. Incorporar Software, Reporte de Pruebas de Integración, Registro de Rastreo, Manual de Operación y Manual de Usuario como líneas base a la Configuración de Software.. RDM. A5.12. Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de inicio y fin, responsable por actividad y mediciones requeridas.. A6. Realización de la fase de Cierre (O2) RM. Documentar el Manual de Mantenimiento o modificar el existente.. RE. Verificar el Manual de Mantenimiento (Ver9).. RM. Corregir los defectos encontrados en el Manual de Mantenimiento con base en el Reporte de Verificación y obtener la aprobación de las correcciones.. RDM. Incorporar Manual de Mantenimiento como línea base a la Configuración de Software.. RDM. Identificar las Lecciones Aprendidas e integrarlas a la Base de. ET. Conocimiento. Como ejemplo, se pueden considerar mejores prácticas, experiencias exitosas de manejo de riesgos, problemas recurrentes, entre.

(41) 26. Rol. Descripción otras.. RDM. Generar el Reporte de Mediciones y Sugerencias de Mejora.. ET RDM. Elaborar el Reporte de Actividades registrando las actividades realizadas, fechas de inicio y fin, responsable por actividad y mediciones requeridas. Tabla 1.6 Actividades para el proceso de Desarrollo de Software Adaptado por: Los Autores.

(42) 27. Diagrama de Flujo de Trabajo. Figura 1.6 Flujo de Trabajo del proceso Desarrollo y Mantenimiento de Software.[1].

(43) 28. Verificaciones y Validaciones Verificación Activid Producto o. Rol. Descripción. RE. Verificar la claridad de redacción. ad. validación Ver1. A2.3. Especificación de. de. la. Requerimientos. Requerimientos y su consistencia. Especificación. de. con la Descripción del Producto y con el estándar de documentación requerido. en. el. Proceso. Específico. Adicionalmente revisar que. requerimientos. los. completos. y. contradictorios.. sean. ambiguos. no. o. defectos. Los. encontrados se documentan en un Reporte de Verificación. Val1. A2.5. Especificación. CL,. Validar que la Especificación de. de. US,. Requerimientos cumple con las. Requerimientos RPU. necesidades. y. acordadas,. incluyendo. realización. de. usabilidad. de. expectativas la. la. la. prueba. de. interfaz. del. usuario. Los defectos encontrados se documentan en un Reporte de Validación. Ver2. A2.8. Plan. de RE. Verificar consistencia del Plan de. de Sistema. Especificación de Requerimientos con. el. Sistema. la. Pruebas y. de. con. Pruebas. estándar. de.

(44) 29. Verificación Activid Producto o. Rol. Descripción. ad. validación documentación requerido en el Proceso Específico. Los defectos encontrados se documentan en un Reporte de verificación. Ver3. A2.11. Manual de. RE. Verificar consistencia del Manual de Usuario con la Especificación. Usuario. de. y. Requerimientos. estándar requerido. de. el. documentación. en. el Los. Específico.. con. Proceso defectos. encontrados se documentan en un Reporte de Verificación. Ver4. A3.3. Análisis. y RE. Verificar. claridad. de. la. Diseño. documentación del. Registro de. Análisis y Diseño, su factibilidad y. Rastreo. la. consistencia. con. la. Especificación de Requerimientos y. con. el. estándar. de. documentación requerido en el Proceso Específico. Verificar que el Registro de Rastreo contenga las relaciones adecuadas entre los requerimientos y los elementos de Análisis y Diseño. Los defectos encontrados se documentan en un Reporte de Verificación..

(45) 30. Verificación Activid Producto o. Rol. Descripción. ad. validación Val2. A3.5. y CL,. Análisis. RPU. Diseño. Validar que el Análisis y Diseño cumple con las necesidades y expectativas. acordadas. con. el. cliente. Los defectos encontrados se documentan en un Reporte de Validación. Ver5. A3.8. Plan. de RE. Verificar consistencia del Plan de. Pruebas. Pruebas de Integración con el. de Integración. Análisis y Diseño y con el estándar de documentación requerido en el Proceso Específico. Los defectos encontrados se documentan en un Reporte de Verificación.. Ver6. A4.3. Registro de. RE. Verificar. que. el. Registro. de. Rastreo contenga las relaciones. Rastreo. adecuadas entre los elementos de Análisis. Diseño. y. componentes.. Los. y. los. defectos. encontrados se documentan en un Reporte de Verificación. Ver7. A5.4. Manual de Operación. RE. Verificar consistencia del Manual de Operación con el Software y con el estándar de documentación requerido Específico.. en. el Los. Proceso defectos. encontrados se documentan en un Reporte de Verificación..

(46) 31. Verificación Activid Producto. Rol. Descripción. RE. Verificar consistencia del Manual. ad. o validación Ver8. A5.9. Manual de Usuario. de. Usuario con el sistema de. Software y con el estándar de documentación. requerido en el. Proceso Específico. Los defectos encontrados se documentan en un Reporte de Verificación. Ver9. A6.2. Manual de. RE. Mantenimiento. Verificar consistencia del Manual de. Mantenimiento. con. la. Configuración de Software y con el estándar requerido. de. documentación. en. Específico.. el Los. Proceso defectos. encontrados se documentan en un Reporte de Verificación. Tabla 1.7 Verificaciones y Validaciones para el proceso de Desarrollo de Software Adaptado por: Los Autores. Incorporación a la Base de Conocimiento Producto. Forma de aprobación. Especificación de Requerimientos. Ver1, Val1. Plan de Pruebas de Sistema. Ver2. Manual de Usuario. Ver3. Análisis y Diseño. Ver4, Val2. Registro de Rastreo. Ver4. Plan de Pruebas de Integración. Ver5.

(47) 32. Producto. Forma de aprobación. Componente(s). Prueba unitaria exitosa. Registro de Rastreo. Ver6. Software. Prueba de integración exitosa, prueba de sistema exitosa. Manual de Operación. Ver7. Manual de Usuario. Ver8. Manual de Mantenimiento. Ver9. Reporte de Pruebas de Integración. Ninguna. Reporte de Pruebas de Sistema. Ninguna. Reporte(s) de Actividades. Ninguna. Lecciones Aprendidas. Ninguna. Reporte(s) de Verificación. Ninguna. Reporte(s) de Validación. Ninguna. Tabla 1.8 Incorporación a la base de conocimiento para el proceso de Desarrollo de Software Adaptado por: Los Autores. Recursos de Infraestructura Actividad. Recurso. A1, A2, A3,. Herramienta para documentación. A4, A5, A6 A2. Herramientas para la Especificación de Requerimientos. A3. Herramientas para el Análisis y Diseño.. A4. Herramientas para la construcción.. A4, A5. Herramientas para la realización de pruebas Tabla 1.9 Recursos de Infraestructura para el proceso de Desarrollo de Software.

(48) 33. Elaborado por: Los Autores. Mediciones Al final de cada ciclo se genera un reporte del estado de los indicadores del proceso con respecto a las metas cuantitativas definidas, se sugieren las siguientes mediciones: M1. (I1) Revisar los Reportes de Verificación, Reportes de Validación y/o reportes de pruebas de cada fase para la confirmación de que se han realizado estas actividades y se han incorporado las correcciones. M2. (I2) Revisar la Configuración de Software para comprobar que los productos que la integran son los mismos que se generaron en el ciclo. M3. (I3) Comparar el Plan de Desarrollo actual para cada fase con el Reporte de Actividades correspondiente para conocer la desviación contra lo planificado. Capacitación El RDM deberá ofrecer las facilidades para que el personal que está involucrado en el proceso de Desarrollo y Mantenimiento de Software participe en las actividades del Plan de Capacitación actual de la Base de Conocimiento. Situaciones excepcionales Los roles involucrados en el proceso de Desarrollo y Mantenimientos de Software deberán notificar al RDM, de manera oportuna, las situaciones que les impidan el desarrollo de las actividades asignadas. El RDM deberá dar respuesta a estas situaciones y en caso de no poder resolverlas o no sean de su competencia deberá escalarlas al RAPE. Lecciones aprendidas Antes de iniciar las actividades asignadas, los roles involucrados en el proceso de Desarrollo y Mantenimientos de Software deberán consultar las Lecciones Aprendidas de la Base de Conocimiento para aprovechar la experiencia de la organización y disminuir la posibilidad de incurrir en problemas recurrentes..

(49) 34. 1.1.3.3 Guías de ajuste Requerimientos: Especificación de Requerimientos La Especificación de Requerimientos puede incluir un prototipo de interfaz con el usuario sencilla, que inclusive no tenga funcionalidad. Requerimientos: Manual de Usuario En la fase de Requerimientos se puede omitir la elaboración o actualización del Manual del Usuario, así como su verificación. Sin embargo esta actividad se deberá realizar a más tardar en la fase de integración y pruebas. Requerimientos: Plan de Pruebas de Sistema El Plan de Pruebas de Sistema se puede validar con el cliente, en caso que se acuerde con él. Análisis y Diseño: Análisis y Diseño En caso que se acuerde con el cliente, se puede omitir la validación del Análisis y Diseño. Construcción: Revisión entre colegas del código Antes de realizar pruebas unitarias se pueden incluir revisiones entre colegas para verificar el código de los componentes con respecto al Análisis y Diseño. El beneficio de estas revisiones es la disminución del número de defectos de fases posteriores y el tiempo de corrección. Construcción: Pruebas unitarias Las pruebas unitarias se pueden definir de manera sistemática y documentada siguiendo el estándar IEEE8 Std. 1008-1987 (R 1993) Standard for Software Unit Testing. Construcción: Prototipo de interfaz En la fase de Construcción se puede agregar la elaboración o modificación del prototipo de la interfaz para realizar una prueba con el usuario, con el fin de identificar defectos críticos de uso. Si no se cuenta con los usuarios para la prueba de interfaz puede recurrirse a la revisión de un experto o se pueden escoger individuos de un perfil similar. 8. Institute of Electrical and Electronics Engineers.

(50) 35. Reporte de Actividades Las mediciones requeridas en el Reporte de Actividades pueden ser modificadas de acuerdo a las necesidades de la organización o del proyecto.. 1.2 MÉTODO. DE. EVALUACIÓN. DE. PROCESOS. PARA. LA. INDUSTRIA DEL SOFTWARE EVALPROSOFT. 1.2.1 INTRODUCCIÓN El Método de Evaluación de procesos para la industria de software EvalProSoft otorga a la organización solicitante un perfil del nivel de capacidad de los procesos implantados y un nivel de madurez de capacidades de la organización. El Método de Evaluación involucra al Organismo Rector y a la organización a evaluar, cuya relación se ilustra en la Figura 1.7. Figura 1.7 Relación entre los elementos del Método de Evaluación.[2]. La organización selecciona a un Evaluador Certificado reconocido por el Organismo Rector. El Evaluador Certificado dirige el proceso de evaluación en función de los datos de la organización. Del proceso de evaluación se obtiene un reporte de resultados para la organización y un reporte estadístico para el Organismo Rector. En el reporte de resultados se documenta el perfil del nivel de capacidad de los procesos y un nivel de madurez de capacidades, así como el resumen de hallazgos.

(51) 36. detectados. En el reporte estadístico se proporciona la información general de la organización evaluada, los resultados de la evaluación y las lecciones aprendidas sobre el Método de Evaluación y su modelo de procesos de referencia, MoProSoft. 1.2.2 ALCANCE DE EVALPROSOFT El Método de Evaluación, EvalProSoft, es aplicable en las organizaciones dedicadas al desarrollo y/o mantenimiento de software. En particular a las que han utilizado como modelo de procesos de referencia a MoProSoft para la implantación de sus procesos; aunque también puede ser usado para evaluar los procesos de una organización que no haya tomado como referencia a MoProSoft ya que para la realización del modelo se tomaron en cuenta los siguientes requerimientos: ·. El uso del Modelo de Procesos para la Industria de Software, MoProSoft V1.1, como modelo de procesos de referencia.. ·. El uso del Modelo de Capacidades de Proceso de la ISO/IEC 15504-2 Performing an assesment.. ·. El cumplimiento de los requisitos de la ISO/IEC 15504-2 Performing an assesment en el Método de Evaluación.. ·. El uso de ISO/IEC TR 15504-4 Guidance on performing an assesment como guía.. 1.2.3 USOS DEL MÉTODO DE EVALUACIÓN EvalProSoft presenta varios posibles usos para método de evaluación, así como para sus resultados, esto dependiendo de cuál sea el motivo por el cual se realizara la evaluación. 1.2.3.1 Posibles usos del Método de Evaluación ·. Evaluación para la acreditación de capacidades, es cuando una organización solicita a un Evaluador Certificado la realización de la evaluación para obtener un perfil del nivel de capacidad de los procesos implantados y un nivel de madurez de capacidades..

(52) 37. ·. Evaluación de capacidades del proveedor, es cuando un cliente solicita a un Evaluador Certificado la realización de una evaluación para obtener un perfil del nivel de capacidad de los procesos implantados por el proveedor de desarrollo y mantenimiento de software. El cliente elige los procesos a evaluar dependiendo del servicio a contratar.. ·. Auto-evaluación de capacidades de proceso, es cuando una organización o el Representante de un proyecto realiza una evaluación por personal interno o externo que no necesariamente sea Evaluador Certificado para evaluar los procesos implantados o el proceso de un proyecto específico. En este caso no interviene el Organismo Rector.. 1.2.3.2 Posibles usos de los resultados de las evaluaciones ·. La evaluación para la acreditación de capacidades sirve a la organización para obtener un estado certificado del perfil del nivel de capacidad por proceso, el cual puede usarse como base para la elaboración del plan de mejora. Mientras que el nivel de madurez de capacidades de la organización puede usarse como comparativo con respecto a otras organizaciones del mercado. El reporte estadístico de la evaluación para la acreditación de capacidades permite que el Organismo Rector elabore un diagnóstico de las capacidades de la industria de software.. ·. La evaluación de capacidades del proveedor sirve para que un cliente seleccione a un proveedor.. ·. La auto-evaluación de capacidades de proceso sirve a la organización para obtener un perfil del nivel de capacidad por proceso o por proyecto. Puede ser la base para elaborar el plan de mejora de la organización y mejorar el desarrollo de nuevos proyectos..

(53) 38. CAPITULO 2 ANÁLISIS DEL MÉTODO DE EVALUACIÓN DE PROCESOS PARA LA INDUSTRIA DEL SOFTWARE EVALPROSOFT. 2.1. DESCRIPCIÓN GENERAL DEL MÉTODO DE EVALUACIÓN.. El Método de Evaluación hace uso de MoProSoft como modelo de procesos de referencia y de un modelo de capacidades, que se utiliza para calificar el nivel de capacidad de los procesos. La Ilustración 2.1 muestra la relación entre los elementos que intervienen en el Proceso de EvalProSoft.. Figura 2.1 Relación de elementos del Método de Evaluación. [2] El proceso de evaluación considera las condiciones para iniciar una evaluación, las actividades de planeación, ejecución, generación y entrega de resultados y el cierre. En este proceso se involucran roles con responsabilidades específicas. El rol que.

(54) 39. dirige la evaluación es el Evaluador Certificado que cumple con un perfil definido y cuenta con una acreditación de su competencia. 2.1.1 MODELO DE CAPACIDADES DE PROCESOS La capacidad de proceso se evalúa en una escala de 0 a 5. El valor cero se asocia al nivel de capacidad más bajo, y significa que no se alcanza el propósito del proceso. El valor 5 se asocia al nivel de capacidad más alto y significa que se logran las metas de negocio actuales y proyectadas a través de la optimización y mejora continua del proceso. La medición de capacidad se obtiene a través de un conjunto de atributos de procesos (AP), los cuales se usan para determinar cuando un proceso ha alcanzado una capacidad. Cada atributo mide un aspecto particular de un proceso. 2.1.1.1 Descripción de niveles de capacidad y atributos respectivos A continuación se presenta la descripción de cada nivel de capacidad y los atributos que lo caracterizan. Nivel 0. Proceso Incompleto El proceso no está implantado o falla en alcanzar el propósito del proceso. Nivel 1: Proceso Realizado El proceso implantado logra su propósito AP 1.1 Atributo de realización del proceso Este atributo es completamente alcanzado cuando: a) el proceso obtiene los resultados definidos. Nivel 2: Proceso Administrado El proceso Realizado se implanta de manera administrada y sus productos de trabajo están apropiadamente establecidos, controlados y mantenidos..

(55) 40. AP 2.1 Atributo de administración de la realización Este atributo es completamente alcanzado cuando: a) los objetivos de desempeño del proceso están definidos b) el desempeño del proceso está planeado y monitoreado c) el desempeño del proceso está ajustado de acuerdo con lo planeado d) las responsabilidades y autoridades para el desempeño del proceso están definidas, asignadas y comunicadas e) están identificados, disponibles, asignados y utilizados los recursos e información necesaria para el desempeño del proceso f) las interfaces entre las partes involucradas están administradas para asegurar la comunicación efectiva y también para la asignación clara de las responsabilidades AP 2.2 Atributo de administración del producto de trabajo Este atributo es completamente alcanzado cuando: a) los requerimientos para los productos de trabajo del proceso están definidos b) los requerimientos para la documentación y control de los productos de trabajo están definidos c) los productos de trabajo están apropiadamente identificados, documentados y controlados d) los productos de trabajo están revisados en concordancia con los planes y son ajustados si es necesario con base en los requerimientos.