Conceptos bsicos.

Modelo de ciclo de vida: es una visin de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas. Un modelo de ciclo de vida del software: Define las fases primarias esperadas a ser ejecutadas durante esas fases. Describe las fases principales de desarrollo de software. Ayuda a administrar el progreso del desarrollo. Requerimientos de un ciclo de vida: Definicin de objetivos: Define el resultado de proyectos y su papel en la estrategia global. Diseo general: requisitos generales de la arquitectura de la aplicacin. Diseo de detalle: Definicin precisa de cada subconjunto de la aplicacin. Programacin: Implementacin de un lenguaje de programacin para crear las funciones definidas durante la etapa de diseo. Modelo de ciclo de vida en cascada: Se define como una secuencia de fases en la que al final de cada una de ellas se rene la documentacin para garantizar que cumple las especificaciones y los requisitos antes de pasar a la fase siguiente. Etapas : Definicion de requerimientos analisis y diseo del sistema. Implementacion(codificacion) Integracion y pruebas Explotacion y mantenimientos.

Criticas al modelo: No refleja realmente el proceso de desarrollo del software Se tarda mucho tiempo en pasar por todo el ciclo El mantenimiento se realiza en el cdigo fuente Las revisiones de proyectos de gran complejidad son muy difciles Impone una estructura de gestin de proyectos

Ventajas Admite iteraciones (se permite volver a una etapa anterior del proyecto). Planificacin sencilla. Provee un producto de un elevado grado de calidad sin disponer de un personal altamente calificado.

Adecuado si se disponen de todos los requerimientos desde el principio.

Desventajas. Es rgido, poco flexible y con muchas restricciones. La necesidad de conocer todos los requerimientos al comienzo del proyecto. Los resultados no se ven hasta las etapas finales del ciclo. Retardo en la entrega del producto. Casos de uso Cuando se disponen de todos los requerimientos desde el principio (reingeniera). Producto no novedoso o con funcionalidades conocidas. Proyectos complejos fcilmente entendibles. Modelo de ciclo de vida prototipo Este modelo principalmente se lo aplica cuando un cliente define un conjunto de objetivos generales para el software a desarrollarse sin delimitar detalladamente los requisitos de entrada procesamiento y salida, es decir cuando el responsable no est seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la forma en que interacta el hombre y la mquina. Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor manera cul ser el resultado de la construccin cuando los requisitos estn satisfechos. Ventajas del Modelo de Prototipo. Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humano-mquina. Desventajas del Modelo de Prototipo. Su principal desventaja es que una vez que el cliente ha dado su aprobacin final al prototipo y cree que est a punto de recibir el proyecto final, se encuentra con que es necesario reescribir buena parte del prototipo para hacerlo funcional, porque lo ms seguro es que el desarrollador haya hecho compromisos de implementacin para hacer que el prototipo funcione rpidamente. Es posible que el prototipo sea muy lento, muy grande, no muy amigable en su uso, o incluso, que est escrito en un lenguaje de programacin inadecuado. El cliente ve funcionando lo que para l es la primera versin del prototipo que ha sido construido con "plastilina y alambres", y puede desilusionarse al decirle que el sistema an no ha sido construido. El desarrollador puede ampliar el prototipo para construir

