Administración de Requerimientos

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

Download "Administración de Requerimientos"

Transcripción

1 Administración de Requerimientos 1

2 Agenda Software Requirements Knowledge Areas. Requirement Statement. Requirement Specification. Agreement and Expectation Mgmt.. Las 5 dimensiones. Change Request Managment SRM Process Change Control Board Requerimientos y gestión de riesgos Ciclos de vida y riesgo. 2 2

3 Software Requirements Qué es? Una condición o capacidad necesaria para un usuario para resolver un problema o alcanzar un objetivo. Una condición o capacidad que se debe alcanzar o debe poseer un sistema o componente para satisfacer un contrato, estándar, especificación u otra formalidad impuesta. Una representación documentada de alguna condición o capacidad descrita en los dos puntos anteriores. 3 3

4 Proceso Esencial de Software Real World System Tiempo de exposición 2 Proceso esencial de software concebido bajo Tech Orientacion a objetos y la creacion de aplicaciones monoliticas. Ausencia de requerimientos de integracion up-front Transicion: Esto nos lleva a una integracion Add-hoc 4

5 Software Requirements - Areas de Conocimiento Requirement Engineering Requirement Development Requirement Management Elicitation Analysis Specification Validation 5 5

6 Requirements Statement Characteristics Complete Correct Feasible Necessary Prioritized Unambiguous Verfiable 6 6

7 Requirements Specification Characteristics Complete Consistent Modifiable Traceable 7 7

8 Software Requirements - Areas de Conocimiento Requirement Engineering Requirement Development Elicitation Requirement Management Project Agreement Analysis Specification Validation 8 8

9 Agenda Software Requirements Knowledge Areas. Requirement Statement. Requirement Specification. Agreement and Expectation Mgmt.. Las 5 dimensiones. Change Request Managment SRM Process Change Control Board Requerimientos y gestión de riesgos Ciclos de vida y riesgo. 9 9

10 Acuerdo: por qué? para qué? Cuándo? Para cumplir nuestros objetivos. Para encontrar mejores objetivos. A lo largo del proyecto, negociando Distintas cosas. En distintos niveles. En distintos procesos. De distinta manera. Con objetivos distintos

11 La negociación es distinta en distintos procesos 11 11

12 Para lo que nos interesa aquí nos centramos... En la Iniciación La iniciación es el proceso de autorizar formalmente un nuevo proyecto o la de permitir que un proyecto ya existente continúe en su fase siguiente. Esta iniciación formal vincula el proyecto con el trabajo continuo de la organización ejecutante. Qué forma parte de la Gestión del Alcance del Proyecto? La gestión del alcance del proyecto incluye los procesos para asegurar que el proyecto incluya todo el trabajo requerido, y solamente el trabajo requerido, de manera tal de completar exitosamente el mismo

13 Negociar: Que cosas? Las 5 dimensiones Funcionalidades Recursos Humanos Calidad Tiempo Costo 13 13

14 Relación entre las dimensiones No son independientes entre sí No se relacionan linealmente Cada proyecto es crítico en algunas dimensiones y es mas libre en otras Cumplir con los objetivos requiere balancear las dimensiones 14 14

15 No todos las dimensiones son iguales Hay aspectos que nos limitan fuertemente y que no podemos controlar: restricción (constraint) Hay aspectos en los que tenemos objetivos que alcanzar: Conductor (driver) Hay aspectos que no son ni uno ni otro: Grado de libertad Esto define las prioridades relativas en el balance entre las dimensiones 15 15

16 Diagrama de Kiviat Al centro (restringido) <-> Afuera (libre) Recursos Humanos Funcionalidades Calidad Tiempo Costo 16 16

17 Houston, we have a problem Recursos Humanos Funcionalidades Calidad Tiempo Costo 17 17

18 Ser millonario y hippie Recursos Humanos Funcionalidades Calidad Tiempo Costo 18 18

19 Sistema de información interno Recursos Humanos Funcionalidades Calidad Tiempo Costo 19 19

20 Aplicación comercial competitiva Recursos Humanos Funcionalidades Calidad Tiempo Costo 20 20

21 Sistemas Quality Driven Recursos Humanos Funcionalidades Calidad Tiempo Costo 21 21

22 Lo importante Merece especial atención la negociación sobre el alcance del proyecto: es de las primeras cosas que se negocia... Y está en tensión todo el proyecto. Cuando cambia la realidad (e.g. Requerimientos, RR HH...) sirve para ver como hay que cambiar el proyecto. Las dimensiones sirven para pensar, negociar objetivos y tomar decisiones realistas. Para cada restricción: cuál es su valor límite? Para cada conductor: cuál es el objetivo? Para cada grado de libertad: cuáles son sus límites? El dibujo es sólo una ayuda gráfica

23 Agenda Software Requirements Knowledge Areas. Requirement Statement. Requirement Specification. Agreement and Expectation Mgmt.. Las 5 dimensiones. Change Request Managment SRM Process Change Control Board Requerimientos y gestión de riesgos Ciclos de vida y riesgo

24 Change Request Management Change Request Management es el almacenamiento, seguimiento y emisión de reportes de requerimientos provenientes de cualquier stakeholder para cambiar un sistema de software. 24 Change Request Management Change Request Management es el almacenamiento, seguimiento y emisión de reportes de requerimientos provenientes de cualquier stakeholder para cambiar un sistema de software. Esto incluye el proceso de toma de decisión en cuanto a que cambios realizar y el proceso de resolución utilizado para hacer esto posible. Sin almacenamiento, los requerimientos de cambio podrían ser perdidos o permanecer desconocidos por parte del team. Sin seguimiento, los cambios se saldrán de schedule o permanecerán indireccionados. 24

25 Qu Qué es Change Request? Change Request es un término general utilizado para identificar cualquier requerimiento proveniente de un stakeholder para cambiar un artifact o proceso. La documentación requerida para acompañar un requerimiento de cambio, es el origen y el impacto del problema, la solución propuesta y una evaluación de su costo. 25 Change Request Management Change Request es un término general utilizado para identificar cualquier requerimiento proveniente de un stakeholder para cambiar un artifact o proceso. La documentación requerida para acompañar un requerimiento de cambio es el origen y el impacto del problema, la solución propuesta y una evaluación de su costo. 25

26 Change Request Los requerimientos de cambio son divididos en dos categorías: enhancements y defects. Los Enhancement Requests especifican funciones nuevas o cambios en el diseño del comportamiento del sistema. Los Defects en cambio, son anomalías en el producto entregado, un error en el software generará un tema a ser seguido hasta ser resuelto. 26 Change Request Management Change Request Los requerimientos de cambio son divididos en dos categorías: mejoras y errores (enhancements and defects). Los Enhancement Requests especifican funciones nuevas o cambios en el diseño del comportamiento del sistema. Los errores (Defect) en cambio, son anomalías en el producto entregado, un error en el software generará un tema a ser seguido hasta ser resuelto. Indicar que la información recolectada es esencialmente distinta para cada uno de los casos. 26

27 CRM - Proceso El proceso de monitoreo de los change requests está representado en la mayoría de las herramientas de CRM como un workflow 27 Change Request Management Proceso El proceso está representado a través de un workflow que refleja el estado del Change Request en todos sus puntos de tratamiento. 27

28 CRM - Proceso Change Request submission Submitted Complete evaluation completion Evaluated Verified decision verification Revised In Process Send to development 28 Change Request Management Proceso Además de esto, las actividades podrían finalizar en la clausura del CR sin completarlo. Este esquema presentado es el ideal donde el CR es recibido, aceptado, categorizado, implementado, verificado y cerrado sin tener en cuenta el tratamiento de excepciones. 28

29 CRM - Proceso Registro del CR Change Request submission Submitted Complete evaluation completion Evaluated Verified decision verification Revised In Process Send to development 29 Change Request Management Proceso Registrado (Submitted) En esta etapa los cambios requeridos son registrados. Defect y Enhancements Requests difieren en el tipo de información que debe ser registrada. Para el caso de enhancements se necesita conocer la importancia del requerimiento para el cliente, con todo el detalle posible acerca del cambio, las restricciones de tiempo impuestas desde fuera de la compañía e identificar al solicitante inicial. En caso de defects, es de suma importancia identificar el modo en el cual han sido descubiertos los errores, como puede reproducirse el error, la severidad del mismo y quien lo ha descubierto. Existe el concepto de shortcut para los casos donde el cambio sea de emergencia. En estos casos el proceso presentado en estos slides alcanza directamente la fase de In Process proviniendo del Configuration Control Board. En resumen, defects y enhancement requests comparten los mismos datos claves, tendiendo en el caso de los defects la información asociada de severidad, usuario referente que identificó el error, y la versión de software que estaba siendo ejecutada. 29

30 CRM - Proceso Evaluación, categorización y establecimiento de prioridad Change Request submission Submitted Complete evaluation completion Evaluated Verified decision verification Revised In Process Send to development 30 Change Request Management Proceso Evaluado (Evaluated): Durante la evaluación alguien deberá revisar los nuevos cambios requeridos y determinar la severidad, duplicidad, determinar si efectivamente se trata de una mejora o un error y si el error puede efectivamente ser reproducido. Todo error debe ser reproducido y confirmado en esta etapa. La prioridad también será establecida en esta etapa basándose en la severidad del caso y en la importancia de que sea resuelta. Las mejoras requeridas no necesitan ser confirmadas, en este caso se establece simplemente la prioridad en relación con los demás requerimientos de mejora existentes. 30

31 CRM - Proceso Qué y cuando implementar Change Request submission Submitted Complete evaluation completion Evaluated Verified decision verification Revised In Process Send to development 31 Change Request Management Proceso Revisado (Revised): Aquí se decide cuando un cambio es implementado, si debe ser pospuesto o directamente rechazado. Los enhancement requests y defects son tratados en forma diferente. La implementación de los requerimientos de mejora es decidida por el gerente de producto o el analista. Todos estos requerimientos son medidos en forma conjunta para determinar en que release serán liberados, cuando deberían ser realizados basados en la información obtenida durante la etapa de evaluación. El tratamiento de los errores depende de la etapa del ciclo de vida en la cual han sido detectados y el tamaño del esfuerzo de desarrollo para corregirlos. En etapas iniciales del ciclo de vida los errores son resueltos de manera informal. En cambio, a medida que nos acercamos al final del ciclo de vida, queremos restringir los cambios solo a los casos en que sea estrictamente necesario hacerlos. Cambios sin control sobre el final del ciclo de desarrollo afectan el orden y seguimiento del proyecto, introducen nuevos riesgos y generalmente causan encarecimiento del costo y desviación de la agenda del proyecto. 31

32 Decision - Configuration Control Board el comité que monitorea el proceso de cambio consiste en representantes de todas las partes interesadas, incluyendo clientes, desarrolladores, y usuarios. En proyectos pequeños una sola persona, como por ejemplo el gerente de proyecto o el arquitecto de software, podría jugar dicho role. 32 Change Request Management Proceso Revisado (Revised): Configuration Control Board Organizaciones de mayor envergadura cuentan usualmente con procesos de revisión formal sobre los requerimientos de cambio realizados por una estructura de control llamada Change/Configuration Control Board. CCB está estructurada regularmente en forma matricial (abarca roles funcionales y de IS) y balancea en los casos que existe litigio entre el área de calidad y agenda del proyecto durante el desarrollo. Se puede definir como el equipo que monitorea el proceso de cambio consiste en representantes de todas las partes interesadas, incluyendo clientes, desarolladores, y usuarios. En proyectos pequeños una sola persona, como por ejemplo el gerente de proyecto o el arquitecto de software, podría jugar dicho role. the board that oversees the change process consisting of representatives from all interested parties, including customers, developers, and users. In a small project a single person, such as the project manager or software arquitect, may play this role [White 2000, page 260] CCB difiere enormemente de acuerdo al tipo de proyecto, la compañía y el tamaño y costo del programa. Sin embargo, en todos los casos donde encontremos CCB que no sean unipersonales deberemos contar con una estructura CCB. 32

33 Configuration Control Board - Estructura CCB del Proyecto CCB Funcional CCB Basis CCB Módulo FI CCB Módulo MM CCB Módulo WM CCB Hardware CCB Tech Support CCB App. Servers 33 Change Request Management Proceso Revisado (Revised): Configuration Control Board CCB Structure Estas estructuras normalmente conforman una especie de modelo de cascada donde contamos con un número bastante grande de CBs en los niveles inferiores que van siendo consolidados por niveles superiores en forma de pirámide hasta alcanzar un único CB. Los cambios generalmente son generados en los niveles inferiores donde la actividad de programación los genera. En otros casos, el camino inverso es tomado cuando un requerimiento de un cliente o un gerente de proyecto. Debería existir una ruta alternativa preparada para administrar cambios de emergencia de modo que la integridad de todo el proceso no se vea afectada por este tipo de situaciones. Dentro de la estructura jerárquica del CCB, la decisión final recae sobre una única persona. El nivel superior decide cuando un parche de emergencia debe ser implementado o una CR autorizado, en muchos casos donde los cambios son mínimos, esta decisión es delegada a los niveles inferiores de la estructura. 33

