Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0"

Transcripción

1 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009

2

3 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7 Descripción General...7 Actividades y Tareas...9 Artefactos y Roles...17 ANÁLISIS Y DISEÑO...19 Descripción General...19 Actividades y Tareas...20 Artefactos y Roles...26 PROGRAMACIÓN...28 Descripción General...28 Actividades y Tareas...29 Artefactos y Roles...32 PRUEBAS...33 Descripción General...33 Actividades y Tareas...35 Artefactos y Roles...38 INSTALACIÓN...39 Descripción General...39 Actividades y Tareas...41 Artefactos y Roles...45 GESTIÓN AVANZADA DE PROYECTOS...47 GESTIÓN DE RIESGOS...48 Descripción General...48 Actividades y Tareas...49 Artefactos y Roles...54 EVALUACIÓN FORMAL DE DECISIONES...55 Descripción General...55 Actividades y Tareas...56 Artefactos y Roles...57 ADMINISTRACIÓN INTEGRADA DEL PROYECTO...58 Descripción General...58 Actividades y Tareas...59 Artefactos y Roles...63 GESTIÓN DE PROCESOS...64 DEFINICIÓN DE PROCESOS ORGANIZACIONALES...65 Descripción General...65 Actividades y Tareas...66 Artefactos y Roles...68 MEJORAMIENTO DE PROCESOS ORGANIZACIONALES...69 Descripción General...69 Actividades y Tareas...70 Artefactos y Roles...73 ENTRENAMIENTO ORGANIZACIONAL...74 Descripción General...74 Actividades y Tareas...75 Artefactos y Roles...79 iii

4 Lista de Figuras FIGURA 1. ÁREA DE PROCESOS: DESARROLLO DE REQUERIMIENTOS...8 FIGURA 2. ACTIVIDAD: ANALIZAR EL PROBLEMA....9 FIGURA 3. ACTIVIDAD: ESPECIFICAR AMBIENTE...10 FIGURA 4. ACTIVIDAD: DESCRIBIR REQUERIMIENTOS...11 FIGURA 5. ACTIVIDAD: ANALIZAR Y VALIDAR REQUERIMIENTOS FIGURA 6. ACTIVIDAD: MANEJAR CAMBIOS...15 FIGURA 7. ÁREA DE PROCESOS: ANÁLISIS Y DISEÑO FIGURA 8. ACTIVIDAD: ESTIMAR ESFUERZO FIGURA 9. ACTIVIDAD: ANÁLISIS FIGURA 10. ACTIVIDAD: DISEÑO FIGURA 11. ÁREA DE PROCESOS: PROGRAMACIÓN FIGURA 12. ACTIVIDAD: IMPLEMENTAR INTERFACES Y COMUNICACIONES FIGURA 13. ACTIVIDAD: IMPLEMENTAR COMPONENTES Y PROGRAMAS...30 FIGURA 14. ACTIVIDAD: IMPLEMENTAR BASE DE DATOS...31 FIGURA 15. ÁREA DE PROCESOS: PRUEBAS...34 FIGURA 16. ACTIVIDAD: DESARROLLAR EL PLAN DE PRUEBAS...35 FIGURA 17. ACTIVIDAD: EJECUTAR LAS PRUEBAS...36 FIGURA 18. ÁREA DE PROCESOS: INSTALACIÓN FIGURA 19. ACTIVIDAD: PREPARAR AMBIENTE FIGURA 20. ACTIVIDAD: GENERAR DOCUMENTACIÓN...42 FIGURA 21. ÁREA DE PROCESOS: GESTIÓN DE RIESGOS...48 FIGURA 22. ACTIVIDAD: PLANIFICAR LA ADMINISTRACIÓN DE RIESGOS FIGURA 23. ACTIVIDAD: IDENTIFICAR Y ANALIZAR RIESGOS...50 FIGURA 24. ACTIVIDAD: SEGUIR LOS RIESGOS FIGURA 25. ÁREA DE PROCESOS: EVALUACIÓN FORMAL DE DECISIONES FIGURA 26. ÁREA DE PROCESOS: ADMINISTRACIÓN INTEGRADA DEL PROYECTO FIGURA 27. ACTIVIDAD: AJUSTAR EL PROCESO FIGURA 28. ACTIVIDAD: INTEGRAR A LOS INVOLUCRADOS FIGURA 29. ÁREA DE PROCESOS: DEFINICIÓN DE PROCESOS ORGANIZACIONALES...65 FIGURA 30. ÁREA DE PROCESOS: MEJORAMIENTO DE PROCESOS ORGANIZACIONALES FIGURA 31. ACTIVIDAD: EJECUTAR PLAN DE MEJORAMIENTO DE PROCESOS FIGURA 32. ÁREA DE PROCESOS: ENTRENAMIENTO ORGANIZACIONAL...74 FIGURA 33. ACTIVIDAD: COORDINAR ACTIVIDADES PARA PLANIFICACIÓN...75 FIGURA 34. ACTIVIDAD: REALIZAR ENTRENAMIENTO...77 Lista de Tablas TABLA 1. ARTEFACTOS Y ROLES DE DESARROLLO DE REQUERIMIENTOS...17 TABLA 2. ESTIMACIONES PARA LA PLANILLA TEC...21 TABLA 3. ARTEFACTOS Y ROLES DE ANÁLISIS Y DISEÑO TABLA 4. ARTEFACTOS Y ROLES DE PROGRAMACIÓN TABLA 5. ARTEFACTOS Y ROLES DE PRUEBAS...38 TABLA 6. ARTEFACTOS Y ROLES DE INSTALACIÓN TABLA 7. ARTEFACTOS Y ROLES DE GESTIÓN DE RIESGOS...54 TABLA 8. ARTEFACTOS Y ROLES DE EVALUACIÓN FORMAL DE DECISIONES TABLA 9. ARTEFACTOS Y ROLES DE ADMINISTRACIÓN INTEGRADA DEL PROYECTO TABLA 10. ARTEFACTOS Y ROLES DE DEFINICIÓN DE PROCESOS ORGANIZACIONALES...68 TABLA 11. ARTEFACTOS Y ROLES DE MEJORAMIENTO DE PROCESOS ORGANIZACIONALES TABLA 12. ARTEFACTOS Y ROLES DE ENTRENAMIENTO ORGANIZACIONAL...79 iv

5 Prefacio TRP (Tutelkan Reference Process) ha sido desarrollado por la academia, el gobierno y la industria del software de Chile como parte del proyecto Tutelkán: Obtención de altos estándares de calidad para la industria del software 1. TRP contiene prácticas recomendadas para: gestión de proyectos, gestión de procesos, y desarrollo y mantención de software. Provee de un entorno común de trabajo a los equipos propios de una organización y a equipos conjuntos conformados con proveedores, usuarios y clientes, i.e., apoya el trabajo mancomunado de diversos grupos de personas que suelen trabajar bajo diferentes culturas, expectativas y ámbitos de conocimiento. El proceso de referencia está separado en dos conjuntos de prácticas, denominados TRP Básico y TRP Avanzado. Este documento contiene las prácticas de TRP Avanzado. Estás se agrupan en 11 áreas de proceso pertenecientes a 3 categorías, denominadas: Desarrollo y Mantención de Software, agrupa las áreas de proceso: Desarrollo de Requerimientos. Análisis y Diseño. Programación. Pruebas. Instalación. Gestión Avanzada de Proyectos, agrupa las áreas de proceso: Gestión de Riesgos. Evaluación Formal de Decisiones. Administración Integrada del Proyecto. Gestión de Procesos, agrupa las áreas de proceso: Definición de Procesos Organizacionales. Mejoramiento de Procesos Organizacionales. Entrenamiento Organizacional. 1 5

6 Desarrollo y Mantención de Software 6

7 Desarrollo de Requerimientos Descripción General Propósito Examinar las características del problema y explicitarlas, entender las necesidades del Cliente y los objetivos de negocio involucrados para poder determinar claramente el deseo y las condiciones que los usuarios e interesados poseen respecto al producto a desarrollar, estableciendo el alcance y los límites del sistema. Objetivos Definir y profundizar el alcance del proyecto. Analizar, describir y validar los requerimientos del proyecto. Evaluar y estimar cambios de requerimientos y su impacto en el proyecto. Notas Introductorias Hay cuatro tipos de requerimientos: Requerimientos funcionales, o sea las tareas que el sistema debe permitir ejecutar. Requerimientos no funcionales, tales como usabilidad, confiabilidad, rendimiento, seguridad, mantenibilidad y en general todos aquellos requerimientos que no tengan relación con la funcionalidad del sistema. Requerimientos técnicos, o sea que tienen que ver con el uso de ciertos estándares, lenguajes de programación, plataformas de desarrollo, etc. Requerimientos de proceso, este tipo de requerimiento aplica cuando el proyecto requiere el uso de una metodología, proceso o procedimiento específico. Desarrollo de Requerimientos 7

8 Diagrama General Figura 1. Área de Procesos: Desarrollo de Requerimientos. Desarrollo de Requerimientos 8

9 Actividades y Tareas 1. Actividad: Analizar el Problema Figura 2. Actividad: Analizar el Problema Tarea: Realizar Análisis Preliminar del Proyecto Descripción Se realiza un análisis preliminar del proyecto, el cual incluye casos de uso de negocio y el análisis de la situación actual. Entradas Análisis preliminar Roles Analista 1.2. Tarea: Definir el Problema y Alcance del Proyecto Descripción Se debe establecer las necesidades, entorno del Cliente y el alcance del problema a partir de entrevistas a los involucrados, las que contienen sus expectativas, criterios de éxito, riesgos, restricciones y condiciones que ellos identifiquen. Los resultados ( Análisis de entrevistas a involucrados ) deben documentarse en el artefacto Visión del producto, este proporciona la base contractual de la cual se detallarán los aspectos técnicos de los requerimientos. Entradas Análisis preliminar Desarrollo de Requerimientos 9

10 Roles Entrevista a involucrado, Análisis de entrevistas a involucrados, Visión del producto Analista 2. Actividad: Especificar Ambiente Figura 3. Actividad: Especificar Ambiente Tarea: Definir Ambiente Descripción Se genera el documento de Especificación de ambientes en base a los requerimientos técnicos provistos. Entradas Visión del producto Especificación de ambientes Roles Jefe de proyecto, Analista 2.2. Tarea: Hacer Checklist de Ambiente Descripción Se crea el documento Checklist de ambientes, para poder así aplicarlo en los respectivos ambientes definidos en el proyecto (ambiente de desarrollo, pruebas y producción) identificando así posibles riesgos dadas las disponibilidades de hardware y software requeridos. Entradas Especificación de ambientes Checklist de ambientes Roles Jefe de proyecto, Analista Desarrollo de Requerimientos 10

