Formalizar el proceso relacionado con la administración de proyectos, requeridos en la prestación del servicio a los clientes de la empresa Cero K S A S

Texto completo

(1)INFORME FINAL - PRÁCTICA DE GRADO NORMA ISO 29110. María Angélica Vargas Molina Código: 1087995599. Director proyecto: Julio César Chavarro Porras. Universidad Tecnológica de Pereira Ingeniería de sistemas y computación Proyecto de grado - Práctica universitaria.

(2) NORMA ISO 29110. Este informe inicia con la descripción de la norma ISO/IEC 29110 del 2011, la cual es la que la empresa Cero K ha venido aplicando y con la cual enfatizo la práctica de grado: Ésta norma reúne las buenas prácticas, perfiles del ciclo de vida, guía de estándares y reportes técnicos para pequeñas organizaciones (VSEs) de ingeniería del software. Fue creada pensando en que la mayoría de estándares internacionales disponibles no tienen en cuenta las necesidades de las VSEs, por lo que resulta difícil y costoso adoptarlos; por lo tanto esto resta posibilidades de reconocimiento y hace que estas organizaciones sean descartadas en algunas ocasiones de ciertas actividades económicas. Se debe reconocer que las VSEs que desarrollan y mantienen software dominan ésta actividad económica, aportan valor y son reconocidas por el mercado, aunque no cuentan con un “sello” de calidad, que soporte su competitividad. Los estándares fueron desarrollados por el grupo de trabajo 24 (WG24) del sub-comité 7 (SC7) del Comité Técnico Conjunto 1 (JTC1) de la Organización Internacional para la Estandarización (ISO) y la Comisión Electrotécnica Internacional (IEC) en el año 2011. Su desarrollo sigue vigente y participan activamente más de 20 países. Al adoptar ésta norma se tienen los siguientes beneficios: ● ● ● ● ● ●. Proporciona mayor confianza y satisfacción de los clientes Ayuda a mejorar la calidad del software Disminuye los riesgos del desarrollo Aumenta la competitividad de la empresa Facilita la comercialización Mejora el potencial para exportar. Además, cuenta con los siguientes atributos: ● ● ● ●. ●. El respaldo de dos organizaciones de cobertura y reconocimiento internacional: La ISO y la IEEE. Menores costos de implementación por estar diseñada desde su origen para VSEs, ser más “liviana”, e incluir “Deployment Packages”. Compatible con y migrable a otros modelos (CMMI, Moprosoft, MpsBR e ISO/IEC 12207, entre otros). Escalable, “Niveles de Madurez”, a través de los perfiles, lo que permite un mejoramiento gradual, al ritmo de las necesidades y capacidades de una organización. Incluye un esquema de evaluación y certificación internacional..

(3) Los procesos del ciclo de vida definidos en la ISO/IEC 29110 pueden ser utilizados por una VSE al adquirir y utilizar, así como al crear y suministrar software. Éstos pueden aplicarse a cualquier nivel en la estructura de un sistema de software y en cualquier etapa del ciclo de vida. Se deben tener en cuenta los siguientes términos y definiciones: ● ● ● ●. ● ●. ● ● ● ● ● ● ● ● ● ● ● ●. ●. Actividad: Conjunto de tareas de un proceso Indicador de evaluación: Fuentes de evidencia objetiva utilizadas para respaldar el juicio de los evaluadores en los atributos del proceso de calificación. Asesor: Individuo que participa en la calificación de los atributos del proceso. Línea base: Especificaciones o productos que han sido formalmente revisados y acordados, los cuales sirven como base para un mayor desarrollo y que solo se pueden cambiar a través de procedimientos formales de control de cambios. Base estándar: Aprobación de la norma Internacional o sector de normalización de las telecomunicaciones de la unión internacional de telecomunicaciones (UIT-T) Asesor competente: Evaluador que ha demostrado las competencias para realizar una evaluación, para supervisar y verificar la conformidad de una evaluación del proceso. Cliente: Organización o persona que recibe un producto o servicio. Paquete de implementación: Conjunto de artefactos desarrollados para facilitar la implementación de un conjunto de prácticas del marco seleccionado. Grupo de perfil genérico: Grupo de perfiles aplicable a los VSE que no desarrollan productos de software críticos y tienen factores situacionales típicos. Guía: Documento publicado por ISO o IEC que proporciona reglas, orientación, asesoramiento o recomendaciones relacionadas con la normalización internacional. Estándar internacional: Estándar adoptado por una organización internacional de estandarización y puesto a disposición del público. Perfil estandarizado: Acuerdo internacional armonizado que describe uno o más perfiles. Ciclo de vida: Evolución de un sistema, producto, servicio, proyecto u otra entidad creada por el hombre desde el inicio hasta el fin. Proceso: Conjunto de actividades interrelacionadas o interactivas que transforma las entradas en salidas. Evaluación de procesos: Evaluación disciplinada de los procesos de una unidad organizacional contra un Modelo de Evaluación de Procesos. Modelo de evaluación de procesos: Modelo adecuado para el propósito de evaluar la capacidad del proceso, basado en uno o más modelos de referencia de proceso. Capacidad del proceso: Caracterización de la capacidad de un proceso para cumplir los objetivos comerciales actuales o proyectados. Nivel de capacidad del proceso: Indica en la escala ordinal de seis puntos (de la capacidad del proceso) que representa la capacidad del proceso, cada nivel se basa en la capacidad del nivel siguiente. Mejora de procesos: Acciones tomadas para cambiar los procesos de una organización para que cumplan de manera más efectiva y/o eficiente los objetivos comerciales de la organización..