el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente. Fases del modelo prototipo. Diseo e incrementacin de un prototipo Ejercicio del prototipo. Refinamiento iterativo del prototipo. Diseo e implementacin del sistema. Criticas El diseo rpido indica muchas veces el utilizar fragmentos de programas ya existentes. No se tienen en cuenta la calidad del software ni su mantenimiento. Ineficiencia de los programas, utilizacin de los recursos, utilizacin de lenguajes inadecuados. Caractersticas No presenta calidad ni robustez. Exige de disponer de las herramientas adecuadas. Reduce el costo y aumenta la probabilidad d costos. No modifica el flujo del ciclo de vida. Para que sea efectivo Debe ser un sistema con el que se pueda experimentar. Debe desarrollarse rpidamente. nfasis en la interfaz del usuario. Equipo de desarrollo reducido. El prototipado evolutivo. - Construccin de una implementacin parcial que cubre los requisitos conocidos para ir aprendiendo del resto y paulatinamente incorporarlos al sistema. - Reduce el riesgo y aumenta la probabilidad de xitos . - No se conoce niveles apropiados de calidad y documentacin. - Problemas de gestin de configuracin. Modelo de ciclo de vida en espiral. Las actividades de este modelo se conforman en un espiral, en la que cada bucle o iteracin representa un conjunto de actividades. Las actividades no estn fijadas a priori sino que las siguientes se eligen en funcin del anlisis de riesgo, comenzando por el bucle interior. Caractersticas En cada giro se construye un nuevo modelo del sistema completo. Este modelo puede combinarse con otros modelos de proceso de desarrollo (cascada, evolutivo). Mejor modelo para el desarrollo de grandes sistemas Es el enfoque ms realista actualmente. Puntos fuertes

Evita las dificultades de los modelos existentes a travs de un acercamiento conducido por el riesgo. Intenta eliminar errores en las fases tempranas. Trabaja bien proyectos complejos, dinmicos e innovadores Puntos dbiles. Falta un da de proceso explicito para determinar objetivos limitaciones y alternativas. Provee ms flexibilidad que la conveniente para la mayora de las aplicaciones. Cuadrantes Planificacin. Anlisis de riesgos. Ingeniera. Evaluacin por el cliente. Cada ciclo comienza identificando: Los objetivos de la correspondiente. Las alternativas. Las correspondientes. Restricciones. Diferencia entre modelo en espiral y modelo tradicional. Reconocimientos explcitos de las diferentes alternativas. Identificacin de riesgos para cada alternativa desde el comienzo. Al dividir los programas en ciclos al final de cada uno existe un acuerdo para los cambios que ah que realizar en el sistema. El modelo se adapta a cualquier tipo de actividad adicional. Modelo evolutivo. En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y slo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementacin parcial del sistema que recibe slo estos requerimientos. El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentacin a los desarrolladores. Ventajas Este modelo acepta que los requerimientos del usuario se pueden cambiar en cualquier momento. Es un modelo es muy til cuando desconocemos la mayora de los requerimientos iniciales o cuando los requerimientos no estn completos. Busca reemplazar el viejo sistema con uno nuevo que tendra la propiedad de satisfacer los nuevos requerimientos lo ms rpido posible. El desarrollo evolutivo es 100% compatible con el modelo cascada. Desventajas Modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.

 El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulacin de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. PROYECTO A QUE ES APLICABLE: Proyecto de ventas Proyecto de Facturacin Proyecto de Mercadeo Modelo concurrente Como el modelo espiral, el modelo concurrente provee una meta-descripcin del proceso software. Mientras que la contribucin primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribucin del modelo concurrente es su capacidad de describir las mltiples actividades del software ocurriendo simultneamente. Modelo incremental El desarrollo incremental es el proceso de construccin siempre incrementando subconjuntos de requerimientos del sistema. Tpicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo. Caractersticas Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. El usuario se involucre ms. Difcil de evaluar el costo total. Difcil de aplicar a los 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.

1. Concepto de Diseo de Software. El diseo es el primer paso de la fase de desarrollo de cualquier producto o sistemas de ingeniera. 2. Ingeniera de Software y Diseo del Software. Resumen. El diseo es la primera de las tres actividades tcnicas: Diseo, Codificacin y Prueba. Cada actividad transforma la informacin de forma que al final se obtiene un software valido. Es tcnicamente la parte central de la ingeniera de software. El diseo da como resultado representaciones cuya calidad pueda ser evaluada. Mediante algunas metodologas se realiza el diseo de datos, arquitectnico y procedimental.

Es la es la nica forma mediante la que podemos traducir con precisin los requisitos del cliente en el producto o sistema acabado. 3. Importancia y proceso del Diseo. Sin diseo, nos arriesgamos a construir un sistema inestable, que falle, cuando se realicen pequeos cambios, que sea difcil de probar y cuya calidad no pueda ser evaluada hasta ms adelante cuando ya quede poco tiempo y se haya gastado mucho dinero. El diseo se realiza en dos etapas: El diseo preliminar se centra en la trasformacin de los requisitos en los datos y la arquitectura del software. El diseo detallado se ocupa del refinamiento y de la representacin arquitectnica 4. Criterios para determinar la calidad del Software. Un diseo debe tener organizacin jerrquica. Debe ser modular, es decir, el software debe estar dividido en elementos que realicen funciones especficas. Debe tener representaciones distintas y separadas de los datos y los procedimientos. Debe llevar a mdulos que exhiban caractersticas funcionales independientes. Debe conducir a interfaces que reduzcan la complejidad exterior. Debe conducir a interfaces que reduzcan la complejidad de las conexiones en los mdulos y el exterior. Debe obtenerse mediante un mtodo que sea reproducible y que este dirigido por la informacin obtenida.

5. Fundamentos del diseo. Los fundamentos ayudan al desarrollador de software a responder ciertas preguntas. Son fundamentos del diseo: abstraccin, refinamiento, modularidad, arquitectura del software, jerarqua de control, estructura de datos, procedimiento del software, ocultamiento de informacin. 6. Abstraccin, Niveles y Tipos. Cuando se considera una solucin modular para cualquier problema pueden formularse varios niveles de abstraccin. En el nivel superior se establece una solucin en trminos generales, en lenguaje natural. En el nivel inferior se utiliza una orientacin ms procedimental. En el nivel ms bajo se establece un solucin de forma que pueda implementarse directamente. Se clasifican en dos tipos:

Una abstraccin de datos. Es un conjunto de datos que describe un objeto. Una abstraccin procedimental. Es una determinada secuencia de instrucciones que tienen una funcin limitada y especifica. 7. Refinamiento. Es una primera estrategia de diseo descendente. La arquitectura de un programa se desarrolla en niveles sucesivos de refinamiento de los detalles procedimentales. 8. Modularidad Que es el software Monoltico? El software se divide en componentes con nombres y ubicaciones determinados, que se denominan MODULOS y que se integrar para satisfacer los requerimientos del proveedor. El software MONOLITICO (Es decir un programa grande compuesto de un solo modulo). No puede ser estudiado fcilmente por un lector, ya que el nmero de caminos de control, el nmero de variables y la complejidad global haran el cdigo prcticamente indescifrable en los datos 9. Como se obtiene la arquitectura de Software Se obtiene mediante un proceso de particin, que relaciona los problemas del mundo real (definidos en el anlisis de requerimientos). Con las soluciones software para resolver los problemas software. 10. Jerarqua de Control. Tambin se lo conoce como estructura del programa y representa la organizacin jerrquica de los mdulos de un programa e implica una jerarqua de control. Se suele representar con diagramas de rbol, pero tambin se pueden usar otras notaciones. 11. Estructura de Datos. Es una representacin de la lgica que existe entre los elementos individuales de la informacin, dicta la organizacin, los mtodos de acceso el grado de asociatividad y las alternativas para el tratamiento de la informacin 12. Que debe proporcionar el procedimiento del software. Una especificacin precisa del procedimiento, incluyendo la secuencia de sucesos, los puntos concretos de decisiones, las repeticiones de operaciones e incluso la organizacin/estructura de los datos. 13. Ocultamiento de Informacin. El principio del ocultamiento de la informacin sugiere que los mdulos deben especificarse de forma que la informacin (procedimientos y datos) contenidos dentro de un mdulo sea inaccesibles a otros mdulos que no necesitan tal informacin. Por tanto trata de definir una serie de mdulos independientes que se comuniquen solo a travs de la informacin necesaria para realizar la funcin del software.