11 3. Actividad: Describir Requerimientos Figura 4. Actividad: Describir Requerimientos Tarea: Definir Requerimientos de Producto y Componentes de Producto Descripción Dependiendo del tipo de proyecto, en esta actividad debe generarse el modelo de casos de uso detallado y el documento Especificación de Requerimientos de Software (ERS). Los requerimientos pueden venir descritos en cualquier documento utilizado (e.g., Visión del producto, Solicitud de requerimientos, o algún Modelo apropiado), pero cumpliendo con los criterios de aceptación definidos en el área de procesos Administración de Requerimientos. Entradas Roles Visión del producto, Solicitud de requerimientos, Modelo Modelo de casos de uso, ERS Analista 3.2. Tarea: Definir Restricciones de Producto y Componentes de Producto Descripción La ERS deberá contener todas las restricciones con las que se enfrenta el proyecto, ya sean funcionales, no funcionales, legales u otras. Entradas Modelo de casos de uso, ERS Desarrollo de Requerimientos 11

12 Roles Modelo de casos de uso, ERS Analista 3.3. Tarea: Identificar Requerimientos de Interfaz Descripción Se debe identificar cualquier interfaz que sea necesaria entre los componentes de la arquitectura propuesta (en el artefacto Análisis preliminar ) ya sea entre objetos y funciones internas y/o con funciones externas, hay que tomar en cuenta que muchas de estas interfaces están relacionadas con el medio ambiente y con el hardware donde las aplicaciones se ejecutarán. Por ejemplo especificaciones de protocolos de intercambio, conexiones a hardware, APIs (Application Programming Interface) entre componentes de software, etc. Se debe documentar cada interfaz identificada, indicando cuáles son sus requerimientos lógicos, procedurales y de hardware. Este documento servirá además para el proceso de integración ya que indica cómo los objetos y funciones se interconectan. Estos requerimientos pueden ir descritos en la ERS y documentarse además en algún Modelo apropiado. Entradas Análisis preliminar ERS, Modelo Roles Analista 3.4. Tarea: Generar Trazabilidad con Requerimientos de Usuario Descripción Cada uno de los requerimientos de negocio definidos previamente debe ser incluido en la Planilla de Tiempo, Esfuerzo y Costo (TEC), para su posterior estimación de esfuerzo (ver área de procesos Análisis y Diseño) y debe ser asociado a uno o más de los requerimientos de sistema definidos en el artefacto Planilla de administración de requerimientos, para mantener la trazabilidad. Entradas ERS Planilla TEC, Planilla de administración de requerimientos Roles Jefe de proyecto, Analista Desarrollo de Requerimientos 12

13 4. Actividad: Analizar y Validar Requerimientos Figura 5. Actividad: Analizar y Validar Requerimientos Tarea: Analizar Requerimientos Descripción Analizar requerimientos para asegurar que son necesarios y suficientes. Se debe analizar los requerimientos para determinar si satisfacen los objetivos del proyecto y del producto. Se debe revisar que estén completos, sean factibles, realizables y verificables mediante pruebas. En particular se debe focalizar el análisis sobre aquellos que por diseño vean afectada su factibilidad. Se deben identificar los requerimientos claves con fuerte impacto en costos, planificación, funcionalidad, riesgo de su desarrollo y rendimiento. Identificar los factores de medición del rendimiento técnico que se controlarán durante el esfuerzo de desarrollo. Registrar todo lo anterior en el artefacto ERS. Con la revisión global de los conceptos operacionales y escenarios, afinar las necesidades del Cliente, restricciones e interfaces y eventualmente descubrir nuevos requerimientos, los que deben ser incorporados. Entradas Visión del producto, ERS, Planilla de administración de requerimientos Roles ERS, Planilla de administración de requerimientos Analista 4.2. Tarea: Lograr Balance de Requerimientos Descripción Como los requerimientos y restricciones de los Clientes direccional costo, planificación, funcionalidad, reusabilidad, mantenibilidad y/o riesgo, se debe, a través de modelos, simulaciones y prototipos, balancear lo anterior, es decir, racionalizar. Se debe efectuar una evaluación de riesgo de la arquitectura funcional y de requerimientos, de modo que el efecto de los requerimientos sobre los riesgos sea equilibrado. Desarrollo de Requerimientos 13

14 Entradas Roles ERS ERS, Lista de riesgos Analista 4.3. Tarea: Validar Requerimientos Descripción En esta revisión se validan los requerimientos para determinar el riesgo de que el producto resultante, no opere adecuadamente en el ambiente definido del usuario, a través del uso de modelos, prototipos y/o demostraciones. Explorar la completitud de requerimientos desarrollando representaciones del producto y obteniendo realimentación respecto de ellos con los Involucrados. Evaluar el diseño, ya que éste madura en el proceso de validación de requerimientos de ambiente, de modo de identificar necesidades, validaciones y requerimientos de Clientes no cubiertos. En este punto, frente a nuevos requerimientos se debe iterar respecto del ciclo de desarrollo de requerimientos. Entradas ERS ERS, Lista de riesgos Roles Analista Desarrollo de Requerimientos 14

15 5. Actividad: Manejar Cambios Notas Introductorias Figura 6. Actividad: Manejar Cambios. El proceso soporta cambios en los requerimientos durante todo el ciclo de vida del proyecto, pero es sumamente importante que estos cambios sean controlados Tarea: Analizar Impacto de Cambios Descripción Todo cambio solicitado debe cumplir con los criterios de aceptación definidos para el proyecto. Estos cambios deben tener una revisión de factibilidad e impacto. El Analista estudia el impacto del cambio del requerimiento o del nuevo requerimiento. El mismo es comentado al Jefe de proyecto, el cual resuelve con el Cliente para ver la factibilidad de la implantación del cambio. Desarrollo de Requerimientos 15

16 Entradas Roles Solicitud de requerimientos Analista, Jefe de proyecto, Cliente 5.2. Tarea: Actualizar Especificación de Requerimientos Descripción En el caso de cambios en los requerimientos, debe actualizarse la Especificación de requerimientos de software (ERS) y/o el Modelo correspondiente para mantener consistente la documentación del proyecto. Entradas ERS, Modelo ERS, Modelo Roles Analista 5.3. Tarea: Actualizar Trazabilidad de Requerimientos Descripción En el caso de cambios en los requerimientos, debe actualizarse la Planilla de administración de requerimientos, incorporando los nuevos requerimientos y actualizando la trazabilidad ya existente. Entradas Planilla de administración de requerimientos, Solicitud de requerimientos Roles Planilla de administración de requerimientos Analista 5.4. Tarea: Actualizar Planes Descripción Los planes se actualizan de acuerdo al impacto del cambio incorporado. Este impacto se puede ver reflejado en los tiempos o esfuerzo del proyecto, en los riesgos, y todos los artefactos relacionados con el artefacto Plan del proyecto. Entradas Plan de proyecto Plan de proyecto Roles Jefe de proyecto 5.5. Tarea: Actualizar Especificación de Ambiente Descripción En el caso de cambios en los requerimientos, podría verse afectado el artefacto Especificación de ambientes por lo que es importante validar que la descripción existente de los ambientes se mantiene, si no, actualizar el documento. Entradas Roles Especificación de ambientes Especificación de ambientes Analista Desarrollo de Requerimientos 16

17 Artefactos y Roles Tabla 1. Artefactos y Roles de Desarrollo de Requerimientos. Actividad/Tarea Entradas Roles 1 Analizar el Problema 1.1 Realizar Análisis Análisis preliminar Analista Preliminar del Proyecto 1.2 Definir el Problema y Alcance del Proyecto Análisis preliminar Analista Entrevista a involucrado Análisis de entrevistas a involucrados Visión del producto 2 Especificar Ambiente 2.1 Definir Ambiente Visión del producto Especificación de ambientes 2.2 Hacer Checklist de Ambiente 3 Describir Requerimientos 3.1 Definir Requerimientos de Producto y Componentes de Producto 3.2 Definir Restricciones de Producto y Componentes de Producto 3.3 Identificar Requerimientos de Interfaz 3.4 Generar Trazabilidad con Requerimientos de Usuario 4 Analizar y Validar Requerimientos 4.1 Analizar Requerimientos 4.2 Lograr Balance de Requerimientos Especificación de ambientes Visión del producto Solicitud de requerimientos Modelo Modelo de casos de uso ERS Análisis preliminar ERS Modelo Visión del producto ERS Planilla de administración de requerimientos Modelo ERS Checklist de ambientes Modelo de casos de uso ERS Modelo de casos de uso ERS ERS Modelo Planilla TEC Planilla de administración de requerimientos ERS Planilla de administración de Requerimientos ERS Lista de riesgos 4.3 Validar Requerimientos ERS ERS Lista de riesgos 5 Manejar Cambios Jefe de proyecto, Analista Jefe de proyecto, Analista Analista Analista Analista Jefe de proyecto, Analista Analista Analista Analista Desarrollo de Requerimientos 17

18 Actividad/Tarea Entradas Roles 5.1 Analizar Impacto de Cambios Solicitud de requerimientos Analista Jefe de proyecto Cliente 5.2 Actualizar Especificación de Requerimientos 5.3 Actualizar Trazabilidad de Requerimientos ERS Modelo Planilla de administración de requerimientos Solicitud de requerimientos ERS Modelo Planilla de administración de requerimientos Analista Analista 5.4 Actualizar Planes Plan de proyecto Plan de proyecto Jefe de proyecto 5.5 Actualizar Especificación de Ambiente Especificación de ambientes Especificación de ambientes Analista Desarrollo de Requerimientos 18

19 Análisis y Diseño Descripción General Propósito Estimar, analizar y desarrollar el diseño de la solución con tal de satisfacer a cabalidad los requerimientos. Esta solución debe ser apropiada para su posterior implementación. Objetivos Estimar tiempo, costo y esfuerzo para analizar, diseñar y construir la solución seleccionada. Evaluar y seleccionar la solución que satisface apropiadamente los requerimientos. Desarrollar detalladamente el diseño para la solución seleccionada. Diagrama General Figura 7. Área de Procesos: Análisis y Diseño. Análisis y Diseño 19

20 Actividades y Tareas 1. Actividad: Estimar Esfuerzo Notas Introductorias Figura 8. Actividad: Estimar Esfuerzo. En determinados casos el artefacto Especificación de requerimientos de software (ERS) se puede reemplazar, para efectuar la estimación de la Planilla de Tiempo, Esfuerzo y Costo (TEC), por el artefacto Análisis preliminar. Ambos artefactos contienen datos para determinar, con una desviación aceptable el tiempo, esfuerzo, costo para crear la Planilla TEC. En determinadas ocasiones el artefacto Planilla TEC se debe desarrollar inclusive antes de la fase de Concepción y contiene un breve análisis técnico del problema, facilitando la estimación aún antes de comenzar el proyecto. Es sumamente útil para aquellos proyectos donde se solicita una estimación preliminar del plazo, esfuerzo y costo del proyecto. La Tabla 2 presenta un ejemplo de rangos típicos de esfuerzo requerido en promedio para completar cada una de las fases del proceso. El esfuerzo es un parámetro variable y depende básicamente de: Análisis y Diseño 20