(4) ● ● ●. ●. ● ● ● ● ● ● ●. ● ● ●. ● ●. ●. Resultado del proceso: Resultado observable de un proceso. Perfil del proceso: Conjunto de calificaciones de atributos de proceso para un proceso evaluado. Modelo de referencia de proceso: Modelo que comprende definiciones de procesos en un ciclo de vida descrito en términos de propósito del proceso y resultados, junto con una arquitectura que describe las relaciones entre los procesos. Perfil: Conjunto de uno o más estándares y/o perfiles básicos y cuando corresponda la identificación de clases elegidas, subconjuntos conformes, opciones y parámetros de esos estándares base o perfiles estandarizados necesarios para cumplir una función particular. Grupo de perfil: Colección de perfiles que están relacionados por composición de procesos (es decir, actividades, tareas) o por nivel de capacidad, o ambos. Proyecto: Proceso con fechas de inicio y finalización definidas para crear un producto o servicio de acuerdo con los recursos y requisitos especificados. Registro: Documento que establece los resultados logrados o proporciona evidencia de las actividades realizadas. Informe: Elemento de información que describe los resultados de actividades tales como investigaciones, evaluaciones y pruebas. Repositorio: Colección de todos los artefactos relacionados con el software que pertenecen a un sistema o la ubicación/formato en que se almacena dicha colección. Recurso: Activo que se utiliza o consume durante la ejecución de un proceso. Revisión: Proceso o reunión durante la cual se presenta un producto de software al personal del proyecto, gerentes, usuarios, clientes, representantes de usuarios u otras partes interesadas para comentarios o aprobación. Software: Programas informáticos, procedimientos y, posiblemente, documentación asociada y datos relacionados con el funcionamiento de un sistema informático. Componentes de software: Sistema o elemento de software, como módulo, unidad, datos o documento. Estándar: Documento, establecido por consenso y aprobado por un reconocido grupo, que ofrece para uso común y repetido, reglas, directrices o características para realizar actividades o sus resultados, dirigido a los logros de óptimo grado de orden en un contexto dado. Taxonomía: Esquema de clasificación de perfiles de referencia o conjuntos de perfiles inequívocamente Informe técnico: Documento publicado por la ISO o IEC que contiene una colección de datos de un tipo diferente del normalmente publicado como un Estándar Internacional o Producto Técnico. Trazabilidad del registro: - Identifica requisitos para ser trazados - Identifica un análisis de requisito al ciclo de vida del producto trabajado - Proporciona el enlace de los requisitos para trabajar la descomposición del producto (requisito, diseño, código, pruebas, entregables, etc.) - Ofrece trazado de antes y después del análisis de los requisitos asociados al productivo trabajado a lo largo de todas las fases del ciclo de vida..

