Unidad 1

Instituto Tecnológico de Tuxtepec

Reingeniería del software

UNIDAD 1
Introducción a la reingeniería
del software
Presentadora: M.C. María Luisa Acosta
Sanjuán

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


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 25%
la reingeniería del software
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.


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/IngSoftw
are.html
2. http://eclases.tripod.com/id11.html
3. http://www.itlalaguna.edu.mx/academico/carreras/sistem
as/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


Unidad 1

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (16)

Destacado

Destacado (20)

Similar a Unidad 1

Similar a Unidad 1 (20)

Unidad 1