21 El conocimiento o dominio del problema. La complejidad del problema. La experiencia y conocimiento del equipo de trabajo. Los riesgos del proyecto. Tabla 2. Estimaciones para la Planilla TEC. Concepción Elaboración Construcción Transición E S F U E R Z O 5-10% 10-30% 50-65% 10-20% 1.1. Tarea: Estimar Complejidad Descripción Se estima la complejidad de cada uno de los requerimientos, de acuerdo a la experiencia adquirida en otros proyectos, requerimientos similares analizados en otros proyectos y a las posibles dificultades que se puedan presentar, en conjunto con el Equipo de proyecto. Entradas Especificación de Requerimientos de Software (ERS) Planilla de Tiempo, Esfuerzo y Costo (TEC) Roles Gerente de proyectos, Jefe de proyecto, Arquitecto, Equipo de proyecto 1.2. Tarea: Estimar Esfuerzo para Integración y Pruebas Descripción Una vez analizada la complejidad y las posibles dificultades de la integración del ambiente requerido, se estima el tiempo necesario para las actividades de integración y pruebas. Entradas ERS Planilla TEC Roles Gerente de proyectos, Jefe de proyecto, Arquitecto, Testeador Análisis y Diseño 21

22 1.3. Tarea: Estimar Esfuerzo para Análisis y Diseño Descripción Una vez analizada la complejidad, se estima el tiempo necesario para las actividades de análisis y diseño. Entradas ERS Planilla TEC Roles Gerente de proyectos, Jefe de proyecto, Arquitecto, Analista 1.4. Tarea: Estimar Esfuerzo para Construcción Descripción Una vez analizada la complejidad, se estima el tiempo necesario para las actividades de construcción Entradas ERS Planilla TEC Roles Gerente de proyectos, Jefe de proyecto, Arquitecto 1.5. Tarea: Crear Planilla TEC Descripción Consiste de la consolidación del artefacto Planilla TEC, en el cual deben registrarse los datos obtenidos durante las estimaciones de esfuerzo de integración, pruebas, análisis, diseño y construcción. Considerando el artefacto Lista de riesgos del proyecto es posible establecer el margen de seguridad, que considera un tiempo adicional en caso de que alguno de los riesgos se manifieste o existan cambios en los requerimientos. Una vez completada la Planilla TEC, se puede obtener el costo del proyecto. Entradas Lista de riesgos, Planilla TEC Planilla TEC Roles Gerente de proyectos, Jefe de proyecto, Arquitecto Análisis y Diseño 22

23 2. Actividad: Análisis Figura 9. Actividad: Análisis Tarea: Realizar Análisis Descripción Se lleva a cabo una vez que se recolectaron las necesidades del usuario, expresadas generalmente en funciones del sistema. Al realizar el análisis del sistema, pueden surgir cambios en los requerimientos, lo cual implica que el artefacto Especificación de requerimientos de software (ERS) debe ser actualizado. Mediante el Modelo de análisis se identifican los principales objetos del sistema, los actores y las interfaces tanto del usuario como con otros sistemas. El Modelo de análisis puede contener varios diagramas, tales como: diagrama de secuencia, actividad, clases y estado. Se deben seleccionar qué diagramas se van usar dependiendo del tipo de sistema y de la profundidad del análisis que se necesita para aclarar y resolver todas las preguntas. Se recomienda hacer solo los artefactos necesarios, es decir, realizar aquellos diagramas que aporten en la clarificación del problema, quedando esta selección a criterio del Jefe de proyecto. En caso de que se requiera, se debe definir un criterio de selección para las diferentes alternativas de solución que puedan satisfacer los requerimientos. En este caso, se debe informar al Cliente con respecto a las posibles soluciones, indicando sus ventajas y desventajas, como por ejemplo, evaluación costo vs. calidad. Entradas Especificación de requerimientos de software (ERS), Análisis preliminar, Especificación de ambientes Modelo de análisis Roles Analista, Arquitecto Análisis y Diseño 23

24 2.2. Tarea: Realizar Análisis Hacer-Reusar-Comprar Descripción Se realiza un análisis para determinar si el proyecto puede reusar componentes desarrollados en proyectos previos y/o externos. Se debe decidir si se partirá de cero, si se reusarán algunos componentes o bien si se comprarán estos componentes. Entradas ERS Roles Grupo de ingeniería de software 3. Actividad: Diseño Figura 10. Actividad: Diseño Tarea: Definir Patrones y Clases Descripción Se deben definir patrones de diseño acorde a los requerimientos. Adicionalmente debe crearse el diseño de clases (incluido en el Modelo de diseño ). Todo debe documentarse en el Modelo de diseño de la solución, el que permite describir los objetos de sistema, componentes, actores e interfaces de la solución, además de los patrones de diseño que se aplicarán (puede contener varios diagramas, tales como: diagrama de clases, estado, despliegue, base de datos, etc.) Entradas Modelo de análisis, Especificación de Requerimientos de Software (ERS) Análisis y Diseño 24

25 Roles Modelo de diseño Arquitecto 3.2. Tarea: Diseñar Componentes y Programas Descripción Realizar el diseño de los componentes y programas para satisfacer los requerimientos, conviene registrarlo con diagramas de componentes y despliegue en el Modelo de diseño. Se recomienda realizar a su vez, más de una alternativa de diseño, con tal de evaluar si alguna de éstas resulta más eficiente para distintas arquitecturas, o bien si es que se pudiere satisfacer los requerimientos de otra forma. En base a los criterios definidos anteriormente, se escoge la mejor alternativa con tal de que la solución sea la óptima para el proyecto. Entradas ERS, Modelo de análisis, Modelo de diseño, Especificación de ambientes Modelo de diseño Roles Arquitecto 3.3. Tarea: Diseñar Interfaces y Comunicaciones Descripción El diseño de interfaces y comunicaciones es requerido cuando existe la necesidad de crear componentes que permitan comunicar sistemas distintos o dispositivos especiales. Conviene registrarlo con diagramas de componentes y despliegue en el Modelo de diseño. Para ello, se debe tener en cuenta los parámetros críticos de comunicación (tales como características de hardware, protocolos, etc.) que permitan diseñar un modelo robusto y que permita satisfacer los requerimientos. En caso de que se requiera comunicar con un dispositivo especial, será necesario contar con manuales o guías de los mismos. Entradas ERS, Modelo de análisis, Modelo de diseño, Especificación de ambientes Modelo de diseño Roles Arquitecto 3.4. Tarea: Diseñar Base de Datos Descripción Si el proyecto lo requiere se debe llevar a cabo la confección del diseño de la base de datos de acuerdo a lo requerido. Se debe registrar con un diagrama (por ej. ER para BD relacionales) que sea parte del Modelo de diseño. Entradas ERS, Modelo de análisis, Modelo de diseño, Especificación de ambientes Modelo de diseño Roles Arquitecto Análisis y Diseño 25

26 Artefactos y Roles Tabla 3. Artefactos y Roles de Análisis y Diseño. Actividad/Tarea Entradas Roles 1 Estimar Esfuerzo 1.1 Estimar Complejidad ERS Planilla TEC Gerente de proyectos Jefe de proyecto Arquitecto Equipo de proyecto 1.2 Estimar Esfuerzo para Integración y Pruebas ERS Planilla TEC Gerente de proyectos Jefe de proyecto 1.3 Estimar Esfuerzo para Análisis y Diseño 1.4 Estimar Esfuerzo para Construcción 1.5 Crear Planilla TEC Lista de riesgos, Planilla TEC 2 Análisis 2.1 Realizar Análisis ERS Análisis preliminar Especificación de ambientes 2.2 Realizar Análisis Hacer- Reusar-Comprar 3 Diseño 3.1 Definir Patrones y Clases 3.2 Diseñar Componentes y Programas 3.3 Diseñar Interfaces y Comunicaciones Arquitecto ERS Planilla TEC Gerente de proyectos Jefe de proyecto Arquitecto Testeador ERS Planilla TEC Gerente de proyectos Jefe de proyecto Arquitecto ERS Modelo de análisis ERS ERS Modelo de análisis Modelo de diseño Especificación de ambientes ERS Modelo de análisis Modelo de diseño Especificación de ambientes Planilla TEC Modelo de análisis Modelo de diseño Modelo de diseño Modelo de diseño Gerente de proyectos Jefe de proyecto Arquitecto Analista Analista Arquitecto Grupo de ingeniería de software Arquitecto Arquitecto Arquitecto Análisis y Diseño 26

27 Actividad/Tarea Entradas Roles 3.4 Diseñar Base de Datos ERS Modelo de análisis Modelo de diseño Especificación de ambientes Modelo de diseño Arquitecto Análisis y Diseño 27

28 Programación Descripción General Propósito Producir el código de la solución utilizando estándares, y realizar las pruebas unitarias de las piezas construidas. Además, dependiendo de las necesidades del Cliente y del tipo de proyecto, se dará más énfasis a los atributos del software que corresponda (por ejemplo: usabilidad, portabilidad, modularidad, etc.). Objetivos Fabricar los componentes en base al diseño desarrollado en etapas anteriores. Realizar pruebas unitarias a los componentes fabricados. Diagrama General Figura 11. Área de Procesos: Programación. Programación 28

29 Actividades y Tareas 1. Actividad: Implementar Interfaces y Comunicaciones Figura 12. Actividad: Implementar Interfaces y Comunicaciones Tarea: Desarrollar Interfaces y Comunicaciones Descripción En caso de que sea necesario, se implementan interfaces y comunicaciones entre sistemas. Esta implementación es requerida cuando existe la necesidad de crear componentes que permitan comunicar sistemas distintos o dispositivos especiales. Se debe tener en cuenta las restricciones que se pudieren presentar durante la etapa de diseño. Entradas Especificación de Requerimientos de Software (ERS), Modelo de diseño Roles Programador 1.2. Tarea: Realizar Pruebas Unitarias de Interfaces y Comunicaciones Descripción Se realizan pruebas unitarias sobre cada una de las piezas de software en construcción, validando así el funcionamiento deseado sobre cada pieza. Entradas Programación 29

30 Roles Programador 2. Actividad: Implementar Componentes y Programas Figura 13. Actividad: Implementar Componentes y Programas Tarea: Desarrollar Componentes y Programas Descripción Corresponde a la programación de componentes o programas. Los estándares de programación a seguir estarán dados por el Cliente y en caso de usar algún framework se programa con el estándar propio del framework. Entradas Roles Especificación de Requerimientos de Software (ERS), Modelo de diseño Programador 2.2. Tarea: Realizar Pruebas Unitarias de Componentes y Programas Descripción Se realizan pruebas unitarias sobre cada una de las piezas de software en construcción, validando así el funcionamiento deseado sobre cada pieza. Entradas Programación 30