(5) ● ● ● ● ● ●. Tarea: Requisito, recomendación o acción permitida que permite el logro de uno o más resultados del proceso. Usuario: Individuo o grupo que se benefician de un sistema durante su utilización. Validación: Confirmación a través la provisión de la evidencia del objetivo, que se cumplan los requisitos para el uso o solicitud específica. Verificación: Confirmación a través dela provisión de la evidencia del objetivo, que se cumplan los requisitos especificados. VSE: Entidad muy pequeño de hasta 25 empleados. Producto trabajado: Método asociado con la ejecución de un proceso.. Las VSE se describen a través de las siguientes características, necesidades y competencias deseables, clasificadas en cuatro categorías: finanzas y recursos, interfaz con el cliente, procesos empresariales internos y aprendizaje y crecimiento. Algunos beneficios considerados para usar la ISO / IEC 29110 son: ● Buenos procesos internos de administración de software ● Mayor confianza y satisfacción del cliente ● Mayor calidad del producto de software ● Mayor patrocinio para la mejora de procesos ● Menor riesgo de desarrollo Cabe aclarar que estos beneficios pueden ayudar a aumentar la competitividad y la cuota de mercado.. Modelos y etapas del ciclo de vida de un software: La vida útil de un sistema o producto de software puede modelarse mediante un modelo de ciclo de vida compuesto por etapas. Los modelos se pueden usar para representar toda la vida desde el concepto hasta la eliminación o para representar la parte de la vida correspondiente al proyecto. El modelo del ciclo de vida se compone de una secuencia de etapas que pueden superponerse o repetirse, según corresponda para el alcance del proyecto, la magnitud, la complejidad, las necesidades cambiantes y las oportunidades. Cada etapa se describe con una declaración de propósito y resultados. Los procesos y actividades del ciclo de vida se seleccionan y emplean en una etapa para cumplir con el propósito y los resultados de esa etapa. Esta norma internacional no requiere el uso de ningún modelo de ciclo de vida particular. Sin embargo, sí requiere que cada proyecto define un modelo de ciclo de vida adecuado, preferiblemente uno que haya sido definido por la organización para su uso en una variedad de proyectos. La aplicación de un modelo de ciclo de vida proporciona los medios para establecer la secuencia dependiente del tiempo necesaria para la gestión del proyecto.

(6) El uso de tipos de productos genéricos simplifica la aplicación de estructura, contenido y formatos coherentes para elementos de información similares (registros y documentos) para respaldar la usabilidad. ISO / IEC 29110 define los datos del ciclo de vida de ISO / IEC 12207: 2008 e ISO / IEC 15288: 2008 al relacionar las tareas y actividades con los tipos de elementos de información genérica que se indican a continuación:. TIPO. PROPÓSITO. MUESTRA DE TIPOS DE INFORMACIÓN DE SALIDA RECOMENDADOS. Registro. Caracterizar los datos que una entidad organizacional retiene.. Registro de configuración Registro de problema. Descripción. Representar una función planificada o real, diseño o elemento.. Descripción de diseño de software de alto nivel. Plan. Definir cuándo, cómo y quién debe realizar las actividades específicas. Plan de gestión de proyectos. Procedimiento. Defina en detalle cuándo y cómo realizar ciertas actividades o tareas, incluidas las herramientas necesarias.. Procedimiento de resolución de problemas. Informe. Describa los resultados de actividades tales como investigaciones, evaluaciones y pruebas. Informe de problema Informe de validación. Solicitud. Registre la información necesaria para solicitar una respuesta.. Solicitud de cambio. Especificación. Especifique una función, rendimiento o proceso requerido (como, especificación de requisitos, estándar, política).. Especificación de Requerimientos de Software.

(7) Conceptos de mejora y evaluación de procesos: El concepto de mejora del proceso es animar a los equipos de proyecto de VSE a implementar enfoques sistemáticos que permitan la repetición y el realismo al estimar e implementar un proyecto. Las evaluaciones periódicas y la comunicación (interna y externa) del progreso del proyecto garantizarán la satisfacción del cliente. Los conceptos de mejora de procesos caracterizan todas las acciones emprendidas para mejorar los procesos de una organización tanto para aumentar su eficiencia como para cumplir los objetivos comerciales de la organización. Las actividades de mejora de procesos se abordan en ISO / IEC 15504 e ISO / IEC 29110-3. Debido a que para una VSE es fácil comprometerse demasiado con un proyecto de cliente específico basado en sus recursos limitados. Las evaluaciones periódicas y la comunicación (interna y externa) del progreso del proyecto ayudarán a garantizar la satisfacción del cliente.. Conceptos de evaluación: El concepto de evaluación se refiere a la determinación de la medida en que los procesos de la organización contribuyen al logro de sus objetivos comerciales y a ayudar a la organización a enfocarse en la necesidad de mejorar los procesos. Por ejemplo, la evaluación puede ser formal o informal, usar un evaluador externo o un evaluador interno, usar una lista de verificación estándar o entrevistas al personal, etc. Las evaluaciones tradicionales pueden ser muy costosas. Las actividades previas a la evaluación, como: la preparación de documentos para demostrar que el trabajo se ha realizado correctamente, la asignación del tiempo del personal para su revisión y el manejo interno de la evaluación puede ser una pérdida de recursos en un VSE. Un método más simple para los VSE puede ser una combinación de autoevaluación y controles puntuales para verificar las prácticas reales seguidas, sin tener un asesor independiente para una evaluación completa. Sin embargo, se puede argumentar que el VSE debe hacer una evaluación para satisfacer las inquietudes de los clientes, independientemente de si se busca una certificación formal de un estándar. Respecto a la estandarización de conceptos, los Estándares de Ingeniería de Software tienen varios objetivos: ● ● ● ●. Proporcionar un marco común y vocabulario para los profesionales del proyecto de software. Proporcionar un marco para los acuerdos entre las dos partes Mejorar y evaluar la competencia del software Facilitar el proceso del software o la evaluación del producto..

(8) Informes Técnicos: Los Informes Técnicos son documentos publicados por ISO / IEC JTC 1 que contienen datos recopilados de un tipo diferente al publicado normalmente como Norma Internacional o Especificación Técnica. Contiene información que ayuda a comprender y usar la parte normativa de un estándar.. Perfil: Conjunto de uno o más estándares base y/o perfiles estandarizados y cuando corresponda, la identificación de clases elegidas, subconjuntos conformes, opciones y parámetros de esos estándares base, o perfiles estandarizados necesarios para cumplir una función particular.. Grupo de perfil: Un grupo de perfiles (PG) es una colección de perfiles que están relacionados ya sea por composición de procesos (es decir, actividades, tareas), o por nivel de capacidad, o ambos. La amplificación de estas características se proporciona en ISO/IEC 29110-2. Grupo de perfil genérico: El grupo de perfil genérico es aplicable a los VSE que no desarrollan productos de software críticos. El grupo de perfil genérico no implica ningún dominio de aplicación específico. La amplificación de estas características se proporciona en ISO/IEC 29110-2.. Guías: Las guías proporcionan información práctica para facilitar la implementación y la evaluación de la implementación de los perfiles definidos. De acuerdo con JTC 1, las guías se publican como Informes Técnicos. Uso de perfiles: Los perfiles están diseñados para ser utilizados por una VSE para implementar funcionalidades específicas a través del uso de guías publicadas como Informes Técnicos. Como mínimo, cada Perfil de la serie ISO / IEC 29110 se vincularía a una Guía de evaluación y a una o más guías de implementación..

(9) DOCUMENTACIÓN PROYECTO NORMA ISO/IEC 29110. Durante la práctica desarrollada, realicé el liderazgo de varios proyectos en el cual se debía cumplir con documentos estándar para aplicar la norma ISO/IEC 29110. En el documento “2016-02-10 Instructivo para llevar a cabo la norma ISO 29110 V.1” se puede consultar el instructivo para llevar a cabo la norma.. En la carpeta “Documentos” se relaciona las plantillas que se utilizaron.. CONCLUSIÓN: Esta norma contiene directrices de implementación sobre cómo llevar a cabo los procesos para alcanzar los niveles de madurez; por ejemplo, actividades recomendadas, medidas, técnicas, plantillas, modelos, métodos, etc. La ISO/IEC 29110, a pesar que es un estándar orientado a pequeñas empresas, aplica perfectamente para iniciar el proceso para certificar y mejorar procesos de desarrollo de software, la cual brinda un marco fácil y detallado a seguir, para que el desarrollo de software cuente con las herramientas requeridas que permitan la entrega de un producto de gran calidad y disminución de costos por errores y/o re-procesos..