14. Diseo Modular efectivo. Reduce la complejidad. Facilita los cambios. Implementacin ms sencilla Permite el desarrollo de partes diferentes de un sistema. 15. Tipos de Mdulos. Explica c/u. Mdulos Secuenciales: Se ejecutan sin interrupcin aparente por parte del software de la aplicacin, es decir, ejecutan secuencialmente una tarea. Mdulos Incrementales: Tambin se le conoce como co rutina , y pueden ser interrumpida antes de que terminen por el software de la aplicacin y reestablecerse posteriormente su ejecucin en el punto en que se interrumpi. Modulo Paralelo: Se ejecuta a la vez que otro modulo en entornos multiprocesadores. 16. Independencia Funcional, Consecuencias. Es una derivacin directa de la modularidad, de la abstraccin y del ocultamiento de la informacin. La independencia funcional se adquiere desarrollando mdulos con una funcin clara y con pocas relaciones con otros mdulos. Consecuencias. Mdulos independientes fciles de desarrollar. Creacin de interfaces sencillas. Facilidad para la prueba y el mantenimiento Se reduce la programacin de errores. Se fomenta la reutilizacin de mdulos. 17. Diseo de Datos. A que conduce. Es una de las primeras de las tres actividades de diseo realizados durante la ingeniera de software. El impacto de la estructura de programa y la complejidad procedimental, hace que el diseo de datos tenga la influencia en la calidad del software. Conduce a: Mejor estructura de programa, modularidad efectiva, complejidad procedimental reducida. 18. Principios para la Especificacin de Datos. Los principios sistemticos de anlisis aplicados a la funcin y el comportamiento tambin deben aplicarse a los datos. Se deben identificar todas las estructuras de datos y las operaciones que se han de realizar sobre cada uno de ellos.

Debe establecerse y usarse un diccionario de datos ara definir un diseo de los datos y del programa. Se debe posponer las decisiones de diseo de datos de bajo nivel hasta ms adelante en el proceso de datos. La representacin de una estructura de datos solo debe ser conocida por los mdulos que hagan uso directo de los datos contenidos en la estructura. Se debe desarrollar una librera de estructura de datos tiles y de las operaciones que se le pueden aplicar. El diseo de software y el lenguaje deben soportar la especificacin y la realizacin de tipos abstractos. 19. Diseo Arquitectnicos. El objetivo principal es desarrollar una estructura de programa modular y representar las relaciones de control entre los mdulos. Adems mezclar la estructura de programas y la de datos y define las interfaces que facilitan el flujo de los datos a la largo del programa. 20. Diseo Procedimental. Se realiza despus de que se ha establecido la estructura del programa y de los datos. 21. Programacin Estructurada. Las construcciones son secuencias, condicin y repeticin y son fundamentales en la programacin estructurada. Se propusieron para limitar el diseo procedimental del software. 22. Diagrama de Flujo. Explica. Es la representacin grfica que ms se utiliza en el diseo procedimental. Para representar un paso de procedimiento se utiliza cuadro, para una condicin se usa un rombo, y para un flujo de control se usan flechas. 23. Diagrama de Cajas. Explica. Esta notacin surgi del deseo de desarrollar una representacin para el diseo procedimental que no permitiera la violacin de construcciones estructuradas. Se puede crear los diagramas de cajas por capaz en mltiples pginas. Se representa una llamada a un mdulo subordinado mediante una caja con el nombre del mdulo encerrado en la circunferencia. 24. Lenguaje de Diseo de Programacin. Tambin conocido como leguaje estructurado o seudocdigo es un leguaje que utiliza el vocabulario de un lenguaje y la sintaxis de otro. 25. Especificacin del Diseo. mbito. Documento de referencia. Descripcin del diseo Mdulos

Estructura de Datos y Datos globales. Referencias cruzadas para los requisitos Provisiones de prueba Empaquetamiento Notas especiales Apndices.