Dpss u3_a2_paov.pptx

ACTIVIDAD 2, PROCESOS DE EVOLUCIÓN DEL
SOFTWARE
Universidad Abierta y a Distancia de México UnADM.
•Asignatura: Pruebas y Mantenimiento de Sistemas de SW.
•Unidad: 3 Mantenimiento de sistemas de software.
•Alumno: Pablo Jonathan Olvera Velázquez.
•Matricula: ES1421000885.
•Docente en línea: Ricardo Rodríguez Nieves
•Grupo: DS-DPSS-1801-B1-001
•Fecha de entrega: 18 de marzo del 2018.

APLICACIÓN DE LAS LEYES DE LEHMAN Y BELADY MEDIANTE LA
DISTINCIÓN DE LAS CATEGORÍAS DE SOFTWARE “PROGRAMAS (S, P, E)”
En sus observaciones Lehman categoriza todos los sistemas de software en tres tipos:
Sistemas de tipo “S” o Estáticos Sistemas de tipo “P” o de tipo práctico Sistemas de tipo “E” o tipo integrado
Se basan en conjuntos de
especificaciones estáticas, formales y
verificables con soluciones fáciles de
entender.
Caracterizados por ser un sistema en el
cual sus especificaciones no cambian,
de ahí el nombre de estático.
Las leyes de Lehman no aplican a estos
sistemas tan simples, por lo tanto no
están sujetos a evolución.
Estos sistemas pueden tener sus requisitos
definidos de manera precisa y formal, pero la
solución no es inmediata ya que depende del
entorno en el que se utiliza el programa.
Se caracterizan por que son desarrollados
iterativamente para mejorar su eficacia.
Los sistemas de este tipo requieren un enfoque
iterativo con el cual se facilita la
retroalimentación para que el usuario entienda
lo que necesita, lo que no, y cómo hacerlo. Aquí
tampoco aplican las leyes de Lehman.
Son los programas que llevan a cabo
procesos que resuelven un problema o
actividad del mundo real, su
implementación es consecuencia directa y
reflejo de los cambios del mundo real y
dinámico.
Es en este tipo de sistemas en donde las
leyes de Lehman sí aplican, pues estos
sistemas mecanizan las actividades
humanas o sociales y se convierten en
parte del mundo que modelan.
Un ejemplo de un sistema tipo S sería:
El programa de calculadora de
Windows, pues ésta realiza cálculos
matemáticos en donde tanto la
operación deseada como la forma de
lograrla son bien entendidas por el
usuario, y es poco probable que
cambien.
Un ejemplo de un programa del tipo P sería:
Un software de juego o videojuego, en donde el
programa te dice qué teclas, o botones
presionar, para hacer una acción, o funciones,
además de que no hacer, y dependerá del
usuario que combinaciones utilizar para lograr
su objetivo.
Un ejemplo de un programa del tipo E
sería:
El sistema de control de tráfico aéreo de
un aeropuerto; sin éste, el trabajo de
controlar la partida segura y la llegada de
vuelos sería imposible, en este ejemplo,
muestra claramente cómo el sistema se
ha convertido en un componente del
mundo real. Si cambian rutas se debe de
actualizar el SW.

ETAPAS DE LA EVOLUCIÓN DEL SOFTWARE (ALFA, MADUREZ, SALIDA), ES LA
PROPUESTA DE EVOLUCIÓN DEL SOFTWARE HECHA POR BENNETT Y RAIJICH.
Todos los programas incluyendo los programas tipo E, se basan en el principio de que todos los
sistemas tienen una versión alfa, una etapa de madurez y una de salida.
Etapa1deevolución
Alfa - Se puede decir que
es el desarrollo inicial del software, y
al finalizar esta etapa se obtendrá el
software terminado y será puesto en
marcha, los errores son corregidos en
esta etapa, lo mismo si se han omitido
características funcionales y no
funcionales del sistema. Aquí se
contemplan cambios futuros.
Los escenarios y casos de estudio son
usados de referencias.
Lo más importante de ésta etapa, es
que durante el desarrollo alfa se
genera un banco de conocimiento que
es importante para la siguiente fase
de evolución.
Etapa2deevolución
Madurez - Es
una etapa que comienza después de
que el sistema ya ha sido puesto en
marcha, comienza cuando los
usuarios detectan fallas, o surgen
necesidades nuevas ya sea del usuario
o en el medio ambiente en que
funciona el sistema, por lo que
estaríamos atendiendo la evolución de
adaptación.
Todo esto se puede corregir en esta
etapa de madurez, tomado en cuenta
los requisitos específicos, los cuales
fueron obtenidos estudiando los casos
o escenarios.
Etapa3deevolución
Salida - Con esta etapa
nos preparamos para cuando el sistema
deje de ser adaptable.
En esta etapa ya no existe soporte
técnico, aunque el sistema siga en
producción.
Es una transición del viejo sistema o
software hacía el nuevo, para que sea
sustituido, apagado o interrumpido.
Esta etapa cuida y planifica la salida de un
sistema, preparando al personal para
recibir al nuevo sistema, y sus
necesidades sigan cubiertas.
Se busca sustituir a tiempo.
Utilizamos reingeniería para identificar
código reutilizable del sistema que va de
salida y adaptarlo al nuevo sistema.

EJEMPLOS GRÁFICOS DE REINGENIERÍA DE SISTEMAS
La reingeniería de software reorganiza y modifica los sistemas de software existentes para facilitar su sostenibilidad o
mantenimiento. Básicamente sería "rehacer" un sistema, pero no desde 0, ya que se enfoca en la conversión del código fuente, en la
reestructuración de los programas y se usa para mantenimiento y evolución del software. Algunos ejemplos de reingeniería de
sistemas son:
El proyecto de administración de dispositivos remotos, usando una
arquitectura central monolítica y el uso de una estructura de base de datos
inconveniente, lo cual causaba problemas de rendimiento y escalabilidad.
Arquitectura del sistema Remote Device Management antes de su
Reingeniería.
Arquitectura del sistema Remote Device Management después de
su Reingeniería.
El uso de nuevas tecnologías (Spring Framework 4, MongoDB, AngularJS y Bootstrap) y la creación de una
nueva arquitectura de sistema no solo aumentó el rendimiento del sistema, sino que también redujo los
términos de desarrollo. Además, el uso de la estructura de datos modificada permite simplificar
significativamente el procesamiento de datos y evitar daños a los datos como resultado de
inconsistencias en las acciones del usuario
Proceso de reingeniería de
sistemas
Otro ejemplo de
reingeniería pero ésta
vez en código:
procedimiento A(var x: w);
begin
b(y, n1);
b(x, n2);
m(w[x]);
y : = x;
r(p[x]);
end;
procedimiento cambiar_ventana(var nw: window);
begin
border(current_window, no_highlight);
border(nw, highlight);
mover_cursor(window[nw]);
current_window : = nw;
resume(process[nw]);
end;
El cambio de nombre de variables y
método muy sencillos a otros más
específicos, ayuda al mantenimiento y
escalabilidad del código, además de que
otros programadores sabrán qué es lo que
hace éste código.

TIPOS DE CAMBIOS
Tipos de cambio subcategorías Ejemplo real
Computacionales
Ecuación
incorrecta o
inexacta
Un ejemplo real podría ser que en un software arquitectónico que haga cálculos sobre
superficies, el problema tenga algunos fallos del tipo computacional de ecuación
inexacta, y esto podría causar grandes problemas al arquitecto, pues en ésta área las
medidas exactas son muy tomadas en cuenta. Por lo tanto se requiere mantenimiento
y el ing. de mantenimiento hará una estimación de esfuerzo enfocada en este tipo de
cambio.
De entrada Formato incorrecto
Puede que nuestro sistema que depende de los archivos generados por otro sistema,
tenga problemas en reconocer documentos que están en otro formato después de que
el otro sistema ha sido actualizado, así que el ing. de mantenimiento también hará la
estimación correspondiente para este tipo de cambio. Pues se necesita un
mantenimiento urgente.
Interfaz
Interfaz de usuario
de software
Puede suceder que haya actualizaciones liberadas que no afectan el funcionamiento,
pero sí la interfaz, el diseño, su visibilidad, y si nuestro software es multiplataforma,
los problemas o bugs pueden afectar únicamente a usuarios de una sola plataforma,
entonces se tiene que dar mantenimiento forzoso al software, para que la interfaz del
software se arregle en todas las plataformas.
Rendimiento
Tiempo limite
excedido
Es cuando algún proceso se ha ejecutado mas que el limite de total que se ha
especificado. Se mide el tiempo total transcurrido (“tiempo reloj”), el tiempo que se ha
estado ejecutando y, en el caso de un proceso interactivo, el tiempo transcurrido
desde que el usuario real realizó su última entrada de datos, puede ser el proceso de
apertura del software, o cuando se cierra el software, incluso al guardar puede
exceder el tiempo límite que se ha fijado. Esto puede ser molesto para el usuario por
lo que debe de entrar en mantenimiento el software y el ing. de mantenimiento
deberá de estimar el esfuerzo para dar mantenimiento basándose en este tipo de
cambio.

CONCLUSIONES
Ahora sabemos qué procesos están disponibles para hacer posible la evolución de un software, primero que
nada, el identificar los tipos de programa de acuerdo a su categoría, en donde los de categoría “E” son los únicos sobre los
que aplican las leyes de Lehman que nos dicen que un sistema debe de evolucionar, ya que si no lo hace está condenado a
desaparecer. También tratamos el tema de las etapas de evolución que tiene el software la cual fue propuesta por Bennett,
la “Alfa” se refiere al sistema desarrollado de principio hasta que es entregado al cliente o puesto en marcha, su etapa de
“Madurez” viene después, se hacen mejoras, ya sean correcciones adaptativas o nuevas funciones, y finalmente, la de
“Salida” ya que se estima que el sistema no puede ser actualizado o su soporte técnico ha concluido, se comienza con la
preparación para la creación de un nuevo sistema para evitar que el negocio colapse porque el software se ha detenido,
además, su desarrollo del nuevo sistema no será desarrollado desde cero, pues utilizaremos del proceso de la reingeniería
(ingeniería inversa), para reutilizar partes del código del viejo programa, y agregar las nuevas adaptaciones o mejoras en el
nuevo sistema. Pero como en todo proceso de desarrollo de software, la evolución debe llevar su proceso, pues antes
debemos de analizar con el equipo de mantenimiento si es viable, y estimar el esfuerzo del mantenimiento basándonos en
la taxonomía de los tipos de cambio del software.
En general fue un tema que me ha fascinado, sobre todo la reingeniería e ingeniería inversa, que bien la hemos
aplicado en nuestros proyectos de software, o por lo menos yo he reutilizado código y lo adapto a otro software con
funciones parecidas, nos queda claro que el proceso de desarrollo del software no termina en el mantenimiento, pues
también tiene que pasar por la madurez hasta alcanzar el grado máximo de evolución y finalmente su salida, que
básicamente es la preparación de su renacimiento como una nueva versión mejorada.

FUENTES DE REFERENCIA
UnADM (15/01/2018) Pruebas y Mantenimiento de Sistemas de Software
Unidad 2. Mantenimiento de sistemas de software.
Recuperado el (del 11 al 15 de marzo 2018)
De (https://unadmexico.blackboard.com/bbcswebdav/institution/DCEIT/2016_S2_B1/DS/08/DPSS/U3/Unidad_3_Mantenimiento_de_sistemas_de_software.pdf)
Ricardo Rodríguez Nieves (3/03/2018) Planeación didáctica-201-B1-S1-U3
Recuperado el (del 15 de marzo 2018)
De (https://unadmexico.blackboard.com/bbcswebdav/internal/courses/DS-DPSS-1801-B1-
001/announcements/_222477_1/Planeaci%C3%B3n%20did%C3%A1ctica-2018-B1-S1-U3.pdf)
Tutorialspoint.com (2017) Resumen de Ingeniería de software
De (http://www.tutorialspoint.com/sp/software_engineering/software_engineering_overview.htm)
Ramin Moazeni, Daniel Link, Barry Boehm (ND) Lehman´s Laws and the productivity of increments
De (http://www-scf.usc.edu/~dlink/idpd%20lehman%20APSEC%202013.pdf)
Larissa Luengas (17 marzo 2014) Reingeniería de software
De (https://prezi.com/stv9fkowp0hj/reingenieria-de-software/)
Vasyl Soloshchuk (29 de enero de 2016) Three Examples of Successful Software Reengineering Implementation.
De (https://www.linkedin.com/pulse/software-reengineering-successful-implementation-vasiliy-soloshchuk-1)
Prof. Mohammad A. Mikki (05/08/2014) Software Maintenance and Evolution
Unit 1: Introduction to maintenance and Reengineering
De (http://slideplayer.com/slide/10814010/)

Dpss u3_a2_paov.pptx

Más contenido relacionado

La actualidad más candente (19)

Similar a Dpss u3_a2_paov.pptx (20)

Último (10)

Dpss u3_a2_paov.pptx