(10) GESTIÓN DEL PROYECTO Para documentar el modelo de procesos utilizado durante el ciclo de vida del proyecto, se utilizó el modelo de procesos BMP, el cual representa los procesos y actividades que componen un macro proceso y permite definir con alto nivel de detalle la forma como se desagrega hasta la descripciòn de cada actividad. Este conjunto de actividades permite describir, en nuestro caso, los procesos que deben seguirse en las diferentes etapas del proyecto y sus actividades. Ademá permite la creación de uno o más modelos para la representación, comunicación, análisis, diseño, síntesis, toma de decisiones y control de un negocio. El modelado de procesos de negocios tiene como objetivo facilitar la comprensión del funcionamiento interno de la organización – de extremo a extremo – y para ello, se utilizan varios artefactos tales como organigramas, diagramas de posicionamiento, flujos de procesos, entre otros, que proporcionan una visión general de las actividades realizadas diariamente por los empleados, creando una base para estudios, mejora de procesos, estimaciones de costos y para la correcta comprensión de los procesos de negocio. A continuación se relaciona el modelo realizado y la respectiva documentación:. INTRODUCCIÓN Propósito. Gestionar los nuevos productos/servicios o las nuevas solicitudes del producto/servicio. Alcance. Todos los nuevos productos/servicios o las nuevas solicitudes del producto/servicio de la organización y que llegan a la organización respectivamente.. Políticas de Calidad. Los requisitos de los productos/servicios deben asegurar que dichos requisitos estén alineados con los planes de trabajo y los productos de trabajo.. Responsables. Rol. Competencias Necesarias.

(11) Cliente (CUS). ●. ● ●. Analista (AN). ●. ●. ●. Diseñador (DES). ●. ●. ●. Desarrollador (PR). ●. ●. ●. Conocimiento de los procesos y capacidad para explicar los requerimientos del cliente. Tener la autoridad para aprobar los requisitos y sus cambios. Incluir representantes de usuarios para garantizar que el ambiente operacional es funcional. Conocimiento y experiencia en especificación y análisis de los requisitos. Conocimiento en: - Diseño de interfaces de usuario y criterios ergonómicos. - Revisiones técnicas. - Técnicas de edición. Experiencia en el desarrollo y mantenimiento de software. Conocimiento y experiencia en: - Los Componentes de Software y diseño arquitectónico - Planificación y desempeño de pruebas de integración. Conocimiento en: - Técnicas de revisión. - Técnicas de edición. Experiencia en el desarrollo y mantenimiento de software. Conocimiento y/o experiencia en programación, integración y pruebas unitarias Conocimiento de: - Técnicas de revisión - Técnicas de edición Experiencia en el desarrollo y mantenimiento de software.

(12) Gerente del proyecto (PM). ●. Capacidad de liderazgo con experiencia en la toma de decisiones, planificación, gestión de personal, delegación y supervisión, finanzas y desarrollo de software.. Líder Técnico. ●. Conocimiento y experiencia dominio de procesos de software. Grupo de Trabajo (WT). ●. Conocimiento y experiencia según sus roles en el proyecto: TL, AN, DES, y / o PR Conocimiento sobre los estándares utilizados por el Cliente y / o por el VSE. ●. Procesos / Procedimientos Relacionados Herramientas Recursos. ● ● ●. Gestión comercial Gestión de calidad Gestión postventa. y Documentación según la norma ISO/IEC 29110. Entradas. Petición de Nuevos Servicios o Proyectos. Salidas. Software desarrollado (SAIA). en.

(13) DIAGRAMA DE FLUJO. DESCRIPCIÓN PROCESO Secuencia 1.1. Detalle Actividad. Socialización del proyecto con el cliente. Responsable. Cliente (CUS) Gerente del proyecto (PM). Entrada. Servicio o producto solicitado.. Herramientas. PLANTILLA - Inicio de Proyecto CLIENTE V1 Descripción.

