CICLO DE VIDA DEL SOFTWARE 1. Concepto de Ciclo de Vida 2. Procesos del Ciclo de Vida del Software 3. Modelo en cascada, modelo V 4. Modelo incremental 5. Modelo en espiral 6. Prototipado 7. La reutilizaci贸n en el Ciclo de Vida 8. S铆ntesis autom谩tica de Software 9. Comparaci贸n de Ciclos de Vida 10. Modelos para desarrollo de sistemas Orientados a Objetos.
¿Qué es un proceso software? • Distintos procesos de software organizan las actividades de diferentes formas, y las describen con diferente nivel de detalle. El tiempo de cada actividad varía, así como los resultados. Organizaciones diferentes usan procesos diferentes para producir el mismo producto.
• Sin embargo, para algunos tipos de aplicación, algunos procesos son más convenientes que otros.
¿Qué es un proceso software?. Ciclo de vida Alternativamente, a veces se usan los términos – “Ciclo de vida”, y – “Modelo de ciclo de vida” ⇒ Sucesión de etapas por las que atraviesa un producto software a lo largo de su existencia (durante su desarrollo y explotación)
1.- ¿Qué es un proceso software?. Ciclo de vida
Ciclo de vida ≠ Ciclo de desarrollo Desde el análisis hasta la entrega al usuario Toda la vida del sistema: desde la concepción hasta el fin de uso
CICLO DE VIDA DEL SOFTWARE • 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 procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso” ISO 12207-1
Estándares relacionados con el proceso software. IEEE 1074-1998. Developing Software Life Cycle Processes Cada organización debe asociar las actividades definidas en el estándar a su propio ciclo de vida del software. Si no lo ha definido, debe hacerlo El seguimiento del estándar no implica el uso de ningún método específico, ni la creación de determinados documentos prescribe los procesos del ciclo de vida, no los productos del mismo.
Estándares relacionados con el proceso software. IEEE 1074-1998. Developing Software Life Cycle Processes Sección 2 3
Título Procesos de modelo de ciclo de vida del software Procesos de gestión del proyecto
4
Procesos pre-desarrollo
5
Procesos de desarrollo
6
Procesos post-desarrollo
7
Procesos integrales
Procesos Modelo del Ciclo de vida del software Inicio del proyecto Monitorización y control del proyecto Gestión de la calidad del software Exploración de conceptos Asignación del sistema Requisitos Diseño Implementación Instalación Operación y soporte Mantenimiento Fin de uso Verificación y validación Gestión de la configuración del software Desarrollo de la documentación Entrenamiento
Estándares relacionados con el proceso software. IEEE 1074-1998. Developing Software Life Cycle Processes • Procesos divididos en actividades (obligatorias y opcionales): • Información de entrada • Descripción • Información de salida • Antes de empezar un proyecto, revisar las actividades para ver si son aplicables, y establecer un orden. • Conformidad con el estándar: realización de todas las actividades obligatorias.
Estándares relacionados con el proceso software. Procesos estándar - IEEE/EIA (ISO/IEC) 12207. Information technology – Software life cycle processes
• Establece un marco común para los procesos de ciclo de vida. • Emplea términos bien definidos. • Describe el ciclo de vida.
Desde la definición de requisitos hasta el fin de uso, y contiene procesos para adquirir y suministrar productos y servicios software.
Estándares relacionados con el proceso software. Procesos estándar - IEEE/EIA (ISO/IEC) 12207. Information technology – Software life cycle processes:
Ciclo de vida • “Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso” Proceso: conjunto de actividades. Actividad: conjunto de tareas. Tarea: acción que transforma entradas en salidas.
Estándares relacionados con el proceso software. Procesos estándar - IEEE/EIA (ISO/IEC) 12207. Information technology – Software life cycle processes:
Ciclo de vida • Indica los procesos, actividades y tareas que se necesitan durante la adquisición de un sistema que contiene software, un producto software autónomo, un servicio software, • y durante el suministro, desarrollo, operación y mantenimiento de productos software.
Estándares relacionados con el proceso software. Procesos estándar - IEEE/EIA (ISO/IEC) 12207. Information technology – Software life cycle processes:
Ciclo de vida • También proporciona procesos para definir, controlar y mejorar los procesos de ciclo de vida software. • El marco descrito por el estándar está diseñado para ser adaptado a cada organización y proyecto. • El proceso de adaptación consiste en la eliminación de procesos, actividades y tareas no aplicables (tb. se pueden añadir).
Estándares relacionados con el proceso software. Procesos estándar - IEEE/EIA (ISO/IEC) 12207. Information technology – Software life cycle processes:
Procesos del Ciclo de vida
PROCESOS PRINCIPALES
PROCESOS DE SOPORTE
ADQUISICIÓN
DOCUMENTACIÓN
SUMINISTRO
GESTIÓN DE CONFIGURACIÓN
DESARROLLO
EXPLOTACIÓN MANTENIMIENTO
ASEGURAMIENTO DE CALIDAD VERIFICACIÓN VALIDACIÓN
PROCESOS DE LA ORGANIZACIÓN GESTIÓN
INFRAESTRUCTURA
MEJORA
FORMACIÓN
REVISIÓN CONJUNTA AUDITORÍA RESOLUCIÓN DE PROBLEMAS
PROCESO DE ADAPTACIÓN
CICLO DE VIDA DEL SOFTWARE
el proceso software. Procesos estándar - IEEE/EIA (ISO/IEC) 12207. Information technology – Software life
cycle processes: Procesos del Ciclo de vida
PROCESOS PRINCIPALES
PROCESOS DE SOPORTE
ADQUISICIÓN
DOCUMENTACIÓN
SUMINISTRO
GESTIÓN DE CONFIGURACIÓN
DESARROLLO
EXPLOTACIÓN MANTENIMIENTO
ASEGURAMIENTO DE CALIDAD VERIFICACIÓN VALIDACIÓN
PROCESOS DE LA ORGANIZACIÓN GESTIÓN
INFRAESTRUCTURA
MEJORA
FORMACIÓN
REVISIÓN CONJUNTA AUDITORÍA RESOLUCIÓN DE PROBLEMAS
PROCESO DE ADAPTACIÓN
Procesos principales: • Útiles a las personas que inician o realizan el desarrollo, la explotación o el mantenimiento del software durante su ciclo de vida – compradores, suministradores, personal de desarrollo, operadores y personal de mantenimiento del software
proceso software. Procesos estándar - IEEE/EIA (ISO/IEC) 12207. Information technology – Software life cycle
processes: Procesos del Ciclo de vida
PROCESOS PRINCIPALES
PROCESOS DE SOPORTE
ADQUISICIÓN
DOCUMENTACIÓN
SUMINISTRO
GESTIÓN DE CONFIGURACIÓN
DESARROLLO
EXPLOTACIÓN
ASEGURAMIENTO DE CALIDAD
MANTENIMIENTO
VERIFICACIÓN VALIDACIÓN
PROCESOS DE LA ORGANIZACIÓN GESTIÓN
INFRAESTRUCTURA
MEJORA
FORMACIÓN
REVISIÓN CONJUNTA AUDITORÍA RESOLUCIÓN DE PROBLEMAS
PROCESO DE ADAPTACIÓN
Procesos de soporte: • Sirven de apoyo al resto. • Contribuyen al éxito y calidad del proyecto software. • Se aplican en cualquier momento del ciclo de vida.
proceso software. Procesos estándar - IEEE/EIA (ISO/IEC) 12207. Information technology – Software life cycle
processes: Procesos del Ciclo de vida
PROCESOS PRINCIPALES
PROCESOS DE SOPORTE
ADQUISICIÓN
DOCUMENTACIÓN
SUMINISTRO
GESTIÓN DE CONFIGURACIÓN
DESARROLLO
EXPLOTACIÓN MANTENIMIENTO
ASEGURAMIENTO DE CALIDAD VERIFICACIÓN VALIDACIÓN
PROCESOS DE LA ORGANIZACIÓN GESTIÓN
INFRAESTRUCTURA
MEJORA
FORMACIÓN
REVISIÓN CONJUNTA AUDITORÍA RESOLUCIÓN DE PROBLEMAS
PROCESO DE ADAPTACIÓN
Procesos de la organización (procesos generales): • Objetivo: establecer, implementar y mejorar la organización (gestión, formación del personal, mejora del proceso, etc.) • Se realizan fuera de proyectos específicos, a nivel organizativo.
proceso software. Procesos estándar - IEEE/EIA (ISO/IEC) 12207. Information technology – Software life cycle
processes: Procesos del Ciclo de vida
PROCESOS PRINCIPALES
PROCESOS DE SOPORTE
ADQUISICIÓN
DOCUMENTACIÓN
SUMINISTRO
GESTIÓN DE CONFIGURACIÓN
DESARROLLO
EXPLOTACIÓN MANTENIMIENTO
ASEGURAMIENTO DE CALIDAD VERIFICACIÓN VALIDACIÓN
PROCESOS DE LA ORGANIZACIÓN GESTIÓN
INFRAESTRUCTURA
MEJORA
FORMACIÓN
REVISIÓN CONJUNTA AUDITORÍA RESOLUCIÓN DE PROBLEMAS
PROCESO DE ADAPTACIÓN
Proceso de adaptación: • Permite adaptar el estándar a cada proyecto y organización. • Factores que influencian la forma de adquirir, desarrollar, explotar o mantener un sistema: • Tamaño y complejidad del proyecto. • Requisitos del sistema. • Métodos de desarrollo. • Variaciones en las políticas y procedimientos de la organización…
Procesos principales: Proceso de adquisición. • Actividades y tareas que el comprador, el cliente o el usuario realizan para adquirir un sistema o producto (servicio) software – Preparación y publicación de una solicitud de ofertas. – Selección del suministrador del software. – Gestión de los procesos desde la adquisición hasta la aceptación del producto.
Procesos principales: Proceso de suministro • Actividades y tareas que realiza el suministrador
– Se inicia al preparar una propuesta para atender una petición de un comprador, o por la firma de un contrato con el comprador para proporcionarle un producto software • Identificación de procedimientos y recursos para gestionar bien el proyecto. • Desarrollo de los planes del proyecto. • Ejecución de los planes del proyecto hasta la entrega del producto software al comprador.
Procesos principales: Proceso de desarrollo • Contiene las actividades y tareas realizadas por el desarrollador. • Integra las siguientes actividades: Implementación del proceso. Análisis de requisitos del sistema. Diseño de la arquitectura del sistema. Análisis de los requisitos del software. Diseño de la arquitectura del software. Diseño detallado del software. Codificación y prueba del software.
Integración del software. Prueba del software. Integración del sistema. Prueba del sistema. Instalación del software. Soporte del proceso de aceptación del software.
Procesos principales: Proceso de desarrollo. Implementación del proceso • Si no está especificado en el contrato, el desarrollador definirá un modelo de ciclo de vida – apropiado al ámbito, magnitud y complejidad del proyecto. • Las actividades y tareas del proceso de desarrollo serán seleccionadas y relacionadas con el modelo de ciclo de vida.
Procesos principales: Proceso de desarrollo. Implementación del proceso • Si no están indicados deberá seleccionar, estándares, métodos, programación que documentados)
en el contrato el desarrollador adaptar y utilizar aquellos herramientas y lenguajes de son apropiados (y están
para realizar las actividades del proceso de desarrollo y de los procesos de soporte.
Procesos principales: Proceso de desarrollo. Análisis de requisitos del sistema
• Los requisitos del sistema incluyen: – funciones y capacidades – requisitos de seguridad – requisitos de interacción hombre-máquina – interfaces del sistema – restricciones aplicables al diseño – requisitos de aceptación –…
Procesos principales: Proceso de desarrollo: Diseño de la arquitectura del sistema
• Se identifica la arquitectura de alto nivel del sistema: – Se determinan los principales componentes hardware, software y las operaciones manuales – Se asignan los requisitos del sistema a dichos componentes
Procesos principales: Proceso de desarrollo Análisis de los requisitos del software • Se identifican y documentan los requisitos del software, incluyendo: – especificaciones funcionales y de capacidad (rendimiento de la aplicación, etc.) – interfaces externas – seguridad y protección (de la información, daños personales, etc.) – datos que se van a manejar y requisitos de la BD – requisitos de instalación y de aceptación – requisitos de mantenimiento..
Procesos principales: Proceso de desarrollo. Análisis de los requisitos del software • Varios estándares definidos para esta fase: – IEEE 830- 1998. Recommended Practice for Software Requirements Specifications – DI-IPSC- 81433. Software Requirements Specification (estándar del DoD)
Procesos principales: Proceso de desarrollo: Diseño de la arquitectura del software
• Componentes principales del software • Versión preliminar de los manuales de usuario • Requisitos de las pruebas • Planificación de la integración del software
Procesos principales: Proceso de desarrollo: Diseño detallado del software
• • • • • • • •
Diseño detallado de cada componente sw. Diseño detallado de las interfaces. Diseño detallado de la BD Actualizar manuales de usuario. Def. y documentar los req. de prueba. Actualizar req. de prueba para la integración del sw. Evaluar todo lo anterior. Reuniones de revisión.
Procesos principales: Proceso de desarrollo: Codificación y prueba del software
• Se desarrollan los componentes software y las bases de datos • Se prueban los componentes (prueba de unidad) • Se actualizan los manuales de usuario
Procesos principales: Proceso de desarrollo: Actividades finales • Integración del software – Se integran los componentes del software y se prueban según sea necesario • Prueba del software – De acuerdo con los requisitos de cualificación (validación) especificados para el software • Integración del sistema – Se integra hardware, manuales.
software
y
operaciones
Procesos principales: Proceso de desarrollo: Actividades finales • Prueba del sistema – Análoga a la del software, pero de acuerdo con los requisitos de cualificación especificados para el sistema • Instalación del software – En el entorno donde vaya a funcionar Cuando reemplace a otro sistema, el estándar recomienda mantener funcionamiento paralelo un tiempo
Procesos principales: Proceso de desarrollo: Actividades finales
• Soporte del proceso de aceptación del software – Finalmente, se debe dar apoyo a la revisión de aceptación y a la prueba del software por el comprador.
Procesos principales: Proceso de explotación
• También llamado de operación. • Explotación del software y del soporte del mismo. • La explotación del software está integrada en la del sistema, por lo que las actividades y tareas de este proceso se aplican al sistema completo.
Procesos principales: Proceso de explotación • El sistema debe ser operado de acuerdo con la documentación de usuario en su entorno previsto •
Entre otras actividades, el operador deberá: – Desarrollar un plan para llevar a cabo las actividades y tareas de este proceso. – Procedimientos para comprobar el producto software en su entorno de operación, enviando informes de problemas y peticiones de modificación al proceso de mantenimiento. – El operador debe proporcionar asistencia a los usuarios.
Procesos principales: Proceso de mantenimiento • El software o la documentación necesita ser modificado, debido a problemas o a necesidades de mejora o adaptación, p.e.: – – – – – –
nuevos errores detectados cambios en la legislación cambios en el entorno necesidad de mejoras migración a un nuevo entorno operativo se va a terminar con su uso…
Procesos principales: Proceso de mantenimiento “Modificar el software existente manteniendo su consistencia” • Comprende las siguientes actividades: – Implementación del proceso de mantenimiento. – Análisis del problema y de la modificación. – Implementación de la modificación. – Revisión y aceptación del mantenimiento. – Migración. – Fin de uso del software.
Procesos de soporte • Sirven de apoyo al resto de procesos. • Se aplican en cualquier momento del ciclo de vida: – – – – – – – –
Documentación Gestión de la configuración Aseguramiento de la calidad Verificación Validación Revisión conjunta Auditoría Resolución de problemas
Procesos de soporte: Proceso de documentación • Registrar la información producida por cualquier proceso o actividad del ciclo de vida. • Gestiona los documentos necesarios para todas las personas involucradas en el proceso software. Directores, ingenieros, personal de desarrollo, usuarios del sistema, etc.
Procesos de soporte: Proceso de gestión de la configuración • Supongamos la siguiente situación: "un programador intenta depurar un programa, haciendo uso de un depurador sobre el ejecutable y con un listado. No encuentra el error, pero más tarde se da cuenta de que le habían dado un listado anticuado. Con el listado correcto, soluciona el problema rápidamente“ ⇒ un problema de gestión de configuración del software
Procesos de soporte: Configuración del software • Configuración del software – Programas – Documentación – Datos • En aplicaciones grandes, la gestión de la configuración del software se convierte en un problema • Ejemplos: – Efecto Y2K → ¿Qué aplicaciones actualizar? – “make” – Control de versiones: SGBDOO GemStone
Procesos de soporte: Proceso de gestión de la configuración • Se encarga de gestionar: las modificaciones de los elementos configuración del software de un sistema
de
“la modificación X al programa Y fue hecha por la persona Z” y las versiones de los elementos “la última versión del programa X es la 1.4”
Procesos de soporte: Proceso de gestión de la configuración • Se encarga de: – registrar e informar sobre el estado de los elementos y las peticiones de modificación – asegurar la completitud, consistencia y corrección de los elementos – controlar el almacenamiento, la manipulación y la entrega de los elementos
Procesos de soporte: Proceso de aseguramiento de la calidad • Aporta confianza en que los procesos y los productos software del ciclo de vida cumplen con los requisitos especificados y se ajustan a los planes establecidos. • Aseguramiento de la calidad: – interno – Externo • Usa resultados de otros procesos de apoyo: verificación, validación, auditorías, etc.
Procesos de soporte: Proceso de verificación • Indica – si los requisitos de un sistema o del software están bien recogidos en cada modelo • verificación horizontal – si los productos software de cada fase del ciclo de vida cumplen los requisitos impuestos sobre ellos en las fases previas • verificación vertical ¿Estamos construyendo correctamente el producto?
Procesos de soporte: Proceso de validación
• Indica si el sistema o software final cumple con las necesidades del usuario. • También se puede validar una especificación. • Puede ser realizado por una organización de servicios independiente (proceso de validación independiente).
Procesos de soporte: Proceso de revisión conjunta
• Evaluar el estado del software y sus productos en una actividad del ciclo de vida o fase del proyecto. • Se realiza durante todo el ciclo de vida: – a nivel de gestión – a nivel técnico del proyecto
Procesos de soporte: Proceso de auditoría • Permite determinar si se cumplen los requisitos, los planes y el contrato. • “El conjunto de técnicas, métodos y procedimientos empleados para la evaluación de sistemas informáticos” • Control de la adecuación de los sistemas a los requisitos establecidos para ellos (corrección, completitud, eficiencia, etc.) • Produce un documento de recomendaciones
Procesos de soporte: Proceso de auditoría • El objetivo de una auditoría es realizar una evaluación exhaustiva y producir un documento de recomendaciones para enmendar o mejorar los aspectos débiles que se detecten • Tipos de auditoría informática: – De explotación – De sistemas – De comunicaciones – De desarrollo de proyectos – De seguridad – ...
Procesos de soporte: Proceso de auditoría • La auditoría informática ayuda a detectar : • Fraudes y delitos económicos producidos en las propias empresas (a veces por los propios empleados, sin conocimiento de la dirección). • Pruebas de privacidad y seguridad (auditoría de seguridad informática, tanto lógica como física) • La corrección de los datos de entrada (auditoría informática de datos). • Pruebas de diseño del sistema informático • ...
Procesos de soporte: Proceso de resoluciĂłn de problemas
• Analizar y eliminar los problemas (diferencias con el contrato o los requisitos) descubiertos durante el desarrollo, el mantenimiento, u otro proceso. • Se trata de disponer de una manera de garantizar que todos los problemas descubiertos se analizan y eliminan.
Procesos de la organización • Ayudan a establecer, implementar y mejorar la gestión consiguiendo una organización más efectiva. • Se llevan a cabo a nivel organizativo, fuera del ámbito de proyectos y contratos específicos. – – – –
Proceso de gestión Proceso de infraestructura Proceso de mejora Proceso de formación
Procesos de la organización: Proceso de gestión • Se incluye en cualquier organización que tenga que gestionar sus procesos. • Implica – planificación, – seguimiento y control, – revisión y evaluación.
Procesos de la organización: Proceso de infraestructura • Establece la infraestructura necesaria para el resto de procesos (para el desarrollo, la explotación o el mantenimiento): – – – – –
hardware, software, herramientas, normas, Instalaciones.
Procesos de la organización: Proceso de mejora • Sirve para establecer, valorar, medir, controlar y mejorar los procesos del ciclo de vida del software. – Quality Improvement Paradigm (QIP) – Personal Software Process (PSP) – Gestión de la calidad total
Procesos de la organizaciรณn: Proceso de formaciรณn
โ ข Sirve para mantener el personal formado, desarrollando un plan de formaciรณn, junto con materiales adecuados.
Problema 1: Los clientes no saben(en realidad) lo que quieren Posiblemente el problema más común en la fase de análisis de los requisitos es que los clientes sólo tienen una vaga idea de lo que necesitan, y le toca a usted hacer las preguntas correctas y realizar los análisis necesarios para convertir esta visión amorfa en un requisito de software formalmente documentado. Asegúrese de que usted pasa tiempo suficiente al inicio del proyecto en la comprensión de los objetivos, los resultados y el alcance del proyecto. Haga visibles las suposiciones que el cliente está utilizando, y evalúe críticamente tanto los posibles beneficios de los usuarios finales y los riesgos del proyecto. Intente escribir una declaración de la visión concreta para el proyecto, que abarca tanto las funciones específicas que ofrece ventajas para el usuario y el problema general del negocio que se espera resolver.
Problema 2: Los requisitos cambian durante el transcurso del proyecto El segundo problema más común con los proyectos de software es que los requisitos definidos en la primera fase cambian a medida que avanza el proyecto. Esto puede ocurrir porque, como avanza el desarrollo y con los prototipos desarrollados, los clientes son capaces de ver más claramente los problemas existentes con el plan original y hacer las correcciones necesarias. También puede ocurrir debido a los cambios del entorno exterior que generan una variación del problema de negocio original y por lo tanto requiere una solución diferente a la inicialmente propuesta. Los buenos gerentes de proyecto son conscientes de estas posibilidades y por lo general ya tienen planes alternativos para hacer frente a estos cambios. Para resolver este problema, usted debe: Contar con un proceso claramente definido para recibir, analizar e incorporar las solicitudes de cambio. Hitos establecidos para cada fase de desarrollo y definir los cambios no permitidos
Problema 3: Los clientes tienen líneas de tiempo no razonable Es muy común escuchar a un cliente decir algo como "es un trabajo de emergencia y necesitamos completar este proyecto en semanas X". Un error común es llegar a un acuerdo con los nuevos plazos antes de realizar un análisis detallado y de comprender tanto el alcance del proyecto y los recursos necesarios para ejecutarlo. Al aceptar una línea de tiempo no razonable, sin discusión, usted está, de hecho, haciendo un flaco favor a su cliente: es muy probable que el proyecto o se retrase (porque no era posible ejecutarlo en el tiempo) o sufra defectos de calidad (porque fue trasladado de urgencia dentro del plan sin una inspección adecuada). Para resolver este problema, usted debe: Convertir la especificación de requerimientos del software en un plan del proyecto, detallando las tareas y los recursos necesarios en cada etapa y modelar un escenario para el mejor de los casos, el mediano de los casos y el peor de los casos. Asegúrese de que el plan del proyecto tiene en cuenta las limitaciones de recursos. Entre en una conversación sobre los plazos con el cliente, utilizando las cifras en su plan de proyecto de pruebas.
Problema 4: existen lagunas de comunicación entre los clientes, ingenieros y gestores de proyectos A menudo, los clientes y los ingenieros no logran comunicarse claramente con los demás porque vienen de mundos diferentes y no entienden los términos técnicos de la misma manera. Esto puede llevar a confusión y faltas de comunicación graves, y una importante tarea de un director de proyecto, especialmente durante la fase de análisis de requerimientos, es asegurar que ambas partes tienen un conocimiento preciso de la entrega y las tareas necesarias para lograrlo. Para resolver este problema, usted debe: Tome notas en cada reunión y difúndalas a todo el equipo del proyecto. Sea consistente en el uso de las palabras. Haga usted mismo un glosario de los términos que usted va a utilizar justo al principio, garantice a todos los interesados tener una copia, y que se adhieran a ella constantemente.
Problema 5: El equipo de desarrollo no entiende la política de la organización del cliente Se sugiere que un gerente efectivo es aquel que ve la organización como un "escenario impugnado" y entiende la importancia del poder, los conflictos, la negociación y coaliciones. Este gerente no sólo es hábil en las tareas operativas y funcionales, sino que también entiende la importancia de definir agendas para propósitos comunes, la creación de coaliciones que estén alineadas a su punto de vista, y convencer a los gerentes resistentes de la validez de una posición en particular. Para resolver este problema, usted debe: Revise la red existente e identifique tanto la información que necesita y quién es probable que la tenga. Cultive aliados, establezca relaciones y piense sistemáticamente sobre su capital social en la organización. Convenza a los opositores dentro de la organización de su cliente mediante la formulación de preguntas de una manera que sea relevante a su propia experiencia.
MODELO EN CASCADA
MODELO EN CASCADA
MODELO EN CASCADA • CRITICAS: • No permite mucha reflexión y revisión. • Una vez que el código está en revisión es muy difícil corregir cualquier error. • No refleja realmente el proceso de desarrollo del software • Se tarda mucho tiempo en pasar por todo el ciclo • Perpetua el fracaso de la industria del software en su comunicación con el usuario final • El mantenimiento se realiza en el código fuente • Las revisiones de proyectos de gran complejidad son muy difíciles • Impone una estructura de gestión de proyectos
MODELO INCREMENTAL
MODELO INCREMENTAL
MODELO INCREMENTAL
MODELO INCREMENTAL • Se evitan proyectos largos y se entrega “Algo de valor” a los usuarios con cierta frecuencia • El usuario se involucra más • Difícil de evaluar el coste total • Difícil de aplicar a sistemas transaccionales que tienden a ser integrados y a operar como un todo • Requiere gestores experimentados • Los errores en los requisitos se detectan tarde. • El resultado puede ser muy positivo
MODELO DE PROTOTIPO
Paradigma de construcción de prototipos: – Escuchar al cliente – Construir/revisar maqueta – Probar maqueta • Los prototipos tienen una doble función: – El cliente ve el producto y refina sus requisitos – El desarrollador comprende mejor lo que necesita hacer • La construcción de prototipos también puede ser problemática
EL PROTOTIPADO “RAPIDO”
MODELO DE PROTOTIPO • No modifica el flujo del ciclo de vida • Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios • Reduce costos y aumenta la probabilidad de éxito • Exige disponer de las herramientas adecuadas • No presenta calidad ni robustez • Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniería.
EL PROTOTIPADO Rápido PARA QUE SEA EFECTIVO: • • • • • •
Debe ser un sistema con el que se pueda experimentar Debe ser comparativamente barato (< 10%) Debe desarrollarse rápidamente Énfasis en la interfaz de usuario Equipo de desarrollo reducido Herramientas y lenguajes adecuados
“El prototipado es un medio excelente para recoger el ‘feedback’ (realimentación) del usuario final”
PELIGROS DEL PROTOTIPO
• El cliente ve funcionando lo que para el es la primera versión del prototipo que ha sido construido con “plastilina y alambres”, y puede desilusionarse al decirle que el sistema aun no ha sido construido.
• El desarrollador puede caer en la tentación de ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.
EL PROTOTIPADO EVOLUTIVO • Construcción de una implementación parcial que cubre los requisitos conocidos, para ir aprendiendo el resto y, paulatinamente, incorporarlos al sistema • Reduce el riesgo y aumenta la probabilidad de éxito • No se conocen niveles apropiados de calidad y documentación. • Problemas de gestión de configuración • Construir software para que pueda ser modificado fácilmente es un “arte desconocido”
EL PROTOTIPADO OPERACIONAL
EL PROTOTIPADO OPERACIONAL • Es una mezcla entre el prototipado rápido y el evolutivo. • En algunos sistemas ni el prototipado rápido ni el evolutivo por si solos son aceptables. • Hay sistemas en que la mayoría de los requisitos son: – Críticos al diseño y bien entendidos – No críticos al diseño y pobremente entendidos – Desconocidos • El prototipado rápido por si solo es poco efectivo porque los requisitos pobremente entendidos no son críticos. • El prototipado evolutivo por si solo es poco efectivo porque no ayuda a clarificar los requerimientos que no se entienden
MODELO EN ESPIRAL
MODELO EN ESPIRAL
MODELO EN ESPIRAL • • • • • • • • •
•
Trata de mejorar los ciclos de vida clásicos y prototipos. Permite acomodar otros modelos Incorpora objetivos de calidad y gestión de riesgos Elimina errores y alternativas no atractivas al comienzo Permite iteraciones, vuelta atrás y finalizaciones rápidas Es difícil de adaptar a los contratos Depende de las personas Difícil de asegurar que las personas involucradas operan en un contexto consistente Cada ciclo empieza identificando: Los objetivos de la porción correspondiente Las alternativas Restricciones Cada ciclo se completa con una revisión que incluye todo el ciclo anterior y el plan para el siguiente
MODELO EN ESPIRAL Diferencias entre modelo en espiral y modelos tradicionales
• •
Reconocimiento explícito de las diferentes alternativas. Identificación de riesgos para cada alternativa desde el comienzo. • Al dividir el proyecto en ciclos, al final de cada uno existe un acuerdo para los cambios que hay que realizar en el sistema. • El modelo se adapta a cualquier tipo de actividad adicional
LA REUTILIZACION EN EL CICLO DE VIDA
LA REUTILIZACION EN EL CICLO DE VIDA • Principios de la reutilización: – – – –
Existen similitudes entre distintos sistemas de un mismo dominio de aplicación El software puede representarse como una combinación de módulos Diseñar aplicaciones = especificar módulos + interrelaciones Los sistemas nuevos se pueden caracterizar por diferencias respecto a los antiguos
• Ventajas y desventajas: - Reduce tiempos y costes de desarrollo - Aumenta la fiabilidad - Dificultad para reconocer los componentes potencialmente reutilizables - Dificultad de catalogación y recuperación - Problemas de motivación - Problemas de gestión de configuración
SÍNTESIS AUTOMÁTICA DE SOFTWARE
SINTESIS AUTOMATICA DEL SOFTWARE Proceso: – La ERS se refina en una especificación formal detallada expresada en notación matemática. – Los procesos (diseño, implementación y pruebas) se reemplazan por un proceso basado en transformaciones donde la especificación formal se refina.
• Otras técnicas avanzadas: – Métodos formales – Técnicas de 4ª generación – Herramientas CASE
SINTESIS AUTOMATICA DEL SOFTWARE • Resumen: • Se define el sistema utilizando un lenguaje formal • La implementación es automática, asistida por el ordenador • La documentación se genera de forma automática • El mantenimiento se realiza “por sustitución” no mediante “parches” • Hay dificultad en la participación del usuario • Los diseños son poco optimizados
COMPARACION DE CICLOS DE VIDA (Clรกsico)
COMPARACION DE CICLOS DE VIDA (Clรกsico)
COMPARACION DE CICLOS DE VIDA (Prototipo rรกpido)
COMPARACION DE CICLOS DE VIDA (Incremental)
COMPARACION DE CICLOS DE VIDA (Prototipado evolutivo)
COMPARACION DE CICLOS DE VIDA (Reutilizaci贸n)
COMPARACION DE CICLOS DE VIDA (Síntesis automática)
MODELOS PARA DESARROLLO ORIENTADOS A OBJETOS • El modelo en cascada no permite aprovechar las ventajas de la tecnología OO • T. OO: – Pretende acelerar el desarrollo de sistemas de una manera iterativa e incremental – Generalizar los componentes para que sean reutilizables • Modelos: – Agrupamiento – Fuente – Remolino – Pinball
MODELOS PARA DESARROLLO ORIENTADOS A OBJETOS • Modelos usuales de ciclo de vida Proyecto • Desarrollo orientado al objeto Producto • Modelo de agrupamiento: Conjunto de clases relacionadas con un objetivo común. • Características: – Subciclos de vida – Cada uno incluye: •Especificación •Diseño •Realización •Validación •Generalización
MODELOS PARA DESARROLLO ORIENTADOS A OBJETOS •
MODELO DE AGRUPAMIENTO
MODELO REMOLINO • Las metodologías de desarrollo no ofrecen una visión real: – El desarrollo es desordenado e implica múltiples iteraciones relacionadas.
• El modelo en cascada asume una dimensión de iteración: la fase del proyecto. • Otras dimensiones: – – – – –
Amplitud: o tamaño del desarrollo Profundidad: nivel de abstracción Madurez: grado de completitud y corrección. Alternativas: diferentes soluciones a un problema Alcance: tiene que ver con los adjetivos del sistema, ya que los requisitos cambian a lo largo del tiempo.
MODELO PINBALL • La pelota representa un proyecto completo o un subproyecto. • El jugador es el equipo de desarrollo. • Se procede de forma iterativa a encontrar clases, atributos métodos e interrelaciones y definir colaboraciones, herencia, agregación y subsistemas. • Por último se pasa a la programación, prueba e implementación. • Hay dos estilos a la hora de “jugar”: • Seguro = tecnologías y métodos probados. • Al límite = Mayor riesgo, más ventajas.
MODELOS OO: FUENTE
CONSIDERACIONES SOBRE MODELOS OO
• Todos estos modelos caracterizan el desarrollo OO por: – Se eliminan fronteras entre fases debido a la naturaleza iterativa del desarrollo orientado al objeto. – Aparece una nueva forma de concebir los lenguajes de programación y su uso al incorporarse bibliotecas de clases y otros componentes reutilizables. – Hay un alto grado de iteración y solapamiento, lo que lleva a una forma de trabajo muy dinámica.
• Desarrollo iterativo e incremental.
EJERCICIOS Ejercicio 1 ¿Qué factores influyen a la hora de elegir un ciclo de vida para resolver un problema dado? ¿Qué ciclo de vida elegiría para resolver un problema que se comprende bien desde el principio y está muy estructurado? Una vez elegido el ciclo de vida, ¿qué procesos escogería para dicho ciclo de vida, teniendo en cuenta que el desarrollo informático para resolver el problema anterior lo realiza una única persona?
EJERCICIOS
Ejercicio 2 Se supone que se va desarrollar una aplicación relativa a la gestión de pedidos de una empresa. En este caso el cliente no tiene todavía muy claro qué es lo que quiere. Además, el personal informático va a utilizar un tecnología que le resulta completamente nueva. Discútase qué tipo de ciclo de vida es más apropiado y qué procesos se deberían utilizar para desarrollar esta aplicación.
EJERCICIOS Ejercicio 3 Indicar la(s) respuesta(s) correcta(s) y razonar la respuesta: El ciclo de vida: a) Comienza con una idea o necesidad que satisfacer y acaba con las pruebas satisfactorias del producto. b) No existe ningún estándar que describa sus procesos y actividades. c) No se trata sólo de realizar el análisis, diseño, codificación y pruebas; también incluye, entre otros, procesos de soporte. d) El mantenimiento lo constituyen las actividades para mantener sin cambios el sistema. e) En la actividad de análisis de los requisitos software los desarrolladores obtienen de los futuros usuarios los requisitos que piden al sistema.