31 Roles Programador 3. Actividad: Implementar Base de Datos Figura 14. Actividad: Implementar Base de Datos Tarea: Desarrollar Base de Datos Descripción Se crea la estructura de BD definida en el Modelo de diseño, creando los scripts y procedimientos almacenados propios de la BD. Entradas Especificación de Requerimientos de Software (ERS), Modelo de diseño Roles Programador 3.2. Tarea: Realizar Pruebas Unitarias de la Base de Datos Descripción Se realizan pruebas unitarias sobre los procedimientos almacenados verificando que ejecutan el resultado deseado. Entradas Roles Programador Programación 31

32 Artefactos y Roles Tabla 4. Artefactos y Roles de Programación. Actividad/Tarea Entradas Roles 1 Implementar Interfaces y Comunicaciones 1.1 Desarrollar Interfaces y Comunicaciones 1.2 Realizar Pruebas Unitarias de Interfaces y Comunicaciones 2 Implementar Componentes y Programas 2.1 Desarrollar Componentes y Programas 2.2 Realizar Pruebas Unitarias de Componentes y Programas 3 Implementar Base de Datos 3.1 Desarrollar Base de Datos 3.2 Realizar Pruebas Unitarias de la Base de Datos ERS Modelo de diseño ERS Modelo de diseño ERS Modelo de diseño Programador Programador Programador Programador Programador Programador Programación 32

33 Pruebas Descripción General Propósito Además de evaluar la aptitud del sistema de realizar las funciones para las que fue construido, encontrando y documentando los defectos, el propósito del Testing es más extenso; no sólo por el resto de los tipos de prueba, siendo las más destacables las de usabilidad y rendimiento, sino que esta disciplina implantada correctamente desde las primeras iteraciones, permite al grupo de trabajo validar la correctitud de la definición de las características y los requerimientos que desde las mismas se desprenden. O sea, el conocer tempranamente cuáles son las condiciones de aprobación de las funcionalidades que permite al grupo de trabajo evitar defectos y eliminar la necesidad de re-trabajo. Objetivos Seleccionar los productos a ser verificados y los métodos utilizados para verificar cada uno. Seleccionar los productos a ser validados y los métodos utilizados para validar cada uno. Pruebas 33

34 Diagrama General Figura 15. Área de Procesos: Pruebas. Pruebas 34

35 Actividades y Tareas 1. Actividad: Desarrollar el Plan de Pruebas Figura 16. Actividad: Desarrollar el Plan de Pruebas Tarea: Generar el Plan de Pruebas Descripción En esta actividad se completa el artefacto Plan de pruebas, en el cual se definen, a partir de los requerimientos, la estrategia, los recursos y ambiente de pruebas. Se seleccionan los productos de trabajo a ser verificados y validados. Además se determina qué tipo de revisión de pares se realizará para evaluar. Entradas Modelo de análisis, Especificación de requerimientos de software (ERS), Plan de proyecto, Especificación de ambientes Plan de proyecto, Plan de pruebas Roles Jefe de proyecto, Arquitecto, Testeador 1.2. Tarea: Crear Casos de Prueba Descripción Se documentan las pruebas a realizar en la Planilla de casos de prueba. Para cada uno de los casos de prueba se establece un identificador, su relación con un caso de uso o funcionalidad mayor, una descripción de la prueba a realizar, los datos con los que se realizará la prueba y el resultado esperado. La Planilla de casos de prueba debe estar disponible para que el equipo de desarrollo conozca lo que se va a probar y permita realizar pruebas unitarias más consistentes. Entradas Modelo de análisis, ERS, Plan de pruebas, Especificación de Ambientes Planilla de casos de prueba Roles Jefe de proyecto, Arquitecto, Testeador Pruebas 35

36 2. Actividad: Ejecutar Pruebas Figura 17. Actividad: Ejecutar las Pruebas Tarea: Aplicar el Plan de Pruebas Descripción Las pruebas funcionales se realizan sobre los requerimientos funcionales y sus casos de uso. La finalidad es verificar la funcionalidad de la aplicación a partir de datos válidamente seleccionados sobre las transacciones del sistema. Se verifica la aplicación (y sus procesos interiores) actuando recíprocamente con la aplicación vía interfaz gráfica de usuario y analizando el rendimiento (resultados). Entradas Plan de pruebas, Planilla de casos de prueba Roles Testeador 2.2. Tarea: Preparar el Plan de Revisiones Descripción Esta tarea se realiza para planificar las revisiones de pares que serán realizadas. Se debe identificar las personas que serán participes de estas revisiones y la información necesaria respecto a los artefactos que serán revisados, junto con establecer el tipo de revisión a realizar. Además, se definen los criterios de aceptación de los mismos. Las revisiones de pares se aplican para revisar código, documentación, arquitectura, diseño, planes de prueba, etc. Entradas Especificación de Requerimientos de Software (ERS) Plan de revisiones Pruebas 36

37 Roles Jefe de proyecto 2.3. Tarea: Ejecutar y Analizar Revisiones Descripción Se ejecutan las revisiones en base al Plan de revisiones y se analizan los resultados de estas revisiones, considerando los criterios de aceptación de los artefactos. De ser necesario, se debe repetir esta actividad si no se cumplen los criterios de aprobación. Entradas Plan de revisiones Plan de revisiones Roles Jefe de proyecto, Equipo de proyecto 2.4. Tarea: Verificar Descripción Esta actividad se realiza para asegurar que los productos de trabajo seleccionados concuerdan con los requerimientos especificados. Incluye la verificación del producto y los productos de trabajo intermedios contra todos los requerimientos seleccionados, incluyendo los requerimientos del Cliente, del producto y de los componentes del producto. Un método probado de verificación es la revisión de pares, el cual es un mecanismo efectivo para eliminar los defectos. A su vez, permite identificar oportunidades de mejora para el proceso. Entradas ERS, Plan de pruebas Roles Testeador, Equipo de proyecto 2.5. Tarea: Validar Descripción Esta actividad se realiza para asegurar que el producto o componentes del producto cumplen con su uso propuesto cuando es instalado en el ambiente propuesto. Entradas Roles ERS, Plan de pruebas Testeador Pruebas 37

38 Artefactos y Roles Tabla 5. Artefactos y Roles de Pruebas. Actividad/Tarea Entradas Roles 1 Desarrollar el Plan de Pruebas 1.1 Generar el Plan de Pruebas Modelo de análisis ERS Plan de proyecto Especificación de ambientes 1.2 Crear Casos de Prueba Modelo de análisis ERS Plan de pruebas Especificación de ambientes 2 Ejecutar Pruebas 2.1 Aplicar el Plan de Pruebas 2.2 Preparar el Plan de Revisiones 2.3 Ejecutar y Analizar Revisiones Plan de pruebas Planilla de casos de prueba 2.4 Verificar ERS Plan de pruebas 2.5 Validar ERS Plan de pruebas Plan de proyecto Plan de pruebas Planilla de casos de prueba Jefe de proyecto Arquitecto Testeador Jefe de proyecto Arquitecto Testeador Testeador ERS Plan de revisiones Jefe de proyecto Plan de revisiones Plan de revisiones Jefe de proyecto Equipo de proyecto Testeador Equipo de proyecto Testeador Pruebas 38

39 Instalación Descripción General Propósito Indicar y planificar actividades que son necesarias efectuar para el paso a producción y poner el sistema a disposición de los usuarios. Objetivos Planificar y preparar el proceso de instalación. Identificar los componentes de software que serán integrados para la instalación. Configurar y preparar el ambiente donde se instalarán los componentes. Integrar los componentes y probar su acoplamiento. Instalar los componentes integrados en producción. Notas Introductorias El plan de instalación se efectúa durante la fase de Elaboración, definiendo el ambiente de certificación y el de producción requerido, siendo refinado a lo largo del resto de las fases. Instalación 39

40 Diagrama General Figura 18. Área de Procesos: Instalación. Instalación 40

41 Actividades y Tareas 1. Tarea: Planificar Instalación e Integración Descripción Se definen las actividades asociadas a la instalación del producto, indicando también las fechas de disponibilidad de ambiente de certificación y paso a producción. Todo esto queda registrado en el Plan de proyecto y en la Carta Gantt de proyecto A su vez, se establece la secuencia de integración de los componentes de software que fueron desarrollados, incluyendo herramientas necesarias para llevar a cabo esta integración y que sea acorde con la solución diseñada. La integración también se documenta en el Plan de proyecto y en la Carta Gantt de proyecto Entradas Plan de proyecto, Especificación de ambientes, Plan de administración de configuraciones, Modelo de diseño Plan de proyecto, Carta Gantt de proyecto Roles Arquitecto, Integrador de sistemas, Administrador de ambientes 2. Tarea: Identificar Piezas de Software para Instalación Descripción Se debe identificar y chequear que todas las piezas requeridas para la instalación del producto estén completas y listas para ser ensambladas. Entradas Planilla de administración de requerimientos Roles Integrador de sistemas 3. Actividad: Preparar Ambiente Figura 19. Actividad: Preparar Ambiente. Instalación 41

42 3.1. Tarea: Chequear Ambiente Actual Descripción Se debe verificar que el ambiente actual cumple con lo necesario para llevar a cabo la instalación. Entradas Especificación de ambientes, Checklist de ambientes, Modelo de diseño Roles Arquitecto, Administrador de ambientes 3.2. Tarea: Instalar y Configurar Ambiente Descripción Se realiza la instalación del ambiente. Normalmente esta actividad es realizada por el Cliente. Entradas Especificación de ambientes, Checklist de ambientes, Modelo de diseño Roles Arquitecto, Administrador de Ambientes, Cliente 4. Actividad: Generar Documentación Figura 20. Actividad: Generar Documentación. Instalación 42

43 4.1. Tarea: Elaborar Manual de Instalación Descripción Se elabora un Manual de instalación que contiene los pasos a seguir para una correcta instalación del producto o las piezas del producto que requieran ser instaladas. Entradas Manual de instalación Roles Documentador 4.2. Tarea: Elaborar Documentos Adicionales Descripción En caso de que el proyecto lo requiera se debe generar documentación adicional para el producto, orientada a sus usuarios. Por ejemplo manual de usuario, documentos de ingeniería reversa, modelos de diseño, especificación de ambientes, modelo de despliegue, etc.) Entradas Roles Documentador 5. Tarea: Integrar Piezas de Software Descripción Se integran todas las piezas de software y sus componentes, además de las interfaces y comunicaciones entre éstos, asegurando que el producto integrado funcione correctamente. Siguiendo lo estipulado en el Modelo de diseño y en el Plan de integración contenido en el artefacto Plan de proyecto. Entradas Roles Modelo de diseño, Plan de proyecto Integrador de sistemas, Arquitecto 6. Tarea: Realizar Pruebas de Integración Descripción Se realizan las pruebas sobre el producto integrado, verificando y validando el producto. Referirse a la actividad Ejecutar Pruebas del área de procesos Pruebas. Entradas Roles Plan de pruebas, Planilla de casos de prueba Sumario de la evaluación de pruebas Testeador 7. Tarea: Instalar en Certificación Descripción Después de realizar las pruebas en integración y si no se encuentran defectos se instala en certificación. En la mayoría de los casos esta actividad es desarrollada por el Cliente. Si esta versión instalada, cambia con respecto a la anterior después de las pruebas de integración, deberá quedar bajo administración de configuración. Instalación 43

44 Entradas Roles Arquitecto, Administrador de Ambientes, Cliente 8. Tarea: Realizar Pruebas de Instalación en Certificación Descripción Se realizan las pruebas sobre el producto instalado en certificación, verificando y validando el producto. Entradas Plan de pruebas, Planilla de casos de prueba Roles Sumario de la evaluación de pruebas Testeador, Cliente 9. Tarea: Realizar Paso a Producción Descripción Los artefactos entregados para el paso a producción ya validados, son pasados para su instalación en producción. En la mayoría de los casos esta actividad es realizada por el Cliente. Entradas Roles Cliente 10. Tarea: Instalar en Producción Descripción Se instala el producto en su ambiente operativo, esta actividad es típicamente realizada por el Administrador de ambientes del Cliente. Entradas Manual de Instalación Roles Administrador de ambientes, Cliente Instalación 44

45 Artefactos y Roles Tabla 6. Artefactos y Roles de Instalación. Actividad/Tarea Entradas Roles 1 Planificar Instalación e Integración 2 Identificar Piezas de Software para Instalación 3 Preparar Ambiente 3.1 Chequear Ambiente Actual 3.2 Instalar y Configurar Ambiente Plan de proyecto Especificación de ambientes Plan de administración de configuraciones Modelo de diseño Planilla de administración de requerimientos Especificación de ambientes Checklist de ambientes Modelo de diseño Especificación de ambientes Checklist de ambientes Modelo de diseño 4 Generar Documentación 4.1 Elaborar Manual de Instalación 4.2 Elaborar Documentos Adicionales 5 Integrar Piezas de Software Modelo de diseño Plan de proyecto 6 Realizar Pruebas de Integración Plan de pruebas Planilla de casos de prueba Plan de proyecto Carta Gantt de proyecto Manual de instalación Sumario de la evaluación de pruebas Arquitecto Integrador de sistemas Administrador de ambientes Integrador de sistemas Arquitecto Administrador de ambientes Arquitecto Administrador de ambientes Cliente Documentador Documentador Integrador de sistemas Arquitecto Testeador 7 Instalar en Certificación Arquitecto Administrador de Ambientes Cliente 8 Realizar Pruebas de Instalación en Certificación Plan de pruebas Planilla de casos de prueba Sumario de la evaluación de pruebas Testeador Cliente 9 Realizar Paso a Producción Cliente Instalación 45

46 Actividad/Tarea Entradas Roles 10 Instalar en Producción Manual de Instalación Administrador de ambientes Cliente Instalación 46

47 Gestión Avanzada de Proyectos 47

48 Gestión de Riesgos Descripción General Propósito Identificar potenciales problemas del proyecto antes de que estos ocurran, con tal de evaluarlos, priorizarlos y administrarlos para prevenir su futura ocurrencia. Objetivos Identificar y analizar todos los riesgos inherentes al proyecto. Desarrollar planes de mitigación para enfrentar los riesgos en caso de que estos ocurran. Planificar la administración de riesgos. Diagrama General Figura 21. Área de Procesos: Gestión de Riesgos. Gestión de Riesgos 48

49 Actividades y Tareas 1. Actividad: Planificar la Administración de Riesgos Notas Introductorias Figura 22. Actividad: Planificar la Administración de Riesgos. El proceso de planificación de administración de riesgos debe desarrollarse en las fases tempranas de la planificación de proyecto, dado que es crucial para las etapas venideras del proyecto. Se debe revisar las actividades a lo largo del proyecto. La planificación de administración de riesgos es el proceso de decidir cómo afrontar y ejecutar las actividades de administración de riesgos de un proyecto Tarea: Desarrollar Calendario de Actividades para Administrar los Riesgos Descripción Se define cuándo y con qué frecuencia se realizarán las tareas de administración de riesgos durante el ciclo de vida del proyecto. Se organizan las actividades con tal de prevenir la ocurrencia y para monitorear y controlar los riesgos previstos. Este calendario es documentado en la sección Plan de administración de riesgos del artefacto Plan de proyecto. Entradas Plan de proyecto Plan de proyecto Roles Jefe de proyecto, Cliente 1.2. Tarea: Identificar Fuentes de Riesgos Descripción Se identifican todas las fuentes de riesgos que puedan afectar al proyecto. Estas fuentes son tanto internas como externas. Además, se deben determinar las Gestión de Riesgos 49

50 Entradas Roles categorías de riesgo de las fuentes existentes para la posterior recopilación y Organización de los riesgos. Por ejemplo, en un proyecto dónde no se tienen muy claros los requerimientos, definitivamente la especificación de requerimientos es una fuente de riesgo importantes, y esos riesgos pueden categorizarse en varios tipos, como riesgo de requerimientos inconsistentes entre sí, riesgo de requerimientos que no reflejan lo que realmente necesita el Cliente, etc. Lista de riesgos Jefe de proyecto, Cliente 1.3. Tarea: Desarrollar una Estrategia para la Administración de Riesgos Descripción Se identifican métodos, herramientas y actividades que puedan ser útiles para enfrentar la ocurrencia de algún riesgo identificado. Para la administración de riesgos es importante definir la estrategia con la cual se abordaran los riesgos. Estas estrategias se documentan en la sección Plan de administración de riesgos del artefacto Plan de proyecto. Entradas Plan de proyecto Roles Jefe de proyecto, Cliente 2. Actividad: Identificar y Analizar Riesgos Notas Introductorias Figura 23. Actividad: Identificar y Analizar Riesgos. La identificación y análisis de riesgos es un proceso iterativo durante todo el ciclo de vida del proyecto, ya que se pueden descubrir nuevos riesgos a medida que el proyecto avanza Tarea: Identificar Riesgos Gestión de Riesgos 50

51 Descripción A partir de las fuentes de riesgos encontradas (tanto internas como externas), se identifican todos los riesgos que puedan afectar el éxito del proyecto, detallando y documentando las características de cada uno de estos. Entradas Lista de riesgos Lista de riesgos Roles Equipo de proyecto 2.2. Tarea: Analizar Riesgos y Estimar Magnitud Descripción Una vez identificados los riesgos, se evalúa cada uno de ellos y se determina una probabilidad de ocurrencia, el impacto y prioridad, en base a los criterios preestablecidos en el artefacto Lista de riesgos. Se estima la magnitud con las que serán priorizados los riesgos, para que una vez identificados, estos puedan ser organizados y administrados de forma correcta. Entradas Lista de riesgos Lista de riesgos Roles Equipo de proyecto 2.3. Tarea: Desarrollar Plan de Acción Descripción Analizados los riesgos, por cada uno de ellos se detallan planes de mitigación para disminuir la probabilidad de ocurrencia de un riesgo y se desarrollan planes de contingencia para enfrentar los efectos en caso de que el riesgo identificado se transforme en un problema real. Entradas Lista de riesgos Lista de riesgos Roles Jefe de proyecto, Cliente Gestión de Riesgos 51

52 3. Actividad: Seguir los Riesgos Figura 24. Actividad: Seguir los Riesgos Tarea: Controlar y Monitorear Riesgos Descripción Se monitorean y controlan los riesgos identificados según la calendarización desarrollada anteriormente. Se evalúan los riesgos y, en caso que fuere necesario, se modifican los planes de acción. Durante esta etapa pueden descubrirse nuevos riesgos, por lo que es necesario actualizar la lista de riesgos y desarrollar planes de acción para hacer frente a estos nuevos riesgos. Entradas Lista de riesgos, Plan de proyecto Lista de riesgos, Plan de proyecto Roles Jefe de proyecto, Cliente Gestión de Riesgos 52

53 3.2. Tarea: Ejecutar Plan de Contingencia Descripción En caso de que algún riesgo ocurra se deben ejecutar las actividades planificadas en el plan de acción para enfrentar la ocurrencia de este. Entradas Lista de riesgos Roles Jefe de proyecto, Equipo de proyecto Gestión de Riesgos 53

54 Artefactos y Roles Tabla 7. Artefactos y Roles de Gestión de Riesgos. Actividad/Tarea Entradas Roles 1 Planificar la Administración de Riesgos 1.1 Desarrollar Calendario de Actividades para Administrar los Riesgos 1.2 Identificar Fuentes de Riesgos 1.3 Desarrollar una Estrategia para la Administración de Riesgos 2 Identificar y Analizar Riesgos Plan de proyecto Plan de proyecto Jefe de proyecto Cliente Lista de riesgos Plan de proyecto Jefe de proyecto Cliente Jefe de proyecto Cliente 2.1 Identificar Riesgos Lista de riesgos Lista de riesgos Equipo de proyecto 2.2 Analizar Riesgos y Lista de riesgos Lista de riesgos Equipo de proyecto Estimar Magnitud 2.3 Desarrollar Plan de Acción 3 Seguir los Riesgos 3.1 Controlar y Monitorear Riesgos 3.2 Ejecutar Plan de Contingencia Lista de riesgos Lista de riesgos Jefe de proyecto Cliente Lista de riesgos Plan de proyecto Lista de riesgos Lista de riesgos Plan de proyecto Jefe de proyecto Cliente Jefe de proyecto Equipo de proyecto Gestión de Riesgos 54

Sistema de Administración de Farmacias Plan de SQA. Historia de revisiones

Sistema de Administración de Farmacias Plan de SQA. Historia de revisiones Sistema de Administración de Farmacias Plan de SQA Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 29/08/2014 1.0 Realización del documento Resp. SQA Plan de SQA Página 1 de 15 ÍNDICE

Más detalles

COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a

COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a 5. METODOLOGIAS COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a incrementar su valor a través de las tecnologías, y permite su alineamiento con los objetivos del negocio

Más detalles

K2BIM Plan de Proyecto Versión 1.5