34 CRM - Proceso Change Request submission Submitted Complete evaluation completion Evaluated Verified decision verification Revised In Process Send to development System Artifact son modificados o creados. La documentación es actualizada. 34 Change Request Management Proceso En Proceso (In Process): Durante esta etapa los artifacts son modificados o creados en busca de satisfacer el requerimiento de cambio. En esta etapa las diferencias entre enhancement request y defect son mas significativas dado que el primer caso contempla una nueva funcionalidad que puede implicar un nuevo diseño. Defects en cambio, requieren que sea reproducido el entorno en el cual el error se presentó para poder reproducir el mismo y probar la solución implementada. 34

35 CRM - Proceso Change Request submission Submitted Complete evaluation completion Evaluated Verified decision verification Revised In Process Send to development El CR es usado para verificar que la nueva versión cumple con el CR. 35 Change Request Management Proceso Verificado (Verified): En esta etapa se verifica que la solución cumple con el CR. Para el caso de mejoras en el producto es simplemente verificar que el comportamiento del producto es el especificado por el CR con lo cual es suficiente con la ejecución del plan de test funcional. Para la verificación se trabaja exclusivamente sobre el nuevo release. En caso de errores, se debe poder reproducir el error en la versión anterior a los efectos de garantizar que el mismo a sido corregido. 35

36 CRM - Proceso Change Request submission Submitted Complete evaluation completion Evaluated Verified decision verification Revised In Process Send to development El solicitante es notificado y la información acerca de costos es almacenada. 36 Change Request Management Proceso Cerrado (Complete): El principal paso aquí es cerrar el tema abierto con el stakeholder que inicio el requerimiento de cambio. Dependiendo el nivel de madurez de la organización es en esta etapa que se dispara un nuevo proceso interno donde se intenta identificar los motivos del error y los nuevos errores que estos motivos puedan estar causando (defect prevention). La estadística de costo real y esfuerzo en encontrar la solución debe ser registrada para alimentar la experiencia del equipo del proyecto. 36

37 Agenda Software Requirements Knowledge Areas. Requirement Statement. Requirement Specification. Agreement and Expectation Mgmt.. Las 5 dimensiones. Change Request Managment SRM Process Change Control Board Requerimientos y gestión de riesgos Ciclos de vida y riesgo

38 Ciclo de Vida Es el conjunto y la disposición de las actividades que suceden desde la concepción del sistema hasta que el mismo es desinstalado de la última maquina del usuario. Tiene como función establecer el criterio bajo el cual proceder de un tipo de tareas a otro. 38 Ciclo de Vida Dependiendo del ciclo de vida que uno elija, es posible mejorar la velocidad del desarrollo, mejorar la calidad, facilitar el seguimiento, reducir la exposición a riesgos o mejorar el contacto con el cliente. La elección errónea puede producir reducción en la productividad, retrabajo y frustración. 38

39 Code and Fix Especificación del sistema (Tal vez exista) Release (Tal vez) 39 Ciclo de Vida Code and Fix Este ciclo de vida es raramente útil pero sin embargo altamente utilizado. Si no se ha explícitamente elejido un ciclo de vida probablemente sea éste el que esté siendo usado. El ciclo comienza con una idea general sobre lo que debe ser construido. Es posible que exista una especificación, sin ser la misma necesaria para comenzar a construir. Luego se comienza a usar cualquier combinación de metodologías de diseño informal, codificación y testing hasta que el producto está listo para ser liberado. 39

40 Especific ación del sistema (Tal vez exista) Code and Fix Release (Tal vez) Puede llegar a ser útil para pequeños proyectos donde se sabe de antemano que el producto será rápidamente descartado. Dos ventajas: No posee overhead. No requiere ningún tipo de conocimiento. Muchas desventajas, entre otras: No tenemos forma de asegurar que existe progreso alguno. No tenemos forma de controlar la calidad ni de identificar riesgos. Es muy probable que se alcancen puntos en el proyecto donde sea necesario descartar absolutamente todo lo realizado. 40 Ciclo de Vida Code and Fix El modelo tiene dos ventajas. Primero, no posee overhead: uno salta directamente a codificar, uno cree que posee inmediatamente signos de progreso. Segundo, no requiere ningún tipo de conocimiento excepto saber programar: cualquiera puede usarlo. Para pequeños proyectos que uno sabe que serán descartados rápidamente luego de ser usados, este modelo puede llegar a ser útil (programas de conversión de datos para una migración, pruebas de concepto en general, etc.). Para cualquier otro projecto este modelo es peligroso. Puede ser que no tenga overhead pero tampoco tenemos forma de asegurar que existe progreso alguno. Uno codifica hasta que el producto se considera listo ( listo no tiene métrica asociada tampoco). No tenemos forma de controlar la calidad ni de identificar riesgos. Es muy probable aquí que se alcancen puntos en el proyecto donde sea necesario descartar absolutamente todo lo realizado justamente por no estar el objetivo bien definido y comprendido. 40

41 Pure Waterfall Concepto Análisis de Requerimientos Diseño Arquitectónico Diseño Detallado Codificación y Debugging Prueba de Sistema 41 Ciclo de Vida Pure Waterfall Bajo este ciclo de vida el proyecto progresa a través de una secuencia ordenada de pasos desde la concepción inicial del Software. El proyecto contempla una revisión al final de cada paso para determinar si se pasará al siguiente. Esto hace que sea posible permanecer por un tiempo indeterminado sobre uno de los pasos si dicha revisión no es alcanzada. El modelo waterfall es orientado a la documentación lo que significa que la gran mayoría de los productos de software que son intercambiados entre etapas son documentación. Las etapas no se solapan en este modelo. 41

42 Pure Waterfall Salmon s Model 42 Ciclo de Vida Pure Waterfall Salmon s Model Es posible retroceder en las fases pero esto puede costarnos el proyecto 42

