Unidad 1: Software y Sistemas

1. Universidad Nacional de la Patagonia San Juan BoscoFacultad de IngenieríaCátedra: Análisis y Diseño de Sistemas Unidad 1: Software y Sistemas

2. Introducción • Actualmente, el software ha superado al hardware como la clave de muchos sistemas basados en computadoras. Tanto si se utiliza la computadora para llevar un negocio, controlar un producto o capacitar un sistema, el software es el factor que marca la diferencia. Lo que diferencia a una compañía de su competidora es la suficiencia y oportunidad de la información dada por el software (y las bases de datos relacionales). • Un sistema puede ser definido como un conjunto interrelacionado de componentes que se ven como un todo y trabajan juntos para realizar una función común o alcanzar un objetivo. Constituye una combinación compleja de recursos tales como seres humanos, materiales, equipos, hardware (HW), software (SW), datos, etc. • Importancia del Software • Durante las tres primeras décadas de la informática, el principal desafío era el desarrollo de hardware, de forma que se redujera el costo de procesamiento y almacenamiento de datos. • Hoy, el problema es diferente. El principal desafío es mejorar la calidad (y reducir el costo) de las soluciones basadas en computadoras, soluciones que se implementan con el software. 2

3. La evolución del Software – Primera Era (1950-1965 aprox.) • Durante los primeros años de desarrollo de las computadoras, el hardware sufrió continuos cambios, mientras que el software se contemplaba simplemente como un añadido. • Existían pocos métodos sistemáticos para la programación. • El desarrollo del software se realizaba virtualmente sin planificación, hasta que los planes comenzaron a descalabrarse y los costos a crecer. • Durante este período se utilizaba la orientación por lotes en la mayoría de los sistemas. • Lo normal era que el HW fuera de propósito general. • El SW se diseñaba a medida para cada aplicación y tenía una distribución relativamente pequeña. • La mayoría del SW se desarrollaba y era utilizado por la misma persona u organización. La misma persona lo escribía, lo ejecutaba y si fallaba, lo depuraba.

4. La evolución del Software – Segunda Era (1965-1975 aprox.) • En la segunda era de la evolución de los sistemas de computadora, la multiprogramación y los sistemas multiusuario introdujeron nuevos conceptos de interacción hombre-máquina. • Las técnicas interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de sofisticación del HW y del SW. • Los sistemas de tiempo real podían recoger, analizar y transformar datos de múltiples fuentes, controlando así los procesos y produciendo salidas en milisegundos en lugar de en minutos. • La segunda era se caracterizó también por el establecimiento del software como producto y la llegada de las casas de SW. El SW ya se desarrollaba para tener una amplia distribución. Todos esos programas tenían que ser corregidos cuando se detectaban fallos, modificados cuando cambiaban los requisitos de los usuarios o adaptados a nuevos dispositivos de HW que se hubieran adquirido. Estas actividades se llamaron mantenimiento de software. • El esfuerzo gastado en el mantenimiento de SW comenzó a absorber recursos en una medida alarmante. Aún peor, la naturaleza personalizada de muchos programas los hacía virtualmente imposibles de mantener. Había comenzado una crisis del software. 4

5. La evolución del Software – Tercer Era (1975-1985 aprox.) • La tercer era se caracteriza por el procesamiento distribuido. • Procesamiento distribuido: varias computadoras, cada una ejecutando funciones concurrentemente y comunicándose con alguna otra. • Incrementó la complejidad de los sistemas informáticos. • Las redes de área local y de área global, las comunicaciones digitales supusieron una fuerte presión sobre los desarrolladores de software. • La tercera era también se caracteriza por la llegada y el amplio uso de los microprocesadores y las computadoras personales. • El hardware de las computadoras se ha convertido rápidamente en un producto estándar, mientras que el software que se suministre con ese hardware, es lo que marca la diferencia. 5

6. La evolución del Software – Cuarta Era (1985-2000 aprox.) • La cuarta era del software está empezando ahora. • Las tecnologías orientadas a los objetos están desplazando rápidamente a los enfoques de desarrollo de software más convencionales en muchas áreas de aplicación. • Las técnicas de cuarta generación para el desarrollo de software ya están cambiando la forma en que algunos segmentos de la comunidad informática construyen los programas de computadora. • Conforme nos movemos en la Cuarta era, continúan intensificándose los problemas asociados con el SW de computadoras: • La sofisticación del HW ha dejado desfasada nuestra capacidad de construir SW que pueda explotar el potencial del HW. • Nuestra capacidad de construir nuevos programas de aplicación no puede dar abasto a la demanda de nuevos programas. • Nuestra capacidad de mantener programas existentes está amenazada por el mal diseño y el uso de recursos inadecuados. • Como respuesta a la crisis del software, muchas industrias están adoptando prácticas de Ingeniería de software. 6

7. La evolución del Software – Etapa actual (principios del tercer milenio) • Componentes y arquitecturas software reutilizables • Web semántica: Web extendida y basada en el significado, se apoya en lenguajes universales • Computación ubicua: integración de la informática en el entorno de la persona • Interfaces multimodales: es un mismo servicio que se presta independientemente de la terminal por la que se accede • Problemas persistentes en la evolución • El SW nunca explota las posibilidades plenas del HW • El desarrollo del SW no es tan rápido como su demanda • La sociedad depende de las computadoras y necesitamos SW fiable • Los programas no son escalables ni mantenibles por culpa de diseños pobres y recursos inadecuados • ¿Aumentan estos problemas? 7

8. El Software - Definición • Existen varias definiciones según Pressman, algunas serían: • Instrucciones (programas de computadora) que cuando se ejecutan proporcionan una función y el comportamiento deseado • Estructuras de datos que facilitan a los programas manipular adecuadamente la información • Documentos que describen la operación y el uso de programas • Para poder comprender lo que es el software es importante examinar las características que lo diferencian de otras cosas que los hombres pueden construir. 8

9. El Software – Características • El SW es un elemento del sistema que es lógico, en lugar de físico. Por lo tanto, tiene características considerablemente distintas a las del HW: • El Software se desarrolla, no se fabrica en el sentido clásico • Ambas actividades requieren la construcción de un producto, pero los métodos son diferentes. Los costes del software se encuentran en la ingeniería. • El Software no se estropea, se deteriora • La mayoría del software se construye a medida, en vez de ensamblar componentes existentes. • Según Pressman: • Curva de fallos del Hardware. • Curva ideal de fallos del Software. • Curva real de fallos del Software. 9

10. Estropeado Defectos fabricación Obsolescencia Indice de fallos Tiempo • Curvas de Fallos - Curva de Fallos del HW • La figura siguiente describe para el HW, la proporción de fallos como una función del tiempo. Esa relación, es denominada frecuentemente “curva de la bañera”. 10

11. Defectos fabricación Obsolescencia Indice de fallos Mismo nivel hasta obsoleto Tiempo • Curvas de Fallos (Cont.) - Curva idealizada de fallos del software • El SW no es susceptible a los males del entorno que hacen que el HW se estropee. Por lo tanto, en teoría, la curva de fallos para el SW tendría la forma que muestra la siguiente figura. • Los defectos no detectados harán que falle el programa durante las primeras etapas de su vida. Una vez que se corrigen y suponiendo que no se introducen nuevos errores, la curva se aplana. Esa figura es una gran simplificación de los modelos reales de fallos de SW. Sin embargo la implicación es clara, el SW no se estropea. ¡Pero se deteriora! 11

12. Defectos fabricación Cambio Cambio Cambio Indice de fallos Curva real Obsolescencia Curva ideal • Curvas de Fallos (Cont.) - Curva real de fallos del software • Durante su vida, el software sufre cambios (mantenimiento). • Conforme se hacen los cambios, es bastante probable que se introduzcan nuevos defectos, haciendo que la curva de fallos tenga picos como se ve en la figura. 12

13. Componentes del Software • Las componentes del software se crean mediante una serie de traducciones que hacen corresponder los requisitos del clientecon un código ejecutable en la máquina. • Se traduce un modelo de requisitos (Prototipo) a un diseño. Se traduce el diseño del software a una forma de lenguaje que especifica las estructuras de datos, los atributos procedimentales y los requisitos que atañen al software. La forma en lenguaje es procesada por un traductor que la convierte en instrucciones ejecutables en máquina. • La reusabilidad es una característica importante para un componente de software de alta calidad. Es decir, el componente debe diseñarse e implementarse para que pueda volver a usarse en otros programas diferentes. • Los componentes de software se construyen mediante un lenguaje de programación que tiene un vocabulario limitado, una gramática definida explícitamente y reglas bien formadas de sintaxis y semántica. 13

14. Aplicaciones del software • El SW puede aplicarse en cualquier situación en la que se haya definido previamente un conjunto específico de pasos procedimentales. • Para determinar la naturaleza de una aplicación de SW hay dos factores importantes que se deben considerar: el contenido y el determinismo de la información: • El contenido se refiere al significado y a la forma de la información de entrada y salida. • El determinismode la información se refiere a la predecibilidad del orden y el tiempo de llegada de datos. • Software de Sistemas • El SW de sistemas es un conjunto de programas que han sido escritos para servir a los otros programas. P.e. compiladores, editores y utilidades de gestión de archivos. • Algunas características son: • Fuerte interacción con el HW • Operación concurrente • Recursos compartidos • Gestión de procesos complicada • Estructura de datos complejas 14

15. Software de Tiempo Real • El SW que mide, analiza, controla sucesos del mundo real conforme ocurren, se denomina de Tiempo Real. • Entre los elementos del SW de Tiempo Real se incluyen: • Un componente de adquisiciónde datos que recolecta y da formato a la información recibida del entorno externo • Un componente de análisis que transforma la información según lo requiera la aplicación • Un componente de control/salida que responda al entorno externo • Un componente de monitorización que coordina todos los demás componentes, de forma que pueda mantenerse la respuesta en tiempo real • Algunas características son: • Tiempo de respuesta crítico: magnitud de milisegundos • Interacción directamente con dispositivos físicos y sensores • Requisitos de rendimiento críticos • Programación de bajo nivel • Concurrencia 15

16. Software de Gestión • El procesamiento de información comercial constituye la mayor de las áreas de aplicación de SW. • Algunos ejemplos son: • Proceso de información comercial (nóminas, clientes, inventarios): manejan gran volumen de datos, complejidad de la información • Sistemas transaccionales: soportan las operaciones diarias de un negocio (pedidos, compras, etc.); los requisitos, los datos y el procesamiento se conoce y está bien estructurado • Análisis de datos: Aplicaciones de consultas (query), Datawarehouse (almacenamiento de versiones históricas de entradas a la base de datos, registros de transacciones y datos históricos) • Soporte a la toma de decisiones: herramienta de usuario final, análisis “what – if”, estadísticas, tendencias, etc. • Software de computadoras personales: herramientas de escritorio, SW para ocio, etc. • Aplicaciones Web: SW accedido a través de un browser 16

17. Software de Ingeniería y Científico • El SW de ingeniería y científico está caracterizado por los algoritmos de manejo de números. Van desde la astronomía a la vulcanología. • Algunas características son: • Algoritmos de tratamiento numérico: simulación, estadística, CAD • Diseño de algoritmos y estructuras de datos • Cálculo intensivo • Paralelización • Software Empotrado • Los productos inteligentes se han convertido en algo común en casi todos los mercados de consumo e industriales. • El SW empotrado reside en memoria de sólo lectura y se utiliza para controlar productos y sistemas de los mercados industriales y de consumo. P.e. el control de las teclas de un horno de microondas. 17

18. Software de Computadoras Personales • El mercado del SW de las computadoras personales ha germinado en la tercer era. • El procesamiento de textos • Las hojas de cálculo • Los gráficos por computadora • Entretenimientos • Gestión de bases de datos • Aplicaciones financieras, de negocios y personales • Redes o acceso a bases de datos externas son sólo algunas de cientos de aplicaciones. • Software de Inteligencia Artificial • El software de inteligencia artificial (IA) hace uso de algoritmos no numéricos para resolver problemas complejos para los que no son adecuados el cálculo o el análisis directo. • Algunos ejemplos son: • Sistemas expertos • Reconocimiento de patrones • Demostradores de teoremas 18

19. Crisis del Software • Muchos observadores de la industria han caracterizado los problemas asociados con el desarrollo del SW como una crisis. Sin embargo, lo que realmente tenemos puede ser algo bastante diferente. • Si hablamos de crisis del SW, el término alude a un conjunto de problemas que aparecen en el desarrollo del SW de computadoras. • Cabe aclarar que los problemas no se limitan al SW que no funciona correctamente. • El mal abarca los problemas asociados a: • Cómo desarrollar software • Cómo mantener el volumen cada vez mayor de software existente • Cómo poder esperar mantenernos al corriente de la demanda creciente de software. • Aunque se puede criticar la referencia a crisis, las frases resultan útiles por referirse a verdaderos problemas que se encuentran en todas las áreas del desarrollo del SW. 19

20. Problemas • Los problemas que afligen al desarrollo del software se pueden caracterizar bajo muchas perspectivas diferentes, pero los responsables de los desarrollos de software se centran sobre los aspectos de fondo: • La planificación y estimación de costos son frecuentemente muy imprecisas • La productividad de la comunidad del software no se corresponde con la demanda de sus servicios • La calidad del software no llega a veces a ser aceptable 20

21. Problemas (Cont.) • Tales problemas son sólo las manifestaciones más visibles de otras dificultades del software: • No tenemos tiempo de recoger datos sobre el proceso de desarrollo del software. Sin datos históricos como guía, la estimación no ha sido buena y los resultados previstos muy pobres. Sin una indicación sólida de la productividad, no podemos evaluar con precisión la eficacia de las nuevas herramientas, técnicas o estándares. • La insatisfacción del cliente con el sistema terminado se produce demasiado frecuentemente. Los proyectos de desarrollo del SW se acometen frecuentemente con sólo una vaga indicación de los requisitos del cliente. Normalmente, la comunicación entre el cliente y el que desarrolla el SW es muy escasa. • La calidad del software es normalmente cuestionable. Hemos empezado a comprender recientemente la importancia de la prueba sistemática y técnicamente completa del SW. • El SW existente puede ser muy difícil de mantener. La tarea de mantenimiento del SW se lleva la mayor parte de todo el dinero invertido en el SW. El mantenimiento no se ha considerado un criterio importante en la aceptación del SW. • Todos los problemas pueden corregirse  Enfoque de ingeniería al desarrollo del software, junto con la mejora continua de las técnicas y de las herramientas. 21

22. Causas • Los problemas asociados con la crisis de SW se han producido por el propio carácter del SW y por los errores de las personas encargadas del desarrollo del mismo. • El SW es un elemento lógico y por lo tanto, el éxito se mide por la calidad de una única entidad en vez de por muchas entidades fabricadas. El SW no se rompe. Si se encuentran fallos, lo más probable es que se introdujeran inadvertidamente durante el desarrollo y no se detectaran durante la prueba. Reemplazamos las partes defectuosas durante el mantenimiento, pero tenemos muy pocas piezas de repuesto, incluso ninguna  el mantenimiento incluye normalmente la corrección o modificación de diseño. • Frecuentemente, los responsables del desarrollo del SW han sido ejecutivos de nivel medio y alto, sin conocimiento de SW. Un antiguo axioma de gestión dice: Un buen gestor puede gestionar cualquier proyecto si está dispuesto a aprender nuevas técnicas que pueden utilizarse para medir el desarrollo del proyecto, a aplicar métodos efectivos de control, a ignorar la mitología y a llegar a conocer la tecnología que cambia rápidamente. • Todos nos resistimos al cambio. Sin embargo, es verdaderamente irónico que, mientras el potencial de cálculo (HW) experimenta enormes cambios, la gente de SW, responsable de aprovechar dicho potencial, se oponga a los cambios cuando se discuten y se resista al cambio cuando se introduce. Puede que ésta sea la causa real de la crisis del SW. 22

23. Mitos del Software • Las actitudes y hábitos son difíciles de modificar y, cuando vamos hacia la quinta década del SW, todavía se cree en algunos de los mitos del SW. • Mitos de Gestión • Mito: Tenemos un libro que está lleno de estándares y procedimientos para construir SW. ¿No le brinda a mi gente lo que necesita saber? • Realidad: Está muy bien que el libro exista, pero ¿se usa? ¿Conocen los trabajadores su existencia? ¿Refleja las prácticas modernas de desarrollo de software? ¿Es completo? En muchos casos, la respuesta a todas esas preguntas es NO. • Mito: Nuestra gente dispone de las herramientas de desarrollo de software más avanzadas  les compramos las PC’s más nuevas. • Realidad: Se necesita mucho más que el último modelo de computadora para desarrollar SW de gran calidad. • Mito: Si fallamos en la planificación podemos añadir más programadores y recuperar el tiempo perdido. • Realidad: El desarrollo de SW no es un proceso mecánico. Añadir gente a un proyecto de SW retrasado, lo retrasa aún más. Cuando se añaden nuevas personas, la necesidad de aprender y comunicarse con el equipo puede y hace que se reduzca la cantidad de tiempo gastado en el desarrollo productivo. Puede añadirse gente, pero sólo de una manera planificada y bien coordinada. 23

24. Impacto de Cambio Definición Desarrollo Después de la Entrega • Mitos del Cliente • Mito: Una declaración general de los objetivos es suficiente para comenzar a escribir los programas • Realidad: Una mala definición inicial es la principal causa del trabajo baldío en SW. Es esencial una descripción formal y detallada del ámbito de la información, funciones, rendimiento, interfaces, ligaduras del diseño y criterios de validación. Estas características pueden determinarse sólo después de una exhaustiva comunicación entre el cliente y el analista. • Mito: Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el SW es flexible. • Realidad: Es verdad que los requisitos del SW cambian, pero el impacto del cambio varía según el momento en que se introduzca. 24

25. Mitos del Desarrollador • Mito: Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado. • Realidad: Alguien dijo una vez Cuanto más pronto se comience a escribir código, más se tardará en terminarlo. Entre el 50% y el 70% de todo el esfuerzo dedicado a un programa se realizará después de que se le haya entregado el SW al cliente por primera vez. • Mito: Hasta que no tengo el programa ejecutándose, realmente no tengo forma de comprobar su calidad. • Realidad: Desde el principio del proyecto se puede aplicar uno de los mecanismos más efectivos para garantizar la calidad del SW, la revisión técnica formal. La revisión del SW es un filtro de calidad que se ha comprobado que es más efectivo que la prueba para encontrar ciertas clases de defectos de SW. • Mito: Lo único que se entrega al terminar el proyecto es el programa funcionando. • Realidad: Un programa que funciona es sólo una parte de una configuración del SW que incluye todos los elementos como: el plan, la especificación de requisitos, diseño, estructuras de datos, especificación de prueba. • El reconocimiento de las realidades del SW es el primer paso hacia la formulación de soluciones prácticas para su desarrollo. 25

26. Atributos de un buen producto de SW • Así como los servicios que proveen, los productos de SW tienen un cierto número de atributos asociados que reflejan la calidad de ese software. Estos atributos no están directamente asociados con lo que el software hace. Más bien, reflejan su comportamiento durante su ejecución, en la estructura y organización del programa fuente y en la documentación asociada. • El conjunto específico de atributos que se espera de un sistema de software depende obviamente de su aplicación. Esto se generaliza en el conjunto de atributos que se describe a continuación, el cual tiene las características esenciales de un sistema de software bien diseñado. • Existen diferentes aspectos de calidad: • Interna: medible a partir de las características intrínsecas, como el código fuente • Externa: medible en el comportamiento del producto, como en una prueba. Son los atributos más difíciles, ya que no pueden ser medidos de manera directa. 26