K2BIM Plan de Proyecto Versión 1.5 K2BIM Plan de Proyecto Versión 1.5 Historia de revisiones Fecha VersiónDescripción Autor 23/08/2009 1.0 Versión inicial Juan Saavedra 25/08/2009 1.1 Entregable Juan Saavedra 30/08/ 1.2 Se incluyen recursos

Más detalles

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0 Deportes LSI 03 Sistema para Gestión de Artículos Deportivos LSI 03 Versión 3.0 Fecha: 02/01/2003 Historial de Revisiones Fecha Versión Descripción Autor 22/07/2002 0.9 Versión preliminar como propuesta

Más detalles

DESARROLLO DE SOFTWARE DEFINICIÓN GENERAL DEL PROCESO GABY LORENA GUERRERO LEYDI ROCIO ERAZO PABLO FELIPE MIRANDA WALTER ALEXIS ANTE

DESARROLLO DE SOFTWARE DEFINICIÓN GENERAL DEL PROCESO GABY LORENA GUERRERO LEYDI ROCIO ERAZO PABLO FELIPE MIRANDA WALTER ALEXIS ANTE DESARROLLO DE SOFTWARE DEFINICIÓN GENERAL DEL PROCESO GABY LORENA GUERRERO LEYDI ROCIO ERAZO PABLO FELIPE MIRANDA WALTER ALEXIS ANTE UNIVERSIDAD DEL CAUCA FACULTAD DE INGENIERÍA ELECTRÓNICA Y TELECOMUNICACIONES

Más detalles

Ingeniería de Software Calidad de Procesos y Productos de Software

Ingeniería de Software Calidad de Procesos y Productos de Software Ingeniería de Software Calidad de Procesos y Productos de Software M. Visconti & H. Astudillo Departamento de Informática Universidad Técnica Federico Santa María Calidad

Más detalles

Ingeniería de Requisitos

Ingeniería de Requisitos Ingeniería de Requisitos Temario Definiciones Requisitos Funcionales y No Funcionales Tipos de Requisitos Ingeniería de Requisitos Proceso de los Requisitos Obtención de Requisitos - Técnicas Modelado

Más detalles

Tema 2. Ingeniería del Software I feliu.trias@urjc.es

Tema 2. Ingeniería del Software I feliu.trias@urjc.es Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición

Más detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 1: Conceptos y Guía Introductoria MAYO 2009 Tabla de Contenidos 1. PREFACIO...5 1.1. ESPECIFICACIONES...5 1.2. PUBLICACIÓN...6 1.3.

Más detalles

El proceso unificado en pocas palabras

El proceso unificado en pocas palabras El Proceso Unificado de Desarrollo de Software Ivar Jacobson Grady Booch James Rumbaugh Addison Wesley Resumen Capítulo 1. El proceso unificado: dirigido por casos de uso, centrado en la arquitectura,

Más detalles

LINQ TO AMAZON PLAN DE PROYECTO. Versión 1.2

LINQ TO AMAZON PLAN DE PROYECTO. Versión 1.2 LINQ TO AMAZON PLAN DE PROYECTO Versión 1.2 Historia de revisiones Fecha Versión Descripción Autor 23/08/2008 1.0 Creación del documento. Martín Rivadavia 20/08/2008 1.1 Correcciones. Martín Rivadavia

Más detalles

Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables.

Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables. Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables. Para obtener el grado de Maestro en Ciencias (Ciencias y Tecnologías de la Información) P R E S E N T A Lic.

Más detalles

Aplicaciones de Ingeniería de Software

Aplicaciones de Ingeniería de Software Aplicaciones de Ingeniería de Software Administración de la Calidad del Producto de Software Qué es la gestión de la calidad? Es una actividad protectora o de sombrilla que se aplica a lo largo del proceso

Más detalles

PUD: Proceso de Desarrollo Unificado

PUD: Proceso de Desarrollo Unificado PUD: Proceso de Desarrollo Unificado 1 1998 Genealogía del PUD Rational Unified Process 5.0 1997 Rational Objectory Process 4.1 UML 1996 Rational Objectory Process 4.0 1995 Método Ericsson Rational Approach

Más detalles

Tecnología de la Información. Administración de Recursos Informáticos

Tecnología de la Información. Administración de Recursos Informáticos Tecnología de la Información Administración de Recursos Informáticos 1. Recursos informáticos: Roles y Responsabilidades 2. Áreas dentro del Departamento de Sistemas 3. Conceptos asociados a proyectos

Más detalles

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0 Centro Ideoinformática Universidad de las Ciencias Informáticas Carretera a San Antonio Km 2 ½. Torrens. Boyeros. Ciudad de La Habana. Cuba Teléfono: + 53 (7)

Más detalles

Testing. Tipos, Planificación y Ejecución de Pruebas

Testing. Tipos, Planificación y Ejecución de Pruebas Testing Tipos, Planificación y Ejecución de Pruebas Contenido Definiciones del Testing de Software Objetivos, conceptos Tipos de Test Testing a-la RUP Rol del Testing en el proceso Artefactos Trabajadores

Más detalles

ANEXO I CONDICIONES PARTICULARES

ANEXO I CONDICIONES PARTICULARES REGISTRO ELECTRONICO DE CONSTRUCTORAS DE OBRA PÚBLICA 1. OBJETO ANEXO I CONDICIONES PARTICULARES La presente contratación directa tiene por objeto la obtención de los servicios Análisis, Desarrollo e Implantación

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

GUÍAS. Módulo de Diseño de software SABER PRO 2013-2

GUÍAS. Módulo de Diseño de software SABER PRO 2013-2 GUÍAS Módulo de Diseño de software SABER PRO 2013-2 GUÍAS Módulo de diseño en ingeniería El diseño de productos tecnológicos (artefactos, procesos, sistemas e infraestructura) está en el centro de la naturaleza

Más detalles

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Plan de Desarrollo de Software Universidad

Más detalles

METODOLOGÍA DE GESTION DE PROYECTOS

METODOLOGÍA DE GESTION DE PROYECTOS METODOLOGÍA DE GESTION DE PROYECTOS CONTENIDO CONTENIDO... 2 ALCANCE... 4 MARCO METODOLÓGICO... 4 ETAPAS DEL PROCESO... 5 1. ETAPA 0: INICIACIÓN...5 FASE DE INICIO...5 2. ETAPA 1: PLANEAMIENTO...6 FASE

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

K2BIM Plan de SQA Versión 1.1

K2BIM Plan de SQA Versión 1.1 K2BIM Plan de SQA Versión 1.1 Historia de revisiones Fecha VersiónDescripción Autor 18/08/2009 1.0 Creación del documento. Diego Píriz 23/08/2009 1.1 Pequeñas correciones. Alan Descoins 1 Contenido 1.

Más detalles

SISTEMAS DE INFORMACIÓN III TEORÍA

SISTEMAS DE INFORMACIÓN III TEORÍA CONTENIDO: QUÉ ES CALIDAD DEL SOFTWARE? ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE CONTROL DE LA CALIDAD DEL SOFTWARE AUDITORÍA DE LA CALIDAD DEL SOFTWARE CALIDAD DEL PRODUCTO DE SOFTWARE CALIDAD DEL PROCESO

Más detalles

Ciclo de vida del Software

Ciclo de vida del Software Tema 2: Ciclo de vida del Software Marcos López Sanz Índice Qué es el ciclo de vida del Software? La norma 12207-2008 Modelos de desarrollo Qué es el Ciclo de Vida del SW? Es una sucesión de etapas por

Más detalles

Introducción a la Ingeniería de Software - Examen 20/07/2012

Introducción a la Ingeniería de Software - Examen 20/07/2012 Cada pregunta múltiple opción contestada correctamente tiene un valor de 2,5 puntos. Esta parte consta de 20 preguntas, haciendo un total de 50 puntos. Los ejercicios de desarrollo tienen un valor total

Más detalles

PEEPER PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS. Mayo 2014. Versión 2.1 OSCAR IVAN LÓPEZ PULIDO

PEEPER PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS. Mayo 2014. Versión 2.1 OSCAR IVAN LÓPEZ PULIDO PEEPER Implementación del cambio de técnica usada para la actualización de datos en los reportes de esfuerzo, usados como métrica de productividad, progreso y costo de los proyectos, de la compañía de

Más detalles

<> Checklist ERS Administración de Calidad. Cliente: <> Cliente Final: <> Versión: 1.0 Fecha: 12.02.

<<Proyecto>> Checklist ERS Administración de Calidad. Cliente: <<Cliente>> Cliente Final: <<Cliente Final>> Versión: 1.0 Fecha: 12.02. Checklist ERS Administración de Calidad Cliente: Cliente Final: Versión: 1.0 Fecha: 12.02.2007 www.snoopconsulting.com CONTENIDO CONTENIDO... 2 DATOS DEL CHECKLISTS...

Más detalles

CAPÍTULO I AUDITORÍA INFORMÁTICA PRESENTACIÓN DEL PROYECTO

CAPÍTULO I AUDITORÍA INFORMÁTICA PRESENTACIÓN DEL PROYECTO CAPÍTULO I AUDITORÍA INFORMÁTICA PRESENTACIÓN DEL PROYECTO 1.1 PROYECTO - Auditoría Informática de los sistemas de información de la ESPE Dominio de Planeación y Organización. 1.2 INTRODUCCIÓN - La evolución

Más detalles

METODOLOGÍA DESARROLLO DE SOFTWARE PARA PYMES DE RETAIL

METODOLOGÍA DESARROLLO DE SOFTWARE PARA PYMES DE RETAIL ! METODOLOGÍA DESARROLLO DE SOFTWARE PARA PYMES DE RETAIL TESIS PARA OPTAR AL GRADO DE MAGÍSTER EN TECNOLOGÍAS DE LA INFORMACIÓN MARCO ANTONIO RIBÓ COLELLA PROFESOR GUÍA: CECILIA BASTARRICA MIEMBROS DE

Más detalles

Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera. Departamento de Lenguajes y Sistemas Informáticos

Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera. Departamento de Lenguajes y Sistemas Informáticos Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera Departamento de Lenguajes y Sistemas Informáticos INDICE 1. Introducción. 2. Documentación del Proyecto de Fin de

Más detalles

Módulo Profesional 01: Bases de datos (código: 0484).

Módulo Profesional 01: Bases de datos (código: 0484). Módulo Profesional 01: Bases de datos (código: 0484). Actividades de enseñanza-aprendizaje que permiten alcanzar los objetivos del módulo. Interpretar diseños lógicos de bases de datos. Realizar el diseño

Más detalles

TTP / Informática Profesional y Personal Módulo / Conexión entre dos computadoras

TTP / Informática Profesional y Personal Módulo / Conexión entre dos computadoras Ministerio de Educación, Ciencia y Tecnología TTP / Informática Profesional y Personal Módulo / Conexión entre dos computadoras Aprobado por Res. 190/02 CFCyE Presentación La problemática abordada por