(14) El Gerente del proyecto y el Cliente se reúnen para dejar claro los alcances y la metodología de trabajo para el servicio o producto solicitado. Nota: Con ésta actividad se inicia la etapa del KICK OFF.. 1.2. Salidas. Aprobación de los alcances y metodología de trabajo.. Actividad. Definición del Plan de Proyecto. Responsable. Gerente del proyecto (PM) Líder técnico (TL). Entrada. Información del proyecto. Herramientas. 2016-05-23 Hoja control de proyecto_Cliente_V.2 Descripción. El gerente del proyecto y el líder técnico se reúnen para elaborar la hoja de control del proyecto donde se incluye la descripción del producto, alcance, objetivos y resultados en el plan de proyecto.. 1.3. Salidas. Hoja de control del proyecto. Actividad. Verificación del Plan de Proyecto. Responsable. Gerente del proyecto (PM) Líder técnico (TL). Entrada. Información del proyecto. Herramientas. 2016-05-23 Hoja control de proyecto_Cliente_V.2 Descripción. El gerente del proyecto y el líder técnico se reúnen para: 1. Verificar y obtener la aprobación de la hoja de control de proyecto. 2. Comprobar que todos los elementos de la hoja de control de proyecto son viables y coherentes. Los resultados encontrados se documentan en una verificación de resultados y se hacen correcciones hasta que el documento sea aprobado.. 1.4. Salidas. Hoja de control del proyecto. Actividad. Aprobación del Plan de Proyecto.

(15) Responsable. Gerente del proyecto (PM) Cliente (CUS). Entrada. Hoja de control del proyecto. Herramientas. 2015-12-20 electrónico. Acta de Reunión - Asunto V.1 ó Correo. Descripción El gerente del proyecto se reúne con el cliente y/o le comparte la hoja de control del proyecto para que sea revisada y aceptada. El cliente revisa y acepta la hoja de control de proyecto, asegurándose de que los elementos de la hoja de control de proyecto corresponden con la Declaración de Trabajo.. 1.5. Salidas. Aprobación de la hoja de control del proyecto. Actividad. Establecer repositorio del Plan de Proyecto. Responsable. Gerente del proyecto (PM) Líder técnico (TL). Entrada. Información del proyecto almacenada. Herramientas. 2017-09-30 Instructivo para almacenar la información V.3 Descripción. El líder técnico establecer el repositorio del proyecto utilizando la estrategia de control de versiones según la información almacenada por el gerente del proyecto.. 1.6. Salidas. Correo de confirmación del repositorio del proyecto generado.. Actividad. Revisión del Plan de Proyecto WT. Responsable. Gerente del proyecto (PM) Líder técnico (TL) Grupo de trabajo (WT). Entrada. Hoja de control del proyecto. Herramientas. 2016-05-23 Hoja control de proyecto_Cliente_V.2 2015-12-20 Acta de Reunión - Asunto V.1 Descripción.

(16) Se reúnen el gerente del proyecto, el líder técnico y el equipo de trabajo para revisar de la hoja de control de proyecto actual con el fin de lograr un entendimiento común y obtener su compromiso con el proyecto. En ésta reunión se revisa cada actividad de la hoja de control de proyecto y en caso de ser necesario se definen los ajustes que se requieran. Nota: Con ésta actividad se finaliza la etapa del KICK OFF.. 2.1. Salidas. Acta de reunión Hoja de control de proyecto. Actividad. Definición de flujo de proceso y reportes. Definición de requerimientos. Responsable. Cliente (CUS) Analista (AN) Gerente del proyecto (PM). Entrada. Requerimientos funcionales y no funcionales. Herramientas. 2016-02-22 Documentación Análisis y diseño Cod Cliente Cod módulo V.1 2016-04-29 Requerimientos No funcionales SAIA V.2 Descripción. Se reúne el gerente del proyecto con el cliente y se realizan las siguientes actividades: 1. El documento o la actualización de la especificación de requerimientos. 2. Se identifica y consulta fuentes de información (clientes, usuarios, sistemas anteriores, documentos, etc.) con el fin de conseguir nuevos requerimientos. 3. Se analizan los requerimientos identificados para determinar el alcance y la viabilidad. 4. Se genera o actualiza la especificación de requisitos. Finalmente ésta información es verificada por el analista. Nota: Con ésta actividad se inicia la etapa de la GESTIÓN DEL PROYECTO.. 2.2. Salidas. Acta de reunión Documentación de análisis y diseño del proyecto. Actividad. Diseño de árbol de proceso - Definición de requerimientos.

