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

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

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

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

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

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

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

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

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

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

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

Cristian Blanco www.cristianblanco.es

Cristian Blanco www.cristianblanco.es 3.1.- INTRODUCCIÓN Para realizar el desarrollo de cualquier proyecto de software es necesario llevar una sistemática de trabajo, que nos asegure el éxito del mismo. Lo que tenemos que evitar, en el desarrollo

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

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

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

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

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

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

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

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

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

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

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

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

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

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

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

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

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

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

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

Análisis de la gestión de configuración de software aplicada al modelo de espiral

Análisis de la gestión de configuración de software aplicada al modelo de espiral Análisis de la gestión de configuración de software aplicada al modelo de espiral Abstract No hay nada permanente, excepto el cambio Heráclito (540 475 A.C.)- Grecia Fernandez, Sebastian Osso, Mariano

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Introducción al Unified Process. Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010

Introducción al Unified Process. Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010 Introducción al Unified Process Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010 Unified Process - UP Un framework de Proceso de Desarrollo de Software, una de cuyas versiones es el más documentado

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

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

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos Tema 13 Metodologías en el desarrollo de Sistemas de Software Prof. Oscar Adolfo Vallejos Desarrollo de Sistemas de Software Objetivo Conceptos en el contexto más amplio de Software e Ingeniería de Software

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

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

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

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

Administración del Tiempo en el Desarrollo de un Sistema de Información

Administración del Tiempo en el Desarrollo de un Sistema de Información Administración del Tiempo en el Desarrollo de un Sistema de Información José Jimmy Camacho Martínez (1) Ramón David Chávez Cevallos (2) Ing. Lennin Freire (3) Facultad de Ingeniería en Electricidad y Computación

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

Diplomado de. Administración. de Proyectos Diplomado de Administración de Proyectos: Preparación para la certificación del PMI

Diplomado de. Administración. de Proyectos Diplomado de Administración de Proyectos: Preparación para la certificación del PMI Diplomado de Administración de Proyectos Diplomado de Administración de Proyectos: Preparación para la certificación del PMI Módulo 1. Conceptos básicos de la Administración de Proyectos Conceptos básicos

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

Ingeniería de Software II

Ingeniería de Software II Ingeniería de Software II Segundo Cuatrimestre 2007 Clase 1b: Modelos de Ciclo de Vida Buenos Aires, 23 de Agosto de 2007 Qué es un modelo del ciclo de vida de un sistema? 8Una representación estandarizada

Más detalles

Introducción 90% Figura 1 Síndrome del 90%

Introducción 90% Figura 1 Síndrome del 90% El Problema Quality Control = Project Control? Indicadores Objetivos para Control de Proyectos de Desarrollo de Software Lic. Juan Pablo Pussacq Laborde Jefe de la Oficina de Proyectos, RMyA Introducció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

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

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

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

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

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

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

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

SCL Artículos CONSULTING. Luis Aguado SCl Consulting CONSULTING

SCL Artículos CONSULTING. Luis Aguado SCl Consulting CONSULTING SCL Artículos Luis Aguado SCl Consulting Two value releases per year Este concepto es simple: la TI debe ser capaz de liberar 2 nuevas versiones (releases) para las soluciones de negocio al año, basadas

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos 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

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

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

Desarrollo en Cascada (Waterfall) VS Desarrollo Agile-SCRUM. Por Jesus Demetrio Velázquez Camacho

Desarrollo en Cascada (Waterfall) VS Desarrollo Agile-SCRUM. Por Jesus Demetrio Velázquez Camacho Desarrollo en Cascada (Waterfall) VS Desarrollo Agile-SCRUM Por Jesus Demetrio Velázquez Camacho Dentro de las organizaciones de desarrollo de aplicaciones existen dos grandes corrientes para la metodología

Más detalles

La Implementación de SAP R/3

La Implementación de SAP R/3 SESIÓN 3 La implementación de SAP R/3 Etapas del Proyecto y Tareas a Realizar Entorno de la Implementación SAP Taller de Introducción a ERP SESIÓN 3/1 La Implementación de SAP R/3 El significado usual

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

LINEAMIENTOS DE MONITOREO Y CONTROL

LINEAMIENTOS DE MONITOREO Y CONTROL Bogotá D.C., Agosto de 2014 TABLA DE CONTENIDO INTRODUCCIÓN ------------------------------------------------------------------------------------------- --3 1. OBJETIVO --------------------------------------------------------------------------------------------

Más detalles

Tema 5. Gestión de Proyectos (ISG3)

Tema 5. Gestión de Proyectos (ISG3) Tema 5. Gestión de Proyectos (ISG3) Antonio José Sáenz Albanés (C.T.O) Reconocimiento No Comercial Compartir Igual - 2.5 - España 1 Planificación 1ª Clase: Presentación y Conceptos Generales 2ª Clase:

Más detalles

Buenas prácticas en el diseño de software

Buenas prácticas en el diseño de software Buenas prácticas en el diseño de software Guión Introducción Conceptos clave Test de usuarios Metodología y procesos de diseño Ejemplos y casos de uso. Preguntas y dudas Objetivos - Explicar un proceso

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

El Proceso Unificado

El Proceso Unificado El Proceso Unificado de Desarrollo de Software Prof. Gustavo J. Sabio Alcance de la presentación QA Entradas Proceso de desarrollo Salida equipo Cliente sistemas Cliente necesidades actividades varias

Más detalles

1. Marco Teórico. 1. Marco Teórico

1. Marco Teórico. 1. Marco Teórico 1.1 Gestión del Servicio Para empezar, antes de entender qué es la gestión del servicio, se tiene que entender qué son para que de esa forma entendamos cómo la gestión de los mismos puede ayudar a los

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

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

Capitulo 2: (PMBOK guide) Ciclo de Vida del Proyecto y Organización

Capitulo 2: (PMBOK guide) Ciclo de Vida del Proyecto y Organización Capitulo 2: (PMBOK guide) Ciclo de Vida del Proyecto y Organización Los proyectos y la dirección de proyectos se llevan a cabo en un entorno más amplio que el atribuible al propio proyecto. El equipo de

Más detalles

Tema 2. El Ciclo de Vida del Software (ISG1-ITIG)

Tema 2. El Ciclo de Vida del Software (ISG1-ITIG) Tema 2. El Ciclo de Vida del Software (ISG1-ITIG) Grupo de Ingeniería del Software Antonio José Sáenz Albanés (C.T.O) Reconocimiento No Comercial Compartir Igual - 3.0 - España 1 Objetivos del Tema Qué

Más detalles

El enfoque ideal para la erm se diseña de forma personalizada para que se adecue a los

El enfoque ideal para la erm se diseña de forma personalizada para que se adecue a los ALEXANDRA PSICA, CMC DIRECTORA GENERAL INTERIS CONSULTING INC. El enfoque ideal para la erm se diseña de forma personalizada para que se adecue a los objetivos de la organización, al nivel de riesgo inherente

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

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

SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS

SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS Universidad de Carabobo Facultad Experimental de Ciencias y Tecnología Departamento de Computación Unidad Académica Base de Datos SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS Integrantes: Fidel Gil

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

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

SOFTWARE PROJECT MANAGEMENT PLAN

SOFTWARE PROJECT MANAGEMENT PLAN SOFTWARE PROJECT MANAGEMENT PLAN HERRAMIENTA PARA LA ADMINISTRACIÓN DE REQUERIMIENTOS DE LOS PROYECTOS DE LAS ASIGNATURAS DE INGENIERÍA Y ARQUITECTURA DE SOFTWARE DE LA PONTIFICIA UNIVERSIDAD JAVERIANA.

Más detalles

Ingeniería de Software I. Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009

Ingeniería de Software I. Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009 Ingeniería de Software I Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009 Quienes somos? 2 Quienes son? 3 Objetivos del Curso Entender el rol fundamental que juega la construcción y análisis

Más detalles

Proyectos en Sistemas Informáticos

Proyectos en Sistemas Informáticos Dirección y Gestión de proyectos Proyectos en Sistemas Informáticos Universidad de Valencia 5º Ingeniería Informática 1 Crédito. Pedro Morillo Tena 2 Dirección y Gestión de proyectos Temario (1 crédito):

Más detalles

Gerencia de Proyectos Proceso de Software

Gerencia de Proyectos Proceso de Software Gerencia de Proyectos Proceso de Software Victor Manuel Toro C. VictorToro@cincosoft.com CincoSOFT Ltda. Compañía de Ingenieros Constructures de Software Tel. (+57)(1) 6230180 * Fax (+57)(1) 2566774 Carrera

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

ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES Y DE GESTIÓN DE RELACIONES CON CLIENTES CUALIFICACIÓN PROFESIONAL

ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES Y DE GESTIÓN DE RELACIONES CON CLIENTES CUALIFICACIÓN PROFESIONAL Página 1 de 23 CUALIFICACIÓN PROFESIONAL Familia Profesional Nivel 3 Código IFC363_3 Versión 5 Situación RD 1701/2007 Actualización ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles