Unidad 1

Instituto Tecnológico de Tuxtepec

Introducción a la reingeniería del software D.R.©

Reingeniería del software

UNIDAD 1

Introducción a la reingeniería del software

Presentadora: M.C. María Luisa Acosta Sanjuán



Objetivo general de la asignatura

• Reflexionar sobre situaciones reales en torno a la construcción de software y cómo afrontarlas para garantizar la calidad del software desarrollado, entendiendo que un software de calidad, no tan sólo hace lo que tiene que hacer, sino que también se tiene que desarrollar en el tiempo y presupuesto establecidos, dando total satisfacción al cliente.



UNIDAD 1. Introducción a la Reingeniería del

software.

• OBJETIVO EDUCACIONAL

• El estudiante Identificará la función de la

reingeniería del software y ¿el porqué de su

utilización?, sus costos y beneficios.



UNIDAD 1. Introducción a la Reingeniería del

software. 1.1 Definición de reingeniería del software.

1.1.1 Crisis del software

1.2 Sistemas de información heredados

1.2.1 ¿Por qué aplicar la reingeniería del software?

1.2.2 ¿Qué implica la reingeniería?

1.2.3 Herramienta que utiliza la reingeniería

1.2.4 ¿Cómo se hace una reingeniería?

1.3 Costes y beneficios de la reingeniería

1.3.1 Justificación del proyecto de reingeniería.

1.3.2 Análisis de la cartera de aplicaciones.

1.3.3 Estimación de costes.

1.3.4 Análisis de costos/beneficios.



Criterios de Evaluación

CRITERIOS VALOR

Asistencia 5%

Ensayo sobre la reingeniería del software: función y beneficio de la reingeniería del software

25%

Video sobre los mitos del software 15%

Anteproyecto de reingeniería 25%

Elaboración del blog 10%

Examen escrito 20%



1.1 Definición de reingeniería del

software.

• La reingeniería del software es la tecnología

que surge de aplicar las técnicas de Ciencias

de la computación y matemática sofisticada al

análisis automatizado y modificación del

código fuente de programas, para abreviarlo

y hacerlo más eficiente.




software.

• La Reingeniería consiste en la automatización del mantenimiento del software.

• Es el proceso de examinar sistemas de software existentes y/o modificarlos con ayuda de herramientas de forma automática o semi-automática.

• Analiza sistemas existentes para entender su diseño y desarrollar estrategias para extraer y reutilizar componentes. Implica la rehabilitación y modernización de los componentes.




software.

• La reingeniería del software se refiere a la reimplementación de los sistemas heredados para hacerlos más mantenibles.

• La reingeniería puede implicar redocumentar el sistema, organizar y reestructurar el sistema, traducir el sistema a un lenguaje de programación más moderno, y modificar y actualizar la estructura y valores de los datos del sistema. (Sommerville)




software.

• Hacer reingeniería de un sistema de software tiene

dos ventajas clave sobre aproximaciones más

radicales a la evolución del sistema:

• Riesgo reducido.

• Coste reducido.




software.

Riesgo reducido.

• Existe un alto riesgo en volver a desarrollar software crítico para los negocios.

• Pueden cometerse errores en la especificación, o puede haber problemas en el desarrollo.

• Los retrasos en la introducción del nuevo software pueden significar pérdidas en el negocio e incurrir en costes adicionales.




software.

Coste reducido.

• El coste de hacer reingeniería es

significativamente menor que el coste de

desarrollar nuevo software



ACTIVIDAD 1

• Ensayo sobre la reingeniería del software:

función y beneficio de la reingeniería del

software.

Valor 25%



1.1.1 Crisis del software.

• El término “crisis del software” se acuñó en 1968, en la primera conferencia organizada por la OTAN sobre desarrollo de software y con él se etiquetaron los problemas que surgían en el desarrollo de sistemas de software.



1.1.1 Crisis del software.

• El término se adjudica a F. L. Bauer, aunque previamente había sido utilizado por Edsger Dijkstra en su obra The Humble Programmer.

• Básicamente, la crisis del software se refiere a la dificultad para escribir programas libres de defectos, fácilmente comprensibles, y que sean verificables.

http://es.wikipedia.org/wiki/Edsger_Dijkstra





1.1.1. Crisis del software

Algunos “síntomas” que indican que el software se encuentra en un periodo de crisis son:

• Baja calidad del software.

• Tiempo y presupuesto excedido.

• Confiabilidad cuestionable.

• Altos requerimientos de personal para desarrollo y mantenimiento.




… Síntomas:

• A menudo el software es imposible de mantener, carece de trasparencia y no se puede modificar ni mejorar.

• Falta de adaptabilidad

• Escasa portabilidad

• Carencia de documentación.




Posibles causas de la crisis del software:

• Proyectos gestionados con un sobre-presupuesto.

• Proyectos gestionados con sobre tiempo.

• Software de baja calidad.

• El software a menudo no satisfacía los requerimientos deseados.

• Los proyectos fueron inmanejables, con un código difícil de mantener




Mitos del software

• Los de gestión

• Los del cliente, y

• Los del desarrollador



MITOS DE GESTION:

MITO:

• Tenemos ya un libro de estándares y

procedimientos el cual proporciona todo

lo que mi gente necesita saber.

REALIDAD:

• Existe pero ¿Se Usa?

• ¿Conocen los trabajadores su existencia?

• ¿Refleja lo actual en desarrollo de

software? ¿Es completo?



MITO:

• Mi gente dispone de las

herramientas de desarrollo de

software más avanzadas, después

de todo, les compramos las

computadoras más modernas.

REALIDAD:

• No solo la PC más grande y mejor

te determina el software a realizar.

• Es más importante las herramientas

de Software (CASE) que el

hardware en sí para calidad y

productividad de Software.



MITO:

• Si fallamos en la planificación,

podemos añadir más

programadores y adelantar el

tiempo perdidos (Efecto de Horda

Mongolia).

REALIDAD:

• El proceso de desarrollo no es una

actividad mecánica.

• Tardará más la gente nueva en

comunicarse y adaptarse al

proyecto.

• Se puede añadir gente de manera

planificada y coordinada.



MITOS DEL CLIENTE:

MITO:

• Una declaración general de los objetivos es

suficiente para comenzar a escribir los

programas- podemos dar los detalles más

adelante.

REALIDAD:

• Una mala definición al inicio es la principal

causa de trabajar en balde en software.

• Es esencial una descripción formal y detallada

del ambiente de la información, funciones,

comportamiento, rendimiento, interfaces,

ligaduras del diseño y criterios de validación.



MITO:

• Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el SW es flexible.

REALIDAD:

• Los requisitos cambian y el impacto del cambio varía según el momento del cambio:

– Impacto 1x en Definición, 1.5 a 6x

en desarrollo, 60 a 100x después de la entrega



MITOS DEL DESARROLLADOR:

MITO:

• Una vez que escribimos el programa

y hacemos que funcione, nuestro

trabajo ha terminado.

REALIDAD:

• 60 a 80% de dedicación a un

programa se realiza después de

entregado al cliente.



MITO:

• Hasta que no tenga el programa ejecutándose, realmente no tengo forma de comprobar su calidad.

REALIDAD:

• Desde el principio debe aplicarse la REVISIÓN técnica formal; con ella se encuentran los defectos / errores.



MITO:

• Lo único que se entrega al terminar

el proyecto es el programa

funcionando.

REALIDAD:

• El programa es sólo una parte de los

elementos del software.

• La documentación proporciona el

fundamento para un buen desarrollo.

• Proporcionar guías para la tarea de

mantenimiento.



De forma general, estos mitos son:

• Ya tenemos el mejor libro para construir software,

• Lo ultimo en computadora para desarrollar,

• Poco importa la planificación,

• Sólo basta conocer el problema de forma general,

• Si requiere un cambio el sistema el software fácilmente lo hará,

• Hasta que se ponga en uso el programa se ve la calidad de este,

• Sólo es necesario entregar el programa funcionando.




No hay crisis pero es un problema crónico

• Después de 35 años la llamada “crisis” del software persiste.

• Los problemas mas importantes siguen siendo los mismos.

– Baja calidad (correcciones, usabilidad, mantenimiento, etc)

– Sobre costos

– Entregas tardías

• Las cosas no se entregan completamente terminadas

• No es una crisis pero es un problema crónico, con la cual la Ingeniería de Software tiene que lidiar.



Actividad 2

Video sobre los mitos del software.

Valor 15%



Fuentes consultadas

1. http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html

2. http://eclases.tripod.com/id11.html

3. http://www.itlalaguna.edu.mx/academico/carreras/sistemas/ingsofware1/Unidad1.pdf

4. Dr. Francisco José García Peñalvo. Ingeniería del Software. http://ocw.usal.es/ensenanzas-tecnicas/ingenieria-del-software/contenidos/Tema1-IntroduccionalaIS-1pp.pdf

5. Sommerville, I. “Ingeniería del Software”. 7ª Edición, Addison-Wesley. 2005

http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html

http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html

http://eclases.tripod.com/id11.html

http://www.itlalaguna.edu.mx/academico/carreras/sistemas/ingsofware1/Unidad1.pdf

http://www.itlalaguna.edu.mx/academico/carreras/sistemas/ingsofware1/Unidad1.pdf

http://ocw.usal.es/ensenanzas-tecnicas/ingenieria-del-software/contenidos/Tema1-IntroduccionalaIS-1pp.pdf











Unidad 1

Documents

Transcript of Unidad 1