(17) Responsable. Cliente (CUS) Analista (AN) Gerente del proyecto (PM). Entrada. Requerimientos funcionales y no funcionales. Herramientas. 2016-02-22 Documentación Análisis y diseño Cod Cliente Cod módulo V.1 2016-04-29 Requerimientos No funcionales SAIA V.2 Descripción. De acuerdo a la información obtenida en la actividad 2.1, se reúne el gerente del proyecto con el cliente y se define el flujo del proceso y demás requerimientos faltantes. Finalmente ésta información es verificada por el analista.. 2.3. Salidas. Acta de reunión Documentación de análisis y diseño del proyecto. Actividad. Verificación de especificaciones. Responsable. Líder técnico (TL) Analista (AN). Entrada. Requerimientos funcionales y no funcionales. Herramientas. 2016-02-02 Verificación Especificación de Requerimientos V.1. Documento. de. requerimientos. y. Descripción Se reúnen el líder técnico y el analista y realizan las siguientes actividades: 1. Se verifica y aprueba la especificación de requerimientos. 2. Se verifica la exactitud y capacidad de la especificación de requerimientos y su consistencia con la descripción del producto. 3. Se revisa que los requerimientos estén completos, sin ambigüedades y no contradictorios. Los resultados encontrados son documentados en una verificación de resultados y las correcciones se hacen hasta que el documento es aprobado por el analista. Si los cambios son significativos, es necesario realizar una solicitud de cambio..

(18) 2.4. Salidas. Verificación de especificación de requerimientos Solicitud de cambios cuando aplica.. Actividad. Validación de especificaciones. Responsable. Cliente (CUS) Gerente de proyecto (PM) Analista (AN). Entrada. Documentación de análisis y diseño Requerimientos no funcionales. Herramientas. 2015-12-20 Acta de Reunión - Asunto V.1. Documento. de. requerimientos. y. Descripción El gerente de proyecto envía al cliente la documentación de análisis y diseño y los requerimientos no funcionales para que los valide y apruebe. Nota: Con ésta actividad se finaliza la etapa de la GESTIÓN DEL PROYECTO.. 2.5. Salidas. Correo de aprobación por parte del cliente.. Actividad. Parametrización de requerimientos. Responsable. Desarrollador (PR). Entrada. Documentación de análisis y diseño Requerimientos no funcionales. Herramientas. 2016-05-06 Componentes del sistema V.1 Descripción. El desarrollador construye o actualizar los Componente de Software basados en la parte de los detalles del Diseño de Software. 2.6. Salidas. Servicio o producto finalizado. Actividad. Pruebas técnicas y funcionales - Realizar las pruebas del software usando los Casos de prueba. Responsable. Cliente (CUS) Desarrollador (PR) Tester (TST).

(19) Entrada. Documentación de análisis y diseño Requerimientos no funcionales Servicio o producto finalizado. Herramientas. Reporte de pruebas Descripción. El desarrollador al realizar el servicio o producto debe realizar las pruebas correspondientes y pasar al tester para que realice las pruebas finales; por lo tanto el tester debe realizar lo siguiente: 1. Realizar las pruebas del software usando los Casos de prueba y procedimientos de prueba para la integración 2. Documentar los resultados en el Reporte de prueba. 3. Entregar al gerente del proyecto el servicio o productivo realizado en el ambiente de pruebas. Nota: Con ésta actividad se finaliza la etapa GESTIÓN DEL PROYECTO.. 2.7. Salidas. Servicio o producto finalizado y testeado.. Actividad. Entrega del producto en ambiente de pruebas. Responsable. Cliente (CUS) Gerente del proyecto (PM). Entrada. Servicio o producto finalizado y testeado. Herramientas. 2015-12-20 Acta de Reunión - Asunto V.1 Descripción. El gerente de proyectos realiza las siguientes actividades: 1. 2.. Programa una reunión de entrega con el cliente En la reunión con el cliente se le entrega el servicio o producto en el ambiente de pruebas 3. El gerente de proyectos entrega al cliente los datos de acceso al ambiente de pruebas 4. El cliente aprueba el servicio o producto para que se proceda con el paso al ambiente productivo. Nota: Con ésta actividad se inicia la etapa de ENTREGA DEL PRODUCTO.. 2.8. Salidas. Acta de entrega del servicio o producto.. Actividad. Capacitación.

(20) Responsable. Gerente del proyecto (PM). Entrada. Servicio o producto aprobado por el cliente. Herramientas. 2016-05-18 ASISTENCIA A CAPACITACIÓN V.1 Descripción. El gerente de proyectos realiza las siguientes actividades: 1. 2.. 2.9. Programa capacitación con el cliente Realiza capacitación sobre el funcionamiento del servicio o producto.. Salidas. Acta de capacitación. Actividad. Salida a producción del módulo y entrega de manuales. Responsable. Gerente del proyecto (PM) Tester (TST). Entrada. Servicio o producto aprobado por el cliente y funcionando en el ambiente productivo. Herramientas. 2015-12-20 Acta de Reunión - Asunto V.1 Correo de entrega Descripción. El tester realiza manuales de funcionamiento. El gerente de proyecto entrega al cliente la salida del producto en el ambiente productivo y se entregan manuales de funcionamiento Nota: Con ésta actividad se finaliza la etapa de ENTREGA DEL PRODUCTO y la gestión del proyecto..

(21) DEFINICIÓN, ACRÓNIMOS Y ABREVIACIONES Término/Acrónimo. Definición. Actividad. Conjunto de tareas de un proceso. Cliente. Organización o persona que recibe un producto o servicio.. Proceso. Conjunto de actividades interrelacionadas o interactivas que transforma las entradas en salidas. Capacidad del proceso. Caracterización de la capacidad de un proceso para cumplir los objetivos comerciales actuales o proyectados.. Nivel de capacidad del proceso. Indica en la escala ordinal de seis puntos (de la capacidad del proceso) que representa la capacidad del proceso, cada nivel se basa en la capacidad del nivel siguiente.. Mejora de procesos. Acciones tomadas para cambiar los procesos de una organización para que cumplan de manera más efectiva y/o eficiente los objetivos comerciales de la organización.. Resultado del proceso. Resultado observable de un proceso.. Proyecto. Proceso con fechas de inicio y finalización definidas para crear un producto o servicio de acuerdo con los recursos y requisitos especificados.. Informe. Elemento de información que describe los resultados de actividades tales como investigaciones, evaluaciones y pruebas.. Repositorio. Colección de todos los artefactos relacionados con el software que pertenecen a un sistema o la ubicación/formato en que se almacena dicha colección.. Recurso. Activo que se utiliza o consume durante la ejecución de un proceso. Revisión. Proceso o reunión durante la cual se presenta un producto de software al personal del proyecto, gerentes, usuarios, clientes, representantes de usuarios u otras partes interesadas para comentarios o aprobación.. Software. Programas informáticos, procedimientos y, posiblemente, documentación asociada y datos relacionados con el funcionamiento de un sistema informático..

(22) Componentes de software Trazabilidad del registro. Sistema o elemento de software, como módulo, unidad, datos o documento. ● ●. Identifica requisitos para ser trazados Identifica un análisis de requisito al ciclo de vida del producto trabajado Proporciona el enlace de los requisitos para trabajar la descomposición del producto (requisito, diseño, código, pruebas, entregables, etc.) Ofrece trazado de antes y después del análisis de los requisitos asociados al productivo trabajado a lo largo de todas las fases del ciclo de vida.. ●. ●. Validación. Confirmación a través la provisión de la evidencia del objetivo, que se cumplan los requisitos para el uso o solicitud específica.. Verificación. Confirmación a través dela provisión de la evidencia del objetivo, que se cumplan los requisitos especificados.. VSE. Entidad muy pequeño de hasta 25 empleados.. Producto trabajado. Método asociado con la ejecución de un proceso. Observaciones: Los documentos relacionados se anexan como información complementaria del informe; así como también el documento de gestión del proyecto.. CONTROL DE CAMBIOS Versión. Fecha. Acción* (C,M,A). 1. 12/12/20 18. C. Resumen de Cambios. Responsable. Aprobado. María Angélica Julio Cesar Vargas Molina Chavarro. *: C =Creación, M =Modificación, A = Aprobación (Excluyentes). Para las acciones Creación y Modificación del documento se diligencia la fecha de la iniciación de la acción..

(23) BIBIOGRAFÍA. ● ● ● ●. ISO/IEC:2011 TR 29110-1 Software engineering — Lifecycle profiles for Very Small Entities (VSEs) — Part 1 ISO/IEC:2011 TR 29110-5-1-2 Software engineering — Lifecycle profiles for Very Small Entities (VSEs) — Part 5-1-2 ISO/IEC TR 29110-3 Software engineering — Lifecycle profiles for Very Small Entities (VSEs) — Part 3 https://www.heflo.com/es/blog/modelado-de-procesos/modelado-de-procesos-bpm/.

(24)