Unidad V: Temas Avanzados de Ingeniería de Software

Transcripción

1 Unidad V: Temas Avanzados de Ingeniería de Software Milton J. Narváez Universidad Don Bosco 01 de Noviembre de 2014

2 AGENDA 5.1. Desarrollo rápido de aplicaciones (RAD) 5.2. Ingeniería de software auxiliada por computadora (CASE) 5.3. Reutilización del software 5.4. Diseño orientado a objetos y UML 5.5. Sistemas heredados 5.6. Cambios en el software 5.7. Reingeniería de software 5.8. Ingeniería de software basada en componentes 5.9. Ingeniería de software basada en agentes Ingeniería de la web

3 INTRODUCCION Las compañías gastan mucho dinero en sistemas informáticos y, para obtener un beneficio de esa inversión el software o el hardware debe utilizarse por varios años. El tiempo de vida de los sistemas informáticos es muy variable, pero muchos sistemas grandes se pueden llegar a utilizarse hasta por más de 20 años. Muchos de estos sistemas antiguos aún son importantes para sus respectivos negocios, es decir, las empresas cuentan con los servicios suministrados por estos sistemas y cualquier fallo en estos servicios tendría un efecto serio en el funcionamiento de la organización.

4 5.1. Desarrollo rápido de aplicaciones (RAD) El Desarrollo Rápido de Aplicaciones (Rapid Application Development, RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. RAD es una adaptación a alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso RAD permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de tiempo.

5 5.1. Desarrollo rápido de aplicaciones (RAD)

6 5.2. Ingeniería de software auxiliada por computadora (CASE) Las herramientas CASE (Ingeniería de Software Asistida por Computadora, Computer Aided Software Engineering) participan en el modelado de funciones de proyectos, flujos de información, entidades de datos y otra información de acuerdo a los requerimientos propuestos del sistema. Las herramientas CASE ayudan a facilitar el proceso de planeación. Las herramientas CASE son consideradas como una mejor manera de diseñar diagramas y también como una forma de almacenar el trabajo de desarrollo de un sistema en un repositorio.

7 5.2. Ingeniería de software auxiliada por computadora (CASE)

8 5.3. Reutilización del software

9 5.4. Diseño orientado a objetos y UML

10 5.5. Sistemas heredados Un sistema heredado (o sistema legacy) es un sistema informático (equipos informáticos o aplicaciones) que ha quedado anticuado pero continúa siendo utilizado por el usuario (típicamente una organización o empresa) y no se quiere o no se puede reemplazar o actualizar de forma sencilla. Reemplazar un sistema heredado es una estrategia de negocios arriesgada por varias razones: Rara vez existe una especificación completa de los sistemas heredados (no existe ninguna forma directa de especificar un nuevo sistema que sea funcionalmente idéntico al sistema que se utiliza). Los procesos de negocios y las formas en que los sistemas heredados operan a menudo están intrincadamente entrelazados. Estos procesos se diseñaron para aprovechar los servicios del software y evitar sus debilidades.

11 5.5. Sistemas heredados Las reglas de negocio importantes están contenidas en el software y no suelen estar anotadas en ningún documento de la empresa (por ejemplo, las reglas para valorar el riesgo de la aplicación de una política de una compañía de seguros pueden estar contemplados en su software. Si a estas reglas no se les da mantenimiento, la compañía puede aceptar políticas de riesgo altas que conduzcan a costosas reclamaciones). El desarrollo de nuevo software es por sí mismo arriesgado, ya que pueden existir problemas inesperados. Puede ser, por ejemplo, que no se entregue a tiempo con el precio previsto.

12 5.6. Cambios en el software Cambio de software Mantenimiento de software Transformación arquitectónica Reingeniería de software El mantenimiento de software es una de las actividades más comunes en la Ingeniería de Software y es el proceso de mejora y optimización del software desplegado (es decir; revisión del programa), así como también corrección de los defectos. Tipos de mantenimiento Perfectivo Evolutivo Adaptativo Correctivo

13 5.6. Cambios en el software Cambio de software Mantenimiento de software Transformación arquitectónica Reingeniería de software La transformación arquitectónica es un enfoque más radical para cambiar el software y continuar dándole mantenimiento conforme se implementan cambios más importantes en la arquitectura del sistema de software. Comúnmente, los sistemas evolucionan de una arquitectura de datos centralizada a una cliente servidor. Existen varios conductores diferentes que contribuyen a este cambio: Los costos de hardware. Las expectativas de la interfaz de usuario. El acceso distribuido a los sistemas.

14 5.6. Cambios en el software Cambio de software Mantenimiento de software Transformación arquitectónica Reingeniería de software La reingeniería de software es un proceso que consiste en reorganizar y modificar sistemas de software existentes para el perfeccionamiento del software; axial como para hacerlos mas mantenibles, propiciando su evolución. Durante el proceso de reingeniería se reestructura y rescriben partes o la totalidad de un sistema pero sin cambiar su funcionalidad. La reingeniería seria entonces cualquier actividad que mejora la comprensión del software y prepara o mejora el propio software, normalmente para incrementar su facilidad de mantenimiento, reutilización o evolución. La reingeniería produce el nuevo código fuente del software sin cambiar la función del sistema global.

15 5.7. Reingeniería en el software Procesos involucrados en la reingeniería La reingeniería debe ser entendida como un proceso mediante el cual se mejora un software existente haciendo uso de técnicas de ingeniería inversa y reestructuración de código. En este proceso juega un papel importante el uso de repositorios para almacenar los resultados de la ingeniería inversa y las herramientas case

16 5.7. Reingeniería en el software Procesos involucrados en la reingeniería Análisis de inventario Consiste en el estudio de la antigüedad, importancia de la aplicación en el negocio y la mantenibilidad actual, entre otros criterios, para estudiar la posible conveniencia de la reingeniería. Reestructuración de documentos Evitar la documentación de los módulo estáticos que no van a sufrir cambios. Documentar sólo lo que se va a modificar. Documentar toda la información del sistema, si es que este es fundamental para el negocio. Ingeniería inversa En este proceso se extraen modelos de alto nivel de abstracción que ayuden a la comprensión de la aplicación para poder modificarla y que sirvan como punto de partida para el siguiente proceso. Estos datos se deben almacenar en un repositorio que permita que las personas o herramientas case que lleven a cabo los siguientes pasos lo encuentren disponible.

17 5.7. Reingeniería en el software Cuándo aplicar la reingeniería Cuando una aplicación de cierto sistema ha funcionado durante varios años, y al paso del tiempo se ha vuelto inestable debido a las correcciones, adaptaciones y mejoras que se le realizaron. Es aplicable cuando alguna de las partes de un gran sistema requiere un mantenimiento frecuente. Cuando los cambios en el sistema se hacen mayormente sobre una parte de un sistema, entonces dicha parte puede ser objeto de reingeniería. Cuando el soporte hardware o software se queda obsoleto. Cuando se dispone de herramientas automáticas para reestructurar el sistema.

18 5.7. Reingeniería en el software Cuándo aplicar la reingeniería

19 5.7. Reingeniería en el software Proceso de ingeniería inversa La ingeniera inversa es el proceso de recuperación del diseño (arquitectónico y de procesos) y especificación de un software, analizándolo para crear una representación del software de mayor nivel de abstracción que el código fuente. La funcionalidad del software no cambia. Puede usarse como parte del proceso de reingeniería o también puede utilizarse para re-especificar el sistema para su re-implementación. La ingeniería inversa no es lo mismo que reingeniería. El objetivo de la primera es derivar el diseño o la especificación de un sistema a partir del código fuente. El objetivo de la reingeniería es producir un sistema nuevo mas mantenible.

20 5.7. Reingeniería en el software Proceso de ingeniería inversa Cuando utilizar la ingeniería inversa a) Cuando el sistema falla continuamente y sus fallas son difíciles de situar. b) Cuando los sistemas tienen una eficiencia menor a la esperada pero tienen los resultados deseados. c) Cuando los sistemas dificultan la interacción con otros sistemas. d) Cuando sea poco factible realizar modificaciones. e) Cuando hay pocas personas que son capases de mantener o modificar el sistema. f) Cuando el mantenimiento consume muchos recursos.

21 5.7. Reingeniería en el software Proceso de ingeniería inversa

22 5.8. Ingeniería de software basada en componentes La ingeniería de software basada en componentes (CBSE) (también conocida como desarrollo basado en componentes (CBD)) es una rama de la ingeniería de software que enfatiza la separación de asuntos (separation of concerns (SoC)) por lo que se refiere a la funcionalidad de ámplio rango disponible a través de un sistema de software dado. Es un acercamiento basado en la reutilización para definir, implementar, y componer, componentes débilmente acoplados en sistemas. Esta práctica apunta traer igualmente un ámplio grado de beneficios tanto en el corto como el largo plazo, para el software en sí mismo, y para las organizaciones que patrocinan tal software.

23 5.8. Ingeniería de software basada en componentes Un componente de software individual es un paquete de software, un servicio web, o un módulo que encapsula un conjunto de funciones relacionadas (o de datos). Todos los procesos del sistema son colocados en componentes separados de tal manera que todos los datos y funciones dentro de cada componente están semánticamente relacionados (justo como con el contenimiento de clases). Debido a este principio, con frecuencia se dice que los componentes son modulares y cohesivos. Con respecto a la coordinación a lo largo del sistema, los componentes se comunican uno con el otro por medio de interfaces. Cuando un componente ofrece servicios al resto del sistema, éste adopta una interface proporcionada que especifica los servicios que otros componentes pueden utilizar, y cómo pueden hacerlo. Esta interface puede ser vista como una firma del componente - el cliente no necesita saber sobre los funcionamientos internos del componente (su implementación) para hacer uso de ella. Este principio resulta en componentes referidos como encapsulados.

24 5.8. Ingeniería de software basada en componentes

25 5.9. Ingeniería de software basada en agentes Los sistemas basados en agentes (SBA) son una disciplina relativamente nueva. Ha tenido un crecimiento importante a nivel de contribuciones científicas. Un agente es un software (o hardware) que está situado en un ambiente y es capaz de actuar autónomamente para cumplir los objetivos para lo que fue diseñado.

26 5.9. Ingeniería de software basada en agentes Un Sistema Multiagente o Sistema Basado en Agentes (SBA) se caracteriza por ser un sistema en el que hay un número de agentes autónomos que habitan (o comparten) un medio ambiente común y que se ven en la necesidad de interactuar por una variedad de razones.

27 5.9. Ingeniería de software basada en agentes

28 5.10. Ingeniería de la web La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en la World Wide Web. La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web está ocasionando un impacto en la sociedad y el nuevo manejo que se le está dando a la información en las diferentes áreas en que se presenta ha hecho que las personas tiendan a realizar todas sus actividades por esta vía.

29 5.10. Ingeniería de la web

30 5.10. Ingeniería de la web

31 La felicidad humana generalmente no se logra con grandes golpes de suerte, que pueden ocurrir pocas veces, sino con pequeñas cosas que ocurren todos los días Benjamin Franklin ( ) 1790) Estadista y científico estadounidense. Milton J. Narváez Universidad Don Bosco 01 de Noviembre de 2014