43 Concepto Pure Waterfall Análisis de Requerimientos Diseño Arquitectónico Diseño Detallado Codificación y Debugging Prueba de Sistema Muy útil cuando los requerimientos de calidad dominan el costo y el cronograma. Debo conocer muy bien los requerimientos y los mètodos a ser usados. Ventajas Produce Sistemas Confiables y de alta calidad. Minimiza el overhead de planning. Desventajas Dificultad de obtener requerimientos completamente especificados al inicio del proyecto. La visualización de resultados se presenta al finalizar el proyecto. No es flexible. No apropiado para desarrollos rápidos por cantidad de documentación. 43 Ciclo de Vida Pure Waterfall En proyectos donde hay alta estabilidad funciona bien. La estabilidad se relaciona con un gran conocimiento de los requerimientos y de los métodos que serán usados. En estos casos no sólo es un modelo eficiente sino que es el correcto a usar puesto que tenemos la oportunidad de encontrar errores de alto impacto en etapas tempranas y de bajo costo. El modelo contribuye a minimizar el overhead en la planificación porque es posible hacer la actividad de planificación al inicio. Por otra parte, no tenemos resultados tangibles hasta el fin del proyecto. El avance debe ser entonces medido a partir de la documentación generada durante las etapas. Funciona bien cuando los requerimientos de calidad dominan el costo y el cronograma. Las desventajas del modelo radican en la dificultad de conocer los requerimientos al 100% antes de comenzar a diseñar. 43

44 Sashimi (Waterfall + Overlapping) Concepto Análisis de Requerimientos Diseño Arquitectónico Diseño Detallado Codificación y Debugging Prueba de Sistema 44 Ciclo de Vida Sashimi En el modelo puro Waterfall, la documentación ideal es la que es pasada de mano en mano entre los equipos de trabajo que operan en las diferentes fases. La pregunta es Por qué?. Si el equipo de trabajo es el mismo que opera en cada una de las fases, entonces no es necesaria la documentación creada para transmitir el conocimiento entre fases. Este cambio reduce la documentación a la necesaria para el posterior mantenimiento del Software. 44

45 Sashimi (Waterfall + Overlapping) Concepto Análisis de Requerimientos Diseño Arquitectónico Diseño Detallado Codificación y Debugging Prueba de Sistema Aplicable en condiciones similares al pure waterfall pero con equipos más pequeños. Asumimos que el mismo equipo realiza actividades en más de una fase. Ventajas Reduce la documentación necesaria en el purewaterfall. Mismas ventajas que el purewaterfall. Desventajas Mismas dificultades que el pure waterfall. Adicionalmente el solapamiento puede ocasionar conflictos relacionados con la comunicación entre fases solapadas. 45 Ciclo de Vida Sashimi Como existe solpamiento entre fases, los milestones son más ambiguos y esto hace más difícil realizar el seguimiento con cierto nivel de seguridad. Efectuar actividades en paralelo requiere que las actividades solapadas estén bien comunicadas, estamos expuestos a que cambios o novedades en actividades viejas no sean comunicadas a las actividades nuevas y por ende exista inconsistencia a lo largo del ciclo. 45

46 Waterfall with Subprojects Concepto Análisis de Requerimientos Diseño Arquitectónico Diseño Detallado Codificación y Debugging Prueba de SubSistema Diseño Detallado Codificación y Debugging Diseño Detallado Prueba de SubSistema Codificación y Debugging Prueba de SubSistema Integración Prueba de Sistema 46 Ciclo de Vida Waterfall with Subprojects Otro problema con el modelo waterfall puro es que se supone que debemos completar el 100% del diseño arquitectónico antes de comenzar con el diseño detallado, y que a su vez debemos completar el 100% del diseño detallado antes de comenzar a codificar.. Los sistemas tienen ciertas áreas donde existen sorpresas de diseño, pero también existen áreas donde la tarea es simple e incluso en algunos casos conocida. Por qué entonces retrasar el comienzo de los subsistemas simples a causa de la complejidad de parte de la arquitectura?. Si es posible partir la arquitectura en subsistemas lógicamente independientes se pueden obtener subproyectos que sean tratados independientemente y en paralelo hasta llegar al momento de integrarlos. 46

47 Concepto Waterfall with Subprojects Análisis de Requerimientos Diseño Arquitectónico Diseño Detallado Codificación y Debugging Diseño Detallado Diseño Detallado Codificación y Debugging Codificación y Debugging Prueba de SubSistema Prueba de SubSistema Integración Aplicable en condiciones similares al pure waterfall pero donde es posible identificar subsistemas independientes. El equipo de trabajo es suficientemente grande como para paralelizar el trabajo. Ventajas Prueba de SubSistema Prueba de Sistema Permite construir los subsistemas en paralelo. Mismas ventajas que el purewaterfall. Desventajas Posibles problemas de integración por interdependencias no identificadas. 47 Ciclo de Vida Waterfall with Subprojects El mayor riesgo de esto es que existan interdependencias no previstas que generen problemas de integración. Este riesgo es posible mitigarlo con una actividad de arquitectura más intenso que en el caso del pure waterfall, pero nunca podremos eliminarlo por completo. 47

48 Waterfall with Risk Reduction Concepto Análisis de Requerimientos Prototipación Diseño Arquitectónico Diseño Detallado Codificación y Debugging Prueba de Sistema 48 Ciclo de Vida Waterfall with Risk Reduction Otro de los problemas del waterfall puro es que es necesario tener una precisa definición de los requerimientos antes de comenzar con el diseño arquitectónico. Esta necesidad no solo se encuentra en los requerimientos sino que es necesario para ingresar en un fase contar con gran estabilidad en la anterior y con el total de los productos requeridos para ingresar en la nueva fase. Una posible modificación leve al pure waterfall es la propuesta por Risk Reduction, donde se incorpora una actividad de prototipado de interfaz o de aquellos componentes de mayor riesgo por la incertidumbre natural al desarrollo de Software. Esta actividad no necesariamente debe centrarse en los requerimientos sino que es posible extenderla al diseño e incluso a la codificación. 48

49 Concepto Waterfall with Risk Reduction Análisis de Requerimientos Diseño Arquitectónico Prototipación Diseño Detallado Lo aplico en los casos donde es posible identificar aquellas áreas donde hace falta mayor conocimiento. (*) Esto no siempre es posible. Codificación y Debugging Ventajas Prueba de Sistema Reduce el riesgo con respecto al pure waterfall proveniente de los requerimientos incompletos o mal definidos. Mismas ventajas que el purewaterfall. Desventajas Debo poder identificar las áreas donde sea necesaria mayor definición. 49 Ciclo de Vida Waterfall with Risk Reduction La actividad de prototipado es generalmente beneficiosa aunque existe la posibilidad de no poder recolectar mayor información incurriendo en gastos que no tienen rédito en el proyecto. Dado que luego de la actividad de prototipado el ciclo es idéntico al pure waterfall estamos frente a las mismas dificultades que en dicho modelo. 49