Más detalles

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Ingeniería de Software

Ingeniería de Software Departamento de Informática Universidad Técnica Federico Santa María Pauta Plan de Proyecto Profesor: Dr. Marcello Visconti Zamora visconti@inf.utfsm.cl 0 Portadas El documento que se está generando corresponde

Más detalles

Prof. Juan José Díaz Nerio. Foro de Tecnología : Gestión de la Calidad del Software. Domingo 16 Noviembre 2014

Prof. Juan José Díaz Nerio. Foro de Tecnología : Gestión de la Calidad del Software. Domingo 16 Noviembre 2014 Prof. Juan José Díaz Nerio. Foro de Tecnología : Gestión de la Calidad del Software. Domingo 16 Noviembre 2014 Agenda La Crisis del Software Conceptos asociados a Calidad Atributos de Calidad Funciones

Más detalles

MANTENIMIENTO DE SEGUNDO NIVEL EN SISTEMAS DE RADIOCOMUNICACIONES

MANTENIMIENTO DE SEGUNDO NIVEL EN SISTEMAS DE RADIOCOMUNICACIONES Página 1 de 24 CUALIFICACIÓN PROFESIONAL MANTENIMIENTO DE SEGUNDO NIVEL EN SISTEMAS DE RADIOCOMUNICACIONES Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC366_3 Versión 5 Situación RD

Más detalles

INDICADORES DE VALORACIÓN EDUCACIÓN SECUNDARIA ÁREA CIENCIAS SOCIALES NIVELES D, E, G2

INDICADORES DE VALORACIÓN EDUCACIÓN SECUNDARIA ÁREA CIENCIAS SOCIALES NIVELES D, E, G2 INDICADORES DE VALORACIÓN EDUCACIÓN SECUNDARIA ÁREA CIENCIAS SOCIALES NIVELES D, E, G2 Indicadores Identificación y formulación del problema Delimitación del problema. Relevancia social, política y cultural

Más detalles

COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE

COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE Creado en May/14 Objetivo: Contar con una guía de las actividades que se deben realizar en esta fase,

Más detalles

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A.

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A. Cátedra : Sistemas de Información Administrativa S.I.A. Escuela de Contadores Auditores Tema: Ingeniería del Software SLC -ERS Relator: Sr. Eduardo Leyton G Ingeniería de Software (IS) Es una disciplina

Más detalles

Modelado y Diseño de Arquitectura de Software

Modelado y Diseño de Arquitectura de Software Modelado y Diseño de Arquitectura de Software CONCEPTOS DE MODELADO Fernando Barraza A. MS.c. fernando.barraza@gmail.com 2 Desarrollo de sistemas de software Requisitos funcionales del software Si todo

Más detalles

Consideraciones para implementaciones BPM y EDA

Consideraciones para implementaciones BPM y EDA Consideraciones para implementaciones BPM y EDA Jesús Buriticá IBM Software Group Brand Architect jburitic@ve.ibm.com Agenda Manejando los conceptos sobre BPM y EDA Abordar una iniciativa BPM/EDA Algunos

Más detalles

Tema 1 Introducción a la Ingeniería de Software

Tema 1 Introducción a la Ingeniería de Software Tema 1 Introducción a la Ingeniería de Software Curso Ingeniería de Software UMCA Profesor Luis Gmo. Zúñiga Mendoza 1. Software En la actualidad todo país depende de complejos sistemas informáticos. Podemos

Más detalles

ISO 9001:2015 Principales cambios

ISO 9001:2015 Principales cambios ISO 9001:2015 Principales cambios ISO 9001: 2015 se basa en el Anexo SL - la nueva estructura de alto nivel. Se trata de un marco común para todos los sistemas de gestión ISO. Esto ayuda a mantener la

Más detalles

Unidades temáticas de Ingeniería del Software. Fases del proceso de desarrollo 4ª edición (2008)

Unidades temáticas de Ingeniería del Software. Fases del proceso de desarrollo 4ª edición (2008) Unidades temáticas de Ingeniería del Software Fases del proceso de desarrollo 4ª edición (2008) Facultad de Informática organización del desarrollo El ciclo de vida del software abarca el proceso de desarrollo,

Más detalles

Calidad del software. Ingeniería del Software I Universidad Rey Juan Carlos

Calidad del software. Ingeniería del Software I Universidad Rey Juan Carlos Calidad del software Ingeniería del Software I Universidad Rey Juan Carlos Definición de Calidad Software I do not worry whether something is cheap or expensive. I only worry if it is good. If it is good

Más detalles

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]:

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]: RESUMEN DE COBIT 4.1 COBIT es un marco de trabajo y un conjunto de herramientas de Gobierno de Tecnología de Información (TI) que permite a la Gerencia cerrar la brecha entre los requerimientos de control,

Más detalles

MEJORAMIENTO DEL PROCESO DE SCM: MARCO DE REFERENCIA Y APLICACIÓN PRÁCTICA. Abstract

MEJORAMIENTO DEL PROCESO DE SCM: MARCO DE REFERENCIA Y APLICACIÓN PRÁCTICA. Abstract MEJORAMIENTO DEL PROCESO DE SCM: MARCO DE REFERENCIA Y APLICACIÓN PRÁCTICA Rodolfo Villarroel 1 Departamento de Computación e Informática Universidad Católica del Maule, Chile rvillarr@spock.ucm.cl Marcello

Más detalles

El Desarrollo de Software desde un enfoque de procesos

El Desarrollo de Software desde un enfoque de procesos El Desarrollo de Software desde un enfoque de procesos Planteamiento del Problema Desarrollo de Software Software Proceso: conjunto de actividades interrelacionadas que permiten

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: DETERMINACIÓN DE REQUERIMIENTOS ENTREVISTAS, CUESTIONARIOS, OBSERVACIONES JOINT APPICATION DESIGN (JAD) PROTOTIPOS, CASE, GROUPWARE Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza

Más detalles

REQ. Fundamento Institucional. Objetivos

REQ. Fundamento Institucional. Objetivos REQ INSTRUCCIONES: a continuación se describe el flujo de trabajo correspondiente al área de procesos de REQUERIMIENTOS para el desarrollo de software en el cual se debe apoyar para la ejecución de sus

Más detalles

ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE

ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE INTRODUCCIÓN La calidad es un concepto complejo, que se viene aplicando en el campo de la informática desde hace muchos años, la aplicación de la calidad al

Más detalles

Pruebas de Usabilidad Cómo planificar, diseñar y conducir pruebas de usabilidad efectivas. Contenido. Diseño centrado en el usuario 17/06/2011

Pruebas de Usabilidad Cómo planificar, diseñar y conducir pruebas de usabilidad efectivas. Contenido. Diseño centrado en el usuario 17/06/2011 Pruebas de Usabilidad Cómo planificar, diseñar y conducir pruebas de usabilidad efectivas Introducción Preparación Conducción Análisis de resultados Reporte de resultados Contenido Diseño centrado en el

Más detalles

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual Introducción Algunas de las personas que trabajan con SGBD relacionales parecen preguntarse porqué deberían preocuparse del diseño de las bases de datos que utilizan. Después de todo, la mayoría de los

Más detalles

GESTIÓN Y CONTROL DEL DESARROLLO E IMPLANTACIÓN DE APLICACIONES

GESTIÓN Y CONTROL DEL DESARROLLO E IMPLANTACIÓN DE APLICACIONES Ciclo Formativo: Módulo: Desarrollo de Aplicaciones Informáticas Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión Unidad de Trabajo 10: GESTIÓN Y CONTROL DEL DESARROLLO E IMPLANTACIÓN

Más detalles

Calidad y Software. Evento ONGEI 29 mar 11. www.asistp.com 1

Calidad y Software. Evento ONGEI 29 mar 11. www.asistp.com 1 Calidad y Software Evento ONGEI 29 mar 11 www.asistp.com 1 Agenda La Calidad y los Procesos El Proceso de Software Las pruebas de Software www.asistp.com 2 Calidad www.asistp.com 3 Calidad algunas definiciones

Más detalles

Denominación de la materia. N créditos ECTS = 60 carácter = OPTATIVA INGENIERIA DE SOFTWARE

Denominación de la materia. N créditos ECTS = 60 carácter = OPTATIVA INGENIERIA DE SOFTWARE Denominación de la materia INGENIERIA DE SOFTWARE N créditos ECTS = 60 carácter = OPTATIVA Ubicación dentro del plan de estudios y duración Esta materia conforma el itinerario de Ingeniería de Software.

Más detalles

Gestión y Desarrollo de Requisitos en Proyectos Software

Gestión y Desarrollo de Requisitos en Proyectos Software Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería

Más detalles

Antes de imprimir este documento piense en el medio ambiente!

Antes de imprimir este documento piense en el medio ambiente! Versión 2.0 Página 1 de 13 1. OBJETIVO: Establecer las etapas que se siguen en el desarrollo y mantenimiento evolutivo y adaptativo de sistemas de información, definiendo el flujo de actividades que se

Más detalles

ORIENTACIONES PARA LA IMPLEMENTACIÓN DE UN SISTEMA INTEGRADO DE GESTIÓN DE LA CALIDAD, AMBIENTAL Y SEGURIDAD Y SALUD EN EL TRABAJO.

ORIENTACIONES PARA LA IMPLEMENTACIÓN DE UN SISTEMA INTEGRADO DE GESTIÓN DE LA CALIDAD, AMBIENTAL Y SEGURIDAD Y SALUD EN EL TRABAJO. ORIENTACIONES PARA LA IMPLEMENTACIÓN DE UN SISTEMA INTEGRADO DE GESTIÓN DE LA CALIDAD, AMBIENTAL Y SEGURIDAD Y SALUD EN EL TRABAJO. 1. INTRODUCCION Esta guía pretende orientar a los consultores que asesoran

Más detalles

Nomenclador de cargos

Nomenclador de cargos Nomenclador de cargos ROLES Áreas de I T Definición de módulos y roles Versión: 1.0 Pagina 1 Módulos interactuantes en un área de IT 1. Infraestructura Tecnológica 2. Producción de Software 3. Asistencia

Más detalles

<TITULO DEL PROYECTO DE DESARROLLO DE SW > Diana Milena Pérez Riveros 1 Diana Milena Pérez Riveros Pagina de

Más detalles

CLASE # 4 DESCRIPCIÓN GENERAL DE LAS PRUEBAS DINÁMICAS

CLASE # 4 DESCRIPCIÓN GENERAL DE LAS PRUEBAS DINÁMICAS CLASE # 4 DESCRIPCIÓN GENERAL DE LAS PRUEBAS DINÁMICAS 750105M - TÉCNICAS DE PRUEBAS DE SOFTWARE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN UNIVERSIDAD DEL VALLE SEMESTRE 2013A - DOCENTE BEATRIZ FLORIAN GAVIRIA

Más detalles

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV 746 Miércoles 5 octubre 2005 Suplemento del BOE núm. 238 CE2.1 Identificar los distintos sistemas de archivo utilizables en un dispositivo de almacenamiento dado para optimizar los procesos de registro

Más detalles

Pauta de Informe de Proyecto

Pauta de Informe de Proyecto Departamento de Informática Universidad Técnica Federico Santa María Pauta de Informe de Proyecto ILI-236 Profesores: Hernán Astudillo y Marcello Visconti 1 Introducción... 3 2 Plan de trabajo... 3 3 Análisis...

Más detalles

Administración y Gestión de Proyectos de Software

Administración y Gestión de Proyectos de Software Administración y Gestión de Proyectos de Software 2do. Cuatrimestre 2005 Depto. Cs. e Ingeniería de la Computación Universidad Nacional del Sur Riesgo: Componentes Riesgo de Rendimiento: el grado de incertidumbre

Más detalles

Denominación de la materia. N créditos ECTS = 60 carácter = OPTATIVA INGENIERIA DE SOFTWARE

Denominación de la materia. N créditos ECTS = 60 carácter = OPTATIVA INGENIERIA DE SOFTWARE Denominación de la materia INGENIERIA DE SOFTWARE N créditos ECTS = 60 carácter = OPTATIVA Ubicación dentro del plan de estudios y duración Esta materia conforma el itinerario de Ingeniería de Software.

Más detalles

Diplomado en Aseguramiento de la Calidad De los Procesos y Productos de Software

Diplomado en Aseguramiento de la Calidad De los Procesos y Productos de Software Diplomado en Aseguramiento de la Calidad De los Procesos y Productos de Software Contenido del programa MÓDULO 1. GESTIÓN DE INGENIERÍA DE REQUERIMIENTOS DE SOFTWARE /16 horas Definiciones Requerimientos

Más detalles

Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas

Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas Información General del Documento Versión Actual del Documento 0.0.0.7 Descripción

Más detalles

Documentando la arquitectura de software Principios básicos por Omar Gómez

Documentando la arquitectura de software Principios básicos por Omar Gómez Documentando la arquitectura de software Principios básicos por Omar Gómez En la actualidad, uno de los temas candentes que se habla dentro de la comunidad de desarrollo de software es el referente a las

Más detalles

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

Más detalles

B.1 Checklist: evaluación heurística del producto software

B.1 Checklist: evaluación heurística del producto software Apéndice B Plantillas En las siguientes secciones se describen las plantillas textuales necesarias para la descripción de los documentos empleados en OPSOA. B.1 Checklist: evaluación heurística del producto

Más detalles

Definir el problema/oportunidad. Desarrollar soluciones alternativas. Seleccionar la solución. Desarrollar / Seleccionar-Adquirirconfigurar

Definir el problema/oportunidad. Desarrollar soluciones alternativas. Seleccionar la solución. Desarrollar / Seleccionar-Adquirirconfigurar 1 Definir el problema/oportunidad Definir problema de negocio o la oportunidad de mejora utilizando el pensamiento sistémico. Mapa Conceptual Desarrollar soluciones alternativas Seleccionar la solución

Más detalles

Parte 1 Múltiple Opción

Parte 1 Múltiple Opción Cada pregunta de la parte múltiple opción contestada correctamente tiene un valor de 1,5 puntos. Cada pregunta incorrecta de la múltiple opción resta 0,5 puntos. Esta parte consta de 25 preguntas por lo

Más detalles

Importancia de la administración de riesgos

Importancia de la administración de riesgos Importancia de la administración de riesgos Una de las definiciones más interesantes acerca de esta teoría es la presentada por McConnell (1997), quien se refiere a la administración de riesgos de la siguiente

Más detalles

Implantación de Sistemas

Implantación de Sistemas Implantación de Sistemas Maria Ines Parnisari 17 de Diciembre de 2014 Índice Parte 1: Implantación... 2 Factores clave para una implantación exitosa... 2 Etapas de un proyecto de Sistemas... 2 Fases de

Más detalles

6 Anexos: 6.1 Definición de Rup:

6 Anexos: 6.1 Definición de Rup: 6 Anexos: 6.1 Definición de Rup: Es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo.

Más detalles

Control de Calidad de Software. Ing. Jorge Montaño Párraga

Control de Calidad de Software. Ing. Jorge Montaño Párraga Control de Calidad de Software Ing. Jorge Montaño Párraga Agenda Contenido Porque es necesario controlar la calidad? Que es testear? 7 Principios de Control de Calidad Proceso Fundamental de SQA Porque

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN Clase 6: Ingeniería de Requerimientos Metododología y Ejemplo Primer Cuatrimestre 2015 Mg. María Mercedes Vitturini

Más detalles

Perfil del Ingeniero en Información y Control de Gestión

Perfil del Ingeniero en Información y Control de Gestión Perfil del Ingeniero en Información y Control de Gestión El Ingeniero en Información y Control de Gestión de la Universidad de Chile es un profesional formado para diseñar, implementar y monitorear sistemas

Más detalles

Universidad Nacional del Sur Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas 1er.Cuatrimestre de 2006.

Universidad Nacional del Sur Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas 1er.Cuatrimestre de 2006. Análisis y Diseño de Sistemas Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Clase 2 Calidades del producto y del proceso Lic. María Mercedes Vitturini [mvitturi@cs.uns.edu.ar]

Más detalles

GUÍA PARA LA MIGRACIÓN DE BASES DE DATOS

GUÍA PARA LA MIGRACIÓN DE BASES DE DATOS MINISTERIO DE SALUD Y PROTECCIÓN SOCIAL BOGOTÁ, AGOSTO DE TABLA DE CONTENIDO I. PROPÓSITO... 3 II. ALCANCE... 3 III. DOCUMENTOS DEL SIGI ASOCIADOS A LA GUÍA... 3 IV. DEFINICIONES... 3 V. NORMATIVA Y OTROS

Más detalles

Estándar Australiano / Neo Zelandés

Estándar Australiano / Neo Zelandés CD&A Consultores de Riesgos Estándar Australiano / Neo Zelandés Administración de Riesgos (Revisión del estándar AS/NZS 4360:1999) PREFACIO Este Estándar fue preparado por el Comité Conjunto de Estándares

Más detalles

INTRODUCCIÓN A LOS PROCESOS DE LA GESTIÓN DE RIESGOS DEL PROYECTO 2. INTRODUCCIÓN A LOS PROCESOS DE LA GESTIÓN DE RIESGOS DEL PROYECTO

INTRODUCCIÓN A LOS PROCESOS DE LA GESTIÓN DE RIESGOS DEL PROYECTO 2. INTRODUCCIÓN A LOS PROCESOS DE LA GESTIÓN DE RIESGOS DEL PROYECTO SESIÓN 2 INTRODUCCIÓN A LOS PROCESOS DE LA GESTIÓN DE RIESGOS DEL PROYECTO INTRODUCCIÓN A LA GESTIÓN DE RIESGOS PRINCIPIOS Y CONCEPTOS INTRODUCCIÓN A LOS PROCESOS DE LA GESTIÓN DE RIESGO DEL PROYECTO CONSTRUYENDO

Más detalles

CAPITULO 2. Como se definió en el plan del presente proyecto, este será desarrollado bajo

CAPITULO 2. Como se definió en el plan del presente proyecto, este será desarrollado bajo 1 CAPITULO 2 ANÁLISIS DEL SISTEMA 1. Introducción Como se definió en el plan del presente proyecto, este será desarrollado bajo la metodología orientada a objetos. El objetivo del análisis será marcar

Más detalles

Resumen General del Manual de Organización y Funciones

Resumen General del Manual de Organización y Funciones Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de

Más detalles

CONTRALORÍA GENERAL DE LA REÚBLICA DE CHILE

CONTRALORÍA GENERAL DE LA REÚBLICA DE CHILE 1 XIV CONCURSO ANUAL DE INVESTIGACIÓN ENFOQUE METODOLÓGICO DE AUDITORÍA A LAS TECNOLOGÍAS DE INFORMACIÓN Y COMUNICACIONES SEUDÓNIMO 6free CONTRALORÍA GENERAL DE LA REÚBLICA DE CHILE 2 SUMARIO Página RESUMEN

Más detalles

Unidad 9. Implementación. M.C. Martín Olguín

Unidad 9. Implementación. M.C. Martín Olguín Unidad 9 Implementación M.C. Martín Olguín Implementación Es la traducción directa del diseño en un lenguaje de programación. Es decir, en la implementación se construyen los componentes: Archivos de código

Más detalles

Módulo Representación gráfica e interpretación de planos

Módulo Representación gráfica e interpretación de planos Trayecto Técnico Profesional en Industrias de Procesos Módulo Representación gráfica e Instituto Nacional de Educación Tecnológica Ministerio de Educación Ciencia y Tecnología Presentación El módulo Representación

Más detalles

INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS

INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS Rubby Casallas, Andrés Yie Departamento de Sistemas y Computación Facultad de Ingeniería Universidad de los Andes Agenda Contexto Ciclos de vida: Modelo

Más detalles

Aplicaciones Web a tu medida!

Aplicaciones Web a tu medida! Nota aclaratoria: El presente documento se realizó tomando como base el documento titulado Ingeniería de Requisitos en Aplicaciones para la Web Un estudio comparativo escrito por María José Escalona (Universidad

Más detalles

5.3.2.8 FICHA DE LA MATERIA INGENIERÍA DEL SOFTWARE, SISTEMAS DE INFORMACIÓN Y SISTEMAS INTELIGENTES

5.3.2.8 FICHA DE LA MATERIA INGENIERÍA DEL SOFTWARE, SISTEMAS DE INFORMACIÓN Y SISTEMAS INTELIGENTES 5.3.2.8 FICHA DE LA MATERIA INGENIERÍA DEL SOFTWARE, SISTEMAS DE INFORMACIÓN Y SISTEMAS INTELIGENTES DENOMINACIÓN DE LA MATERIA INGENIERÍA DEL SOFTWARE, SISTEMAS DE INFORMACIÓN Y SISTEMAS INTELIGENTES

Más detalles

Manual de Gestión de Calidad

Manual de Gestión de Calidad Manual de Gestión de Calidad MC: v2 Fecha: 26/12/2013 MANUAL DE GESTIÓN DE CALIDAD Revisión: 2 Indica modificaciones Vigencia : 26/12/2013 Copia no controlada La información contenida en este manual no

Más detalles

GERENCIA DE INTEGRACIÓN

GERENCIA DE INTEGRACIÓN GERENCIA DE INTEGRACIÓN CONTENIDO Desarrollo del plan Ejecución del plan Control de cambios INTRODUCCIÓN La gerencia de integración del proyecto incluye los procesos requeridos para asegurar que los diversos

Más detalles