Documentos de Académico
Documentos de Profesional
Documentos de Cultura
INGENIERIA DE SOFTWARE
Modelos - Paradigmas
Cul es el problema a resolver? Cules son las caractersticas de la solucin que se utiliza para resolver el problema? Cmo se realizar la solucin? Cmo se construir la solucin? Qu enfoque se va a utilizar para no contemplar los errores que se cometieron en el diseo y en la construccin de la solucin? Cmo se apoyar la solucin cuando los usuarios soliciten correcciones, adaptaciones y mejoras?
Profesor: Luz Mara Correa Pag. 2
Pag. 1
Productos de Software
Productos genricos
Mantenibles
Productos que son producidos por una organizacin para ser vendidos al mercado.
Debe ser posible que el software evolucione y que siga cumpliendo con sus especificaciones.
Confiabilidad
La mayor parte del gasto del software es en productos genricos, pero hay ms esfuerzo en el desarrollo de los sistemas hechos a medida.
Profesor: Luz Mara Correa Pag. 3
Eficiencia
Utilizacin adecuada
Pag. 4
El Proceso de Software
Las actividades varan dependiendo de la organizacin y del tipo de sistema a desarrollarse Debe estar explcitamente modelado si va a ser bien administrado
Pag. 5
Especificacin de la Prueba
Pag. 6
Es la etapa en la que se determina si el proyecto es o no factible de realizar Se determinan tiempos y costos aproximados, estableciendo as la ruta crtica de cada actividad.
Esto es porque la falta de planeacin de un sistema es la causa principal de retrasos en programacin, incremento de costos, poca calidad, y altos costos de mantenimiento en los desarrollos de productos de software.
Es indispensable comprender perfectamente los requisitos del software, para que ste no fracase. Esta etapa puede parecer una tarea relativamente sencilla, pero las apariencias engaan. Existe una frase que se utiliza al momento de hacer el anlisis, y es la siguiente:
"S que crees que comprendes lo que piensas que he dicho, pero no estoy seguro que lo que creste or sea lo que yo quise decir... Abundan los casos en que se puede llegar a malas interpretaciones o falta de informacin. Especificacin de requerimientos Establecer restricciones del sistema
Con frecuencia se dice que es imposible realizar una planeacin inicial, porque la informacin precisa sobre las metas del proyecto, necesidades del cliente y restricciones del producto no se conocen al comenzar el proyecto de desarrollo, sin embargo, uno de los principales propsitos de esta fase es aclarar los objetivos, problemas o necesidades y restricciones. La dificultad de la planeacin no debe desalentar tan importante actividad.
Profesor: Luz Mara Correa Pag. 7
Pag. 8
Producir un modelo en papel del sistema El diseo del software es realmente un proceso multipaso que se enfoca sobre cuatro atributos distintos del programa:
Estructura de los datos Arquitectura del software Detalle procedimental Caracterizacin de la interfaz
Mantenimiento
Fases Ingeniera SW
Es indudable que el software una vez entregado al cliente sufrir cambios Los cambios ocurrirn debido a que:
posible excepcin es el software empotrado Se hayan encontrado errores Que el software deba adaptarse a posibles cambios del entorno externo El cliente desea ampliar las funcionalidades o el rendimiento del software
El mantenimiento aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en vez de a uno nuevo
Pag. 13
Pag. 14
Tres pasos
Anlisis del sistema Planificacin del proyecto de software (riesgos, recursos, costos, tareas) Anlisis de requisitos (direccin a seguir)
Tres pasos
Diseo del software Codificacin Prueba del software
Pag. 15
Pag. 16
La fase de mantenimiento vuelve a aplicar los pasos de las fases de definicin y de desarrollo, pero en el contexto del software y existente.
Normalmente, las especificaciones son incompletas o anmalas No existe una distincin precisa entre la especificacin, el diseo y la manufactura Slo hasta que el sistema se ha producido se puede probar El software no se puede remplazar siempre durante el mantenimiento
Pag. 17
Pag. 18
Modelos Genricos
Modelo de Codificar-y-Fijar
Prototipado
Separar en distintas fases de especificacin y desarrollo. Un modelo sirve de prototipo para la construccin del sistema final. La especificacin y el desarrollo estn intercalados. Un modelo matemtico del sistema se transforma formalmente en la implementacin. El sistema es ensamblado a partir de componentes existentes.
Modelo bsico usado en los primeros das del desarrollo de software, tiene dos pasos:
(1) Escribir algn cdigo (2) Fijar los problemas en el cdigo
El orden de los pasos era fabricar algn cdigo primero y pensar sobre los requerimientos, diseo, prueba y mantencin a continuacin
Pag. 19
Pag. 20
Modelo de Cascada
Definicin de Requerimientos
Modelo de Cascada
Este modelo divide el ciclo de vida del producto de programacin en una serie de actividades sucesivas;
cada fase requiere informacin de entrada, procesos y resultados, bien definidos
Postula un marco de trabajo claro, que reconoce y define las actividades involucradas en el desarrollo de software, permitiendo establecer relaciones de cooperacin entre ellas. Este es el ciclo de vida clsico y ms antiguo, usado en el desarrollo de productos de software.
Operacin y Mantenimiento
Pag. 21
Pag. 22
Modelo de Cascada
Construccin de Prototipos
El desarrollo de productos de software bajo este ciclo de vida tiene los siguientes problemas:
1. Los proyectos reales raramente siguen el flujo secuencial que propone el modelo. 2. Normalmente, es difcil para el cliente establecer explcitamente al principio todos los requisitos. Este ciclo lo requiere y tiene dificultades en acomodas posibles incertidumbres que pudieran existir al principio. 3. El cliente debe tener paciencia, dado que hasta llegar a las etapas finales del desarrollo no estar disponible una versin operativa del SW.
Un error importante no detectado hasta que el SW est funcionando puede ser desastroso
A pesar de sus inconvenientes, este ciclo de vida sigue siendo el modelo clsico ms ampliamente usado por los ingenieros del software.
Pag. 23
Pag. 24
Construccin de Prototipos
Se inicia con la recoleccin de requerimientos Comienzo El desarrollador y cliente encuentran y definen los objetivos globales, identifican los requisitos Parada conocidos. Luego aparece el Diseo rpido, que est centrado en una representacin de los aspectos del SW que sern visibles para el usuario-cliente. El diseo rpido lleva a la construccin de un prototipo. El prototipo lo evala el cliente-usuario y lo utiliza para refinar los requisitos del SW a desarrollar. Hasta que el prototipo satisface las necesidades del cliente, a la vez que permite que el desarrollador comprenda mejor lo que necesita.
Construccin de Prototipos
Producto de Ingeniera
La construccin de prototipos es un proceso que facilita al programador la creacin de un modelo del software a construir
Curso: Ingeniera de Software Profesor: Luz Mara Correa Pag. 26
Pag. 25
Construccin de Prototipos
El modelo puede tener tres formas: Un prototipo en papel o un modelo basado en PC que describa la interaccin hombre-mquina, de manera que facilite al usuario la comprensin de cmo se producir tal interaccin. Un prototipo que implemente algunos subconjuntos de la funcin requerida del programa. Un programa existente que ejecute parte o toda la funcin deseada, pero que tenga otras caractersticas que deben ser mejoradas en el nuevo desarrollo.
Construccin de Prototipos
Pag. 27
Pag. 28
Construccin de Prototipos
Problemas
Construccin de Prototipos
Problemas
La cuestin no es si hay que construir un sistema piloto y tirarlo. Se tirar. La nica cuestin es si planificar de antemano la construccin de algo que se va desechar.
Profesor: Luz Mara Correa Pag. 29
Cuando se informa al cliente que debe ser reconstruido, el cliente solicita que se apliquen cuantas mejoras sean necesarias para hacer del prototipo un producto final que funcione.
El gestor del desarrollo cede demasiado a menudo.
Pag. 30
Construccin de Prototipos
Problemas
Modelo Evolutivo
El tcnico de desarrollo con tal de obtener un prototipo que funcione rpidamente puede que:
Utilice un sistema operativo o un lenguaje de programacin inapropiados, slo porque ya est disponible y es conocido. Implemente ineficientemente un algoritmo, para demostrar su capacidad.
Combina los elementos del modelo lineal secuencial con la filosofa interactiva de construccin de prototipos El nfasis est puesto sobre un sistema que flexible y expandible
Si los requerimientos cambian durante el desarrollo del sistema, entonces con un mnimo de esfuerzo y tiempo se puede desarrollar un sistema de trabajo flexible
Despus de un tiempo el tcnico puede familiarisarse con estas elecciones y olvidar las razones por las que eran inapropiadas.
La eleccin menos ideal forma ahora parte integral del sistema.
La diferencia fundamental con la construccin de prototipos es que busca reemplazar el viejo sistema con uno nuevo que satisface los nuevos requerimientos lo ms rpido posible.
Profesor: Luz Mara Correa Pag. 32
Pag. 31
Desarrollo Evolutivo
La idea es estar liberando constantemente una nueva versin del sistema que sea completamente funcional; as, cada sistema producto de las iteraciones sucesivas del mtodo tendra incorporado los nuevos requerimientos que ha sido posible identificar y que no estaran considerados en la anterior versin.
Descripcin del sistema
Desarrollo Evolutivo
Problemas
Versin Inicial
Actividades Concurrentes
Especificacin
Poca visibilidad en el proceso Los sistemas estn pobremente especificados Se requieren habilidades especiales
Aplicabilidad
Desarrollo
Versiones Intermedias
Validacin
Versin Final
Pag. 33
Pag. 34
Las actividades se encadenan en una minicascada con un alcance limitado por los objetivos de la iteracin
Anlisis Diseo Codific.
n veces
Pruebas e Integracin
Pag. 36
Cascada
Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseo. Bajo riesgo para desarrollos bien comprendidos utilizando tecnologa conocida. Bajo riesgo para nuevas aplicaciones debido a que las especificaciones y el diseo se llevan a cabo paso a paso. Alto riesgo debido a falta de visibilidad. Alto riesgo debido a la necesidad de tecnologa avanzada y habilidades del grupo desarrollador.
La integracin del nuevo cdigo con lo hecho en iteraciones anteriores se hace gradualmente durante la construccin evaluacin del prototipo en funcin de las pruebas y de los criterios definidos
Prototipo
Preparacin de la entrega
Evolutivo
Pag. 37
Pag. 38
Manejo de Riesgo
Modelo Hbridos
La tarea principal del administrador consiste en minimizar riesgos El riesgo inherente en una actividad se mide en base a la incertidumbre que presenta el resultado de esa actividad Las actividades con alto riesgo causan sobrecostes en cuanto a planeacin y costos El riesgo es proporcional al monto de la calidad de la informacin disponible
Cuanto menos informacin, mayor el riesgo
Los sistemas grandes estn hechos usualmente de varios subsistemas. No es necesario utilizar el mismo modelo de proceso para todos los subsistemas. Los paradigmas pueden combinarse utilizando las ventajas de cada uno en un nico proyecto. No importa como se combinen, siempre se debe empezar por la recoleccin de requisitos, y luego se puede tomar cualquier camino.
Pag. 39
Pag. 40
Modelo Espiral
Planificacin
Recoleccin de requisitos y planificacin del proyecto inicial Planificacin basada en los comentarios del cliente
Modelo Espiral
Anlisis de Riesgos
Anlisis de riesgo basado en los requisitos iniciales
Determine objetivos alternativas y restricciones Anlisis de Riesgos Anlisis de Riesgos Anlisis de Riesgos Anlisis de Proto Riesgos tipo 3 Prototipo 2
Prototipo 3
Prototipo Operacional
REVISIN
Prototipo Inicial
Decisin de seguir o no
Ingeniera
Requeri Diseo Diseo mientos de del Detallado SW Plan de Validacin de Producto Codificacin Desarrollo Requerimientos Prueba de Unidades Plan de Integracin Diseo Prueba de y Prueba V &V Prueba de Integracin Desarrolla y verifica Aceptacin el siguiente nivel Servicio del producto
Pag. 41
Pag. 42
El modelo en Espiral
El modelo en Espiral
Actividades
Cubre las mejores caractersticas tanto del ciclo de vida clsico, como de la creacin de prototipos. Aade el elemento de anlisis de riesgo. En cada ciclo de la espiral el producto de software es cada vez ms sofisticado. En cada etapa de planificacin se producen ajustes al plan del proyecto. Costos y planificacin se ajustan segn la evaluacin del cliente.
Pag. 43
Pag. 44
El modelo en Espiral
Caractersticas
El modelo en Espiral
Caractersticas (continuacin)
Se construyen sucesivas versiones del software, cada vez ms completas. Durante la primera vuelta alrededor del espiral se definen los objetivos, las alternativas, restricciones y se identifican los riesgos. Si el anlisis de riesgo indica que hay una incertidumbre, se puede usar la creacin de prototipos en el cuadrante de ingeniera. Se pueden usar simulaciones y otros modelos para definir ms el problema y refinar los requisitos.
Profesor: Luz Mara Correa Pag. 45
El cliente evala el trabajo de ingeniera y sugiere modificaciones. En base a los comentarios del cliente se produce la siguiente fase de planificacin y de anlisis de riesgo. En cada bucle del espiral, la culminacin del anlisis de riesgo resulta en una decisin de seguir o no seguir. Si los riesgos son demasiado grandes, se puede dar por terminado el proyecto.
Pag. 46
El modelo en Espiral
Caractersticas (continuacin)
El modelo en Espiral
Problemas
En la mayora de los casos se avanza alrededor del espiral llevando a los desarrolladores hacia fuera, hacia un modelo ms completo del sistema, y al final, al propio sistema operacional. Cada vuelta requiere ingeniera, que se puede llevar a cabo mediante el enfoque de ciclo de vida clsico o la creacin de prototipos. El nmero de actividades de ingeniera aumenta al alejarse del centro del espiral. Es el enfoque ms realista.
Profesor: Luz Mara Correa Pag. 47
Puede ser difcil convencer a grandes clientes que el enfoque evolutivo es controlable. Requiere una considerable habilidad para la valoracin del riesgo. Si no se descubre un riesgo importante, indudablemente surgirn problemas. El modelo es relativamente nuevo, no se puede determinar con certeza la eficacia de su uso.
Pag. 48
Prueba
T4G abarca un gran espectro de herramientas de software que tienen algo en comn: todas facilitan, al que desarrolla, la especificacin de algunas caractersticas del software. La herramienta genera automticamente el cdigo fuente basndose en las especificaciones del tcnico. El paradigma se orienta hacia la especificacin del SW a un nivel ms prximo al lenguaje natural o en una notacin que proporcione funciones significativas.
Pag. 49
Pag. 50
Al igual que otros paradigmas, T4G comienza con la recoleccin de requisitos, los que son traducidos directamente a un prototipo operativo. El cliente puede no estar seguro de lo que quiere, puede ser ambiguo en la especificacin o puede ser incapaz de especificarlos en la forma que la herramienta de T4G puede aceptar. Las herramientas actuales de T4G no son lo suficientemente sofisticadas para entender el lenguaje natural.
La implementacin mediante un L4G permite centrarse en la representacin de los resultados deseados. Existen reducciones considerables en el tiempo de desarrollo de aplicaciones pequeas y medianas. Mejora significativa en la productividad de la gente que construye el software. Las herramientas de T4G no son ms fciles de usar que los lenguajes de programacin. El cdigo fuente producido puede ser ineficiente. El mantenimiento de grandes sistemas es cuestionable.
Profesor: Luz Mara Correa Pag. 52
Pag. 51
Combinacin de Modelos
Resumen
Si se puede especificar completamente el sistema al principio se pueden seguir los pasos del ciclo de vida. Si los requisitos son inciertos, se pueden utilizar la construccin de prototipos, y usndolo como gua, se puede volver a los pasos del ciclo de vida. Se puede usar L4G junto con el modelo espiral, en los pasos de creacin de prototipos o de codificacin.
El modelo de cascada considera cada actividad del proceso como una actividad discreta. El modelo de desarrollo evolutivo considera actividades del proceso en forma concurrente. El modelo de espiral se basa en anlisis de riesgos. Adems,
La visibilidad del proceso involucra la creacin de documentos o resultados de las actividades. Los ingenieros de software deben tener responsabilidades ticas, sociales y profesionales.
Pag. 53
Pag. 54