50 Spiral Objetivos Riesgos Planificación Desarrollo Profundidad: 1ero: análisis, 2do: diseño, 3ero construcción, 4to implementación 50 Ciclo de Vida Spiral El ciclo de vida spiral es un modelo orientado a riesgos, donde el proyecto es dividido en mini-proyectos. Cada uno de los mini-proyectos atiende a uno a más riesgos importantes hasta que finalmente todos los riesgos con alta exposición han sido atendidos. El concepto de riesgo es el visto en clase, se refiere a requerimientos pobremente entendidos, a arquitectura pobremente definida o comprendida, problemas potenciales de performance, problemas en la tecnología subyacente, y demás temas del proyecto donde sea requerido mayor conocimiento. Una vez que los riesgos han sido atendidos el ciclo de vida finaliza como el pure waterefall. La idea detrás del modelo es que uno comienza con un alcance reducido en el centro de la espiral, explora los riesgos ç, construye el plan para atender los riesgos encontrados, y luego planea el siguiente ciclo. Cada iteración mueve el proyecto hacia un alcance más extenso. 50

51 Spiral Determinar objetivos, alternativas y restricciones Compromiso para la siguiente iteración Revisión Planificar la siguiente iteración Plan de Prueba Inicio Plan de Req., Plan de Ciclo de Vida Plan de Desarrollo Plan de Integración Identificar y resolver riesgos Análisis de Riesgos Validación de Requer. Prototipo 1,.. 3 Simulaciones Diseño de V & V Requer. de Soft. Integr. y Prueba Prueba Acept. Release Modelos Prototipo Operacional Benchmarks Diseño Detallado Code Prueba Unidad Diseño de Producto Evaluar alternativas Construir el entregable de la iteración y verificar que es correcto. 51 Ciclo de Vida Spiral Cada iteración comprende 6 pasos representados en los cuadros que rodean la espiral del slide. 1. Determinar objetivos, alternativas y restricciones. 2. Identificar y resolver riesgos. 3. Evaluar alternativas. 4. Desarrollar los entregables de la iteración y verificar que son correctos. 5. Planificar la siguiente iteración. 6. Si se decide continuar, obtener compromiso para la siguiente iteraciòn. 51

52 Spiral Objetivos Planificación Riesgos Desarrollo Modelo orientado a manejo de riesgos. A medida que avanza el tiempo y dinero invertidos, la exposición al riesgo disminuye. Ventajas Equilibrio óptimo entre exposición al riesgo e inversión. Mayor o equivalente control que en el modelo pure waterfall. Desventajas Requiere gran conocimiento de gestión por parte de quien dirige el proyecto. Es posible que si en un momento del proyecto la exposición al riesgo es baja, el modelo se vuelva innecesariamente caro. 52 Ciclo de Vida Spiral En el modelo espiral las etapas tempranas son las más económicas. Uno gasta menos desarrollando el concepto de operación del Software de los que gasta en la ingeniería de requerimientos, y menos en los requerimientos de lo que gasta en el diseño, desarrollando el producto y probándolo. Una de las ventajas más importantes del modelo es que el costo aumenta a medida que el riesgo decrece. A mayor tiempo y dinero invertido, menor la exposición al riesgo. Esto es justamente uno de los atributos más buscados en un proyecto de Software. El modelo espiral provee igual o mayor control en la gestión del proyecto de la provista por el modelo tradicional pure waterfall. Uno cuenta con puntos de control al finalizar cada iteración. Si el proyecto es inviable debido a razones técnicas o funcionales, es descubierto ésto en forma temprana. La única desventaja del modelo radica en su complejidad. Requiere de quién gestiona el proyecto conciencia, atención y conocimiento en gestión. Puede llegar a ser difícil definir milestones objetivos y verificables, que indiquen cuando uno está en condiciones de agregar una nueva iteración. En algunos casos el producto alcanzado es suficiente, y los riesgos a los que estamos expuesto moderados lo suficiente como para que no sea requerido continuar pensando en riesgos, con lo que el modelo orientado a riesgos propuesto por el ciclo de vida espiral se vuelve redundante. 52

Preparación de Plan de Proyecto

Preparación de Plan de Proyecto Preparación de Plan de Proyecto Preparación de Plan de Proyecto 1 Contenido Etapas en la Preparación Plan de Proyecto Estructura del Equipo de Proyecto Pasos en la Preparación del Work-Plan Seguimiento

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

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

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

Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 2: EL CICLO DE VIDA DEL SOFTWARE

Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 2: EL CICLO DE VIDA DEL SOFTWARE Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 2: EL CICLO DE VIDA DEL SOFTWARE 1 DEFINICIÓN DE CICLO DE VIDA DEL SOFTWARE ISO/IEC 12207-1 Marco de referencia que contiene

Más detalles

CICLO DE VIDA DEL SOFTWARE

CICLO DE VIDA DEL SOFTWARE CICLO DE VIDA DEL SOFTWARE 1. Concepto de Ciclo de Vida 2. Procesos del Ciclo de Vida del Software 3. Modelo en cascada 4. Modelo incremental 5. Modelo en espiral 6. Prototipado 7. La reutilización en

Más detalles

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto

Más detalles

CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS. USB Ing. De Software. Prof. I. C. Martínez

CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS. USB Ing. De Software. Prof. I. C. Martínez CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS USB Ing. De Software. Prof. I. C. Martínez Ing. De Software Ingeniería de Software La Ingeniería de Software es la ciencia

Más detalles

Implantación y Aceptación del Sistema

Implantación y Aceptación del Sistema y Aceptación del Sistema 1 y Aceptación del Sistema ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN...5 Tarea IAS 1.1: De finición del Plan de... 5 Tarea IAS

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

El modelo de ciclo de vida cascada, captura algunos principios básicos:

El modelo de ciclo de vida cascada, captura algunos principios básicos: Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software. El primer ciclo de vida del software, "Cascada",

Más detalles

Gerencia de Proyectos, un enfoque. Marco de referencia

Gerencia de Proyectos, un enfoque. Marco de referencia Gerencia de Proyectos, un enfoque Directivo Marco de referencia Confidencialidad Este documento está dirigido a las personas que participan en este seminarioynopuedeserreproducidoocopiadodemaneraalguna,entodoo

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

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

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

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

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 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

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

Plan de estudios ISTQB: Nivel Fundamentos

Plan de estudios ISTQB: Nivel Fundamentos Plan de estudios ISTQB: Nivel Fundamentos Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE

Más detalles

Herramientas automáticas y semiautomáticas que apoyan a la aplicación de los métodos.

