Diseño de soluciones de Tecnologías de la Información y Comunicación

Transcripción

1 Diseño de soluciones de Tecnologías de la Información y Comunicación D 1. Análisis de modelos tecnológicos: Identificación de las características del modelo tecnológico Selección del modelo tecnológicos D 2. Definición de modelos tecnológicos: Identificación de objetivos y resultados de un modelo tecnológico Elección de modelos tecnológicos acordes a las políticas de la organización Evaluación de la utilidad de modelos tecnológicos

2 Diseño de soluciones de Tecnologías de la Información y Comunicación D 3. Evaluación de modelos tecnológicos: Evaluación de alternativas de modelos tecnológicos viables Elección de modelos tecnológicos con base a las necesidades de la organización D 4. Validación de modelos tecnológicos: Seguimiento del cumplimiento de los requerimientos del cliente Refinamiento del modelo tecnológico

3 Proceso de Software Conjunto de actividades que conducen a la creación de un producto software. Dependen de personas que toman decisiones y juicios. No existe proceso ideal. Para los sistemas críticos, se requiere un proceso de desarrollo muy estructurado. Para sistemas de negocio con requerimientos rápidamente cambiantes, un proceso flexible y ágil probablemente sea más efectivo.

4 Fases de proceso de software Especificación del software Se debe definir la funcionalidad del software y las restricciones en su operación. Es una etapa crítica ya que los errores de esta etapa originan problemas en las demás. Se produce un documento de requerimientos.

5 Fases de proceso de software Diseño e implementación del software Se debe producir software que cumpla su especificación. Proceso de convertir una especificación del sistema en un sistema ejecutable. Es una descripción de la estructura del software, datos del sistema, interfaces entre los componentes y algoritmos utilizados.

6 Fases de proceso de software Validación del software Se debe validar el software para asegurarse que hace lo que el cliente desea. Se utiliza para mostrar que el sistema se ajusta a su especificación. Deben aprobar un proceso de pruebas. Etapas: pruebas de componentes, prueba del sistema, prueba de aceptación.

7 Fases de proceso de software Evolución del software El software debe evolucionar para cubrir las necesidades cambiantes del cliente. En hardware es muy costoso hacer cambios en su diseño. En software se pueden hacer cambios en cualquier momento. El software se cambia continuamente durante su periodo de vida

8 Modelos del Proceso de Software Representación abstracta de un proceso del software. Proceso desde perspectiva particular. Proporciona sólo información parcial no son descripciones definitivas de los procesos del software. Pueden ser extendidos y adaptados para crear procesos más específicos de ingeniería del software. Modelos: El modelo en cascada Desarrollo evolutivo Ingeniería del software basada en componentes

9 Modelos del Proceso de Software Se utilizan para resolver los problemas reales de una industria, un ingeniero del software o un equipo de ingenieros debe incorporar una estrategia de desarrollo que acompañe al proceso, métodos y capas de herramientas. Se selecciona un modelo de proceso para la ingeniería del software según la naturaleza del proyecto y de la aplicación, los métodos y las herramientas a utilizarse, los controles y entregas que se requieren.

10 Modelos del Proceso de Software Todo el desarrollo del software se puede caracterizar como bucle de resolución de problemas en el que se encuentran cuatro etapas distintas: ESTADO ACTUAL DEFINICION DE PROBLEMAS INTEGRACION DE SOLUCIONES DESARROLLO TECNICO

11 Modelos del Proceso de Software ESTADO ACTUAL (STATUS QUO): «representa el estado actual de sucesos». DEFINICIÓN DE PROBLEMAS: identifica el problema específico a resolverse; DESARROLLO TÉCNICO : resuelve el problema a través de la aplicación de alguna tecnología

12 Modelos del Proceso de Software INTEGRACIÓN DE SOLUCIONES: ofrece los resultados (por ejemplo: documentos, programas, datos, nueva función comercial, nuevo producto) a los que solicitan la solución en primer lugar.

13 Modelos del Proceso de Software Independientemente del modelo de proceso que se seleccione para un proyecto de software, todas las etapas podrían coexisten simultáneamente en algún nivel de detalle. Las etapas tratadas anteriormente se aplican igualmente al análisis de una aplicación completa y a la generación de un pequeño segmento de código.

14 Modelo en Cascada (Lineal-Secuencial) Llamado algunas veces «ciclo de vida básico» el modelo lineal secuencial sugiere un enfoque sistemático, secuencial, para el desarrollo del software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.

15 Modelo en Cascada (Lineal-Secuencial) Características: Es el más utilizado. Es una visión del proceso de desarrollo de software como una sucesión de etapas que producen productos intermedios. Para que el proyecto tenga éxito deben desarrollarse todas las fases. Las fases continúan hasta que los objetivos se han cumplido. Si se cambia el orden de las fases, el producto final será de inferior calidad.

16 Modelo en Cascada (Lineal-Secuencial)

17 Modelo en Cascada (Lineal-Secuencial) Análisis de los requisitos del software. Para comprender la naturaleza del (los) programa(s) a construirse, el ingeniero («analista») del software debe comprender el dominio de información del software, así como la función requerida, comportamiento, rendimiento de interconexión.

18 Modelo en Cascada (Lineal-Secuencial) Diseño. se centra en cuatro atributos distintos de programa: estructura de datos, arquitectura de software, representaciones de interfaz y detalle procedimental (algoritmo). Generación de código. El diseño se debe traducir en una forma legible por la máquina. El paso de generación de código lleva a cabo esta tarea. Si se lleva a cabo el diseño de una forma detallada, la generación de código se realiza mecánicamente.

19 Modelo en Cascada (Lineal-Secuencial) Pruebas. Una vez que se ha generado el código, comienzan las pruebas del programa. detección de errores y asegurar que la entrada definida produce resultados reales de acuerdo con los resultados requeridos. Mantenimiento. Una vez terminado el sistema se le debe dar mantenimiento para adaptarlo a las cuestiones cambiantes de la empresa. Suelen haber proyectos que una vez terminados no se les da mantenimiento a estos su vida en producción es mas corta. El mantenimiento también pueden ser implementación de nuevas funciones o corrección de errores que no se detectan en la fase de pruebas.

20 Modelo en Cascada (Lineal-Secuencial) Criticas: 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

21 Modelo en Cascada (Lineal-Secuencial) A menudo es difícil que el cliente exponga explícitamente todos los requisitos. El modelo lineal secuencial lo requiere y tiene dificultades a la hora de acomodar la incertidumbre natural al comienzo de muchos proyectos. El cliente debe tener paciencia. Una versión de trabajo del (los) programa(s) no estará disponible hasta que el proyecto esté muy avanzado.

22 Modelo en Cascada (Lineal-Secuencial) Limitaciones: No se permiten las iteraciones. Los requisitos se congelan al principio del proyecto. No existe un proyecto enseñable hasta el final del proyecto.

23 Modelo en Cascada (Lineal-Secuencial) EJEMPLO Cualquier software en el que la versión se cierra, es decir, se empaqueta y se entrega al cliente final. En el que una actualización implica una nueva versión. Tutorial e-learning (en flash). Software de aplicación como Word, excel, etc. Videojuego. Apps de uso general. Alarmas. Contabilidad. Fotografía.

24 Modelo de Construcción de Prototipos El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición.

25 Modelo de Construcción de Prototipos

26 Modelo de Construcción de Prototipos 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.

27 Modelo de Construcción de Prototipos EL PROTOTIPADO 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

28 Modelo de Construcción de Prototipos El diseño rápido se centra en una representación de aspectos del software que serán visibles para el usuario/cliente (enfoques de entrada y formatos de salida). El diseño rápido lleva a la construcción de un prototipo. En la mayoría de los proyectos, el primer sistema construido apenas se puede utilizar y se tiene que tirar, porque incluso la mejor planificación no es omnisciente como para que esté perfecta la primera vez.

29 Modelo de Construcción de Prototipos La iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer.

30 Modelo de Construcción de Prototipos 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.

31 Modelo de Construcción de Prototipos El cliente ve una versión de trabajo del software, sin saber que con la prisa de hacer que funcione no se ha tenido en cuenta la calidad del software global o la facilidad de mantenimiento a largo plazo. Se puede utilizar un sistema operativo o lenguaje de programación inadecuado simplemente porque está disponible

32 Modelo de Construcción de Prototipos EJEMPLO Cualquier aplicación en la que el cliente desea ver tener idea de cómo quedaría la versión final, se van tomando los requerimiento con base a lo que el cliente retroalimente. Aplicaciones muy visuales y cuando las ideas son frescas. Pagina web informativa. Apps de un negocio. Aplicaciones con realidad aumentada.

33 Modelo DRA El Desarrollo Rápido de Aplicaciones (DRA)es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. Es una adaptación a «alta velocidad» del modelo lineal secuencial en el que se logra el desarrollo rápido utilizando una construcción basada en componentes.

34 Modelo DRA Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un «sistema completamente funcional» dentro de períodos cortos de tiempo (por ejemplo: de 60 a 90 días)

35 Modelo DRA Modelado de Gestión. El flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: Qué información conduce el proceso de gestión? Qué información se genera? Quién la genera? A dónde va la información? Quién la procesa?

36 Modelo DRA Modelado de datos. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos. Modelado del proceso. Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos.

37 Modelo DRA Generación de aplicaciones. En lugar de crear software con lenguajes de programación, trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). Se utilizan herramientas para facilitar la construcción del software.

38 Modelo DRA Pruebas y entrega. Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

39 Modelo DRA EJMEPLO: Aplicaciones en donde se desarrollen proyectos simultáneos con un mismo fin o que sean parte de la mismo software. Desarrollo Orientado a Objetos. Punto de Venta tipo OXXO. Cajero Automático.

40 Modelo en Espiral Es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema diseñado.

41 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

42 Modelo en Espiral 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

43 Modelo en Espiral Se usa en proyectos en los que se prevén riesgos. Representa un enfoque dirigido por el riesgo para el análisis y estructuración del proceso software. Ventajas: Utiliza las fases de modelos tradicionales. Se centra en la eliminación de errores y alternativas poco atractivas. Su orientación a detectar y prevenir el riesgo evita muchas dificultades. Desventajas: Complicado: Consume muchos recursos. Las etapas y sus E/S no están claramente definidas.

44 Modelo en Espiral En modelo en espiral que contiene seis regiones de tareas: Comunicación con el cliente- las tareas requeridas para establecer comunicación entre el desarrollador y el cliente. planificación- las tareas requeridas para definir recursos, el tiempo y otra información relacionadas con el proyecto.

45 Modelo en Espiral análisis de riesgos- las tareas requeridas para evaluar riesgos técnicos y de gestión. ingeniería- las tareas requeridas para construir una o más representaciones de la aplicación. construcción y acción- las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo: documentación y práctica)

46 Modelo en Espiral evaluación del cliente- las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación.

47 Modelo en Espiral EJEMPLO Proyectos en los que hace falta una revisión exhaustiva, proyectos en los que una vez terminados se deben hacer pilotos para poder liberarlos al resto de los clientes. Aplicaciones bancarias y de procesamiento de pagos. Aplicaciones con cero tolerancia a fallos como detección de fraudes.

48 Iterativo Es una repetición de varios ciclos de vida en cascada. Al final de cada ciclo se entrega una versión completa del software mejorada respecto a la anterior. Los ciclos se repiten hasta obtener un producto satisfactorio. Los usuarios deben evaluar el producto en cada iteración y proponer mejoras. Se suele aplicar en desarrollos en los que los requisitos no están claros, las primeras versiones pueden ser prototipos que se desechan posteriormente.

49 Iterativo

50 Incremental

51 Iterativo e Incremental EJEMPLO (INCREMENTAL E ITERATIVO) Software que requiere liberaciones previas a la productiva como pilotaje. Aplicaciones con muchos usuarios que requieren ser revisadas antes de ponerse en producción. Servicios de correo electrónico. Software financiero. Software que implique revisiones previas.

52 Modelo Basado en Componentes Enfatiza la creación de clases que encapsulan tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se diseñan y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadora.

53 Modelo Basado en Componentes

54 Modelo Basado en Componentes EJEMPLO Software reutilizable y modular donde componentes de código pueden utilizarse n veces o adaptarse con base a los requerimientos. Son utilizados por empresas que tienen alta vision de proyectos. Todo se puede ocupar de nuevo. Aplicaciones en donde hay muchos servicos adjuntos y que los dueños de los servicios venden en varios lados. Servicios de tiempo aire. Software integrables. Módulos de lectura de tarjetas bancarias. Módulos de cifrados de datos.

55 Metodologías El conjunto de métodos que se utilizan en una determinada actividad con el fin de formalizarla y optimizarla. Determina los pasos a seguir y cómo realizarlos para finalizar una tarea.

56 Metodologías: Aplicación a la Ingeniería de Software Optimiza el proceso y el producto software. Metodologías que guían en la planificación y en el desarrollo del software. Define qué hacer, cómo y cuándo durante todo el desarrollo y mantenimiento de un proyecto.

57 Metodologías: Aplicación a la Ingeniería de Software Sin metodología Con metodología

58 Metodologías: Elementos Define una estrategia global para enfrentarse con el proyecto: Fases. Tareas a realizar en cada fase. Productos (final e intermedios). E/S de cada fase, documentos. Procedimientos y herramientas. Apoyo a la realización de cada tarea. Criterios de evaluación. Del proceso y producto. Saber si se han logrado los objetivos.

59 Ventajas de los Metodologías Desde el punto de vista de gestión: Facilitar la tarea de planificación. Facilitar la tarea de control y seguimiento de un proyecto. Mejorar la relación coste/beneficio. Optimizar el uso de recursos disponibles. Facilitar la evaluación de resultados y cumplimiento de los objetivos. Facilitar la comunicación efectiva entre usuarios y desarrolladores. Ayuda a la gestión del proyecto.

60 Ventajas de los Metodologías Desde el punto de vista de los ingenieros del software: Ayudar a la comprensión del problema. Optimizar el conjunto y cada una de las fases del proceso de desarrollo. Facilitar el mantenimiento del producto final. Permitir la reutilización de partes del producto.

61 Ventajas de los Metodologías Desde el punto de vista del cliente o usuario final: Garantía de un determinado nivel de calidad en el producto final. Confianza en los plazos de tiempo fijados en la definición del proyecto. Definir el ciclo de vida que más se adecue a las condiciones y características del desarrollo.

62 Ventajas de utilizar Metodologías Determinar las fases dentro del ciclo de vida especificando su orden de ejecución. Definir los resultados intermedios y finales. Proporcionar un conjunto de métodos, herramientas y técnicas para facilitar la tarea del ingeniero del software y aumentar su productividad.