Presentacion del proyecto
View more presentations from Sarai Madrigal.
miércoles, 28 de marzo de 2012
lunes, 26 de marzo de 2012
Metodologias de la Reingenieria
INTRODUCCIÓN
En el siguiente informe vamos a
plantear los métodos y modelos que son utilizados para realizar una buena
reingeniería del software cuya finalidad es la restructuración de sistemas ya
creados.
Se
definirá y explicara el porqué
aplicar el método de análisis de opciones de la
reingeniería (OAR cuyas siglas en ingles Options Analysis For
Reingeneering), así como también las siguientes actividades que la conforman: Establecimiento
de contexto de extracción (ECE), Inventario de componentes (IC), Análisis de
componentes a candidatos (ACC), plan de
opciones de extracción (POE), selección de opciones de extracción (SOE); cada
una de estas actividades conlleva distintas tareas que deben realizar.
Algunos de los modelos que engloba
la parte de este informe y los cuales se explicaran dentro del desarrollo del
mismo son el Modelo herradura y el Modelo cíclico junto con sus respectivas
actividades.
1.
EL
METODO DE ANALISIS DE OPCIONES PARA LA REINGENIERIA (Options Analysis For
Reingeneering (OAR) )
Definición y necesidades de análisis de
opción para la reingeniería.
Es
un método sistemático de arquitectura central y de toma de decisiones para la
identificación y extracción de componentes dentro de amplio y extensos sistemas
del software. OAR identifica componentes de la arquitectura y analiza los
cambios requeridos para usarlos en la creación de nuevos softwares.
Hay
organizaciones que se comprometen actualizar su sistema de software para
establecer formas más eficientes de desarrollo del software.
La
extracción de componentes ha sido una
discusión como una alternativa, pero requiere
entendimiento de tipos de componentes que se debían comprender. Puntos
para motivos al cambio:
·
Componentes existentes casi siempre eran
pobremente estructurados y documentados.
·
Componentes existentes diferían en niveles de
granularidad.
·
No había una guía clara sobre como salvar
componentes.
OAR
proporciona un acercamiento sistemático para direccionar estos puntos y tomar decisiones
requeridas para el costo efectivamente
de extraer componentes de sistemas heredados.
1.2 ACTIVIDADES
PRINCIPALES DEL METODO OAR.
Establecimiento
del contexto de extracción (ECE).
Es importante para OAR entender el contexto
para extracción. La primer actividad de OAR consiste en entrevistar a los
accionistas y estudiar la línea de
producción de la organización. Estos esfuerzos establecen una línea base de un
conjunto de metas, expectaciones y necesidades de componentes.
Inventario
de Componentes (IC).
Después del ECE, la OAR identifica componentes del sistema heredado
que pueden ser extraídos para usarlos en una línea de producción.
En el proceso de esta actividad, lo miembros
del equipo identifican componentes de líneas de producción necesarios y evalúan
los componentes heredados basados en estos criterios. Las actividades del IC son
seis tareas:
1.
Identificar
características de los componentes necesarios:
·
Determina las características requeridas de los
potenciales componentes heredados.
2.
Identifica
las características satisfactorias de los componentes:
·
Crea una
tabla de componentes heredados con detalles de sus características.
·
Filtra los
componentes que no satisfacen las características requeridas.
3.
Compara las
necesidades de los componentes:
·
Compara los
componentes heredados con detalles de sus características.
·
Filtra los
componentes que no satisfacen las características requeridas.
4.
Inventario
de componentes candidatos
·
Actualiza la
tabla de componentes con más detalles de los componentes candidatos
seleccionados.
5.
Produce
tópicos de extracción.
·
Revisa
cualquier tópico de extracción e inquietudes que fueron identificados durante
la actividad.
6.
Revisión del
calendario OAR:
·
Actualiza el
calendario OAR si fuera necesario.
Análisis de componentes candidatos (ACC)
El siguiente paso de los miembros del equipo
es analizar el conjunto de los candidatos de componentes heredados para extraer
los tipos de cambios que son requeridos.
Esta actividad tiene seis tareas:
1. Selección de componentes deseables.
·
Determinar
criterios deseables para cada componente heredado.
·
Deja afuera
aquellos que no satisfacen esos criterios.
2. Identifica los componentes “Tal como están y
de caja negra”.
·
Determinan
aquellos componentes que pueden ser tapados o usados “tal como están.
3. Identifica componentes de caja blanca.
·
Determina
aquellos componentes que necesitarán ser modificados.
4. Determina cambios requeridos
·
Determina
los tipos de cambios que cada componente necesitará, el costo y el esfuerzo
involucrados, el nivel de dificultad y riesgos, el costo y esfuerzo comparativo
para el desarrollo de componentes desde cero.
5. Producción de tópico s de extracción.
·
Revisa
cualquier tópico de extracción e inquietudes que fueron identificado durante la
actividad.
6.
Revisa del
calendario OAR:
·
Actualiza el
calendario OAR si fuera necesario.
Plan de
opciones de extracción (POE)
Teniendo el conjunto de componentes de
candidatos analizados, el equipo desarrolla alternativas para la extracción
basada en consideraciones de calendario, costo, esfuerzo, riego y recursos. POE
tiene siete tareas:
1.
Selecciona
componentes favorables
·
Desarrolla
criterios, tales como el costo o niveles de esfuerzos requeridos.
2.
Ejecución de
intercambio de componentes:
·
Identifica
un componente por línea de producción de componentes necesarios.
3.
Formas
opciones de componentes:
·
Desarrolla
criterios para agregar componentes.
4.
Determina
costos comparativos de esfuerzos:
·
Compara el
costo para cada agregación con el costo a desarrollar desde cero.
5.
Analiza
dificultad o riesgo :
·
Determina el
nivel de dificultad y riesgo involucrados por cada agregación.
6.
Producción
de tópicos de extracción:
·
Revisa
cualquier tópico de extracción e
inquietudes que fueron identificados
durante la actividad.
7.
Revisa del
calendario OAR:
·
Actualiza el
calendario OAR si fuera necesario.
Selección de opciones de extracción (SOE)
Como último paso los miembros del equipo seleccionan la mejor opción de
extracción para programas y
consideraciones técnicas. Una vez terminando de evaluar cada opción de
extracción , preparan un resumen y presenta y justifica sus elecciones.
La actividad SOE tiene cinco tareas:
1. Eligir la mejor opción :
·
Determina
los controladores para seleccionar entre las opciones.
·
Selecciona una opción o combinación de ellas.
2. Verificación de opción:
·
Guarda todos
los detalles acerca de cada de las opciones escogidas.
3. Identifica componentes necesarios satisfechos.
·
Completa la
lista final de componentes necesarios satisfechos y no satisfechos atreves de
las opciones seleccionadas.
4. Presentación de descubrimientos.
·
Prepara la
presentación de descubrimientos que proporciona detalles acerca de las opciones
selecciona
5. Producción de resumen.
·
Producción
de un reporte final ya detallando las opciones seleccionadas y las razones para
esas elecciones.
1.3
Tareas Especializadas.
Las
actividades tienen a su vez un grupo de actividades particulares que guían los
diferentes escenarios que podrían impedir que se cumplan. Existen las
siguientes condiciones para aplicar esas tareas:
·
Actividades
no satisfechas.
·
Se requiere
más trabajo.
·
Se requieren
datos adicionales.
·
Existe
necesidad de completar tareas estándares OAR.
1.4
Estructura de actividades
Las tareas tienen sub-tareas para resolver
cuestiones de actividades específicas. Estas cuestionen definen la actividad y
sirven como puntos para revisar cada actividad.
Formato ¨EITVOX
(Entry Criteria, Inputs, Task, Validation, Outputs, Exit Criteria) ¨ [Berg 01]
2 El modelo herradura
El modelo herradura tiene como base los tres procesos
básicos, análisis de un sistema existente, transformación lógica y desarrollo
de un nuevo sistema. El primer proceso sube al extremo izquierdo de la
herradura, el segundo atraviesa la parte superior y el tercero baja por el
extremo derecho de la herradura. Lo que este modelo muestra son los niveles de
abstracción que pueden ser adecuados a los requerimientos lógicos.
El primer proceso retoma la arquitectura
mediante la extracción del código fuente. La estructura es analizada y se
revisa si es posible adaptarla a una arquitectura anterior. También se evalúan
diferentes características.
Transformar
la arquitectura es el segundo proceso. Se recupera la arquitectura antes echa y
se le aplica reingeniería para hacerla como se quiere.
El tercer modelo de herradura usa el
¨Architecture-Based Development (ABD) ¨. En esta parte, se juntan las
estrategias seleccionadas. Los artefactos a nivel de código del sistema de
información heredados son normalmente tapados o reescritos para adaptarlos
dentro de la nueva arquitectura.
2.1 Los tres niveles del modelo herradura
Los tres niveles del modelo herradura son:
·
¨Representación
de la estructura de código¨
·
¨Representación
del nivel funcional¨
·
¨Nivel
conceptual¨
El modelo no solo hace transformaciónes en el
nivel de arquitectura, también puede realizarse en los niveles subsidiarios.
3 El modelo cíclico
Este modelo refiere seis actividades, que son
gráficamente expuestas en la figura a continuación. Normalmente el flujo de
estas seis actividades ocurre de manera secuencial y lineal, pero en ocasiones
no es así. Por ejemplo la reingeniería inversa podría requerirse antes de la
reestructuración de documentos.
La forma de este modelo muestra que cualquier
actividad puede repetirse varias veces. Para un caso particular el ciclo podría
comenzar y/0 acabar en cualquiera de sus elementos.
3.1 Actividades del modelo cíclico
Se repasaran las diferentes actividades de
cada una de las etapas del modelo cíclico como lo son: Análisis de inventario,
Restructuración de documentos, Ingeniería Inversa, Reestructuración de código,
Restructuración de datos e Ingeniería directa.
Análisis de inventario
Todas las empresas desarrolladoras de
software deberán tener un catalogo con todas sus aplicaciones, puede ser un
formato sencillo donde se enlisten las características esenciales, como nombre,
tamaño, importancia para la empresa, etc.
Cuando
se tiene un inventario con información bien clasificada es entonces cuando
aparecen las posibles candidatas para el trabajo de reingeniería.
Restructuración de documentos.
Cuando se tiene un sistema donde se carece de
información puede ser la consecuencia de muchos sistemas heredados. ¿Qué se
puede hacer?
·
Opción 1:
Generar nueva documentación seria un trabajo muy lento, se trabajara con lo que
se tiene.
·
Opción 2: Se
necesita actualizar documentos, pero hay pocos recursos, se documentara si se
modifica.
·
Opción 3: La
documentación es inminente. En este caso se reducirá al mínimo los datos.
Ingeniería
inversa
La
ingeniería inversa no es más que el proceso de hacer reingeniería comenzando
por un producto terminado y descubrir su estructura y desarrollar las etapas de
manera inversa hasta llegar a sus especificaciones más simples. Un ejemplo
práctico de la reingeniería inversa es un empleado que compra un producto del
competidor y lo abre en el laboratorio de su empresa, ahí se debe descubrir
cómo fue creado ese producto.
Restructuración
del código
Es la forma más básica de reingeniería, es
donde fundamentalmente se buscan las fallas. Algunos sistemas cuentan con una
programación solida y confiable, pero algunos módulos pueden demostrar
debilidades y es ahí en donde se puede hacer una restructuración de algunas líneas
de código para tratar de solucionar fallas o encontrar posibles mejoras.
Restructuración
de datos
En un sistema que posee una base de datos
débil, existirá una latente posibilidad de aplicar reingeniería. Los datos que
alimentan al sistema no pueden ser imprecisos, si eso sucede todo el sistema
colapsaría y le reingeniería seria más urgente. Esto sucede mucho cuando se
solicitan ampliaciones y modificaciones de todas y cada una de las bases de
datos.
Ingeniería
Directa (foward engineering)
Se puede decir que es la reingeniería
automática, donde aplicaciones obsoletas se modifican a través de un disco que
al ser insertado detecta lo que se puede re ingeniar y se ejecuta dentro del
programa , arrojando una versión eficiente.
Conclusión
Las metodologías para la reingeniería del
software, son una gran guía para cualquier caso de reingeniería. Debido a sus
diversos métodos y modelos existen diversas maneras de identificar los casos en
los que será necesario aplicar reingeniería y en cuáles no.
Las
metodologías ayudan porque existe una estandarización en el procedimiento y
ejecución de las diferentes actividades. Estudiando nuestro sistema y tomando
como base uno de los modelos, se puede fácilmente llegar a una solución
específica que atienda el caso que requiere la modificación.
Los modelos sistemáticos como el de “Análisis
de opciones para Reingeniería” (OAR) nos dan un seguimiento por partes, en
donde nos permiten elegir de entre diferentes opciones, estas opciones nos
llevan a otras que se desglosan de la anterior y especifican mas el problema.
Esto ayuda a que se llegue ordenadamente a una solución correcta.
Los
modelos como el de herradura y el cíclico presentan formas más orientadas a
secciones para aplicar reingeniería, El primero nos muestra una formación
lógica de los tres procesos básicos conocidos y sus actividades, mientras que
el segundo tiene seis formas de ingeniería aplicadas a diferentes partes o
momentos del sistema.
REFERENCIAS:
[Bass
99]
Bass,
L & Kazman, R. “Architecture-Based Development”
(CMU/SEI-99-TR-007).
Pittsburgh, Pa.: Software Engineering
Institute, Carnegie Mellon University, 1999
[Behf
96]
Behforooz,
Ali & Hudson, Frederick. “Software Engineering
Fundamentals”.
Publicado por Oxford University Press, New
York, 1996.
[Berg
99]
Bergey,
John; Smith, Dennis; Weiderman, Nelson & Woods,
Steven
“Options Analysis for Reengineering (OAR): Issues
and
Conceptual Approach” (CMU/SEI-99-TN-014).
Pittsburgh,
Pa.: Software Engineering Institute, Carnegie
Mellon University, 1999.
[Berg 00]
Bergey,
John & Smith Dennis "Guidelines for Using OAR
Concepts
in a DoD Product Line Acquisition Context"
(CMU/SEI-2000-TN-004).
Pittsburgh, Pa.: Software
Engineering
Institute, Carnegie Mellon University, 2000
martes, 6 de marzo de 2012
martes, 21 de febrero de 2012
Introdución
Reingeniería del software se puede definir como: “modificación de un producto software, o de ciertos componentes, usando para el análisis del sistema existente técnicas de Ingeniería Inversa y, para la etapa de reconstrucción, herramientas de Ingeniería Directa, de tal manera que se oriente este cambio hacia mayores niveles de facilidad en cuanto a mantenimiento, reutilización, comprensión o evaluación.”
Este blog fue creado con la finalidad, de exponer las evidencias formadas en este curso, asi como un enlace para complementar nuestro aprendizaje con las publicaciones de nuestros compañeros. Tambien porque facilita el proceso de revision y calificacion del docente.