27. Atributos de un buen producto de SW (Cont.) • Factores Externos: Detectados por los usuarios. Son los factores que realmente interesan (objetivo): • Facilidad de mantenimiento: debe poder evolucionar para adaptarse a las necesidades de cambio de los clientes • Confiabilidad: no debe causar daños físicos o económicos en el caso de fallo del sistema. Fiabilidad, seguridad y protección • Eficiencia: capacidad del SW para proporcionar un desempeño apropiado, en relación con la cantidad de recurso utilizado, bajo condiciones establecidas • Usabilidad: Esfuerzo necesario para aprender, operar, preparar entradas e interpretar la salida de un programa. Debe tener una interfaz de usuario apropiada y documentación adecuada • Reusabilidad: capacidad de que un SW pueda utilizarse en un contexto diferente al de su creación • Portabilidad: facilidad de transferir productos SW a diferentes plataformas 27

28. Atributos de un buen producto de SW (Cont.) • Factores Internos: Únicamente percibidos por los desarrolladores. Son un medio para conseguir la calidad externa: • Facilidad de traza • Modularidad • Tolerancia a fallos • Eficiencia de ejecución • Eficiencia de almacenamiento • Legibilidad • Facilidad de expansión • Independencia del sistema y HW • Estandarización de datos y comunicaciones 28

29. Paradigmas de la Ingeniería de Software • El mal que ha infectado el desarrollo del SW no va a desaparecer de la noche a la mañana. • Reconocer los problemas y sus causas y demoler los mitos del SW son los primeros pasos hacia las soluciones. Pero las propias soluciones tienen que: • Proporcionar asistencia práctica a la persona que desarrolla SW • Mejorar la calidad del software • Permitir al mundo del SW mantenerse en paz con el mundo del HW • No existe un único enfoque mejor para solucionar el mal del SW. Sin embargo, podemos conseguir una disciplina para el desarrollo del software  llamada Ingeniería del Software: • Mediante la combinación de métodos completos para todas las fases del desarrollo del SW • Mejores herramientas para automatizar estos métodos • Bloques de construcción más potentes para la implementación del SW • Mejores técnicas para la garantía de calidad de software • Una filosofía predominante para la coordinación, control y gestión 29

30. Ingeniería de software – Definición • La ingeniería del software (IS) surge de la ingeniería de sistemas y de HW. Abarca un conjunto de tres elementos clave: • Métodos • Herramientas • Procedimientos • Estos tres elementos facilitan al gestor controlar el proceso del desarrollo del software y suministrar a los que practiquen dicha ingeniería las bases para construir SW de alta calidad de una forma productiva. • En los párrafos que siguen, examinaremos brevemente cada uno de estos elementos. 30

31. Ingeniería de software – Definición (Cont.) • Los métodos de la ingeniería de software indican cómo construir técnicamente el software. • Abarcan un amplio espectro de tareas que incluyen: • Planificación y estimación de proyectos • Análisis de requerimientos del sistema y del software • Diseño de estructuras de datos, arquitectura de programas y procedimientos algorítmicos • Codificación • Prueba • Mantenimiento • Los métodos de la ingeniería de software introducen frecuentemente una notación especial orientada a un lenguaje o gráfica y un conjunto de criterios para calidad de SW. En resumen el método consiste en: • Formulación del problema • Análisis del problema • Búsqueda de soluciones • Elección de la solución más adecuada • Especificación de la solución 31

32. Ingeniería de software – Definición (Cont.) • Las herramientas de la IS suministran un soporte automático o semiautomático para los métodos. Hoy existen herramientas para soportar cada uno de los métodos mencionados anteriormente. • Los procedimientos de la IS son el pegamento que junta los métodos y las herramientas y facilita un desarrollo racional y oportuno del SW. Los procedimientos definen la secuencia en la que se aplican los métodos, las entregas (documentos, informes, etc.), los controles que ayudan a asegurar la calidad y coordinar los cambios, y las directrices que ayudan a los gestores del SW a evaluar el progreso. • La IS está compuesta por una serie de pasos que abarcan los métodos, las herramientas y los procedimientos antes mencionados. Estos pasos se denominan frecuentemente Paradigmas de la IS. La elección de un paradigma para la IS se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicación, los métodos y herramientas a usar y los controles y entregas requeridos. • El trabajo que se asocia a la IS se puede dividir en tres fases genéricas: Definición, Desarrollo y Mantenimiento. Con independencia del área de aplicación, tamaño o complejidad del proyecto. Cada fase se enfrenta con una o varias cuestiones de las destacadas anteriormente. 32

33. Fases de la IS • La Fase de Definición se centra sobre el qué. Es decir, durante la definición, quien desarrolla el SW intenta identificar qué información ha de ser procesada, qué función y rendimiento se desea, qué comportamiento del sistema, qué interfases van a ser establecidas, qué restricciones de diseño existen, y qué criterios de validación se necesitan para definir el sistema correcto. Aunque los métodos dependen del paradigma, las tareas principales son: ingeniería de sistemas (o de información), la planificación del proyecto de SW y el análisis de los requisitos. • La Fase de Desarrollo se centra en el cómo. Es decir, durante el desarrollo un ingeniero de software intenta definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función como una arquitectura del SW, cómo han de implementarse detalles procedimentales, cómo ha de realizarse la prueba. Las tareas son: diseño del SW, generación de código y prueba de SW. • La Fase de Mantenimiento se centra en el cambio asociado a la corrección de errores (correctivo), a las adaptaciones requeridas a medida que evoluciona el entorno de del software (adaptativo), a cambios debidos a las mejoras producidas por requisitos cambiantes del cliente (perfectivo) y a mejoras en las características internas del producto para hacerlo más mantenible (preventivo). 33

34. Herramientas CASE • Son herramientas que combinan software, hardware y bases de datos de la ingeniería de software para crear un entorno que facilite el desarrollo del software. Ofrecen soporte al proceso SW automatizando algunas de sus actividades. • En cuanto a la clasificación de las herramientas CASE, Sommerville establece que se pueden realizar diferentes clasificaciones en función de diversas perspectivas: • Perspectiva funcional: se clasifican de acuerdo a su función específica en herramientas de planificación, herramientas de soporte, herramientas de documentación, etc. • Perspectiva de proceso: se clasifican de acuerdo a las actividades del proceso SW que soportan. • Perspectiva de integración: se clasifican de acuerdo a cómo se organizan en unidades de integración que ofrecen soporte a una o más actividades del proceso SW. 34

35. Beneficios de las herramientas CASE • Facilitan la verificación y mantenimiento de la consistencia de la información • Facilitan el establecimiento de estándares en el proceso de desarrollo y documentación • Facilitan el mantenimiento del sistema y las actualizaciones de su documentación • Facilitan la aplicación de las técnicas de una metodología • Brindan disponibilidad de funciones automatizadas tales como: obtención de prototipos, generación de código, generación de pantallas e informes, generación de diseños físicos de bases de datos, verificadores automáticos de consistencia • Facilitan la aplicación de técnicas de reutilización y reingeniería • Facilitan la planificación y gestión de los proyectos 35

36. Ciclos de vida del desarrollo de software • El Ciclo de Vida del Desarrollo de software es un proceso por el cual los analistas de sistemas, los ingenieros de software, los programadores y los usuarios finales (stakeholders) elaboran sistemas de información y aplicaciones informáticas. • Para realizar un efectivo análisis de sistemas necesitamos herramientas de modelización  métodos. • Los propósitos de tener un ciclo de vida del proyecto son: • Definir las actividades a realizar en el proyecto de desarrollo del sistema. • Lograr consistencia entre los distintos proyectos de desarrollo en la misma organización. • Proveer puntos de control al administrador del proyecto que lo guíen en la toma de decisiones. 36

37. Tipos de modelos de procesos - Modelo Lineal o Secuencial: Ciclo de Vida Clásico • Han sido ampliamente utilizados: • Ofrecen grandes facilidades a los gestores para controlar el progreso de los proyectos • Proponen un enfoque sistemático, secuencial, para el desarrollo del SW • Comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento • Fases separadas en la especificación y el desarrollo • La filosofía de estos modelos de proceso no es realista: • No se ajusta al proceso de desarrollo de SW • Raramente sigue un flujo secuencial sino que exige diversas iteraciones • No ofrece un soporte adecuado a las técnicas de desarrollo basadas en objetos y componentes 37

38. Tipos de modelos de procesos – Ciclo de Vida Clásico • También llamado modelo en cascada, exige un enfoque sistemático y secuencial del desarrollo del software que comienza en un nivel del sistema y progresa a través del análisis, diseño, codificación, prueba y mantenimiento. • Modelizado a partir del ciclo de vida de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades: • Ingeniería y análisis de sistemas: Debido a que el software es siempre parte de un sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software. La ingeniería y el análisis de sistemas abarca los requisitos globales del sistema con una pequeña cantidad de análisis y de diseño a un nivel superior. 38

39. Tipos de modelos de procesos – Ciclo de Vida Clásico (Cont.) • Análisis de los requisitos del SW: El proceso de recopilación de los requisitos se centra e intensifica especialmente para el SW. Para comprender la naturaleza de los programas que hay que construir, el ingeniero de software debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas. Los requisitos, tanto del sistema como del SW, se documentan y se revisan con el cliente. • Diseño: El diseño de SW es realmente un proceso multipaso que se enfoca sobre cuatro atributos distintos: • La estructura de los datos • La arquitectura del software • El detalle procedimental • La caracterización de la interfaz El proceso de diseño traduce los requisitos en una representación del SW que pueda ser establecida de forma que obtenga la calidad requerida antes de que comience la codificación (SQA). El diseño se documenta y es parte de la configuración del SW. • Codificación: El diseño debe traducirse en una forma legible para la máquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada, la codificación puede realizarse mecánicamente. 39

40. Tipos de modelos de procesos – Ciclo de Vida Clásico (Cont.) • Prueba: Una vez que se ha generado el código, comienza la prueba del programa. La prueba se centra en la lógica interna del software, asegurando que todas las sentencias se hayan probado, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. • Mantenimiento: El SW indudablemente sufrirá cambios después de que se entregue al cliente. Los cambios ocurrirán debido a que se hayan encontrado errores, a que el software debe adaptarse a cambios de entorno externo, o debido a que el cliente requiera ampliaciones funcionales o del rendimiento  El mantenimiento de software aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en vez de a uno nuevo. 40

41. Tipos de modelos de procesos – Ciclo de Vida Clásico - Problemas • Los proyectos reales raramente siguen el flujo secuencial que propone el modelo. Siempre hay iteraciones y se crean problemas en la aplicación del paradigma. • Normalmente es difícil para el cliente establecer al principio explícitamente todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos proyectos. • No estará disponible una versión operativa del programa hasta llegar a las etapas finales del proyecto. Un error importante no detectado hasta que el programa esté funcionando puede ser desastroso. • Los responsables del desarrollo del SW siempre se retrasan innecesariamente, ya que algunos miembros del equipo del proyecto deben esperar a otros para completar tareas dependientes. • Es un modelo monolítico  hasta llegar a las etapas finales del desarrollo no habrá una versión operativa del programa, lo que influye negativamente en el descubrimiento a tiempo de errores o incongruencias en los requisitos. • Consideraciones finales • Tiene un lugar destacado en la IS • Proporciona una plantilla para adecuar otros métodos • Es muy utilizado • Tiene problemas pero es mejor que desarrollar sin guías 41

42. Tipos de modelos de procesos – Ciclo de Vida Estructurado 42

43. Tipos de modelos de procesos – Ciclo de Vida Estructurado (Cont.) • Actividad 1: La encuesta • Empieza cuando el usuario solicita que una o más partes de su sistema se automaticen. Los objetivos son: • Identificar a los usuarios responsables y crear un campo de actividad inicial del sistema. Esto puede comprender la conducción de una serie de entrevistas para determinar qué usuarios estarán comprendidos. • Identificar las deficiencias actuales en el ambiente del usuario. Esto en general comprenderá una lista de funciones que hacen falta o que se están llevando a cabo insatisfactoriamente en el sistema actual. • Establecer metas y objetivos para un sistema nuevo. Esto puede ser una simple lista narrativa que contenga las funciones existentes que deben reimplementarse, las nuevas que necesitan añadirse y los criterios de desempeño del nuevo sistema. • Determinar si es factible automatizar el sistema y, de ser así, sugerir escenarios aceptables. Esto implicará algunas estimaciones bastantes rudimentarias y aproximadas del costo y tiempo necesarios para construir un sistema nuevo, y los beneficios que se derivarán de ello. • Preparar el esquema que se usará para guiar el resto del proyecto. Este esquema incluirá toda la información que se lista anteriormente, además de identificar al administrador responsable del proyecto. También pudiera describir los detalles del ciclo de vida que seguirá el resto del proyecto. 43

44. Tipos de modelos de procesos – Ciclo de Vida Estructurado (Cont.) • Actividad 2: El análisis de sistemas • El propósito principal de la actividad de análisis es transformar sus dos entradas principales, las políticas del usuario y el esquema del proyecto, en una especificación estructurada. • Actividad 3: El diseño de sistemas • La actividad de diseño se dedica a asignar porciones de la especificación a procesadores adecuados y a labores apropiadas dentro de cada procesador. Dentro de cada labor, la actividad de diseño se dedica a la creación de una jerarquía apropiada de módulos de programas y de interfases entre ellos para implementar la especificación creada en el análisis. Además, la actividad de diseño se ocupa de la transformación de modelos de datos de entidad-relación en un diseño de base de datos. • Actividad 4: Implantación ó Implementación • Esta actividad incluye la codificación y la integración de módulos en un esquema progresivamente más completo del sistema final. • Actividad 5: Generación de pruebas de aceptación • La especificación estructurada debe contener toda la información necesaria para definir un sistema que sea aceptable desde el punto de vista del usuario. Por eso, una vez generada la especificación, puede comenzar la actividad de producir un conjunto de casos de prueba de aceptación desde la especificación estructurada. 44

45. Tipos de modelos de procesos – Ciclo de Vida Estructurado (Cont.) • Actividad 6: Garantía de calidad • La garantía de calidad también se conoce como la prueba final o la prueba de aceptación. Esta actividad requiere como entradas datos de la prueba de aceptación generada en la actividad 5 y el sistema integrado producido en la actividad 4. • Actividad 7: Descripción del procedimiento • El resultado es el manual para el usuario. • Actividad 8: Conversión de bases de datos • En algunos proyectos, la conversión de bases de datos involucra más trabajo que el desarrollo de programas de computadora para el nuevo sistema. En otros casos, pudiera no haber existido una base de datos que convertir. En caso general, esta actividad requiere como entrada la base de datos actual del usuario, al igual que la especificación del diseño producida por medio de la actividad 3. • Actividad 9: Instalación • La actividad final es la instalación, sus entradas son el manual del usuario producido en la actividad 7, la base de datos convertida que se creó con la actividad 8 y el sistema aceptado producido por la actividad 6. 45

46. Tipos de modelos de procesos – Modelo V • Es una variación del modelo en cascada que demuestra cómo se relacionan las actividades de prueba con las de análisis y desarrollo. Presenta una implementación ascendente. • Se puede identificar una ventaja principal con respecto al Modelo Cascada, y se refiere a que involucra chequeos de cada una de las etapas del modelo de cascada. • Demuestra que el desarrollo de las pruebas se efectúa de manera síncrona con el desarrollo del programa. Mientras que el modelo clásico centra su atención en los documentos y artefactos producidos, el modelo en V lo hace en la actividad y exactitud. • No contempla la posibilidad de retornar a etapas inmediatamente anteriores, cosa que en la realidad puede ocurrir. • Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclos de desarrollo, lo que disminuye el riesgo. 46

47. Tipos de modelos de procesos – Modelos Basados en Prototipos • Un prototipo es un modelo experimental de un sistema o de un componente de un sistema que tiene los suficientes elementos que permiten su uso. Es una solución parcial que describe la interacción entre el hombre y la máquina, mostrando parte de su funcionalidad no optimizada. Este modelo presenta un componente iterativo que facilita involucrar a los clientes/usuarios en el desarrollo del SW para ayudar a éstos a comprender los requisitos. • Pueden presentar diferentes enfoques en la utilización de los prototipos en el ciclo de vida: • Enfoque desechable: el propósito del prototipo es validar algún aspecto del sistema, sirviendo, como herramienta auxiliar a la especificación de requisitos y el diseño. Este enfoque suele derivar en un modelo lineal una vez que el prototipo ha cumplido su misión. • Enfoque evolutivo: el prototipo se utiliza como alternativa de ciclo de vida. Es la base de los modelos de proceso evolutivos. • Enfoque mixto: conocido como prototipado operativo, combina ambos tipos de prototipos. 47

48. Tipos de modelos de procesos – Ciclo de vida de Prototipos • Un cliente a menudo define un conjunto de objetivos generales para el software pero no identifica los requisitos detallados de entrada, procesamiento o salida. En otros casos, el responsable del desarrollo del software puede no estar seguro de la eficacia de un algoritmo, de la capacidad de adaptación del sistema operativo, o de la forma en que debería tomarse la interacción hombre-máquina. En éstas y en muchas otras situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque. • 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. Entonces aparece un diseño rápido. El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente. El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el usuario/cliente y lo utiliza para refinar los requisitos de SW a desarrollar. La interacción ocurre cuando el prototipo satisface las necesidades del cliente, a la vez que permite que el desarrollador comprenda mejor lo que necesita hacer. • El prototipo puede servir como primer sistema pero se recomienda tirar. 48

49. Tipos de modelos de procesos – Ciclo de vida de Prototipos - Problemas • El cliente ve lo que parece ser una versión de trabajo del software, sin tener conocimiento que es el prototipo y sin saber que con prisa de hacer que funcione, no se ha tenido en cuenta la calidad del software global o la facilidad de mantenimiento a largo plazo. Cuando se le informa que el producto se debe construir otra vez para que se puedan mantener los niveles altos de calidad, el cliente no lo entiende y pide que se apliquen unos pequeños ajustes para que se pueda hacer del prototipo un producto final. De forma demasiado frecuente la gestión de desarrollo de SW es muy lenta. • El desarrollador a menudo hace compromisos de implementación para hacer que el prototipo funcione rápidamente. Se puede utilizar un sistema operativo o lenguaje de programación inadecuado simplemente porque está disponible y porque es conocido. Un algoritmo eficiente se puede implementar simplemente para demostrar capacidad. Después de algún tiempo, el desarrollador debe familiarizarse con estas selecciones, y olvidarse de las razones por las que son inadecuadas. La selección menos ideal ahora es una parte integral del sistema. • Al usuario le desagrada que se deseche código. • Relajación de los desarrolladores. 49

50. Tipos de modelos de procesos – Ciclo de vida de Prototipos – Problemas (Cont.) • Aunque pueden surgir problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería de software. La clave es definir las reglas del juego al comienzo; es decir, el cliente y el desarrollador se deben poner de acuerdo en que el prototipo que se construya para servir como un mecanismo de definición de requisitos. Entonces se descarta, y se realiza la ingeniería del software con una visión hacia la calidad y la facilidad de mantenimiento. 50