Herramientas automáticas y semiautomáticas que apoyan a la aplicación de los métodos. Unidad I Introducción a la ingeniería del software y sistemas de información Las economías de todos las paises son cada vez más y más dependientes del Software Importancia del Software 10 Cada vez más

Más detalles

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Tabla de Contenidos PARTE I INTRODUCCIÓN Capítulo 1: Evolución Los hitos en la evolución histórica del Desarrollo de Software Problemas y soluciones... Fallas, malas estimaciones

Más detalles

Ingeniería de Software II

Ingeniería de Software II Ingeniería de Software II Gestión de Configuración de Software: Requisitos para la resolución de la práctica El alumno debe haber asistido a la clase de Gestión de Configuración y de Gestión de Requerimientos.

Más detalles

Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo

Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo Todas las slides siguientes están tomadas de la guía de los fundamentos para

Más detalles

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Introducción Este documento recopila las preguntas, opiniones y respuestas que se produjeron en un pequeño curso sobre las

Más detalles

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred. cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema

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

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: CICLO DE VIDA VISIÓN TRADICIONAL DEL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN STEMAS DE INFORMACIÓN Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza M. Material revisado

Más detalles

1.1 Aseguramiento de la calidad del software

1.1 Aseguramiento de la calidad del software 1.1 Aseguramiento de la calidad del software El propósito del Aseguramiento de la Calidad (Software Quality Assurance, SQA) es entregar a la administración una visibilidad adecuada del proceso utilizado

Más detalles

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Rational Unified Process Basado en 6 mejores prácticas de la industria de software: Desarrollo incremental Administración de requisitos Uso de arquitecturas basadas en componentes

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

CICLO DE VIDA DEL SOFTWARE. Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software

CICLO DE VIDA DEL SOFTWARE. Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software 3.010 CONCEPTO DE CICLO DE VIDA Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software IEEE 1074 Un marco de referencia que contiene los

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

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

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

Más detalles

Ingeniería de Software Dr. Marcello Visconti Z. Ingeniería de Software

Ingeniería de Software Dr. Marcello Visconti Z. Ingeniería de Software Universidad Técnica Federico Santa María Departamento de Informática Ingeniería de Software Dr. Marcello Visconti Z. Programa Proceso de Software y Paradigmas de Desarrollo Gestión de Proyectos Fases del

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

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación Liberando el sistema Ayudar a los usuarios a entender y usar el sistema Distintos tipos de usuarios Entrenamiento Documentación Solución de Problemas Conversión Instalación May-12 Ing. de Software Liberación

Más detalles

Ciclo de vida del software

Ciclo de vida del software Ciclo de vida del software Definición El proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una idea hasta la entrega y el retiro del sistema. Confiable,

Más detalles

RUP: Disciplina de Manejo de Cambios y Configuraciones

RUP: Disciplina de Manejo de Cambios y Configuraciones RUP: Disciplina de Preparado por: Amelia Soriano Mayo 2005 Tomado de: Rational Unified Process Version 2003.06.12.01 Copyright 1987 2003 Rational Software Corporation Curso Rational Unified Process Rational

Más detalles

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Cenditel, Mayo 2011 Licencia de Uso Copyright (c) 2010, Alvarez J., Solé S., Briceño R., Fundación CENDITEL. La Fundación CENDITEL

Más detalles

Metodologías de Desarrollo de Sistemas de Información

Metodologías de Desarrollo de Sistemas de Información Metodologías de Desarrollo de Sistemas de Información Metodología para el Desarrollo de SI Las metodologías son sistemas completos de técnicas que incluyen procedimientos paso a paso, productos resultante,

Más detalles

IT Project Management Desarrollo de Software

IT Project Management Desarrollo de Software IT Project Management Desarrollo de Software Es posible una mezcla de Waterfall y Agile? Cómo se acerca el PMBOK a Agile? Autor: Norberto Figuerola Resulta muy frecuente que se suela confundir una aproximación

Más detalles

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.

Más detalles

GeneXus BPM Suite X. Última actualización: 01 de Setiembre de 2008

GeneXus BPM Suite X. Última actualización: 01 de Setiembre de 2008 Última actualización: 01 de Setiembre de 2008 Copyright Artech Consultores S. R. L. 1988-2008. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento

Más detalles

Ingeniería de Software: Parte 2

Ingeniería de Software: Parte 2 Ingeniería de Software: Parte 2 Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes.

Más detalles

Modelos de Proceso Tradicionales

Modelos de Proceso Tradicionales Modelos de Proceso Tradicionales Capitulo 2,QJHQLHUtDGHO6RIWZDUH (VSHFLDOL]DFLyQHQ*HUHQFLDGH6LVWHPDVGH,QIRUPDFLyQ 8QLYHUVLGDG6DQWLDJRGH&DOL Profesor: MSc. MIGUEL ANGEL NIÑO ZAMBRANO Programación: Tiempo

Más detalles

Escuela Politécnica Superior. Proyectos de Desarrollo Software. Capítulo 5. daniel.tapias@uam.es. Dr. Daniel Tapias Curso 2014/ 15 PROYECTOS

Escuela Politécnica Superior. Proyectos de Desarrollo Software. Capítulo 5. daniel.tapias@uam.es. Dr. Daniel Tapias Curso 2014/ 15 PROYECTOS Escuela Politécnica Superior Proyectos de Desarrollo Software Capítulo 5 Dr. Daniel Tapias Curso 2014/ 15 daniel.tapias@uam.es PROYECTOS PROGRAMA DE LA ASIGNATURA Capítulo 1: Introducción. Capítulo 2:

Más detalles

Ingeniería de Software. Procesos. Proyecto de Ingeniería. Metodologías. Metodologías. Metodologías. Metodologías de desarrollo

Ingeniería de Software. Procesos. Proyecto de Ingeniería. Metodologías. Metodologías. Metodologías. Metodologías de desarrollo Ingeniería de Software Procesos Laboratorio de Ingeniería de Software 2004 La ingeniería de software trata sobre la aplicación de practicas y métodos para construir productos de software que cumplan las

Más detalles

Universidad ORT Uruguay

Universidad ORT Uruguay Facultad de Ingeniería Metodología SCRUM Cátedra de Ingeniería de Software. Docente Responsable: Gastón Mousqués. Autor: Adriana Peralta 123357 2003 ÍNDICE GENERAL Introducción 2 Principales características

Más detalles

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007 Enunciado Se desea efectuar el testing funcional de un programa que ejecuta transferencias entre cuentas bancarias. El programa recibe como parámetros la cuenta de origen, la de cuenta de destino y el

Más detalles

Descripción de las posiciones del área de sistemas

Descripción de las posiciones del área de sistemas Descripción de posiciones del área de Sistemas Operador/Data Entry Entrar y verificar datos provenientes de distintas vías de ingreso. Monitorear procesos, programas y resultados. Seguir los formatos apropiados

Más detalles

5 La Gerencia de Proyectos

5 La Gerencia de Proyectos 5 La Gerencia de Proyectos La gran mayoría de las civilizaciones han tenido como factor común la ejecución de grandes hazañas dignas de recordarse, que han quedado plasmadas en los libros de historia y

Más detalles

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Jorge Bozo jbozo@inf.ucv.cl Escuela de Ingeniería Informática Universidad Católica de Valparaíso Valparaíso, Chile

Más detalles

75.46 - Administración y Control de Proyectos II. Sergio Martinez

75.46 - Administración y Control de Proyectos II. Sergio Martinez 75.46 - Administración y Control de Proyectos II Sergio Martinez 1er cuatrimestre 2006 Introducción Qué es un Servicio? Cliente Lavandería Transporte Lavadero Industrial Precio por el Servicio Mismo día:\300

Más detalles

PRU. Fundamento Institucional. Objetivos. Alcance

PRU. Fundamento Institucional. Objetivos. Alcance PRU INSTRUCCIONES: a continuación se describe el flujo de trabajo correspondiente al área de procesos de PRUEBAS para el desarrollo de software, en el cual se debe apoyar para la ejecución de sus actividades;

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

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

INFORMACIÓN RELACIONADA

INFORMACIÓN RELACIONADA INFORMACIÓN RELACIONADA Solucionar problemas para empresas de la industria del gas y el petróleo Soluciones de gestión de cartera de proyectos Primavera ORACLE ES LA COMPAÑÍA DE INFORMACIÓN Lograr objetivos

Más detalles

Arquitectura de Proyectos de IT

Arquitectura de Proyectos de IT Arquitectura de Proyectos de IT Apunte: Comunicación de Arquitectura de Software Autores: Ing. Gustavo A. Brey (gbrey@sistemas.frba.utn.edu.ar) Santiago Blanco (santiago.blanco@gmail.com) Versión: 0.8.20081106

Más detalles

BPM: Articulando Estrategia, Procesos y Tecnología

BPM: Articulando Estrategia, Procesos y Tecnología BPM: Articulando Estrategia, Procesos y Tecnología Resumen: La competitividad es el imaginario que dirige las acciones empresariales en la actualidad. Lograr condiciones que permitan competir con mayores

Más detalles

Aseguramiento de la calidad del software

Aseguramiento de la calidad del software Aseguramiento de la calidad del software Standard for Software Reviews and Audits [IEEE 1028] IEEE 1028 Para qué sirve Provee definiciones y requerimientos uniformes para los procesos de revisión y auditoría.

Más detalles

Administración de proyectos de desarrollo de software

Administración de proyectos de desarrollo de software DATOS GENERALES SI-00875 ADMINISTRACIÓN DE PROYECTOS DE INFORMÁTICA (3-0-8. Requisito: Haber aprobado Si00854. 6 ISC, 6 ISI, 7 LSCA) Requisito para planes de transición:haber aprobado Cb95855 o Si00854

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

Empresa Financiera Herramientas de SW Servicios

Empresa Financiera Herramientas de SW Servicios Empresa Financiera Herramientas de SW Servicios Resulta importante mencionar que ésta es una empresa cuya actividad principal está enfocada a satisfacer las necesidades financieras de los clientes, a través

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

Un modelo de proceso es una representación abstracta de un proceso. Presenta una descripción de un proceso desde una perspectiva particular.

Un modelo de proceso es una representación abstracta de un proceso. Presenta una descripción de un proceso desde una perspectiva particular. El proceso software Un conjunto estructurado de actividades y resultados asociados que conducen a la creación de un producto de software Especificación: Definir la funcionalidad y las restricciones en

Más detalles

Análisis y Diseño de Aplicaciones

Análisis y Diseño de Aplicaciones Análisis y Diseño de Aplicaciones Ciclo de Vida Docente: T/RT Gonzalo Martínez CETP EMT Informática 3er Año Introducción En el desarrollo de sistemas, el ciclo de vida son las etapas por las que pasa un

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

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

Introducción a Rational Unified Process (RUP)

Introducción a Rational Unified Process (RUP) Qué es un Proceso de Desarrollo de SW? Introducción a Patricio Letelier letelier@dsic.upv.es Departamento Sistemas Informáticos y Computación (DSIC) (UPV) - España Define Quién debe hacer Qué, Cuándo y

Más detalles

Desarrollo Ágil. Software Engineering: A Practitioner s Approach Roger S. Pressman, Ph.D. Tomás Balderas Contreras Ingeniería de Software I

Desarrollo Ágil. Software Engineering: A Practitioner s Approach Roger S. Pressman, Ph.D. Tomás Balderas Contreras Ingeniería de Software I Desarrollo Ágil Software Engineering: A Practitioner s Approach Roger S. Pressman, Ph.D. Tomás Balderas Contreras Ingeniería de Software I Coordinación de Ciencias Computacionales INAOE 2011 Preguntas

Más detalles

CMMi. Lic. Virginia Cuomo

CMMi. Lic. Virginia Cuomo CMMi Lic. Virginia Cuomo 1 Agenda Repaso CMMI Introducción Arquitectura Niveles de Madurez Representaciones Representación Discreta Representación Continua Discreta VS Continua 2 Repaso Qué vimos la tercer

Más detalles

CONCEJO MUNICIPAL DE CHOCONTA- CUNDINAMARCA

CONCEJO MUNICIPAL DE CHOCONTA- CUNDINAMARCA CONCEJO MUNICIPAL DE CHOCONTA- CUNDINAMARCA PLAN DE MANEJO DE RIESGOS Contenido PLAN DE MANEJO DE RIESGOS.... 3 Elaboración del mapa de riesgos... 3 Monitoreo... 4 Autoevaluación... 4 Metodología... 7

Más detalles

Construcción de sistemas de soporte a la toma de decisiones

Construcción de sistemas de soporte a la toma de decisiones INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE CÓMPUTO Construcción de sistemas de soporte a la toma de decisiones M. En C. Eduardo Bustos Farías 1 Desarrolla en Sistemas de Apoyo de Decisión Como

Más detalles

IMPLANTACIÓN DE UNA ESTRATEGIA DE GESTIÓN POR PROCESOS (BPM). Factores críticos de éxito y competencias profesionales necesarias.

IMPLANTACIÓN DE UNA ESTRATEGIA DE GESTIÓN POR PROCESOS (BPM). Factores críticos de éxito y competencias profesionales necesarias. IMPLANTACIÓN DE UNA ESTRATEGIA DE GESTIÓN POR PROCESOS (BPM). 1 Factores críticos de éxito y competencias profesionales necesarias. Objetivos generales del TFG Determinar cuales son los factores críticos

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

Trabajo Práctico Integrador

Trabajo Práctico Integrador Trabajo Práctico Integrador Objetivo: Relacionar los conceptos vistos durante la cursada bajo una actividad práctica en la que los alumnos puedan aplicar los conceptos a la luz de un contexto organizacional.

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles

MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS

MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS Existen diversos métodos para desarrollar un sistema de información o un microsistema, pero en esencia todos parten de los mismos principios

Más detalles

El Gerente de Proyecto. 3: El Gerente de Proyecto. Analogía - Responsabilidades. Liderazgo del Proyecto. Responsabilidades Implícitas

El Gerente de Proyecto. 3: El Gerente de Proyecto. Analogía - Responsabilidades. Liderazgo del Proyecto. Responsabilidades Implícitas 3: El Gerente de Proyecto El Gerente de Proyecto Selección del Gerente de Proyecto Habilidades Requeridas Criterios aplicables a la Selección. Descripción de Tareas. Project Charter 1 2 Responsabilidades

Más detalles

GESTIÓN DE PROYECTOS DE SOFTWARE

GESTIÓN DE PROYECTOS DE SOFTWARE GESTIÓN DE PROYECTOS DE SOFTWARE LA PLANIFICACIÓN de proyectos se define como la predicción de la duración de las actividades y tareas a escala individual. LA ESTIMACIÓN se define como la predicción de

Más detalles

Copyright 2011 - bizagi. Gestión de Cambios Documento de Construcción Bizagi Process Modeler

Copyright 2011 - bizagi. Gestión de Cambios Documento de Construcción Bizagi Process Modeler Copyright 2011 - bizagi Gestión de Cambios Bizagi Process Modeler Tabla de Contenido Gestión de Cambios... 4 Descripción... 4 Principales factores en la Construcción del Proceso... 5 Modelo de Datos...

Más detalles

PDSM: PROCESO DE DESARROLLO DE SOFTWARE MIXTO COMBINANDO RUP Y SCRUM. Mariani, María Florencia Okabe, Evangelina

PDSM: PROCESO DE DESARROLLO DE SOFTWARE MIXTO COMBINANDO RUP Y SCRUM. Mariani, María Florencia Okabe, Evangelina PDSM: PROCESO DE DESARROLLO DE SOFTWARE MIXTO COMBINANDO RUP Y SCRUM Mariani, María Florencia Okabe, Evangelina Agenda Introducción Metodologías RUP SCRUM Proyectos PDSM: Definición y Aplicación del proceso

Más detalles

GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS TABLA DE CONTENIDO

GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS TABLA DE CONTENIDO - 1 - RUP/Easy GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS Setiembre 2004 TABLA DE CONTENIDO 1 INTRODUCCIÓN...1 2 ADECUACIÓN DE LOS WORKFLOWS ESENCIALES DEL RUP...2 2.1 WORKFLOWS ESENCIALES DEL RUP...2

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

IMPLEMENTACIÓN DE PRÁCTICAS PARA LA GESTIÓN DE PROGRAMAS EN ECOPETROL

IMPLEMENTACIÓN DE PRÁCTICAS PARA LA GESTIÓN DE PROGRAMAS EN ECOPETROL IMPLEMENTACIÓN DE PRÁCTICAS PARA LA GESTIÓN DE PROGRAMAS EN ECOPETROL UNA MIRADA AL PROCESO Y SUS RESULTADOS Nombre Oscar Fernando Conferencista Rodriguez Bernal, I.C., M. Sc., PMP ECOPETROL Empresa 1

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

CM colabora con el proceso a través de la implementación de políticas de tracking, seguridad, integración y administración de cambios.

CM colabora con el proceso a través de la implementación de políticas de tracking, seguridad, integración y administración de cambios. 1 Administración de Configuraciones - Introducción La facilidad de cambio en el software pone en riesgo la integridad de los productos. Cambios sin control, despliegue de componentes inconsistentes entre

Más detalles

SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE

SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE Recibido: 23 de febrero de 2011 Aceptado: 29 de marzo de 2011 SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE MSc. Ailin Orjuela, MSc. Luis Alberto Esteban, MSc.

Más detalles

JUSTIFICACIÓN DEL DESARROLLO DE UN SE

JUSTIFICACIÓN DEL DESARROLLO DE UN SE JUSTIFICACIÓN DEL DESARROLLO DE UN SE El beneficio económico que representa la solución del problema es alto La experiencia humana puede desaparecer La experiencia humana no se encuentra comúnmente disponible

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Plan de iteraciones RUP Proceso Iterativo e Incremental El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran a los usuarios y clientes (miniproyectos)

Más detalles

Ingeniería de Software II

Ingeniería de Software II Ingeniería de Software II Segundo Cuatrimestre 2007 Clase 8 Parte 1: Gestión de Riesgos Algunas enfermedades, como dicen los médicos, son al principio fáciles de curar pero difíciles de reconocer... pero,

Más detalles

Capítulo 1. Introducción

Capítulo 1. Introducción Capítulo 1. Introducción 1.1. Propósito de la Guía BABOK El propósito principal de la Guía BABOK Guide es definir la profesión del Análisis de Negocio y proveer un conjunto de prácticas comúnmente aceptadas.

Más detalles

Implementación de Procesos Business Process Management BPM Services Oriented Architecture SOA

Implementación de Procesos Business Process Management BPM Services Oriented Architecture SOA Implementación de Procesos Business Process Management BPM Services Oriented Architecture SOA Título Área específica de la publicación 2 Implementación de Procesos Business Process Management BPM Services

Más detalles

ITIL FOUNDATION V3 2011

ITIL FOUNDATION V3 2011 ITIL FOUNDATION V3 2011 Examen de Certificación Instrucciones 1. Revise su Hoja de Respuesta, debe contener espacio para responder 40 preguntas y una sección para incorporar su Nombre 2. Espere por la

Más detalles

Administración de Proyectos de Implementación de Paquetes

Administración de Proyectos de Implementación de Paquetes 29/10/ Administración de Proyectos de Implementación de Paquetes FIUBA Administración y Control de Proyectos II Fases de Project Management Visión Proyecto Aprobado Inicio (Alcance) Alcance Aprobado Organización

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles