revista de ingenieria de software
DESCRIPTION
Articulos de Ingenieria de SoftwareTRANSCRIPT
] INGENIERIacuteA DE SOFTWARE
1
INGENIERIacuteA DE SISTEMAS
2012
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Revista Conceptual Ing de Software Este segundo nuacutemero nos entrega informacioacuten de Ingenieriacutea de Software
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
2
EDITORIAL
El emprendimiento para realizar la revista es hacer nacer el intereacutes a los alumnos en el aacutembito de
la investigacioacuten daacutendoles paraacutemetros para que ellos en su futuro proyecten sus propias
investigacioacuten de temas de intereacutes personal con referencia a la carrera incentivando al resto del
alumnado para la creacioacuten de nuevos nuacutemeros de revistas en futuro
Se quiere realizar una directriz de la parte investigativa juntamente con la parte educativa
despertando a nuevas adquisiciones de saberes que nos brindaraacute a futuro estudiantes con una
visioacuten maacutes amplia en la parte de la investigacioacuten que es lo que debemos fomentar
Se felicita y conmina a los autores de los artiacuteculos a seguir por este camino que les llevaraacute a
grandes logros en su vida profesional
Tomen en cuenta siempre ldquoEL SABER ES PODERrdquo
MSc Elizabeth Pommier Gallo
] INGENIERIacuteA DE SOFTWARE
3
INGENIERIacuteA DE SISTEMAS
INDICE Tom DeMarco Ingenieria de Software y Control de
Proyectoshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip4
Adictos al helliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip6
Skinput Una pantalla taacutectil en tu pielhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip11
Mini
computadorashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip14
Estudio de redes
GNOPhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
7
La suacuteper caacutemara que lo ve
todohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip20
Des-
impresioacuten helliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
helliphelliphelliphelliphelliphelliphelliphelliphelliphellip23
Cloud
Computinghelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
helliphelliphelliphelliphelliphelliphelliphelliphellip26
Nano- celular
solareshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
helliphelliphelliphelliphellip29
Memorias USB en
moacuteduloshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
hellip32
Teleacutefonos moacuteviles de ultima
generacioacutenhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip34
My
coachhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
helliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip37
Factores del Cableado en el Centro de Coacutemputohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip40
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
4
Tom DeMarco
Ingenieriacutea de Software
y Control de Proyectos Joe Luis Aramayo Blanco
Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
20 de Octubre Esq Belisario Salinas
La Paz - Bolivia jlaramayousfaeduboResumen- En este artiacuteculo
haremos algunas observaciones sobre un artiacuteculo
que escribioacute hace un tiempo atraacutes Tom DeMarco
sobre meacutetricas control de proyectos e
ingenieriacutea de software donde en general podemos
encontrar frases que claramente contradicen su
postura de hace unas deacutecadas
Palabras clave- Ingenieriacutea de Software Control de Proyectos
Meacutetricas No puedes controlar lo que no puedes medir Desarrollo
de Software
I INTRODUCCIOacuteN
Todos comprendemos que las meacutetricas de software cuestan
dinero y tiempo y que deben ser usadas con moderacioacuten
El desarrollo de software es inherentemente diferente de las
ciencias naturales tales como la fiacutesica por lo que sus meacutetricas
son mucho menos precisas para capturar lo que deben describir
La frase ―No puedes controlar lo que no puedes medir lleva
impliacutecita que el control es un aspecto importante quizaacutes el maacutes
importante de cualquier proyecto de software Pero no lo es
Fig 1 Ejemplo de ―No puedes controlar lo que no puedes medir
Muchos proyectos se han realizado sin demasiado control pero
han generado productos maravillosos tales como Google Earth o
la Wikipedia
Esto nos lleva a la desagradable conclusioacuten que el control
estricto es algo que importa mucho en proyectos relativamente
inuacutetiles y mucho menos en proyectos uacutetiles
iquestEstoy diciendo que estaacute bien ejecutar proyecto sin control o
con un control relativamente menor Casi Estoy sugiriendo que
deberiacuteamos seleccionar primero a los proyectos cuyo control
preciso no importe demasiado
En los uacuteltimos 40 antildeos nos hemos torturado por nuestra
ineptitud en acabar proyectos a tiempo y con el presupuesto
previsto Pero como sugeriacute antes no deberiacutea haber sido el
objetivo supremo
El objetivo maacutes importante es la transformacioacuten crear software
que cambie el mundo o que transforme una empresa o la forma
en que hace negocios
El desarrollo de software es y seraacute siempre algo experimental
La construccioacuten real de software no es necesariamente
experimental pero siacute lo es su concepcioacuten Alliacute deberiacuteamos
enfocar nuestros esfuerzos Alliacute es donde deberiacuteamos haberlo
hecho siempre Estaacute claro que es mucho maacutes faacutecil criticar un
artiacuteculo que hacer uno nuevo pero dada la trascendencia que estaacute
teniendo este escrito en particular voy a expresar mi opinioacuten
Creo que DeMarco sabe venderse Creo que cuando era maacutes
joven se supo posicionar como guruacute de la Ingenieriacutea de Software
y el control de proyectos y creo que ahora estaacute en la edad en que
puede decir que parte de lo que dijo estaacute mal e igual quedar bien
porque su posicioacuten coincide con la de muchos guruacutees actuales
Sin embargo me parece que el artiacuteculo estaacute lleno de frases
impactantes pero que no salen de un anaacutelisis profundo Me voy
a explayar
] INGENIERIacuteA DE SOFTWARE
5
INGENIERIacuteA DE SISTEMAS
Fig 3 Referencia a las Meacutetricas cuestan dinero
Que las meacutetricas cuestan dinero en cierto sentido es cierto
Tambieacuten es cierto que ahora es mucho maacutes faacutecil llevar algunas
meacutetricas que hace unos antildeos dado que ahora utilizamos
herramientas que las generan de manera automaacutetica Podriacuteamos
decir que en el presente es mucho menos costoso tener la misma
informacioacuten que hace unas deacutecadas DeMarco consideraba
importante
Que el desarrollo de software es inherentemente diferente de las
ciencias naturales como la fiacutesica tambieacuten es verdad Lo que no
se termina de entender es por queacute nos comparamos con las
Fiacutesicas y no con las Ingenieriacuteas
El disentildeo de una planta de gas en situaciones extremas tambieacuten
es uacutenico y con resultados impredecibles la construccioacuten de una
torre en Dubai alguacuten nuevo prototipo de avioacuten un nuevo
celular etc tambieacuten son inherentemente diferentes de las
ciencias naturales y sin embargo cuentan con presupuestos
meacutetricas de avance de defectos etc O sea es una verdad pero
que no aplica a la conclusioacuten a la que llega
Donde puedo estar maacutes de acuerdo es cuando hablamos del
control de proyectos de software aunque maacutes adelante voy a
definir mi posicioacuten En este caso en mi opinioacuten tambieacuten escribe
algo cierto ―El control no es lo maacutes importante de un proyecto
de software pero cuando toma ejemplos elije dos proyectos en
los que las desviaciones admitidas eran del orden de entre 100
y 1000 ya que o el objetivo era otro o los resultados
esperados eran mucho mayores a una desviacioacuten de 500 en
costos
Fig 1 Referencia de Google Earth
Ambos proyectos (Wikipedia que surge de NuPedia) y
GoogleEarth fueron proyectos en los que hubo inversores
poniendo su dinero durante antildeos sin ver resultados Se puede
buscar en Internet acerca de la historia de NuPedia antecesora
de Wikipedia y a Jimi Wales explicando que despueacutes de haber
gastado 250000 doacutelares solo habiacutea logrado 16 artiacuteculos en su
nueva Enciclopedia Lo mismo pasoacute con GoogleEarth
anteriormente en manos de KeyHole con inversores como Sony
y otros Fondos de Capital En este tipo de proyectos se pueden
asumir peacuterdidas durante antildeos hasta lograr un producto que
puede romper con el mercado o tambieacuten se puede perder todo lo
invertido Se trata de proyectos de inversioacuten de alto riesgo y
determinan proyectos de desarrollo que claramente son poco
comunes
Fig 3 Referencia de WIKIPEDIA
Al menos en mi entorno la mayoriacutea de los proyectos son
internos o externos (para un cliente) Los proyectos externos
tienen presupuestos o se crean luego de llamados a licitacioacuten
Es decir costo fijo tiempo fijo alcance fijo maacutes menos alguna
que otra variacioacuten Es claro que si no contamos con un miacutenimo
de control en estos proyectos la empresa no sabe si estaacute siendo
rentable o no Tampoco sabe si el producto que es desarrollado
le puede traer problemas a futuro por alguna cuestioacuten de calidad
No poner un miacutenimo eacutenfasis en el control de estos proyectos
puede llevar a la empresa a la quiebra sin que esta sea
consciente salvo por los nuacutemeros rojos que aparecen en sus
balances Por lo tanto explicar que un proyecto de software no
hace falta controlarlo mucho y poner como ejemplo dos casos
muy poco relevantes no parece muy serio
Por uacuteltimo cuando dice el desarrollo de software es y siempre
seraacute algo experimental vuelve a caer en las afirmaciones de las
que en 40 antildeos (en caso de estar vivo claro) podriacutea volver a
arrepentirse Es cierto que todaviacutea estamos en una etapa inicial
de la que llamamos ingenieriacutea de software Es cierto que no es
faacutecil gestionar proyectos de software por sus caracteriacutesticas
intriacutensecas (intangibilidad maleabilidad etc) pero cada
ingenieriacutea tiene sus problemas particulares y cada una supo
evolucionar a lo que son ahora Seguramente la ingenieriacutea de
Software con el tiempo encontraraacute su camino
Ahora bien aparte de criticar un poco a DeMarco (que era lo
maacutes faacutecil) vamos a retomar la frase
―No puedes controlar lo que no puedes medir lleva impliacutecita
que el control es un aspecto importante quizaacutes el maacutes
importante de cualquier proyecto de software Pero no lo es
En cierta medida explicaba arriba estoy de acuerdo con esta
afirmacioacuten Un buen proyecto de software con mucho control
pero malos programadores lleva al fracaso inevitablemente (lo
he vivido personalmente y por experiencias de terceros) Por el
contrario un buen equipo de programadores (pero de los
buenos) puede terminar el proyecto maacutes complejo haciendo que
ninguacuten indicador tenga sentido ya que la diferencia de calidad
del producto y la eficiencia del trabajo de este tipo de gente
multiplica por 10 o por 100 la de un equipo estaacutendar
Este tipo de gente piensa las cosas de manera diferente tiene la
calidad incorporada como meacutetodo de trabajo y la capacidad de
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
6
generar soluciones a las distintas situaciones hace que el
esfuerzo estimado pueda acortarse en oacuterdenes de magnitud
Estuve dentro equipos de este estilo y lo que se puede lograr en
un ambiente hiperproductivo difiacutecilmente se logre en una
empresa de desarrollo comuacuten y corriente El problema es que la
gente que tiene estas cualidades escasea y el mercado estaacute lleno
de trabajadores ―estaacutendar que requieren definiciones procesos
un aacuterea de calidad que verifique sus entregables y un PM que le
indique queacute es lo que tiene que hacer De a poco estimo yo la
industria iraacute decantando por rendimiento aquellos profesionales
que hacen la diferencia y los estaacutendares de productividad
calidad base teoacuterica requerida para un puesto iraacuten aumentando
Fue pasando durante estas deacutecadas y seguiraacute pasando en el
futuro
II CONCLUSIONES
En siacutentesis y para terminar con este artiacuteculo medir y controlar
importa importa maacutes en las empresas con gente estaacutendar
importa maacutes en las empresas con proyectos estaacutendar y siempre
que estemos dentro de una empresa algo vamos a tener que
medir pero el control no es condicioacuten necesaria ni menos
suficiente para lograr un proyecto exitoso No es algo
fundamental como tener un buen equipo de programadores
como tener gente que sepa interpretar lo que se pide y
transformarlo de manera natural en la solucioacuten que el cliente
necesita Por eso cuando veo gente que se preocupa por
aumentar el control o aumentar los procesos creo que estaacute
perdiendo el foco cuando lo que deberiacutea buscar es coacutemo hacer
para encontrar y hacer rendir a los verdaderos profesionales del
software
III REFERENCIAS
[1] Software Engenieering an idea whose time has come and gone por Tom
DeMarco [2] CyS Ingenieria de Software El blog del aacuterea de Ingenieriacutea de Software de
CyS Informaacutetica SA
] INGENIERIacuteA DE SOFTWARE
7
INGENIERIacuteA DE SISTEMAS
EXTREME PROGRAMMING PARA DESARROLLO
DE SOFTWARE
Erwin Adaacuten Choque Ulloa Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
Plaza Avaroa esq Belisario Salinas
La paz ndash Bolivia adan_ekinghotmailcom
Resumen
En este articulo se describiraacute algunas de las metodologiacuteas
agiles de desarrollo de software puesto que para asegurar el
eacutexito durante el desarrollo de un software es importante
saber la metodologiacutea de desarrollo la cual nos provee una
guiacutea para la correcta aplicacioacuten y desarrollo de Software
La metodologiacutea Extreme Programming XP que es una de las
metodologiacuteas aacutegiles maacutes extendidas y populares ademaacutes es
considerada como una metodologiacutea posmoderna donde
grandes capacidades se generan a traveacutes de procesos
emergentes
Palabras claves Extreme Programming metodologiacutea software
usuario
1 INTRODUCCION
El esquema tradicional para abordar el desarrollo de
software ha demostrado ser efectivo y necesario en
proyectos de gran tamantildeo respecto a tiempo y recursos
Sin embargo este enfoque no resulta ser el maacutes adecuado
para muchos de los proyectos actuales donde el entorno
del sistema es muy cambiante y en donde se exige
reducir draacutesticamente los tiempos de desarrollo pero
manteniendo una alta calidad Ante este problema las
metodologiacuteas aacutegiles son una posible respuesta para llenar
ese vaciacuteo metodoloacutegico Orientadas para proyectos
pequentildeos las metodologiacuteas aacutegiles constituyen una
solucioacuten
A continuacioacuten se describiraacute cada una de las
metodologiacuteas de desarrollo de software
2 EXTREME PROGRAMMING XP
La metodologiacutea de desarrollo de software XP es la
primera metodologiacutea aacutegil y la que le dio conciencia al
movimiento actual de metodologiacuteas aacutegiles Kent Beck el
padre de la metodologiacutea XP se basa en realimentacioacuten
continua entre el cliente y el equipo de desarrollo
comunicacioacuten fluida entre todos los participantes
simplicidad en las soluciones implementadas y facilidad
para enfrentar los cambios XP se define como
especialmente adecuada para proyectos con requisitos
imprecisos y muy cambiantes y donde existe un alto
riesgo teacutecnico Ahora se describiraacute las caracteriacutesticas
esenciales del Extreme Programming
21 LAS HISTORIAS DEL USUARIO
La red Las historias del usuario es la teacutecnica utilizada
para especificar los requisitos de software son tarjetas de
papel donde el cliente especifica de manera simplificada
las caracteriacutesticas que el sistema debe poseer ya sean
requisitos funcionales o requisitos no funcionales Se
caracteriza por ser dinaacutemica y flexible cada historia de
usuario debe ser comprensible y delimitada para que los
programadores puedan implementarla en pocas semanas
22 ROLES XP
Seguacuten Kent Beck los roles son
Programador El programador se encarga de escribir las
pruebas unitarias y tambieacuten estaacute encargado de producir el
coacutedigo del sistema
Cliente Encargado de escribir las historias de usuario y
los requisitos funcionales y selecciona las historias por
prioridad de conveniencia al negocio
Encargado de pruebas Encargado de ayudar al cliente a
escribir las pruebas funcionales ademaacutes de ejecutar las
pruebas constantemente encargado de de las
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
8
herramientas de soporte de pruebas como tambieacuten
difundir los resultados de dicha prueba
Encargado de seguimiento Es el encargado de la
realimentacioacuten al equipo y realiza el seguimiento del
proceso de cada iteracioacuten
Entrenador Es el encargado de prever guiacuteas al equipo
basadas en XP y de seguir el proceso correctamente
Consultor Es el que posee un conocimiento especifico
en alguacuten tema necesario para el proyecto para solucionar
problemas
Gestor Es la interaccioacuten entre clientes y programadores
ayudando a trabajar de forma adecuada y de esta manera
coordinar de forma correcta
23 PROCESO XP
El ciclo de desarrollo XP consiste en
El cliente define el valor del negocio a implementar
El programador estima el esfuerzo necesario para su
implementacioacuten
El cliente selecciona que construir de acuerdo con sus
propiedades y las restricciones del tiempo
El programador construye ese valor de negocio
Vuelve al principio
En todas las iteraciones de este ciclo tanto el cliente como
el programador aprenden No se debe presionar al
programador a realizar maacutes trabajo que el estimado ya
que se perderaacute calidad en el software o no se cumpliraacuten
los plazos
El ciclo de vida ideal de XP consiste de seis fases
Exploracioacuten
Planificacioacuten de la Entrega (Release)
Iteraciones
Produccioacuten
Mantenimiento y Muerte del Proyecto
24 PRACTICAS XP
Las siguientes praacutecticas ayudan al desarrollo de software
El juego de la planificacioacuten Hay una comunicacioacuten
frecuente el cliente y los programadores El equipo
teacutecnico realiza una estimacioacuten del esfuerzo requerido para
la implementacioacuten de las historias de usuario y los
clientes deciden sobre el aacutembito y el tiempo de entregas y
de cada iteracioacuten
Entregas pequentildeas Producir raacutepidamente versiones del
sistema que sean operativas aunque no cuenten con toda
la funcionalidad del sistema Esta versioacuten ya constituye
un resultado de valor para el negocio Una entrega no
deberiacutea tardar maacutes de tres meses
Metaacutefora El sistema es definido mediante un conjunto
de metaacuteforas compartidas por el cliente y el equipo de
desarrollo Una metaacutefora es una historia compartida que
describe como deberiacutea funcionar el sistema
Disentildeo simple Se disentildea la solucioacuten maacutes simple que
pueda funcionar y ser implementada en un determinado
momento del proyecto
Pruebas La produccioacuten de coacutedigo estaacute dirigida para las
pruebas unitarias Estas son establecidas por el cliente
antes de escribirse el coacutedigo y son ejecutadas
continuamente ante cada modificacioacuten del sistema
Pruebas Es una actividad constante de reestructuracioacuten
del coacutedigo con el objetivo de remover duplicacioacuten de
coacutedigo mejorar su legibilidad simplificarlo y hacerlo
maacutes flexible para facilitar los cambios Se mejora la
estructura interna del coacutedigo sin alterar su
comportamiento externo
Programacioacuten en parejas Toda la produccioacuten del
coacutedigo debe realizarse con trabajo en parejas de
programadores Para tener ventajas como menor tasa de
errores mejor disentildeo etc
Propiedad colectiva del coacutedigo Cualquier programador
puede cambiar cualquier parte del coacutedigo en cualquier
instante
Integracioacuten continua Cada pieza del coacutedigo es
integrada en el sistema una vez que este listaasi el
sistema puede ser integrado y construido varias veces en
un mismo diacutea
40 horas por semana Se debe trabajar un maacuteximo de 40
horas por semana no se trabajan horas extras en dos
semanas seguidas Si esto ocurre estaacute existe un problema
porque el trabajo extra desmotiva al equipo
Cliente in-situ El cliente tiene que estar presente y
disponible todo el tiempo para el equipo este es uno de
los principales factores de eacutexito para el proyecto XP Y
asiacute guiar y disipar cualquier duda de los programadores
donde la comunicacioacuten es maacutes efectiva que la escrita
Estaacutendares de programacioacuten XP enfatiza que la
comunicacioacuten de los programadores es a traveacutes del
coacutedigo por lo que es importante que se sigan estaacutendares
de programacioacuten para mantener el coacutedigo legible
3 CONCLUCIONES
] INGENIERIacuteA DE SOFTWARE
9
INGENIERIacuteA DE SISTEMAS
Las metodologiacuteas aacutegiles ofrecen una solucioacuten casi a
medida para una gran cantidad de proyectos
La metodologiacutea XP es una de las metodologiacuteas aacutegiles maacutes
extendidas y populares ademaacutes es considerada como una
metodologiacutea posmoderna cuyas grandes capacidades se
generan a traveacutes de procesos emergentes
4 REFERENCIAS
httpwwwmetodologiasSoftcomdesarrolloagil
httpwwwwikipediacommetodologiaXP
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
10
Desarrollo de Scrum
Sergio J Guzmaacuten L Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 Octubre Esq Belisario Salinas
La Paz - Bolivia
sjguzmanusfaedubo
Resumenmdash Scrum es una metodologiacutea aacutegil de desarrollo de
proyectos que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ldquocampos de scrumrdquo al
software
Palabras clave mdash scrum metodologiacutea patroacuten software
sprint rol
I Que es Scrum
Scrum es una metodologiacutea aacutegil de desarrollo de proyectos
que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ―campos de scrum al
software
Esta fue la primera definicioacuten de un patroacuten Scrum aplicado
al software disentildeada por Jeff Sutherland y Ken Schwaber y
presentada en Object-Oriented Programming Systems
Languages amp Applications OOPSLA en 1996
II iquestCoacutemo incorporarla
La competitividad del mercado de desarrollo de Software y
la necesidad de los clientes de reducir el tiempo de
mercado obligan a las organizaciones de desarrollo de
software a ser agresivas en sus calendarios de entrega Esto
ha hecho que hayan surgido metodologiacuteas para la gestioacuten y
desarrollo de software basadas en un proceso iterativo e
incremental Su estructura estaacute basada en corto tiempo los
cuales son iteraciones de 1 a 4 semanas Scrum se usa en
proyectos de entorno complejos donde se desea obtener
resultados raacutepidos y la productividad es lo maacutes importante
En los proyectos basados en Scrum se consideran tres
roles
Duentildeo del producto Es quien determina las propiedades de
los entregables
Maestro de Scrum Administra y facilita la ejecucioacuten del
proceso
Equipo de Trabajo Trabajan en conjunto para entregar
resultados en cada sprint
Fig 1 El flujo de Scrum
Como se puede observar en medio de los participantes del
proceso no quedan claras las responsabilidades del
arquitecto de software Sin embargo como comenta
Charlie Alfred ―la arquitectura es al aceite y el filtro que
lubrica adecuadamente a Scrum
Fig 2 El flujo de Scrum
] INGENIERIacuteA DE SOFTWARE
11
INGENIERIacuteA DE SISTEMAS
Si se compara el rol del arquitecto de edificaciones con el
del arquitecto de software se puede observar que ambos
modelan las construcciones a un alto nivel de abstraccioacuten
proveen posibles soluciones mejoran la comunicacioacuten con
los miembros del equipo de construccioacuten a traveacutes de
modelos visualizan las generalidades del problema
definen los roles y las interacciones entre los componentes
de construccioacuten entre otras tareas Al igual que es
imposible pensar que un rascacielos puede ser construido
sin una arquitectura soacutelida es imposible pensar que
productos de software empresariales puedan ser
implementados sin una arquitectura bien pensada
Seguacuten Bass Clements y Kasman ―La arquitectura de
software de un programa o sistema informaacutetico es la
estructura o estructuras del sistema que incluyen elementos
de software las propiedades externamente visibles de esos
elementos y las relaciones entre ellos Esta definicioacuten nos
lleva a concluir que la arquitectura de software garantiza el
buen desarrollo del software y a tener un sistema que
cumpla con los requerimientos funcionales y no
funcionales del cliente Ademaacutes la arquitectura es clave en
la reutilizacioacuten de artefactos de software en sistemas de
liacutenea de productos de software
Viendo la importancia de la arquitectura en el desarrollo
del software en eacuteste artiacuteculo se presenta una propuesta para
gestionar la arquitectura de Software en Scrum En el
primer capiacutetulo se trata el tema de la localizacioacuten de la
arquitectura de software en el ciclo de desarrollo de Scrum
en el segundo capiacutetulo se describen las tareas del arquitecto
de software en Scrum finalmente se presentan las
conclusiones y el trabajo futuro
III Arquitectura de Software en el ciclo de desarrollo de
Scrum
La idea fundamental de la presente propuesta es adicionar
un sprint inicial llamado ―Sprint 0Prime al inicio del ciclo de
desarrollo El objetivo principal del arquitecto en el Sprint
0 es analizar y disentildear la generalidad del sistema que
satisfaga los requisitos y sea entendible por los miembros
del equipo desde sus diferentes puntos de vista durante el
desarrollo Un punto clave es reutilizar artefactos de
software creados a partir de la arquitectura para ser maacutes
aacutegiles en el desarrollo de productos especiacuteficos
El Sprint 0 comprende tres fases que fueron tomadas del
ciclo de vida de entregas evolutivas En el Sprint 0 se
construye la arquitectura de forma iterativa mediante un
anaacutelisis preliminar de los conductores arquitectoacutenicos
(requisitos funcionales de calidad y del negocio) y de un
estudio de factibilidad del proyecto No se necesita tener
todos los requisitos claros para comenzar la fase de disentildeo
arquitectoacutenico
Para determinar los conductores arquitectoacutenicos se debe
identificar los objetivos del negocio de maacutes alta prioridad
que son pocos Estos objetivos del negocio se convierten en
los escenarios de calidad o casos de uso De esta lista se
deben escoger los que tendraacuten un mayor impacto sobre la
arquitectura El disentildeo arquitectoacutenico puede comenzar una
vez que se encuentran definidos los conductores
arquitectoacutenicos El proceso de anaacutelisis de requisitos seraacute
entonces influenciado por las preguntas generadas durante
el disentildeo arquitectoacutenico
El resultado del Srpint 0 es un documento inicial que
explica la arquitectura El documento puede basarse en los
pasos definidos por el meacutetodo ADD (Attrbute Driver
Design) Este meacutetodo ha sido probado exitosamente en
proyectos anteriores Con ADD se puede definir una
arquitectura de software mediante un proceso de
descomposicioacuten basado en los atributos de calidad de
Software
El documento inicial de la arquitectura se debe avaluar con
el fin de saber si la arquitectura cumple con los requisitos
de calidad Para realizar esta evaluacioacuten se propone el
meacutetodo ATAM (Architecture Tradeoff Analysis Method)
El ATAM revela cuaacuten bien una arquitectura satisface los
objetivos particulares de calidad y provee una
aproximacioacuten de coacutemo los objetivos de calidad interactuacutean
Si la evaluacioacuten de la arquitectura se encuentra que se
deben realizar cambios a la misma entonces eacutesta se debe
refinar hasta llegar a tener como resultado del Sprint 0 el
documento puacuteblico de la arquitectura junto con el sistema
esqueleto Finalmente la arquitectura creada en el Sprint 0
beneficiaraacute el desarrollo en los siguientes sprints
IV Rol del arquitecto de Software en Scrum
El rol y actividades del arquitecto de software cambian de
enfoque dependiendo de si se estaacute en el Sprint 0 o en
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
12
sprints subsecuentes
Fig 3 La Comunicacioacuten
Sprint 0 En sistemas complejos una persona difiacutecilmente
puede cubrir con amplitud teacutecnica las decisiones
arquitectoacutenicas y dar credibilidad a la arquitectura de
software Esto quiere decir que la participacioacuten del equipo
es de vital importancia para la creacioacuten y el mantenimiento
de la arquitectura Un equipo de arquitectos de software
que se aiacutesle del equipo de Scrum puede producir una
arquitectura que corra el riesgo de ser rechazada Es por
esto que recomendamos que el arquitecto o los arquitectos
se software sean miembros del equipo de Scrum Una de
las actividades que se debe realizar en equipo es la
evaluacioacuten de la arquitectura Especiacuteficamente en el
meacutetodo ATAM se requiere la participacioacuten mutua de tres
equipos que trabajan en conjunto con los arquitectos de
software el de evaluacioacuten el de tomadores de decisiones
del proyecto y el de los involucrados en la arquitectura
Sprints subsecuentes El arquitecto de software asegura que
el equipo de Scrum entienda el enfoque y los retos
arquitectoacutenicos maacutes importantes en casa sprint Los
equipos de Scrum realizan construcciones cortas guiados
por las estrategias de la arquitectura A continuacioacuten se
nombran algunas de las responsabilidades del arquitecto de
software desde el Sprint 1 en adelante
El duentildeo del producto y el maestro del Scrum trabajan con
el arquitecto para priorizar los requisitos a implementar en
cada iteracioacuten
El arquitecto comunica las decisiones y facilita las
conversaciones arquitectoacutenicas de distintos puntos de vista
en cada sprint
El arquitecto asegura que haya conformidad entre las
entregas en cada sprint y la arquitectura
El arquitecto responde preguntas y da orientacioacuten
arquitectoacutenica cuando sea necesario
Junto con el maestro de Scrum coordina a los miembros
del equipo para adaptarse a la arquitectura previa
El arquitecto junto con el duentildeo del producto y los
miembros del equipo preparan el Product Backlog
V Conclusioacuten
En el presente artiacuteculo ofrecimos una propuesta para incluir
la arquitectura de software en Scrum En el Sprint 0 se
realizan las actividades concernientes al anaacutelisis y disentildeo
de la arquitectura de software y el sistema esqueleto En
los siguientes sprints el arquitecto de software se asegura
de que la implementacioacuten cumpla con la arquitectura
REFERENCIAS
[3] httpwwwsafecreativeorgwork
[4] Hirotaka Takeuchi es decano de la Graduate School of International
Corporate Strategy en la Universidad Hitotsubashi en Tokio y fue profesor visitante en la Escuela de Negocios Harvard entre 1989 y 1990
[5] Ikujiro NonakaNo soy un guruacute porque me falta carisma
] INGENIERIacuteA DE SOFTWARE
13
INGENIERIacuteA DE SISTEMAS
El futuro de la ingenieriacutea de software Luis E Aguirre
Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 de Octubre esq Belisario Salinas
La Paz - Bolivia leaguirreusfaedubo
Resumen El disentildeo de programas a partir de informacioacuten binaria
significoacute un paso sustantivo para la industria desarrolladora de
software Desde ese hallazgo ocurrido en la deacutecada de los
cincuenta hasta hoy el crecimiento de metodologiacuteas para su
desarrollo ha subido notablemente en complejidad Sin embargo
los ciacuterculos viciosos que acusa hoy la confeccioacuten de programas
informaacuteticos impiden conceptualizar el objeto a un nivel
superior de abstraccioacuten tal y como lo exige el avance tecnoloacutegico
y los procesos de negocios
Palabras clave mdash futuro software ingenieriacutea programador y
desarrollo
I Introduccioacuten
La calidad de los sistemas informaacuteticos satisfaccioacuten de sus
usuarios y clientes son temas ampliamente conocidos
recurrentes y de constante preocupacioacuten por parte de los
practicantes de la Ingenieriacutea de software
Esta joven y dinaacutemica ingenieriacutea siempre estaacute en busca de
mejoras en el desarrollo de sistemas aumento de
productividad del ingeniero de software mayor control del
proceso de desarrollo establecimiento de nuevos meacutetodos de
desarrollo
Fig 1 Primeros programas computacionales en formato de tarjeta perforada
Estos elementos combinados y aplicados de buena forma
logran un buen proceso de desarrollo y en definitiva un buen
producto
Identificar los pasos que ha recorrido esta ingenieriacutea analizar
su contexto actual y finalmente proyectar hacia doacutende se
dirige es el pilar de este artiacuteculo
II iquestSe aplica actualmente la ingenieriacutea del software
La investigacioacuten y el desarrollo de teacutecnicas y meacuteto
dos de ingenieriacutea del software son constantes y suelen suponer
interesantes avances en la resolucioacuten de problemas de
desarrollo de software Sin embargo es habitual que en la
praacutectica diaria profesional no se incluya praacutecticamente
ninguna de las recomendaciones maacutes elementales de la
ingenieriacutea del software En efecto es habitual que el
desarrollo de software se parezca maacutes al descontrol del cuento
de laquosi los programadores fueran albantildeilesraquo ([Novatica
1996]) que a una idiacutelica y bien organizada factoriacutea de
software (concepto de gran vigencia a finales de los ochenta
[Nunamaker et al 1988])
De hecho las evaluaciones de los procesos productivos de
software realizadas a raiacutez de los modelo de procesos de
software (por ejemplo con CMM [Paulk et al 1993])
confirman que el desarrollo de software suele estar
baacutesicamente en estado caoacutetico
Y no soacutelo en como uno podriacutea pensar pequentildeas
organizaciones de un paiacutes mediterraacuteneo como el nuestro sino
en tambieacuten en las empresas adjudicatarias de interesantes
contratos de defensa de paiacuteses laquoavanzadosraquo como EEUU o
Japoacuten Si bien estos modelos de evaluacioacuten auacuten acumulan
distintas acusaciones de rigidez o falta de contraste empiacuterico
los resultados obtenidos en sus evaluaciones resultan
consistentes con la sensacioacuten de constante laquoapagafuegosraquo que
suelen sufrir los profesionales del software Tambieacuten suelen
revelar la praacutectica despreocupacioacuten de los responsables de las
organizaciones de software por la mejora de la calidad de sus
procesos de trabajo o de sus productos bien sea por contar con
una situacioacuten interna de empresa poco propicia porque el
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
14
ambiente del mercado no fomenta la preocupacioacuten por estos
temas o bien por su poco intereacutes real en la buacutesqueda de la
calidad
III La actualidad
La gran mayoriacutea de los sistemas de software creados hoy en
diacutea son los llamados sistemas corporativos es decir son
orientados a formar una parte importante de los negocios de
las grandes empresas
Continuando en nuestro contexto se identifica un nuevo
enfoque del problema de desarrollo el apoyo en la
sincronizacioacuten de los procesos de negocio estructuras
complejas de informacioacuten manejada por el negocio todo esto
entrelazado por restricciones dadas por las reglas del negocio
La tecnologiacutea actual por otro lado ha alejado maacutes todaviacutea los
ingenieros de las maacutequinas sistemas operativos incluso de
las tareas de programacioacuten
El enfoque de la mayoriacutea de los equipos de desarrollo e
ingenieros participes en proyectos sigue siendo con un bajo
nivel de abstraccioacuten cerca de la codificacioacuten Se tiende a
pensar en la base de datos a utilizar establecer la navegacioacuten
de las paacuteginas programar los protocolos de comunicacioacuten etc
Esto lleva a utilizar las tareas de programacioacuten y de pruebas
para validar el entendimiento y cumplimiento de la
funcionalidad de los sistemas
Lo anteriormente expuesto muestra un problema
metodoloacutegico consecuencia de un desfase entre el enfoque
teoacuterico oacuteptimo (anaacutelisis de negocio) y el enfoque praacutectico real
(programacioacuten y pruebas) en los proyectos de hoy En otras
palabras la metodologiacutea actualmente usada estaacute atrasada con
respecto al avance tecnoloacutegico
Desarrollando maacutes esta idea se identifican algunos
problemas concretos de las metodologiacuteas
Ellas no obligan a sus ejecutores a respetar todas las
normas y los procedimientos establecidos especialmente
en las etapas tempranas del proyecto Es muy faacutecil y
tentador ―saltar una o maacutes de estas etapas uno o maacutes
documentos o modelos pasando directamente a
implementacioacuten produccioacuten y posterior correccioacuten de los
sistemas desarrollados
Control de calidad del producto final La codificacioacuten y
complejidad del programa es demasiada para ser revisada
y verificada fehacientemente Por otro lado los coacutedigos
fuentes y los ejecutables actualmente son los uacutenicos
entregables eficientemente verificables
Estos dos problemas al parecer forman una situacioacuten
contradictoria la metodologiacutea tradicional no permite validar
eficientemente la calidad de los sistemas antes de llegar al
coacutedigo fuente y por otro lado tampoco permite llegar
eficientemente a coacutedigos fuentes de calidad
IV Futuro
La salida de este ―ciacuterculo vicioso que se propone es
bastante natural analizar la situacioacuten actual de la ingenieriacutea
de software en la luz de sus tendencias histoacutericas
La primera de ellas relacionada con los problemas que
resuelven los sistemas obviamente presente y muy utilizada
en nuestra realidad los sistemas de hoy no soacutelo resuelven los
problemas del mundo real sino que estaacuten fuertemente influen-
ciando el desarrollo del mundo real
Fig2 Modela
El enfoque de los ingenieros desde hace unos antildeos no se ha
movido significativamente por el camino del aumento de
abstraccioacuten establecido histoacutericamente Se han hecho ciertos
avances en temas puntuales (como arquitecturas de
componentes patrones de disentildeo nuevos lenguajes de
programacioacuten etc) pero conceptualmente
metodoloacutegicamente la tarea de programacioacuten sigue siendo
ejecutada de la misma forma escribiendo coacutedigos fuentes en
forma de los programas textuales
Eacuteste es justamente el ―atraso metodoloacutegico que se
mencionoacute Para disminuir la brecha entre las tendencias
histoacutericas es necesario ajustar la metodologiacutea en teacuterminos de
aumentar la abstraccioacuten del enfoque de los ingenieros de
software y acercarlo a la abstraccioacuten del problema
El aumento de la abstraccioacuten del proceso de desarrollo del
software hace pensar que la proacutexima generacioacuten de meacutetodos
de desarrollo se perfila en un conceptualmente nuevo con-
] INGENIERIacuteA DE SOFTWARE
15
INGENIERIacuteA DE SISTEMAS
junto de herramientas que permitan aumentar en un mayor
grado al actual la abstraccioacuten escondiendo los detalles de maacutes
bajo nivel
Fig3 Probable modelo a futuro
Las nuevas herramientas permitiraacuten ―programar en nivel
de anaacutelisis generando coacutedigos en un lenguaje de
programacioacuten tradicional de forma automaacutetica tal como hoy
los compiladores generan el lenguaje maacutequina a partir del
coacutedigo fuente Nuevos ―lenguajes de programacioacuten
naturalmente seriacutean visuales y se pareceriacutean a las
especificaciones de software en uno de los lenguajes de
modelamiento por ejemplo UML
V Conclusioacuten
Es muy probable que estemos proacuteximos a ver un nuevo
paso evolutivo en la ingenieriacutea de software Tan grande como
el invento de lenguajes de alto nivel o anaacutelisis y disentildeo
orientado a objetos Una nueva generacioacuten que absorberaacute a la
actual automatizando la mayoriacutea de las buenas praacutecticas
usadas actualmente
Una pregunta natural es si una maacutequina puede llegar a
generar programas tan buenos como los hechos por un pro-
gramador experto En vez de ―romper la cabeza con esta
pregunta ahora quizaacutes seriacutea suficiente recordarse otra vez de
la historia Los primeros compiladores de ninguna generacioacuten
alcanzaban de inmediato lo deseable y oacuteptimo Sin embargo
con el paso del tiempo apoyados en la experiencia de los
ingenieros y en el avance tecnoloacutegico se mejoraban hasta el
nivel de superar significativamente las generaciones
anteriores
Es poco factible que hoy en diacutea alguien cuestione la calidad
de los compiladores de por ejemplo Java y la calidad del
coacutedigo de maacutequina generado por ellos
VI Referencias [6] Website [Online]
httpwwwenterpriseanalystnetdownloadmda_informaticap
df
[7] httpwwwslidesharenetamrrochafuturo-del-software-impacto-en-las-organizaciones-y-en-los-profesionales
[8] httpwwwdcubaareventseci2008conferenciasIngSoftHexacta
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
2
EDITORIAL
El emprendimiento para realizar la revista es hacer nacer el intereacutes a los alumnos en el aacutembito de
la investigacioacuten daacutendoles paraacutemetros para que ellos en su futuro proyecten sus propias
investigacioacuten de temas de intereacutes personal con referencia a la carrera incentivando al resto del
alumnado para la creacioacuten de nuevos nuacutemeros de revistas en futuro
Se quiere realizar una directriz de la parte investigativa juntamente con la parte educativa
despertando a nuevas adquisiciones de saberes que nos brindaraacute a futuro estudiantes con una
visioacuten maacutes amplia en la parte de la investigacioacuten que es lo que debemos fomentar
Se felicita y conmina a los autores de los artiacuteculos a seguir por este camino que les llevaraacute a
grandes logros en su vida profesional
Tomen en cuenta siempre ldquoEL SABER ES PODERrdquo
MSc Elizabeth Pommier Gallo
] INGENIERIacuteA DE SOFTWARE
3
INGENIERIacuteA DE SISTEMAS
INDICE Tom DeMarco Ingenieria de Software y Control de
Proyectoshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip4
Adictos al helliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip6
Skinput Una pantalla taacutectil en tu pielhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip11
Mini
computadorashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip14
Estudio de redes
GNOPhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
7
La suacuteper caacutemara que lo ve
todohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip20
Des-
impresioacuten helliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
helliphelliphelliphelliphelliphelliphelliphelliphelliphellip23
Cloud
Computinghelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
helliphelliphelliphelliphelliphelliphelliphelliphellip26
Nano- celular
solareshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
helliphelliphelliphelliphellip29
Memorias USB en
moacuteduloshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
hellip32
Teleacutefonos moacuteviles de ultima
generacioacutenhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip34
My
coachhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
helliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip37
Factores del Cableado en el Centro de Coacutemputohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip40
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
4
Tom DeMarco
Ingenieriacutea de Software
y Control de Proyectos Joe Luis Aramayo Blanco
Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
20 de Octubre Esq Belisario Salinas
La Paz - Bolivia jlaramayousfaeduboResumen- En este artiacuteculo
haremos algunas observaciones sobre un artiacuteculo
que escribioacute hace un tiempo atraacutes Tom DeMarco
sobre meacutetricas control de proyectos e
ingenieriacutea de software donde en general podemos
encontrar frases que claramente contradicen su
postura de hace unas deacutecadas
Palabras clave- Ingenieriacutea de Software Control de Proyectos
Meacutetricas No puedes controlar lo que no puedes medir Desarrollo
de Software
I INTRODUCCIOacuteN
Todos comprendemos que las meacutetricas de software cuestan
dinero y tiempo y que deben ser usadas con moderacioacuten
El desarrollo de software es inherentemente diferente de las
ciencias naturales tales como la fiacutesica por lo que sus meacutetricas
son mucho menos precisas para capturar lo que deben describir
La frase ―No puedes controlar lo que no puedes medir lleva
impliacutecita que el control es un aspecto importante quizaacutes el maacutes
importante de cualquier proyecto de software Pero no lo es
Fig 1 Ejemplo de ―No puedes controlar lo que no puedes medir
Muchos proyectos se han realizado sin demasiado control pero
han generado productos maravillosos tales como Google Earth o
la Wikipedia
Esto nos lleva a la desagradable conclusioacuten que el control
estricto es algo que importa mucho en proyectos relativamente
inuacutetiles y mucho menos en proyectos uacutetiles
iquestEstoy diciendo que estaacute bien ejecutar proyecto sin control o
con un control relativamente menor Casi Estoy sugiriendo que
deberiacuteamos seleccionar primero a los proyectos cuyo control
preciso no importe demasiado
En los uacuteltimos 40 antildeos nos hemos torturado por nuestra
ineptitud en acabar proyectos a tiempo y con el presupuesto
previsto Pero como sugeriacute antes no deberiacutea haber sido el
objetivo supremo
El objetivo maacutes importante es la transformacioacuten crear software
que cambie el mundo o que transforme una empresa o la forma
en que hace negocios
El desarrollo de software es y seraacute siempre algo experimental
La construccioacuten real de software no es necesariamente
experimental pero siacute lo es su concepcioacuten Alliacute deberiacuteamos
enfocar nuestros esfuerzos Alliacute es donde deberiacuteamos haberlo
hecho siempre Estaacute claro que es mucho maacutes faacutecil criticar un
artiacuteculo que hacer uno nuevo pero dada la trascendencia que estaacute
teniendo este escrito en particular voy a expresar mi opinioacuten
Creo que DeMarco sabe venderse Creo que cuando era maacutes
joven se supo posicionar como guruacute de la Ingenieriacutea de Software
y el control de proyectos y creo que ahora estaacute en la edad en que
puede decir que parte de lo que dijo estaacute mal e igual quedar bien
porque su posicioacuten coincide con la de muchos guruacutees actuales
Sin embargo me parece que el artiacuteculo estaacute lleno de frases
impactantes pero que no salen de un anaacutelisis profundo Me voy
a explayar
] INGENIERIacuteA DE SOFTWARE
5
INGENIERIacuteA DE SISTEMAS
Fig 3 Referencia a las Meacutetricas cuestan dinero
Que las meacutetricas cuestan dinero en cierto sentido es cierto
Tambieacuten es cierto que ahora es mucho maacutes faacutecil llevar algunas
meacutetricas que hace unos antildeos dado que ahora utilizamos
herramientas que las generan de manera automaacutetica Podriacuteamos
decir que en el presente es mucho menos costoso tener la misma
informacioacuten que hace unas deacutecadas DeMarco consideraba
importante
Que el desarrollo de software es inherentemente diferente de las
ciencias naturales como la fiacutesica tambieacuten es verdad Lo que no
se termina de entender es por queacute nos comparamos con las
Fiacutesicas y no con las Ingenieriacuteas
El disentildeo de una planta de gas en situaciones extremas tambieacuten
es uacutenico y con resultados impredecibles la construccioacuten de una
torre en Dubai alguacuten nuevo prototipo de avioacuten un nuevo
celular etc tambieacuten son inherentemente diferentes de las
ciencias naturales y sin embargo cuentan con presupuestos
meacutetricas de avance de defectos etc O sea es una verdad pero
que no aplica a la conclusioacuten a la que llega
Donde puedo estar maacutes de acuerdo es cuando hablamos del
control de proyectos de software aunque maacutes adelante voy a
definir mi posicioacuten En este caso en mi opinioacuten tambieacuten escribe
algo cierto ―El control no es lo maacutes importante de un proyecto
de software pero cuando toma ejemplos elije dos proyectos en
los que las desviaciones admitidas eran del orden de entre 100
y 1000 ya que o el objetivo era otro o los resultados
esperados eran mucho mayores a una desviacioacuten de 500 en
costos
Fig 1 Referencia de Google Earth
Ambos proyectos (Wikipedia que surge de NuPedia) y
GoogleEarth fueron proyectos en los que hubo inversores
poniendo su dinero durante antildeos sin ver resultados Se puede
buscar en Internet acerca de la historia de NuPedia antecesora
de Wikipedia y a Jimi Wales explicando que despueacutes de haber
gastado 250000 doacutelares solo habiacutea logrado 16 artiacuteculos en su
nueva Enciclopedia Lo mismo pasoacute con GoogleEarth
anteriormente en manos de KeyHole con inversores como Sony
y otros Fondos de Capital En este tipo de proyectos se pueden
asumir peacuterdidas durante antildeos hasta lograr un producto que
puede romper con el mercado o tambieacuten se puede perder todo lo
invertido Se trata de proyectos de inversioacuten de alto riesgo y
determinan proyectos de desarrollo que claramente son poco
comunes
Fig 3 Referencia de WIKIPEDIA
Al menos en mi entorno la mayoriacutea de los proyectos son
internos o externos (para un cliente) Los proyectos externos
tienen presupuestos o se crean luego de llamados a licitacioacuten
Es decir costo fijo tiempo fijo alcance fijo maacutes menos alguna
que otra variacioacuten Es claro que si no contamos con un miacutenimo
de control en estos proyectos la empresa no sabe si estaacute siendo
rentable o no Tampoco sabe si el producto que es desarrollado
le puede traer problemas a futuro por alguna cuestioacuten de calidad
No poner un miacutenimo eacutenfasis en el control de estos proyectos
puede llevar a la empresa a la quiebra sin que esta sea
consciente salvo por los nuacutemeros rojos que aparecen en sus
balances Por lo tanto explicar que un proyecto de software no
hace falta controlarlo mucho y poner como ejemplo dos casos
muy poco relevantes no parece muy serio
Por uacuteltimo cuando dice el desarrollo de software es y siempre
seraacute algo experimental vuelve a caer en las afirmaciones de las
que en 40 antildeos (en caso de estar vivo claro) podriacutea volver a
arrepentirse Es cierto que todaviacutea estamos en una etapa inicial
de la que llamamos ingenieriacutea de software Es cierto que no es
faacutecil gestionar proyectos de software por sus caracteriacutesticas
intriacutensecas (intangibilidad maleabilidad etc) pero cada
ingenieriacutea tiene sus problemas particulares y cada una supo
evolucionar a lo que son ahora Seguramente la ingenieriacutea de
Software con el tiempo encontraraacute su camino
Ahora bien aparte de criticar un poco a DeMarco (que era lo
maacutes faacutecil) vamos a retomar la frase
―No puedes controlar lo que no puedes medir lleva impliacutecita
que el control es un aspecto importante quizaacutes el maacutes
importante de cualquier proyecto de software Pero no lo es
En cierta medida explicaba arriba estoy de acuerdo con esta
afirmacioacuten Un buen proyecto de software con mucho control
pero malos programadores lleva al fracaso inevitablemente (lo
he vivido personalmente y por experiencias de terceros) Por el
contrario un buen equipo de programadores (pero de los
buenos) puede terminar el proyecto maacutes complejo haciendo que
ninguacuten indicador tenga sentido ya que la diferencia de calidad
del producto y la eficiencia del trabajo de este tipo de gente
multiplica por 10 o por 100 la de un equipo estaacutendar
Este tipo de gente piensa las cosas de manera diferente tiene la
calidad incorporada como meacutetodo de trabajo y la capacidad de
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
6
generar soluciones a las distintas situaciones hace que el
esfuerzo estimado pueda acortarse en oacuterdenes de magnitud
Estuve dentro equipos de este estilo y lo que se puede lograr en
un ambiente hiperproductivo difiacutecilmente se logre en una
empresa de desarrollo comuacuten y corriente El problema es que la
gente que tiene estas cualidades escasea y el mercado estaacute lleno
de trabajadores ―estaacutendar que requieren definiciones procesos
un aacuterea de calidad que verifique sus entregables y un PM que le
indique queacute es lo que tiene que hacer De a poco estimo yo la
industria iraacute decantando por rendimiento aquellos profesionales
que hacen la diferencia y los estaacutendares de productividad
calidad base teoacuterica requerida para un puesto iraacuten aumentando
Fue pasando durante estas deacutecadas y seguiraacute pasando en el
futuro
II CONCLUSIONES
En siacutentesis y para terminar con este artiacuteculo medir y controlar
importa importa maacutes en las empresas con gente estaacutendar
importa maacutes en las empresas con proyectos estaacutendar y siempre
que estemos dentro de una empresa algo vamos a tener que
medir pero el control no es condicioacuten necesaria ni menos
suficiente para lograr un proyecto exitoso No es algo
fundamental como tener un buen equipo de programadores
como tener gente que sepa interpretar lo que se pide y
transformarlo de manera natural en la solucioacuten que el cliente
necesita Por eso cuando veo gente que se preocupa por
aumentar el control o aumentar los procesos creo que estaacute
perdiendo el foco cuando lo que deberiacutea buscar es coacutemo hacer
para encontrar y hacer rendir a los verdaderos profesionales del
software
III REFERENCIAS
[1] Software Engenieering an idea whose time has come and gone por Tom
DeMarco [2] CyS Ingenieria de Software El blog del aacuterea de Ingenieriacutea de Software de
CyS Informaacutetica SA
] INGENIERIacuteA DE SOFTWARE
7
INGENIERIacuteA DE SISTEMAS
EXTREME PROGRAMMING PARA DESARROLLO
DE SOFTWARE
Erwin Adaacuten Choque Ulloa Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
Plaza Avaroa esq Belisario Salinas
La paz ndash Bolivia adan_ekinghotmailcom
Resumen
En este articulo se describiraacute algunas de las metodologiacuteas
agiles de desarrollo de software puesto que para asegurar el
eacutexito durante el desarrollo de un software es importante
saber la metodologiacutea de desarrollo la cual nos provee una
guiacutea para la correcta aplicacioacuten y desarrollo de Software
La metodologiacutea Extreme Programming XP que es una de las
metodologiacuteas aacutegiles maacutes extendidas y populares ademaacutes es
considerada como una metodologiacutea posmoderna donde
grandes capacidades se generan a traveacutes de procesos
emergentes
Palabras claves Extreme Programming metodologiacutea software
usuario
1 INTRODUCCION
El esquema tradicional para abordar el desarrollo de
software ha demostrado ser efectivo y necesario en
proyectos de gran tamantildeo respecto a tiempo y recursos
Sin embargo este enfoque no resulta ser el maacutes adecuado
para muchos de los proyectos actuales donde el entorno
del sistema es muy cambiante y en donde se exige
reducir draacutesticamente los tiempos de desarrollo pero
manteniendo una alta calidad Ante este problema las
metodologiacuteas aacutegiles son una posible respuesta para llenar
ese vaciacuteo metodoloacutegico Orientadas para proyectos
pequentildeos las metodologiacuteas aacutegiles constituyen una
solucioacuten
A continuacioacuten se describiraacute cada una de las
metodologiacuteas de desarrollo de software
2 EXTREME PROGRAMMING XP
La metodologiacutea de desarrollo de software XP es la
primera metodologiacutea aacutegil y la que le dio conciencia al
movimiento actual de metodologiacuteas aacutegiles Kent Beck el
padre de la metodologiacutea XP se basa en realimentacioacuten
continua entre el cliente y el equipo de desarrollo
comunicacioacuten fluida entre todos los participantes
simplicidad en las soluciones implementadas y facilidad
para enfrentar los cambios XP se define como
especialmente adecuada para proyectos con requisitos
imprecisos y muy cambiantes y donde existe un alto
riesgo teacutecnico Ahora se describiraacute las caracteriacutesticas
esenciales del Extreme Programming
21 LAS HISTORIAS DEL USUARIO
La red Las historias del usuario es la teacutecnica utilizada
para especificar los requisitos de software son tarjetas de
papel donde el cliente especifica de manera simplificada
las caracteriacutesticas que el sistema debe poseer ya sean
requisitos funcionales o requisitos no funcionales Se
caracteriza por ser dinaacutemica y flexible cada historia de
usuario debe ser comprensible y delimitada para que los
programadores puedan implementarla en pocas semanas
22 ROLES XP
Seguacuten Kent Beck los roles son
Programador El programador se encarga de escribir las
pruebas unitarias y tambieacuten estaacute encargado de producir el
coacutedigo del sistema
Cliente Encargado de escribir las historias de usuario y
los requisitos funcionales y selecciona las historias por
prioridad de conveniencia al negocio
Encargado de pruebas Encargado de ayudar al cliente a
escribir las pruebas funcionales ademaacutes de ejecutar las
pruebas constantemente encargado de de las
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
8
herramientas de soporte de pruebas como tambieacuten
difundir los resultados de dicha prueba
Encargado de seguimiento Es el encargado de la
realimentacioacuten al equipo y realiza el seguimiento del
proceso de cada iteracioacuten
Entrenador Es el encargado de prever guiacuteas al equipo
basadas en XP y de seguir el proceso correctamente
Consultor Es el que posee un conocimiento especifico
en alguacuten tema necesario para el proyecto para solucionar
problemas
Gestor Es la interaccioacuten entre clientes y programadores
ayudando a trabajar de forma adecuada y de esta manera
coordinar de forma correcta
23 PROCESO XP
El ciclo de desarrollo XP consiste en
El cliente define el valor del negocio a implementar
El programador estima el esfuerzo necesario para su
implementacioacuten
El cliente selecciona que construir de acuerdo con sus
propiedades y las restricciones del tiempo
El programador construye ese valor de negocio
Vuelve al principio
En todas las iteraciones de este ciclo tanto el cliente como
el programador aprenden No se debe presionar al
programador a realizar maacutes trabajo que el estimado ya
que se perderaacute calidad en el software o no se cumpliraacuten
los plazos
El ciclo de vida ideal de XP consiste de seis fases
Exploracioacuten
Planificacioacuten de la Entrega (Release)
Iteraciones
Produccioacuten
Mantenimiento y Muerte del Proyecto
24 PRACTICAS XP
Las siguientes praacutecticas ayudan al desarrollo de software
El juego de la planificacioacuten Hay una comunicacioacuten
frecuente el cliente y los programadores El equipo
teacutecnico realiza una estimacioacuten del esfuerzo requerido para
la implementacioacuten de las historias de usuario y los
clientes deciden sobre el aacutembito y el tiempo de entregas y
de cada iteracioacuten
Entregas pequentildeas Producir raacutepidamente versiones del
sistema que sean operativas aunque no cuenten con toda
la funcionalidad del sistema Esta versioacuten ya constituye
un resultado de valor para el negocio Una entrega no
deberiacutea tardar maacutes de tres meses
Metaacutefora El sistema es definido mediante un conjunto
de metaacuteforas compartidas por el cliente y el equipo de
desarrollo Una metaacutefora es una historia compartida que
describe como deberiacutea funcionar el sistema
Disentildeo simple Se disentildea la solucioacuten maacutes simple que
pueda funcionar y ser implementada en un determinado
momento del proyecto
Pruebas La produccioacuten de coacutedigo estaacute dirigida para las
pruebas unitarias Estas son establecidas por el cliente
antes de escribirse el coacutedigo y son ejecutadas
continuamente ante cada modificacioacuten del sistema
Pruebas Es una actividad constante de reestructuracioacuten
del coacutedigo con el objetivo de remover duplicacioacuten de
coacutedigo mejorar su legibilidad simplificarlo y hacerlo
maacutes flexible para facilitar los cambios Se mejora la
estructura interna del coacutedigo sin alterar su
comportamiento externo
Programacioacuten en parejas Toda la produccioacuten del
coacutedigo debe realizarse con trabajo en parejas de
programadores Para tener ventajas como menor tasa de
errores mejor disentildeo etc
Propiedad colectiva del coacutedigo Cualquier programador
puede cambiar cualquier parte del coacutedigo en cualquier
instante
Integracioacuten continua Cada pieza del coacutedigo es
integrada en el sistema una vez que este listaasi el
sistema puede ser integrado y construido varias veces en
un mismo diacutea
40 horas por semana Se debe trabajar un maacuteximo de 40
horas por semana no se trabajan horas extras en dos
semanas seguidas Si esto ocurre estaacute existe un problema
porque el trabajo extra desmotiva al equipo
Cliente in-situ El cliente tiene que estar presente y
disponible todo el tiempo para el equipo este es uno de
los principales factores de eacutexito para el proyecto XP Y
asiacute guiar y disipar cualquier duda de los programadores
donde la comunicacioacuten es maacutes efectiva que la escrita
Estaacutendares de programacioacuten XP enfatiza que la
comunicacioacuten de los programadores es a traveacutes del
coacutedigo por lo que es importante que se sigan estaacutendares
de programacioacuten para mantener el coacutedigo legible
3 CONCLUCIONES
] INGENIERIacuteA DE SOFTWARE
9
INGENIERIacuteA DE SISTEMAS
Las metodologiacuteas aacutegiles ofrecen una solucioacuten casi a
medida para una gran cantidad de proyectos
La metodologiacutea XP es una de las metodologiacuteas aacutegiles maacutes
extendidas y populares ademaacutes es considerada como una
metodologiacutea posmoderna cuyas grandes capacidades se
generan a traveacutes de procesos emergentes
4 REFERENCIAS
httpwwwmetodologiasSoftcomdesarrolloagil
httpwwwwikipediacommetodologiaXP
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
10
Desarrollo de Scrum
Sergio J Guzmaacuten L Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 Octubre Esq Belisario Salinas
La Paz - Bolivia
sjguzmanusfaedubo
Resumenmdash Scrum es una metodologiacutea aacutegil de desarrollo de
proyectos que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ldquocampos de scrumrdquo al
software
Palabras clave mdash scrum metodologiacutea patroacuten software
sprint rol
I Que es Scrum
Scrum es una metodologiacutea aacutegil de desarrollo de proyectos
que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ―campos de scrum al
software
Esta fue la primera definicioacuten de un patroacuten Scrum aplicado
al software disentildeada por Jeff Sutherland y Ken Schwaber y
presentada en Object-Oriented Programming Systems
Languages amp Applications OOPSLA en 1996
II iquestCoacutemo incorporarla
La competitividad del mercado de desarrollo de Software y
la necesidad de los clientes de reducir el tiempo de
mercado obligan a las organizaciones de desarrollo de
software a ser agresivas en sus calendarios de entrega Esto
ha hecho que hayan surgido metodologiacuteas para la gestioacuten y
desarrollo de software basadas en un proceso iterativo e
incremental Su estructura estaacute basada en corto tiempo los
cuales son iteraciones de 1 a 4 semanas Scrum se usa en
proyectos de entorno complejos donde se desea obtener
resultados raacutepidos y la productividad es lo maacutes importante
En los proyectos basados en Scrum se consideran tres
roles
Duentildeo del producto Es quien determina las propiedades de
los entregables
Maestro de Scrum Administra y facilita la ejecucioacuten del
proceso
Equipo de Trabajo Trabajan en conjunto para entregar
resultados en cada sprint
Fig 1 El flujo de Scrum
Como se puede observar en medio de los participantes del
proceso no quedan claras las responsabilidades del
arquitecto de software Sin embargo como comenta
Charlie Alfred ―la arquitectura es al aceite y el filtro que
lubrica adecuadamente a Scrum
Fig 2 El flujo de Scrum
] INGENIERIacuteA DE SOFTWARE
11
INGENIERIacuteA DE SISTEMAS
Si se compara el rol del arquitecto de edificaciones con el
del arquitecto de software se puede observar que ambos
modelan las construcciones a un alto nivel de abstraccioacuten
proveen posibles soluciones mejoran la comunicacioacuten con
los miembros del equipo de construccioacuten a traveacutes de
modelos visualizan las generalidades del problema
definen los roles y las interacciones entre los componentes
de construccioacuten entre otras tareas Al igual que es
imposible pensar que un rascacielos puede ser construido
sin una arquitectura soacutelida es imposible pensar que
productos de software empresariales puedan ser
implementados sin una arquitectura bien pensada
Seguacuten Bass Clements y Kasman ―La arquitectura de
software de un programa o sistema informaacutetico es la
estructura o estructuras del sistema que incluyen elementos
de software las propiedades externamente visibles de esos
elementos y las relaciones entre ellos Esta definicioacuten nos
lleva a concluir que la arquitectura de software garantiza el
buen desarrollo del software y a tener un sistema que
cumpla con los requerimientos funcionales y no
funcionales del cliente Ademaacutes la arquitectura es clave en
la reutilizacioacuten de artefactos de software en sistemas de
liacutenea de productos de software
Viendo la importancia de la arquitectura en el desarrollo
del software en eacuteste artiacuteculo se presenta una propuesta para
gestionar la arquitectura de Software en Scrum En el
primer capiacutetulo se trata el tema de la localizacioacuten de la
arquitectura de software en el ciclo de desarrollo de Scrum
en el segundo capiacutetulo se describen las tareas del arquitecto
de software en Scrum finalmente se presentan las
conclusiones y el trabajo futuro
III Arquitectura de Software en el ciclo de desarrollo de
Scrum
La idea fundamental de la presente propuesta es adicionar
un sprint inicial llamado ―Sprint 0Prime al inicio del ciclo de
desarrollo El objetivo principal del arquitecto en el Sprint
0 es analizar y disentildear la generalidad del sistema que
satisfaga los requisitos y sea entendible por los miembros
del equipo desde sus diferentes puntos de vista durante el
desarrollo Un punto clave es reutilizar artefactos de
software creados a partir de la arquitectura para ser maacutes
aacutegiles en el desarrollo de productos especiacuteficos
El Sprint 0 comprende tres fases que fueron tomadas del
ciclo de vida de entregas evolutivas En el Sprint 0 se
construye la arquitectura de forma iterativa mediante un
anaacutelisis preliminar de los conductores arquitectoacutenicos
(requisitos funcionales de calidad y del negocio) y de un
estudio de factibilidad del proyecto No se necesita tener
todos los requisitos claros para comenzar la fase de disentildeo
arquitectoacutenico
Para determinar los conductores arquitectoacutenicos se debe
identificar los objetivos del negocio de maacutes alta prioridad
que son pocos Estos objetivos del negocio se convierten en
los escenarios de calidad o casos de uso De esta lista se
deben escoger los que tendraacuten un mayor impacto sobre la
arquitectura El disentildeo arquitectoacutenico puede comenzar una
vez que se encuentran definidos los conductores
arquitectoacutenicos El proceso de anaacutelisis de requisitos seraacute
entonces influenciado por las preguntas generadas durante
el disentildeo arquitectoacutenico
El resultado del Srpint 0 es un documento inicial que
explica la arquitectura El documento puede basarse en los
pasos definidos por el meacutetodo ADD (Attrbute Driver
Design) Este meacutetodo ha sido probado exitosamente en
proyectos anteriores Con ADD se puede definir una
arquitectura de software mediante un proceso de
descomposicioacuten basado en los atributos de calidad de
Software
El documento inicial de la arquitectura se debe avaluar con
el fin de saber si la arquitectura cumple con los requisitos
de calidad Para realizar esta evaluacioacuten se propone el
meacutetodo ATAM (Architecture Tradeoff Analysis Method)
El ATAM revela cuaacuten bien una arquitectura satisface los
objetivos particulares de calidad y provee una
aproximacioacuten de coacutemo los objetivos de calidad interactuacutean
Si la evaluacioacuten de la arquitectura se encuentra que se
deben realizar cambios a la misma entonces eacutesta se debe
refinar hasta llegar a tener como resultado del Sprint 0 el
documento puacuteblico de la arquitectura junto con el sistema
esqueleto Finalmente la arquitectura creada en el Sprint 0
beneficiaraacute el desarrollo en los siguientes sprints
IV Rol del arquitecto de Software en Scrum
El rol y actividades del arquitecto de software cambian de
enfoque dependiendo de si se estaacute en el Sprint 0 o en
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
12
sprints subsecuentes
Fig 3 La Comunicacioacuten
Sprint 0 En sistemas complejos una persona difiacutecilmente
puede cubrir con amplitud teacutecnica las decisiones
arquitectoacutenicas y dar credibilidad a la arquitectura de
software Esto quiere decir que la participacioacuten del equipo
es de vital importancia para la creacioacuten y el mantenimiento
de la arquitectura Un equipo de arquitectos de software
que se aiacutesle del equipo de Scrum puede producir una
arquitectura que corra el riesgo de ser rechazada Es por
esto que recomendamos que el arquitecto o los arquitectos
se software sean miembros del equipo de Scrum Una de
las actividades que se debe realizar en equipo es la
evaluacioacuten de la arquitectura Especiacuteficamente en el
meacutetodo ATAM se requiere la participacioacuten mutua de tres
equipos que trabajan en conjunto con los arquitectos de
software el de evaluacioacuten el de tomadores de decisiones
del proyecto y el de los involucrados en la arquitectura
Sprints subsecuentes El arquitecto de software asegura que
el equipo de Scrum entienda el enfoque y los retos
arquitectoacutenicos maacutes importantes en casa sprint Los
equipos de Scrum realizan construcciones cortas guiados
por las estrategias de la arquitectura A continuacioacuten se
nombran algunas de las responsabilidades del arquitecto de
software desde el Sprint 1 en adelante
El duentildeo del producto y el maestro del Scrum trabajan con
el arquitecto para priorizar los requisitos a implementar en
cada iteracioacuten
El arquitecto comunica las decisiones y facilita las
conversaciones arquitectoacutenicas de distintos puntos de vista
en cada sprint
El arquitecto asegura que haya conformidad entre las
entregas en cada sprint y la arquitectura
El arquitecto responde preguntas y da orientacioacuten
arquitectoacutenica cuando sea necesario
Junto con el maestro de Scrum coordina a los miembros
del equipo para adaptarse a la arquitectura previa
El arquitecto junto con el duentildeo del producto y los
miembros del equipo preparan el Product Backlog
V Conclusioacuten
En el presente artiacuteculo ofrecimos una propuesta para incluir
la arquitectura de software en Scrum En el Sprint 0 se
realizan las actividades concernientes al anaacutelisis y disentildeo
de la arquitectura de software y el sistema esqueleto En
los siguientes sprints el arquitecto de software se asegura
de que la implementacioacuten cumpla con la arquitectura
REFERENCIAS
[3] httpwwwsafecreativeorgwork
[4] Hirotaka Takeuchi es decano de la Graduate School of International
Corporate Strategy en la Universidad Hitotsubashi en Tokio y fue profesor visitante en la Escuela de Negocios Harvard entre 1989 y 1990
[5] Ikujiro NonakaNo soy un guruacute porque me falta carisma
] INGENIERIacuteA DE SOFTWARE
13
INGENIERIacuteA DE SISTEMAS
El futuro de la ingenieriacutea de software Luis E Aguirre
Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 de Octubre esq Belisario Salinas
La Paz - Bolivia leaguirreusfaedubo
Resumen El disentildeo de programas a partir de informacioacuten binaria
significoacute un paso sustantivo para la industria desarrolladora de
software Desde ese hallazgo ocurrido en la deacutecada de los
cincuenta hasta hoy el crecimiento de metodologiacuteas para su
desarrollo ha subido notablemente en complejidad Sin embargo
los ciacuterculos viciosos que acusa hoy la confeccioacuten de programas
informaacuteticos impiden conceptualizar el objeto a un nivel
superior de abstraccioacuten tal y como lo exige el avance tecnoloacutegico
y los procesos de negocios
Palabras clave mdash futuro software ingenieriacutea programador y
desarrollo
I Introduccioacuten
La calidad de los sistemas informaacuteticos satisfaccioacuten de sus
usuarios y clientes son temas ampliamente conocidos
recurrentes y de constante preocupacioacuten por parte de los
practicantes de la Ingenieriacutea de software
Esta joven y dinaacutemica ingenieriacutea siempre estaacute en busca de
mejoras en el desarrollo de sistemas aumento de
productividad del ingeniero de software mayor control del
proceso de desarrollo establecimiento de nuevos meacutetodos de
desarrollo
Fig 1 Primeros programas computacionales en formato de tarjeta perforada
Estos elementos combinados y aplicados de buena forma
logran un buen proceso de desarrollo y en definitiva un buen
producto
Identificar los pasos que ha recorrido esta ingenieriacutea analizar
su contexto actual y finalmente proyectar hacia doacutende se
dirige es el pilar de este artiacuteculo
II iquestSe aplica actualmente la ingenieriacutea del software
La investigacioacuten y el desarrollo de teacutecnicas y meacuteto
dos de ingenieriacutea del software son constantes y suelen suponer
interesantes avances en la resolucioacuten de problemas de
desarrollo de software Sin embargo es habitual que en la
praacutectica diaria profesional no se incluya praacutecticamente
ninguna de las recomendaciones maacutes elementales de la
ingenieriacutea del software En efecto es habitual que el
desarrollo de software se parezca maacutes al descontrol del cuento
de laquosi los programadores fueran albantildeilesraquo ([Novatica
1996]) que a una idiacutelica y bien organizada factoriacutea de
software (concepto de gran vigencia a finales de los ochenta
[Nunamaker et al 1988])
De hecho las evaluaciones de los procesos productivos de
software realizadas a raiacutez de los modelo de procesos de
software (por ejemplo con CMM [Paulk et al 1993])
confirman que el desarrollo de software suele estar
baacutesicamente en estado caoacutetico
Y no soacutelo en como uno podriacutea pensar pequentildeas
organizaciones de un paiacutes mediterraacuteneo como el nuestro sino
en tambieacuten en las empresas adjudicatarias de interesantes
contratos de defensa de paiacuteses laquoavanzadosraquo como EEUU o
Japoacuten Si bien estos modelos de evaluacioacuten auacuten acumulan
distintas acusaciones de rigidez o falta de contraste empiacuterico
los resultados obtenidos en sus evaluaciones resultan
consistentes con la sensacioacuten de constante laquoapagafuegosraquo que
suelen sufrir los profesionales del software Tambieacuten suelen
revelar la praacutectica despreocupacioacuten de los responsables de las
organizaciones de software por la mejora de la calidad de sus
procesos de trabajo o de sus productos bien sea por contar con
una situacioacuten interna de empresa poco propicia porque el
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
14
ambiente del mercado no fomenta la preocupacioacuten por estos
temas o bien por su poco intereacutes real en la buacutesqueda de la
calidad
III La actualidad
La gran mayoriacutea de los sistemas de software creados hoy en
diacutea son los llamados sistemas corporativos es decir son
orientados a formar una parte importante de los negocios de
las grandes empresas
Continuando en nuestro contexto se identifica un nuevo
enfoque del problema de desarrollo el apoyo en la
sincronizacioacuten de los procesos de negocio estructuras
complejas de informacioacuten manejada por el negocio todo esto
entrelazado por restricciones dadas por las reglas del negocio
La tecnologiacutea actual por otro lado ha alejado maacutes todaviacutea los
ingenieros de las maacutequinas sistemas operativos incluso de
las tareas de programacioacuten
El enfoque de la mayoriacutea de los equipos de desarrollo e
ingenieros participes en proyectos sigue siendo con un bajo
nivel de abstraccioacuten cerca de la codificacioacuten Se tiende a
pensar en la base de datos a utilizar establecer la navegacioacuten
de las paacuteginas programar los protocolos de comunicacioacuten etc
Esto lleva a utilizar las tareas de programacioacuten y de pruebas
para validar el entendimiento y cumplimiento de la
funcionalidad de los sistemas
Lo anteriormente expuesto muestra un problema
metodoloacutegico consecuencia de un desfase entre el enfoque
teoacuterico oacuteptimo (anaacutelisis de negocio) y el enfoque praacutectico real
(programacioacuten y pruebas) en los proyectos de hoy En otras
palabras la metodologiacutea actualmente usada estaacute atrasada con
respecto al avance tecnoloacutegico
Desarrollando maacutes esta idea se identifican algunos
problemas concretos de las metodologiacuteas
Ellas no obligan a sus ejecutores a respetar todas las
normas y los procedimientos establecidos especialmente
en las etapas tempranas del proyecto Es muy faacutecil y
tentador ―saltar una o maacutes de estas etapas uno o maacutes
documentos o modelos pasando directamente a
implementacioacuten produccioacuten y posterior correccioacuten de los
sistemas desarrollados
Control de calidad del producto final La codificacioacuten y
complejidad del programa es demasiada para ser revisada
y verificada fehacientemente Por otro lado los coacutedigos
fuentes y los ejecutables actualmente son los uacutenicos
entregables eficientemente verificables
Estos dos problemas al parecer forman una situacioacuten
contradictoria la metodologiacutea tradicional no permite validar
eficientemente la calidad de los sistemas antes de llegar al
coacutedigo fuente y por otro lado tampoco permite llegar
eficientemente a coacutedigos fuentes de calidad
IV Futuro
La salida de este ―ciacuterculo vicioso que se propone es
bastante natural analizar la situacioacuten actual de la ingenieriacutea
de software en la luz de sus tendencias histoacutericas
La primera de ellas relacionada con los problemas que
resuelven los sistemas obviamente presente y muy utilizada
en nuestra realidad los sistemas de hoy no soacutelo resuelven los
problemas del mundo real sino que estaacuten fuertemente influen-
ciando el desarrollo del mundo real
Fig2 Modela
El enfoque de los ingenieros desde hace unos antildeos no se ha
movido significativamente por el camino del aumento de
abstraccioacuten establecido histoacutericamente Se han hecho ciertos
avances en temas puntuales (como arquitecturas de
componentes patrones de disentildeo nuevos lenguajes de
programacioacuten etc) pero conceptualmente
metodoloacutegicamente la tarea de programacioacuten sigue siendo
ejecutada de la misma forma escribiendo coacutedigos fuentes en
forma de los programas textuales
Eacuteste es justamente el ―atraso metodoloacutegico que se
mencionoacute Para disminuir la brecha entre las tendencias
histoacutericas es necesario ajustar la metodologiacutea en teacuterminos de
aumentar la abstraccioacuten del enfoque de los ingenieros de
software y acercarlo a la abstraccioacuten del problema
El aumento de la abstraccioacuten del proceso de desarrollo del
software hace pensar que la proacutexima generacioacuten de meacutetodos
de desarrollo se perfila en un conceptualmente nuevo con-
] INGENIERIacuteA DE SOFTWARE
15
INGENIERIacuteA DE SISTEMAS
junto de herramientas que permitan aumentar en un mayor
grado al actual la abstraccioacuten escondiendo los detalles de maacutes
bajo nivel
Fig3 Probable modelo a futuro
Las nuevas herramientas permitiraacuten ―programar en nivel
de anaacutelisis generando coacutedigos en un lenguaje de
programacioacuten tradicional de forma automaacutetica tal como hoy
los compiladores generan el lenguaje maacutequina a partir del
coacutedigo fuente Nuevos ―lenguajes de programacioacuten
naturalmente seriacutean visuales y se pareceriacutean a las
especificaciones de software en uno de los lenguajes de
modelamiento por ejemplo UML
V Conclusioacuten
Es muy probable que estemos proacuteximos a ver un nuevo
paso evolutivo en la ingenieriacutea de software Tan grande como
el invento de lenguajes de alto nivel o anaacutelisis y disentildeo
orientado a objetos Una nueva generacioacuten que absorberaacute a la
actual automatizando la mayoriacutea de las buenas praacutecticas
usadas actualmente
Una pregunta natural es si una maacutequina puede llegar a
generar programas tan buenos como los hechos por un pro-
gramador experto En vez de ―romper la cabeza con esta
pregunta ahora quizaacutes seriacutea suficiente recordarse otra vez de
la historia Los primeros compiladores de ninguna generacioacuten
alcanzaban de inmediato lo deseable y oacuteptimo Sin embargo
con el paso del tiempo apoyados en la experiencia de los
ingenieros y en el avance tecnoloacutegico se mejoraban hasta el
nivel de superar significativamente las generaciones
anteriores
Es poco factible que hoy en diacutea alguien cuestione la calidad
de los compiladores de por ejemplo Java y la calidad del
coacutedigo de maacutequina generado por ellos
VI Referencias [6] Website [Online]
httpwwwenterpriseanalystnetdownloadmda_informaticap
df
[7] httpwwwslidesharenetamrrochafuturo-del-software-impacto-en-las-organizaciones-y-en-los-profesionales
[8] httpwwwdcubaareventseci2008conferenciasIngSoftHexacta
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
3
INGENIERIacuteA DE SISTEMAS
INDICE Tom DeMarco Ingenieria de Software y Control de
Proyectoshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip4
Adictos al helliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip6
Skinput Una pantalla taacutectil en tu pielhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip11
Mini
computadorashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip14
Estudio de redes
GNOPhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
7
La suacuteper caacutemara que lo ve
todohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip20
Des-
impresioacuten helliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
helliphelliphelliphelliphelliphelliphelliphelliphelliphellip23
Cloud
Computinghelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
helliphelliphelliphelliphelliphelliphelliphelliphellip26
Nano- celular
solareshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
helliphelliphelliphelliphellip29
Memorias USB en
moacuteduloshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
hellip32
Teleacutefonos moacuteviles de ultima
generacioacutenhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip34
My
coachhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip
helliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip37
Factores del Cableado en el Centro de Coacutemputohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip40
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
4
Tom DeMarco
Ingenieriacutea de Software
y Control de Proyectos Joe Luis Aramayo Blanco
Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
20 de Octubre Esq Belisario Salinas
La Paz - Bolivia jlaramayousfaeduboResumen- En este artiacuteculo
haremos algunas observaciones sobre un artiacuteculo
que escribioacute hace un tiempo atraacutes Tom DeMarco
sobre meacutetricas control de proyectos e
ingenieriacutea de software donde en general podemos
encontrar frases que claramente contradicen su
postura de hace unas deacutecadas
Palabras clave- Ingenieriacutea de Software Control de Proyectos
Meacutetricas No puedes controlar lo que no puedes medir Desarrollo
de Software
I INTRODUCCIOacuteN
Todos comprendemos que las meacutetricas de software cuestan
dinero y tiempo y que deben ser usadas con moderacioacuten
El desarrollo de software es inherentemente diferente de las
ciencias naturales tales como la fiacutesica por lo que sus meacutetricas
son mucho menos precisas para capturar lo que deben describir
La frase ―No puedes controlar lo que no puedes medir lleva
impliacutecita que el control es un aspecto importante quizaacutes el maacutes
importante de cualquier proyecto de software Pero no lo es
Fig 1 Ejemplo de ―No puedes controlar lo que no puedes medir
Muchos proyectos se han realizado sin demasiado control pero
han generado productos maravillosos tales como Google Earth o
la Wikipedia
Esto nos lleva a la desagradable conclusioacuten que el control
estricto es algo que importa mucho en proyectos relativamente
inuacutetiles y mucho menos en proyectos uacutetiles
iquestEstoy diciendo que estaacute bien ejecutar proyecto sin control o
con un control relativamente menor Casi Estoy sugiriendo que
deberiacuteamos seleccionar primero a los proyectos cuyo control
preciso no importe demasiado
En los uacuteltimos 40 antildeos nos hemos torturado por nuestra
ineptitud en acabar proyectos a tiempo y con el presupuesto
previsto Pero como sugeriacute antes no deberiacutea haber sido el
objetivo supremo
El objetivo maacutes importante es la transformacioacuten crear software
que cambie el mundo o que transforme una empresa o la forma
en que hace negocios
El desarrollo de software es y seraacute siempre algo experimental
La construccioacuten real de software no es necesariamente
experimental pero siacute lo es su concepcioacuten Alliacute deberiacuteamos
enfocar nuestros esfuerzos Alliacute es donde deberiacuteamos haberlo
hecho siempre Estaacute claro que es mucho maacutes faacutecil criticar un
artiacuteculo que hacer uno nuevo pero dada la trascendencia que estaacute
teniendo este escrito en particular voy a expresar mi opinioacuten
Creo que DeMarco sabe venderse Creo que cuando era maacutes
joven se supo posicionar como guruacute de la Ingenieriacutea de Software
y el control de proyectos y creo que ahora estaacute en la edad en que
puede decir que parte de lo que dijo estaacute mal e igual quedar bien
porque su posicioacuten coincide con la de muchos guruacutees actuales
Sin embargo me parece que el artiacuteculo estaacute lleno de frases
impactantes pero que no salen de un anaacutelisis profundo Me voy
a explayar
] INGENIERIacuteA DE SOFTWARE
5
INGENIERIacuteA DE SISTEMAS
Fig 3 Referencia a las Meacutetricas cuestan dinero
Que las meacutetricas cuestan dinero en cierto sentido es cierto
Tambieacuten es cierto que ahora es mucho maacutes faacutecil llevar algunas
meacutetricas que hace unos antildeos dado que ahora utilizamos
herramientas que las generan de manera automaacutetica Podriacuteamos
decir que en el presente es mucho menos costoso tener la misma
informacioacuten que hace unas deacutecadas DeMarco consideraba
importante
Que el desarrollo de software es inherentemente diferente de las
ciencias naturales como la fiacutesica tambieacuten es verdad Lo que no
se termina de entender es por queacute nos comparamos con las
Fiacutesicas y no con las Ingenieriacuteas
El disentildeo de una planta de gas en situaciones extremas tambieacuten
es uacutenico y con resultados impredecibles la construccioacuten de una
torre en Dubai alguacuten nuevo prototipo de avioacuten un nuevo
celular etc tambieacuten son inherentemente diferentes de las
ciencias naturales y sin embargo cuentan con presupuestos
meacutetricas de avance de defectos etc O sea es una verdad pero
que no aplica a la conclusioacuten a la que llega
Donde puedo estar maacutes de acuerdo es cuando hablamos del
control de proyectos de software aunque maacutes adelante voy a
definir mi posicioacuten En este caso en mi opinioacuten tambieacuten escribe
algo cierto ―El control no es lo maacutes importante de un proyecto
de software pero cuando toma ejemplos elije dos proyectos en
los que las desviaciones admitidas eran del orden de entre 100
y 1000 ya que o el objetivo era otro o los resultados
esperados eran mucho mayores a una desviacioacuten de 500 en
costos
Fig 1 Referencia de Google Earth
Ambos proyectos (Wikipedia que surge de NuPedia) y
GoogleEarth fueron proyectos en los que hubo inversores
poniendo su dinero durante antildeos sin ver resultados Se puede
buscar en Internet acerca de la historia de NuPedia antecesora
de Wikipedia y a Jimi Wales explicando que despueacutes de haber
gastado 250000 doacutelares solo habiacutea logrado 16 artiacuteculos en su
nueva Enciclopedia Lo mismo pasoacute con GoogleEarth
anteriormente en manos de KeyHole con inversores como Sony
y otros Fondos de Capital En este tipo de proyectos se pueden
asumir peacuterdidas durante antildeos hasta lograr un producto que
puede romper con el mercado o tambieacuten se puede perder todo lo
invertido Se trata de proyectos de inversioacuten de alto riesgo y
determinan proyectos de desarrollo que claramente son poco
comunes
Fig 3 Referencia de WIKIPEDIA
Al menos en mi entorno la mayoriacutea de los proyectos son
internos o externos (para un cliente) Los proyectos externos
tienen presupuestos o se crean luego de llamados a licitacioacuten
Es decir costo fijo tiempo fijo alcance fijo maacutes menos alguna
que otra variacioacuten Es claro que si no contamos con un miacutenimo
de control en estos proyectos la empresa no sabe si estaacute siendo
rentable o no Tampoco sabe si el producto que es desarrollado
le puede traer problemas a futuro por alguna cuestioacuten de calidad
No poner un miacutenimo eacutenfasis en el control de estos proyectos
puede llevar a la empresa a la quiebra sin que esta sea
consciente salvo por los nuacutemeros rojos que aparecen en sus
balances Por lo tanto explicar que un proyecto de software no
hace falta controlarlo mucho y poner como ejemplo dos casos
muy poco relevantes no parece muy serio
Por uacuteltimo cuando dice el desarrollo de software es y siempre
seraacute algo experimental vuelve a caer en las afirmaciones de las
que en 40 antildeos (en caso de estar vivo claro) podriacutea volver a
arrepentirse Es cierto que todaviacutea estamos en una etapa inicial
de la que llamamos ingenieriacutea de software Es cierto que no es
faacutecil gestionar proyectos de software por sus caracteriacutesticas
intriacutensecas (intangibilidad maleabilidad etc) pero cada
ingenieriacutea tiene sus problemas particulares y cada una supo
evolucionar a lo que son ahora Seguramente la ingenieriacutea de
Software con el tiempo encontraraacute su camino
Ahora bien aparte de criticar un poco a DeMarco (que era lo
maacutes faacutecil) vamos a retomar la frase
―No puedes controlar lo que no puedes medir lleva impliacutecita
que el control es un aspecto importante quizaacutes el maacutes
importante de cualquier proyecto de software Pero no lo es
En cierta medida explicaba arriba estoy de acuerdo con esta
afirmacioacuten Un buen proyecto de software con mucho control
pero malos programadores lleva al fracaso inevitablemente (lo
he vivido personalmente y por experiencias de terceros) Por el
contrario un buen equipo de programadores (pero de los
buenos) puede terminar el proyecto maacutes complejo haciendo que
ninguacuten indicador tenga sentido ya que la diferencia de calidad
del producto y la eficiencia del trabajo de este tipo de gente
multiplica por 10 o por 100 la de un equipo estaacutendar
Este tipo de gente piensa las cosas de manera diferente tiene la
calidad incorporada como meacutetodo de trabajo y la capacidad de
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
6
generar soluciones a las distintas situaciones hace que el
esfuerzo estimado pueda acortarse en oacuterdenes de magnitud
Estuve dentro equipos de este estilo y lo que se puede lograr en
un ambiente hiperproductivo difiacutecilmente se logre en una
empresa de desarrollo comuacuten y corriente El problema es que la
gente que tiene estas cualidades escasea y el mercado estaacute lleno
de trabajadores ―estaacutendar que requieren definiciones procesos
un aacuterea de calidad que verifique sus entregables y un PM que le
indique queacute es lo que tiene que hacer De a poco estimo yo la
industria iraacute decantando por rendimiento aquellos profesionales
que hacen la diferencia y los estaacutendares de productividad
calidad base teoacuterica requerida para un puesto iraacuten aumentando
Fue pasando durante estas deacutecadas y seguiraacute pasando en el
futuro
II CONCLUSIONES
En siacutentesis y para terminar con este artiacuteculo medir y controlar
importa importa maacutes en las empresas con gente estaacutendar
importa maacutes en las empresas con proyectos estaacutendar y siempre
que estemos dentro de una empresa algo vamos a tener que
medir pero el control no es condicioacuten necesaria ni menos
suficiente para lograr un proyecto exitoso No es algo
fundamental como tener un buen equipo de programadores
como tener gente que sepa interpretar lo que se pide y
transformarlo de manera natural en la solucioacuten que el cliente
necesita Por eso cuando veo gente que se preocupa por
aumentar el control o aumentar los procesos creo que estaacute
perdiendo el foco cuando lo que deberiacutea buscar es coacutemo hacer
para encontrar y hacer rendir a los verdaderos profesionales del
software
III REFERENCIAS
[1] Software Engenieering an idea whose time has come and gone por Tom
DeMarco [2] CyS Ingenieria de Software El blog del aacuterea de Ingenieriacutea de Software de
CyS Informaacutetica SA
] INGENIERIacuteA DE SOFTWARE
7
INGENIERIacuteA DE SISTEMAS
EXTREME PROGRAMMING PARA DESARROLLO
DE SOFTWARE
Erwin Adaacuten Choque Ulloa Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
Plaza Avaroa esq Belisario Salinas
La paz ndash Bolivia adan_ekinghotmailcom
Resumen
En este articulo se describiraacute algunas de las metodologiacuteas
agiles de desarrollo de software puesto que para asegurar el
eacutexito durante el desarrollo de un software es importante
saber la metodologiacutea de desarrollo la cual nos provee una
guiacutea para la correcta aplicacioacuten y desarrollo de Software
La metodologiacutea Extreme Programming XP que es una de las
metodologiacuteas aacutegiles maacutes extendidas y populares ademaacutes es
considerada como una metodologiacutea posmoderna donde
grandes capacidades se generan a traveacutes de procesos
emergentes
Palabras claves Extreme Programming metodologiacutea software
usuario
1 INTRODUCCION
El esquema tradicional para abordar el desarrollo de
software ha demostrado ser efectivo y necesario en
proyectos de gran tamantildeo respecto a tiempo y recursos
Sin embargo este enfoque no resulta ser el maacutes adecuado
para muchos de los proyectos actuales donde el entorno
del sistema es muy cambiante y en donde se exige
reducir draacutesticamente los tiempos de desarrollo pero
manteniendo una alta calidad Ante este problema las
metodologiacuteas aacutegiles son una posible respuesta para llenar
ese vaciacuteo metodoloacutegico Orientadas para proyectos
pequentildeos las metodologiacuteas aacutegiles constituyen una
solucioacuten
A continuacioacuten se describiraacute cada una de las
metodologiacuteas de desarrollo de software
2 EXTREME PROGRAMMING XP
La metodologiacutea de desarrollo de software XP es la
primera metodologiacutea aacutegil y la que le dio conciencia al
movimiento actual de metodologiacuteas aacutegiles Kent Beck el
padre de la metodologiacutea XP se basa en realimentacioacuten
continua entre el cliente y el equipo de desarrollo
comunicacioacuten fluida entre todos los participantes
simplicidad en las soluciones implementadas y facilidad
para enfrentar los cambios XP se define como
especialmente adecuada para proyectos con requisitos
imprecisos y muy cambiantes y donde existe un alto
riesgo teacutecnico Ahora se describiraacute las caracteriacutesticas
esenciales del Extreme Programming
21 LAS HISTORIAS DEL USUARIO
La red Las historias del usuario es la teacutecnica utilizada
para especificar los requisitos de software son tarjetas de
papel donde el cliente especifica de manera simplificada
las caracteriacutesticas que el sistema debe poseer ya sean
requisitos funcionales o requisitos no funcionales Se
caracteriza por ser dinaacutemica y flexible cada historia de
usuario debe ser comprensible y delimitada para que los
programadores puedan implementarla en pocas semanas
22 ROLES XP
Seguacuten Kent Beck los roles son
Programador El programador se encarga de escribir las
pruebas unitarias y tambieacuten estaacute encargado de producir el
coacutedigo del sistema
Cliente Encargado de escribir las historias de usuario y
los requisitos funcionales y selecciona las historias por
prioridad de conveniencia al negocio
Encargado de pruebas Encargado de ayudar al cliente a
escribir las pruebas funcionales ademaacutes de ejecutar las
pruebas constantemente encargado de de las
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
8
herramientas de soporte de pruebas como tambieacuten
difundir los resultados de dicha prueba
Encargado de seguimiento Es el encargado de la
realimentacioacuten al equipo y realiza el seguimiento del
proceso de cada iteracioacuten
Entrenador Es el encargado de prever guiacuteas al equipo
basadas en XP y de seguir el proceso correctamente
Consultor Es el que posee un conocimiento especifico
en alguacuten tema necesario para el proyecto para solucionar
problemas
Gestor Es la interaccioacuten entre clientes y programadores
ayudando a trabajar de forma adecuada y de esta manera
coordinar de forma correcta
23 PROCESO XP
El ciclo de desarrollo XP consiste en
El cliente define el valor del negocio a implementar
El programador estima el esfuerzo necesario para su
implementacioacuten
El cliente selecciona que construir de acuerdo con sus
propiedades y las restricciones del tiempo
El programador construye ese valor de negocio
Vuelve al principio
En todas las iteraciones de este ciclo tanto el cliente como
el programador aprenden No se debe presionar al
programador a realizar maacutes trabajo que el estimado ya
que se perderaacute calidad en el software o no se cumpliraacuten
los plazos
El ciclo de vida ideal de XP consiste de seis fases
Exploracioacuten
Planificacioacuten de la Entrega (Release)
Iteraciones
Produccioacuten
Mantenimiento y Muerte del Proyecto
24 PRACTICAS XP
Las siguientes praacutecticas ayudan al desarrollo de software
El juego de la planificacioacuten Hay una comunicacioacuten
frecuente el cliente y los programadores El equipo
teacutecnico realiza una estimacioacuten del esfuerzo requerido para
la implementacioacuten de las historias de usuario y los
clientes deciden sobre el aacutembito y el tiempo de entregas y
de cada iteracioacuten
Entregas pequentildeas Producir raacutepidamente versiones del
sistema que sean operativas aunque no cuenten con toda
la funcionalidad del sistema Esta versioacuten ya constituye
un resultado de valor para el negocio Una entrega no
deberiacutea tardar maacutes de tres meses
Metaacutefora El sistema es definido mediante un conjunto
de metaacuteforas compartidas por el cliente y el equipo de
desarrollo Una metaacutefora es una historia compartida que
describe como deberiacutea funcionar el sistema
Disentildeo simple Se disentildea la solucioacuten maacutes simple que
pueda funcionar y ser implementada en un determinado
momento del proyecto
Pruebas La produccioacuten de coacutedigo estaacute dirigida para las
pruebas unitarias Estas son establecidas por el cliente
antes de escribirse el coacutedigo y son ejecutadas
continuamente ante cada modificacioacuten del sistema
Pruebas Es una actividad constante de reestructuracioacuten
del coacutedigo con el objetivo de remover duplicacioacuten de
coacutedigo mejorar su legibilidad simplificarlo y hacerlo
maacutes flexible para facilitar los cambios Se mejora la
estructura interna del coacutedigo sin alterar su
comportamiento externo
Programacioacuten en parejas Toda la produccioacuten del
coacutedigo debe realizarse con trabajo en parejas de
programadores Para tener ventajas como menor tasa de
errores mejor disentildeo etc
Propiedad colectiva del coacutedigo Cualquier programador
puede cambiar cualquier parte del coacutedigo en cualquier
instante
Integracioacuten continua Cada pieza del coacutedigo es
integrada en el sistema una vez que este listaasi el
sistema puede ser integrado y construido varias veces en
un mismo diacutea
40 horas por semana Se debe trabajar un maacuteximo de 40
horas por semana no se trabajan horas extras en dos
semanas seguidas Si esto ocurre estaacute existe un problema
porque el trabajo extra desmotiva al equipo
Cliente in-situ El cliente tiene que estar presente y
disponible todo el tiempo para el equipo este es uno de
los principales factores de eacutexito para el proyecto XP Y
asiacute guiar y disipar cualquier duda de los programadores
donde la comunicacioacuten es maacutes efectiva que la escrita
Estaacutendares de programacioacuten XP enfatiza que la
comunicacioacuten de los programadores es a traveacutes del
coacutedigo por lo que es importante que se sigan estaacutendares
de programacioacuten para mantener el coacutedigo legible
3 CONCLUCIONES
] INGENIERIacuteA DE SOFTWARE
9
INGENIERIacuteA DE SISTEMAS
Las metodologiacuteas aacutegiles ofrecen una solucioacuten casi a
medida para una gran cantidad de proyectos
La metodologiacutea XP es una de las metodologiacuteas aacutegiles maacutes
extendidas y populares ademaacutes es considerada como una
metodologiacutea posmoderna cuyas grandes capacidades se
generan a traveacutes de procesos emergentes
4 REFERENCIAS
httpwwwmetodologiasSoftcomdesarrolloagil
httpwwwwikipediacommetodologiaXP
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
10
Desarrollo de Scrum
Sergio J Guzmaacuten L Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 Octubre Esq Belisario Salinas
La Paz - Bolivia
sjguzmanusfaedubo
Resumenmdash Scrum es una metodologiacutea aacutegil de desarrollo de
proyectos que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ldquocampos de scrumrdquo al
software
Palabras clave mdash scrum metodologiacutea patroacuten software
sprint rol
I Que es Scrum
Scrum es una metodologiacutea aacutegil de desarrollo de proyectos
que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ―campos de scrum al
software
Esta fue la primera definicioacuten de un patroacuten Scrum aplicado
al software disentildeada por Jeff Sutherland y Ken Schwaber y
presentada en Object-Oriented Programming Systems
Languages amp Applications OOPSLA en 1996
II iquestCoacutemo incorporarla
La competitividad del mercado de desarrollo de Software y
la necesidad de los clientes de reducir el tiempo de
mercado obligan a las organizaciones de desarrollo de
software a ser agresivas en sus calendarios de entrega Esto
ha hecho que hayan surgido metodologiacuteas para la gestioacuten y
desarrollo de software basadas en un proceso iterativo e
incremental Su estructura estaacute basada en corto tiempo los
cuales son iteraciones de 1 a 4 semanas Scrum se usa en
proyectos de entorno complejos donde se desea obtener
resultados raacutepidos y la productividad es lo maacutes importante
En los proyectos basados en Scrum se consideran tres
roles
Duentildeo del producto Es quien determina las propiedades de
los entregables
Maestro de Scrum Administra y facilita la ejecucioacuten del
proceso
Equipo de Trabajo Trabajan en conjunto para entregar
resultados en cada sprint
Fig 1 El flujo de Scrum
Como se puede observar en medio de los participantes del
proceso no quedan claras las responsabilidades del
arquitecto de software Sin embargo como comenta
Charlie Alfred ―la arquitectura es al aceite y el filtro que
lubrica adecuadamente a Scrum
Fig 2 El flujo de Scrum
] INGENIERIacuteA DE SOFTWARE
11
INGENIERIacuteA DE SISTEMAS
Si se compara el rol del arquitecto de edificaciones con el
del arquitecto de software se puede observar que ambos
modelan las construcciones a un alto nivel de abstraccioacuten
proveen posibles soluciones mejoran la comunicacioacuten con
los miembros del equipo de construccioacuten a traveacutes de
modelos visualizan las generalidades del problema
definen los roles y las interacciones entre los componentes
de construccioacuten entre otras tareas Al igual que es
imposible pensar que un rascacielos puede ser construido
sin una arquitectura soacutelida es imposible pensar que
productos de software empresariales puedan ser
implementados sin una arquitectura bien pensada
Seguacuten Bass Clements y Kasman ―La arquitectura de
software de un programa o sistema informaacutetico es la
estructura o estructuras del sistema que incluyen elementos
de software las propiedades externamente visibles de esos
elementos y las relaciones entre ellos Esta definicioacuten nos
lleva a concluir que la arquitectura de software garantiza el
buen desarrollo del software y a tener un sistema que
cumpla con los requerimientos funcionales y no
funcionales del cliente Ademaacutes la arquitectura es clave en
la reutilizacioacuten de artefactos de software en sistemas de
liacutenea de productos de software
Viendo la importancia de la arquitectura en el desarrollo
del software en eacuteste artiacuteculo se presenta una propuesta para
gestionar la arquitectura de Software en Scrum En el
primer capiacutetulo se trata el tema de la localizacioacuten de la
arquitectura de software en el ciclo de desarrollo de Scrum
en el segundo capiacutetulo se describen las tareas del arquitecto
de software en Scrum finalmente se presentan las
conclusiones y el trabajo futuro
III Arquitectura de Software en el ciclo de desarrollo de
Scrum
La idea fundamental de la presente propuesta es adicionar
un sprint inicial llamado ―Sprint 0Prime al inicio del ciclo de
desarrollo El objetivo principal del arquitecto en el Sprint
0 es analizar y disentildear la generalidad del sistema que
satisfaga los requisitos y sea entendible por los miembros
del equipo desde sus diferentes puntos de vista durante el
desarrollo Un punto clave es reutilizar artefactos de
software creados a partir de la arquitectura para ser maacutes
aacutegiles en el desarrollo de productos especiacuteficos
El Sprint 0 comprende tres fases que fueron tomadas del
ciclo de vida de entregas evolutivas En el Sprint 0 se
construye la arquitectura de forma iterativa mediante un
anaacutelisis preliminar de los conductores arquitectoacutenicos
(requisitos funcionales de calidad y del negocio) y de un
estudio de factibilidad del proyecto No se necesita tener
todos los requisitos claros para comenzar la fase de disentildeo
arquitectoacutenico
Para determinar los conductores arquitectoacutenicos se debe
identificar los objetivos del negocio de maacutes alta prioridad
que son pocos Estos objetivos del negocio se convierten en
los escenarios de calidad o casos de uso De esta lista se
deben escoger los que tendraacuten un mayor impacto sobre la
arquitectura El disentildeo arquitectoacutenico puede comenzar una
vez que se encuentran definidos los conductores
arquitectoacutenicos El proceso de anaacutelisis de requisitos seraacute
entonces influenciado por las preguntas generadas durante
el disentildeo arquitectoacutenico
El resultado del Srpint 0 es un documento inicial que
explica la arquitectura El documento puede basarse en los
pasos definidos por el meacutetodo ADD (Attrbute Driver
Design) Este meacutetodo ha sido probado exitosamente en
proyectos anteriores Con ADD se puede definir una
arquitectura de software mediante un proceso de
descomposicioacuten basado en los atributos de calidad de
Software
El documento inicial de la arquitectura se debe avaluar con
el fin de saber si la arquitectura cumple con los requisitos
de calidad Para realizar esta evaluacioacuten se propone el
meacutetodo ATAM (Architecture Tradeoff Analysis Method)
El ATAM revela cuaacuten bien una arquitectura satisface los
objetivos particulares de calidad y provee una
aproximacioacuten de coacutemo los objetivos de calidad interactuacutean
Si la evaluacioacuten de la arquitectura se encuentra que se
deben realizar cambios a la misma entonces eacutesta se debe
refinar hasta llegar a tener como resultado del Sprint 0 el
documento puacuteblico de la arquitectura junto con el sistema
esqueleto Finalmente la arquitectura creada en el Sprint 0
beneficiaraacute el desarrollo en los siguientes sprints
IV Rol del arquitecto de Software en Scrum
El rol y actividades del arquitecto de software cambian de
enfoque dependiendo de si se estaacute en el Sprint 0 o en
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
12
sprints subsecuentes
Fig 3 La Comunicacioacuten
Sprint 0 En sistemas complejos una persona difiacutecilmente
puede cubrir con amplitud teacutecnica las decisiones
arquitectoacutenicas y dar credibilidad a la arquitectura de
software Esto quiere decir que la participacioacuten del equipo
es de vital importancia para la creacioacuten y el mantenimiento
de la arquitectura Un equipo de arquitectos de software
que se aiacutesle del equipo de Scrum puede producir una
arquitectura que corra el riesgo de ser rechazada Es por
esto que recomendamos que el arquitecto o los arquitectos
se software sean miembros del equipo de Scrum Una de
las actividades que se debe realizar en equipo es la
evaluacioacuten de la arquitectura Especiacuteficamente en el
meacutetodo ATAM se requiere la participacioacuten mutua de tres
equipos que trabajan en conjunto con los arquitectos de
software el de evaluacioacuten el de tomadores de decisiones
del proyecto y el de los involucrados en la arquitectura
Sprints subsecuentes El arquitecto de software asegura que
el equipo de Scrum entienda el enfoque y los retos
arquitectoacutenicos maacutes importantes en casa sprint Los
equipos de Scrum realizan construcciones cortas guiados
por las estrategias de la arquitectura A continuacioacuten se
nombran algunas de las responsabilidades del arquitecto de
software desde el Sprint 1 en adelante
El duentildeo del producto y el maestro del Scrum trabajan con
el arquitecto para priorizar los requisitos a implementar en
cada iteracioacuten
El arquitecto comunica las decisiones y facilita las
conversaciones arquitectoacutenicas de distintos puntos de vista
en cada sprint
El arquitecto asegura que haya conformidad entre las
entregas en cada sprint y la arquitectura
El arquitecto responde preguntas y da orientacioacuten
arquitectoacutenica cuando sea necesario
Junto con el maestro de Scrum coordina a los miembros
del equipo para adaptarse a la arquitectura previa
El arquitecto junto con el duentildeo del producto y los
miembros del equipo preparan el Product Backlog
V Conclusioacuten
En el presente artiacuteculo ofrecimos una propuesta para incluir
la arquitectura de software en Scrum En el Sprint 0 se
realizan las actividades concernientes al anaacutelisis y disentildeo
de la arquitectura de software y el sistema esqueleto En
los siguientes sprints el arquitecto de software se asegura
de que la implementacioacuten cumpla con la arquitectura
REFERENCIAS
[3] httpwwwsafecreativeorgwork
[4] Hirotaka Takeuchi es decano de la Graduate School of International
Corporate Strategy en la Universidad Hitotsubashi en Tokio y fue profesor visitante en la Escuela de Negocios Harvard entre 1989 y 1990
[5] Ikujiro NonakaNo soy un guruacute porque me falta carisma
] INGENIERIacuteA DE SOFTWARE
13
INGENIERIacuteA DE SISTEMAS
El futuro de la ingenieriacutea de software Luis E Aguirre
Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 de Octubre esq Belisario Salinas
La Paz - Bolivia leaguirreusfaedubo
Resumen El disentildeo de programas a partir de informacioacuten binaria
significoacute un paso sustantivo para la industria desarrolladora de
software Desde ese hallazgo ocurrido en la deacutecada de los
cincuenta hasta hoy el crecimiento de metodologiacuteas para su
desarrollo ha subido notablemente en complejidad Sin embargo
los ciacuterculos viciosos que acusa hoy la confeccioacuten de programas
informaacuteticos impiden conceptualizar el objeto a un nivel
superior de abstraccioacuten tal y como lo exige el avance tecnoloacutegico
y los procesos de negocios
Palabras clave mdash futuro software ingenieriacutea programador y
desarrollo
I Introduccioacuten
La calidad de los sistemas informaacuteticos satisfaccioacuten de sus
usuarios y clientes son temas ampliamente conocidos
recurrentes y de constante preocupacioacuten por parte de los
practicantes de la Ingenieriacutea de software
Esta joven y dinaacutemica ingenieriacutea siempre estaacute en busca de
mejoras en el desarrollo de sistemas aumento de
productividad del ingeniero de software mayor control del
proceso de desarrollo establecimiento de nuevos meacutetodos de
desarrollo
Fig 1 Primeros programas computacionales en formato de tarjeta perforada
Estos elementos combinados y aplicados de buena forma
logran un buen proceso de desarrollo y en definitiva un buen
producto
Identificar los pasos que ha recorrido esta ingenieriacutea analizar
su contexto actual y finalmente proyectar hacia doacutende se
dirige es el pilar de este artiacuteculo
II iquestSe aplica actualmente la ingenieriacutea del software
La investigacioacuten y el desarrollo de teacutecnicas y meacuteto
dos de ingenieriacutea del software son constantes y suelen suponer
interesantes avances en la resolucioacuten de problemas de
desarrollo de software Sin embargo es habitual que en la
praacutectica diaria profesional no se incluya praacutecticamente
ninguna de las recomendaciones maacutes elementales de la
ingenieriacutea del software En efecto es habitual que el
desarrollo de software se parezca maacutes al descontrol del cuento
de laquosi los programadores fueran albantildeilesraquo ([Novatica
1996]) que a una idiacutelica y bien organizada factoriacutea de
software (concepto de gran vigencia a finales de los ochenta
[Nunamaker et al 1988])
De hecho las evaluaciones de los procesos productivos de
software realizadas a raiacutez de los modelo de procesos de
software (por ejemplo con CMM [Paulk et al 1993])
confirman que el desarrollo de software suele estar
baacutesicamente en estado caoacutetico
Y no soacutelo en como uno podriacutea pensar pequentildeas
organizaciones de un paiacutes mediterraacuteneo como el nuestro sino
en tambieacuten en las empresas adjudicatarias de interesantes
contratos de defensa de paiacuteses laquoavanzadosraquo como EEUU o
Japoacuten Si bien estos modelos de evaluacioacuten auacuten acumulan
distintas acusaciones de rigidez o falta de contraste empiacuterico
los resultados obtenidos en sus evaluaciones resultan
consistentes con la sensacioacuten de constante laquoapagafuegosraquo que
suelen sufrir los profesionales del software Tambieacuten suelen
revelar la praacutectica despreocupacioacuten de los responsables de las
organizaciones de software por la mejora de la calidad de sus
procesos de trabajo o de sus productos bien sea por contar con
una situacioacuten interna de empresa poco propicia porque el
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
14
ambiente del mercado no fomenta la preocupacioacuten por estos
temas o bien por su poco intereacutes real en la buacutesqueda de la
calidad
III La actualidad
La gran mayoriacutea de los sistemas de software creados hoy en
diacutea son los llamados sistemas corporativos es decir son
orientados a formar una parte importante de los negocios de
las grandes empresas
Continuando en nuestro contexto se identifica un nuevo
enfoque del problema de desarrollo el apoyo en la
sincronizacioacuten de los procesos de negocio estructuras
complejas de informacioacuten manejada por el negocio todo esto
entrelazado por restricciones dadas por las reglas del negocio
La tecnologiacutea actual por otro lado ha alejado maacutes todaviacutea los
ingenieros de las maacutequinas sistemas operativos incluso de
las tareas de programacioacuten
El enfoque de la mayoriacutea de los equipos de desarrollo e
ingenieros participes en proyectos sigue siendo con un bajo
nivel de abstraccioacuten cerca de la codificacioacuten Se tiende a
pensar en la base de datos a utilizar establecer la navegacioacuten
de las paacuteginas programar los protocolos de comunicacioacuten etc
Esto lleva a utilizar las tareas de programacioacuten y de pruebas
para validar el entendimiento y cumplimiento de la
funcionalidad de los sistemas
Lo anteriormente expuesto muestra un problema
metodoloacutegico consecuencia de un desfase entre el enfoque
teoacuterico oacuteptimo (anaacutelisis de negocio) y el enfoque praacutectico real
(programacioacuten y pruebas) en los proyectos de hoy En otras
palabras la metodologiacutea actualmente usada estaacute atrasada con
respecto al avance tecnoloacutegico
Desarrollando maacutes esta idea se identifican algunos
problemas concretos de las metodologiacuteas
Ellas no obligan a sus ejecutores a respetar todas las
normas y los procedimientos establecidos especialmente
en las etapas tempranas del proyecto Es muy faacutecil y
tentador ―saltar una o maacutes de estas etapas uno o maacutes
documentos o modelos pasando directamente a
implementacioacuten produccioacuten y posterior correccioacuten de los
sistemas desarrollados
Control de calidad del producto final La codificacioacuten y
complejidad del programa es demasiada para ser revisada
y verificada fehacientemente Por otro lado los coacutedigos
fuentes y los ejecutables actualmente son los uacutenicos
entregables eficientemente verificables
Estos dos problemas al parecer forman una situacioacuten
contradictoria la metodologiacutea tradicional no permite validar
eficientemente la calidad de los sistemas antes de llegar al
coacutedigo fuente y por otro lado tampoco permite llegar
eficientemente a coacutedigos fuentes de calidad
IV Futuro
La salida de este ―ciacuterculo vicioso que se propone es
bastante natural analizar la situacioacuten actual de la ingenieriacutea
de software en la luz de sus tendencias histoacutericas
La primera de ellas relacionada con los problemas que
resuelven los sistemas obviamente presente y muy utilizada
en nuestra realidad los sistemas de hoy no soacutelo resuelven los
problemas del mundo real sino que estaacuten fuertemente influen-
ciando el desarrollo del mundo real
Fig2 Modela
El enfoque de los ingenieros desde hace unos antildeos no se ha
movido significativamente por el camino del aumento de
abstraccioacuten establecido histoacutericamente Se han hecho ciertos
avances en temas puntuales (como arquitecturas de
componentes patrones de disentildeo nuevos lenguajes de
programacioacuten etc) pero conceptualmente
metodoloacutegicamente la tarea de programacioacuten sigue siendo
ejecutada de la misma forma escribiendo coacutedigos fuentes en
forma de los programas textuales
Eacuteste es justamente el ―atraso metodoloacutegico que se
mencionoacute Para disminuir la brecha entre las tendencias
histoacutericas es necesario ajustar la metodologiacutea en teacuterminos de
aumentar la abstraccioacuten del enfoque de los ingenieros de
software y acercarlo a la abstraccioacuten del problema
El aumento de la abstraccioacuten del proceso de desarrollo del
software hace pensar que la proacutexima generacioacuten de meacutetodos
de desarrollo se perfila en un conceptualmente nuevo con-
] INGENIERIacuteA DE SOFTWARE
15
INGENIERIacuteA DE SISTEMAS
junto de herramientas que permitan aumentar en un mayor
grado al actual la abstraccioacuten escondiendo los detalles de maacutes
bajo nivel
Fig3 Probable modelo a futuro
Las nuevas herramientas permitiraacuten ―programar en nivel
de anaacutelisis generando coacutedigos en un lenguaje de
programacioacuten tradicional de forma automaacutetica tal como hoy
los compiladores generan el lenguaje maacutequina a partir del
coacutedigo fuente Nuevos ―lenguajes de programacioacuten
naturalmente seriacutean visuales y se pareceriacutean a las
especificaciones de software en uno de los lenguajes de
modelamiento por ejemplo UML
V Conclusioacuten
Es muy probable que estemos proacuteximos a ver un nuevo
paso evolutivo en la ingenieriacutea de software Tan grande como
el invento de lenguajes de alto nivel o anaacutelisis y disentildeo
orientado a objetos Una nueva generacioacuten que absorberaacute a la
actual automatizando la mayoriacutea de las buenas praacutecticas
usadas actualmente
Una pregunta natural es si una maacutequina puede llegar a
generar programas tan buenos como los hechos por un pro-
gramador experto En vez de ―romper la cabeza con esta
pregunta ahora quizaacutes seriacutea suficiente recordarse otra vez de
la historia Los primeros compiladores de ninguna generacioacuten
alcanzaban de inmediato lo deseable y oacuteptimo Sin embargo
con el paso del tiempo apoyados en la experiencia de los
ingenieros y en el avance tecnoloacutegico se mejoraban hasta el
nivel de superar significativamente las generaciones
anteriores
Es poco factible que hoy en diacutea alguien cuestione la calidad
de los compiladores de por ejemplo Java y la calidad del
coacutedigo de maacutequina generado por ellos
VI Referencias [6] Website [Online]
httpwwwenterpriseanalystnetdownloadmda_informaticap
df
[7] httpwwwslidesharenetamrrochafuturo-del-software-impacto-en-las-organizaciones-y-en-los-profesionales
[8] httpwwwdcubaareventseci2008conferenciasIngSoftHexacta
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
4
Tom DeMarco
Ingenieriacutea de Software
y Control de Proyectos Joe Luis Aramayo Blanco
Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
20 de Octubre Esq Belisario Salinas
La Paz - Bolivia jlaramayousfaeduboResumen- En este artiacuteculo
haremos algunas observaciones sobre un artiacuteculo
que escribioacute hace un tiempo atraacutes Tom DeMarco
sobre meacutetricas control de proyectos e
ingenieriacutea de software donde en general podemos
encontrar frases que claramente contradicen su
postura de hace unas deacutecadas
Palabras clave- Ingenieriacutea de Software Control de Proyectos
Meacutetricas No puedes controlar lo que no puedes medir Desarrollo
de Software
I INTRODUCCIOacuteN
Todos comprendemos que las meacutetricas de software cuestan
dinero y tiempo y que deben ser usadas con moderacioacuten
El desarrollo de software es inherentemente diferente de las
ciencias naturales tales como la fiacutesica por lo que sus meacutetricas
son mucho menos precisas para capturar lo que deben describir
La frase ―No puedes controlar lo que no puedes medir lleva
impliacutecita que el control es un aspecto importante quizaacutes el maacutes
importante de cualquier proyecto de software Pero no lo es
Fig 1 Ejemplo de ―No puedes controlar lo que no puedes medir
Muchos proyectos se han realizado sin demasiado control pero
han generado productos maravillosos tales como Google Earth o
la Wikipedia
Esto nos lleva a la desagradable conclusioacuten que el control
estricto es algo que importa mucho en proyectos relativamente
inuacutetiles y mucho menos en proyectos uacutetiles
iquestEstoy diciendo que estaacute bien ejecutar proyecto sin control o
con un control relativamente menor Casi Estoy sugiriendo que
deberiacuteamos seleccionar primero a los proyectos cuyo control
preciso no importe demasiado
En los uacuteltimos 40 antildeos nos hemos torturado por nuestra
ineptitud en acabar proyectos a tiempo y con el presupuesto
previsto Pero como sugeriacute antes no deberiacutea haber sido el
objetivo supremo
El objetivo maacutes importante es la transformacioacuten crear software
que cambie el mundo o que transforme una empresa o la forma
en que hace negocios
El desarrollo de software es y seraacute siempre algo experimental
La construccioacuten real de software no es necesariamente
experimental pero siacute lo es su concepcioacuten Alliacute deberiacuteamos
enfocar nuestros esfuerzos Alliacute es donde deberiacuteamos haberlo
hecho siempre Estaacute claro que es mucho maacutes faacutecil criticar un
artiacuteculo que hacer uno nuevo pero dada la trascendencia que estaacute
teniendo este escrito en particular voy a expresar mi opinioacuten
Creo que DeMarco sabe venderse Creo que cuando era maacutes
joven se supo posicionar como guruacute de la Ingenieriacutea de Software
y el control de proyectos y creo que ahora estaacute en la edad en que
puede decir que parte de lo que dijo estaacute mal e igual quedar bien
porque su posicioacuten coincide con la de muchos guruacutees actuales
Sin embargo me parece que el artiacuteculo estaacute lleno de frases
impactantes pero que no salen de un anaacutelisis profundo Me voy
a explayar
] INGENIERIacuteA DE SOFTWARE
5
INGENIERIacuteA DE SISTEMAS
Fig 3 Referencia a las Meacutetricas cuestan dinero
Que las meacutetricas cuestan dinero en cierto sentido es cierto
Tambieacuten es cierto que ahora es mucho maacutes faacutecil llevar algunas
meacutetricas que hace unos antildeos dado que ahora utilizamos
herramientas que las generan de manera automaacutetica Podriacuteamos
decir que en el presente es mucho menos costoso tener la misma
informacioacuten que hace unas deacutecadas DeMarco consideraba
importante
Que el desarrollo de software es inherentemente diferente de las
ciencias naturales como la fiacutesica tambieacuten es verdad Lo que no
se termina de entender es por queacute nos comparamos con las
Fiacutesicas y no con las Ingenieriacuteas
El disentildeo de una planta de gas en situaciones extremas tambieacuten
es uacutenico y con resultados impredecibles la construccioacuten de una
torre en Dubai alguacuten nuevo prototipo de avioacuten un nuevo
celular etc tambieacuten son inherentemente diferentes de las
ciencias naturales y sin embargo cuentan con presupuestos
meacutetricas de avance de defectos etc O sea es una verdad pero
que no aplica a la conclusioacuten a la que llega
Donde puedo estar maacutes de acuerdo es cuando hablamos del
control de proyectos de software aunque maacutes adelante voy a
definir mi posicioacuten En este caso en mi opinioacuten tambieacuten escribe
algo cierto ―El control no es lo maacutes importante de un proyecto
de software pero cuando toma ejemplos elije dos proyectos en
los que las desviaciones admitidas eran del orden de entre 100
y 1000 ya que o el objetivo era otro o los resultados
esperados eran mucho mayores a una desviacioacuten de 500 en
costos
Fig 1 Referencia de Google Earth
Ambos proyectos (Wikipedia que surge de NuPedia) y
GoogleEarth fueron proyectos en los que hubo inversores
poniendo su dinero durante antildeos sin ver resultados Se puede
buscar en Internet acerca de la historia de NuPedia antecesora
de Wikipedia y a Jimi Wales explicando que despueacutes de haber
gastado 250000 doacutelares solo habiacutea logrado 16 artiacuteculos en su
nueva Enciclopedia Lo mismo pasoacute con GoogleEarth
anteriormente en manos de KeyHole con inversores como Sony
y otros Fondos de Capital En este tipo de proyectos se pueden
asumir peacuterdidas durante antildeos hasta lograr un producto que
puede romper con el mercado o tambieacuten se puede perder todo lo
invertido Se trata de proyectos de inversioacuten de alto riesgo y
determinan proyectos de desarrollo que claramente son poco
comunes
Fig 3 Referencia de WIKIPEDIA
Al menos en mi entorno la mayoriacutea de los proyectos son
internos o externos (para un cliente) Los proyectos externos
tienen presupuestos o se crean luego de llamados a licitacioacuten
Es decir costo fijo tiempo fijo alcance fijo maacutes menos alguna
que otra variacioacuten Es claro que si no contamos con un miacutenimo
de control en estos proyectos la empresa no sabe si estaacute siendo
rentable o no Tampoco sabe si el producto que es desarrollado
le puede traer problemas a futuro por alguna cuestioacuten de calidad
No poner un miacutenimo eacutenfasis en el control de estos proyectos
puede llevar a la empresa a la quiebra sin que esta sea
consciente salvo por los nuacutemeros rojos que aparecen en sus
balances Por lo tanto explicar que un proyecto de software no
hace falta controlarlo mucho y poner como ejemplo dos casos
muy poco relevantes no parece muy serio
Por uacuteltimo cuando dice el desarrollo de software es y siempre
seraacute algo experimental vuelve a caer en las afirmaciones de las
que en 40 antildeos (en caso de estar vivo claro) podriacutea volver a
arrepentirse Es cierto que todaviacutea estamos en una etapa inicial
de la que llamamos ingenieriacutea de software Es cierto que no es
faacutecil gestionar proyectos de software por sus caracteriacutesticas
intriacutensecas (intangibilidad maleabilidad etc) pero cada
ingenieriacutea tiene sus problemas particulares y cada una supo
evolucionar a lo que son ahora Seguramente la ingenieriacutea de
Software con el tiempo encontraraacute su camino
Ahora bien aparte de criticar un poco a DeMarco (que era lo
maacutes faacutecil) vamos a retomar la frase
―No puedes controlar lo que no puedes medir lleva impliacutecita
que el control es un aspecto importante quizaacutes el maacutes
importante de cualquier proyecto de software Pero no lo es
En cierta medida explicaba arriba estoy de acuerdo con esta
afirmacioacuten Un buen proyecto de software con mucho control
pero malos programadores lleva al fracaso inevitablemente (lo
he vivido personalmente y por experiencias de terceros) Por el
contrario un buen equipo de programadores (pero de los
buenos) puede terminar el proyecto maacutes complejo haciendo que
ninguacuten indicador tenga sentido ya que la diferencia de calidad
del producto y la eficiencia del trabajo de este tipo de gente
multiplica por 10 o por 100 la de un equipo estaacutendar
Este tipo de gente piensa las cosas de manera diferente tiene la
calidad incorporada como meacutetodo de trabajo y la capacidad de
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
6
generar soluciones a las distintas situaciones hace que el
esfuerzo estimado pueda acortarse en oacuterdenes de magnitud
Estuve dentro equipos de este estilo y lo que se puede lograr en
un ambiente hiperproductivo difiacutecilmente se logre en una
empresa de desarrollo comuacuten y corriente El problema es que la
gente que tiene estas cualidades escasea y el mercado estaacute lleno
de trabajadores ―estaacutendar que requieren definiciones procesos
un aacuterea de calidad que verifique sus entregables y un PM que le
indique queacute es lo que tiene que hacer De a poco estimo yo la
industria iraacute decantando por rendimiento aquellos profesionales
que hacen la diferencia y los estaacutendares de productividad
calidad base teoacuterica requerida para un puesto iraacuten aumentando
Fue pasando durante estas deacutecadas y seguiraacute pasando en el
futuro
II CONCLUSIONES
En siacutentesis y para terminar con este artiacuteculo medir y controlar
importa importa maacutes en las empresas con gente estaacutendar
importa maacutes en las empresas con proyectos estaacutendar y siempre
que estemos dentro de una empresa algo vamos a tener que
medir pero el control no es condicioacuten necesaria ni menos
suficiente para lograr un proyecto exitoso No es algo
fundamental como tener un buen equipo de programadores
como tener gente que sepa interpretar lo que se pide y
transformarlo de manera natural en la solucioacuten que el cliente
necesita Por eso cuando veo gente que se preocupa por
aumentar el control o aumentar los procesos creo que estaacute
perdiendo el foco cuando lo que deberiacutea buscar es coacutemo hacer
para encontrar y hacer rendir a los verdaderos profesionales del
software
III REFERENCIAS
[1] Software Engenieering an idea whose time has come and gone por Tom
DeMarco [2] CyS Ingenieria de Software El blog del aacuterea de Ingenieriacutea de Software de
CyS Informaacutetica SA
] INGENIERIacuteA DE SOFTWARE
7
INGENIERIacuteA DE SISTEMAS
EXTREME PROGRAMMING PARA DESARROLLO
DE SOFTWARE
Erwin Adaacuten Choque Ulloa Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
Plaza Avaroa esq Belisario Salinas
La paz ndash Bolivia adan_ekinghotmailcom
Resumen
En este articulo se describiraacute algunas de las metodologiacuteas
agiles de desarrollo de software puesto que para asegurar el
eacutexito durante el desarrollo de un software es importante
saber la metodologiacutea de desarrollo la cual nos provee una
guiacutea para la correcta aplicacioacuten y desarrollo de Software
La metodologiacutea Extreme Programming XP que es una de las
metodologiacuteas aacutegiles maacutes extendidas y populares ademaacutes es
considerada como una metodologiacutea posmoderna donde
grandes capacidades se generan a traveacutes de procesos
emergentes
Palabras claves Extreme Programming metodologiacutea software
usuario
1 INTRODUCCION
El esquema tradicional para abordar el desarrollo de
software ha demostrado ser efectivo y necesario en
proyectos de gran tamantildeo respecto a tiempo y recursos
Sin embargo este enfoque no resulta ser el maacutes adecuado
para muchos de los proyectos actuales donde el entorno
del sistema es muy cambiante y en donde se exige
reducir draacutesticamente los tiempos de desarrollo pero
manteniendo una alta calidad Ante este problema las
metodologiacuteas aacutegiles son una posible respuesta para llenar
ese vaciacuteo metodoloacutegico Orientadas para proyectos
pequentildeos las metodologiacuteas aacutegiles constituyen una
solucioacuten
A continuacioacuten se describiraacute cada una de las
metodologiacuteas de desarrollo de software
2 EXTREME PROGRAMMING XP
La metodologiacutea de desarrollo de software XP es la
primera metodologiacutea aacutegil y la que le dio conciencia al
movimiento actual de metodologiacuteas aacutegiles Kent Beck el
padre de la metodologiacutea XP se basa en realimentacioacuten
continua entre el cliente y el equipo de desarrollo
comunicacioacuten fluida entre todos los participantes
simplicidad en las soluciones implementadas y facilidad
para enfrentar los cambios XP se define como
especialmente adecuada para proyectos con requisitos
imprecisos y muy cambiantes y donde existe un alto
riesgo teacutecnico Ahora se describiraacute las caracteriacutesticas
esenciales del Extreme Programming
21 LAS HISTORIAS DEL USUARIO
La red Las historias del usuario es la teacutecnica utilizada
para especificar los requisitos de software son tarjetas de
papel donde el cliente especifica de manera simplificada
las caracteriacutesticas que el sistema debe poseer ya sean
requisitos funcionales o requisitos no funcionales Se
caracteriza por ser dinaacutemica y flexible cada historia de
usuario debe ser comprensible y delimitada para que los
programadores puedan implementarla en pocas semanas
22 ROLES XP
Seguacuten Kent Beck los roles son
Programador El programador se encarga de escribir las
pruebas unitarias y tambieacuten estaacute encargado de producir el
coacutedigo del sistema
Cliente Encargado de escribir las historias de usuario y
los requisitos funcionales y selecciona las historias por
prioridad de conveniencia al negocio
Encargado de pruebas Encargado de ayudar al cliente a
escribir las pruebas funcionales ademaacutes de ejecutar las
pruebas constantemente encargado de de las
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
8
herramientas de soporte de pruebas como tambieacuten
difundir los resultados de dicha prueba
Encargado de seguimiento Es el encargado de la
realimentacioacuten al equipo y realiza el seguimiento del
proceso de cada iteracioacuten
Entrenador Es el encargado de prever guiacuteas al equipo
basadas en XP y de seguir el proceso correctamente
Consultor Es el que posee un conocimiento especifico
en alguacuten tema necesario para el proyecto para solucionar
problemas
Gestor Es la interaccioacuten entre clientes y programadores
ayudando a trabajar de forma adecuada y de esta manera
coordinar de forma correcta
23 PROCESO XP
El ciclo de desarrollo XP consiste en
El cliente define el valor del negocio a implementar
El programador estima el esfuerzo necesario para su
implementacioacuten
El cliente selecciona que construir de acuerdo con sus
propiedades y las restricciones del tiempo
El programador construye ese valor de negocio
Vuelve al principio
En todas las iteraciones de este ciclo tanto el cliente como
el programador aprenden No se debe presionar al
programador a realizar maacutes trabajo que el estimado ya
que se perderaacute calidad en el software o no se cumpliraacuten
los plazos
El ciclo de vida ideal de XP consiste de seis fases
Exploracioacuten
Planificacioacuten de la Entrega (Release)
Iteraciones
Produccioacuten
Mantenimiento y Muerte del Proyecto
24 PRACTICAS XP
Las siguientes praacutecticas ayudan al desarrollo de software
El juego de la planificacioacuten Hay una comunicacioacuten
frecuente el cliente y los programadores El equipo
teacutecnico realiza una estimacioacuten del esfuerzo requerido para
la implementacioacuten de las historias de usuario y los
clientes deciden sobre el aacutembito y el tiempo de entregas y
de cada iteracioacuten
Entregas pequentildeas Producir raacutepidamente versiones del
sistema que sean operativas aunque no cuenten con toda
la funcionalidad del sistema Esta versioacuten ya constituye
un resultado de valor para el negocio Una entrega no
deberiacutea tardar maacutes de tres meses
Metaacutefora El sistema es definido mediante un conjunto
de metaacuteforas compartidas por el cliente y el equipo de
desarrollo Una metaacutefora es una historia compartida que
describe como deberiacutea funcionar el sistema
Disentildeo simple Se disentildea la solucioacuten maacutes simple que
pueda funcionar y ser implementada en un determinado
momento del proyecto
Pruebas La produccioacuten de coacutedigo estaacute dirigida para las
pruebas unitarias Estas son establecidas por el cliente
antes de escribirse el coacutedigo y son ejecutadas
continuamente ante cada modificacioacuten del sistema
Pruebas Es una actividad constante de reestructuracioacuten
del coacutedigo con el objetivo de remover duplicacioacuten de
coacutedigo mejorar su legibilidad simplificarlo y hacerlo
maacutes flexible para facilitar los cambios Se mejora la
estructura interna del coacutedigo sin alterar su
comportamiento externo
Programacioacuten en parejas Toda la produccioacuten del
coacutedigo debe realizarse con trabajo en parejas de
programadores Para tener ventajas como menor tasa de
errores mejor disentildeo etc
Propiedad colectiva del coacutedigo Cualquier programador
puede cambiar cualquier parte del coacutedigo en cualquier
instante
Integracioacuten continua Cada pieza del coacutedigo es
integrada en el sistema una vez que este listaasi el
sistema puede ser integrado y construido varias veces en
un mismo diacutea
40 horas por semana Se debe trabajar un maacuteximo de 40
horas por semana no se trabajan horas extras en dos
semanas seguidas Si esto ocurre estaacute existe un problema
porque el trabajo extra desmotiva al equipo
Cliente in-situ El cliente tiene que estar presente y
disponible todo el tiempo para el equipo este es uno de
los principales factores de eacutexito para el proyecto XP Y
asiacute guiar y disipar cualquier duda de los programadores
donde la comunicacioacuten es maacutes efectiva que la escrita
Estaacutendares de programacioacuten XP enfatiza que la
comunicacioacuten de los programadores es a traveacutes del
coacutedigo por lo que es importante que se sigan estaacutendares
de programacioacuten para mantener el coacutedigo legible
3 CONCLUCIONES
] INGENIERIacuteA DE SOFTWARE
9
INGENIERIacuteA DE SISTEMAS
Las metodologiacuteas aacutegiles ofrecen una solucioacuten casi a
medida para una gran cantidad de proyectos
La metodologiacutea XP es una de las metodologiacuteas aacutegiles maacutes
extendidas y populares ademaacutes es considerada como una
metodologiacutea posmoderna cuyas grandes capacidades se
generan a traveacutes de procesos emergentes
4 REFERENCIAS
httpwwwmetodologiasSoftcomdesarrolloagil
httpwwwwikipediacommetodologiaXP
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
10
Desarrollo de Scrum
Sergio J Guzmaacuten L Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 Octubre Esq Belisario Salinas
La Paz - Bolivia
sjguzmanusfaedubo
Resumenmdash Scrum es una metodologiacutea aacutegil de desarrollo de
proyectos que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ldquocampos de scrumrdquo al
software
Palabras clave mdash scrum metodologiacutea patroacuten software
sprint rol
I Que es Scrum
Scrum es una metodologiacutea aacutegil de desarrollo de proyectos
que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ―campos de scrum al
software
Esta fue la primera definicioacuten de un patroacuten Scrum aplicado
al software disentildeada por Jeff Sutherland y Ken Schwaber y
presentada en Object-Oriented Programming Systems
Languages amp Applications OOPSLA en 1996
II iquestCoacutemo incorporarla
La competitividad del mercado de desarrollo de Software y
la necesidad de los clientes de reducir el tiempo de
mercado obligan a las organizaciones de desarrollo de
software a ser agresivas en sus calendarios de entrega Esto
ha hecho que hayan surgido metodologiacuteas para la gestioacuten y
desarrollo de software basadas en un proceso iterativo e
incremental Su estructura estaacute basada en corto tiempo los
cuales son iteraciones de 1 a 4 semanas Scrum se usa en
proyectos de entorno complejos donde se desea obtener
resultados raacutepidos y la productividad es lo maacutes importante
En los proyectos basados en Scrum se consideran tres
roles
Duentildeo del producto Es quien determina las propiedades de
los entregables
Maestro de Scrum Administra y facilita la ejecucioacuten del
proceso
Equipo de Trabajo Trabajan en conjunto para entregar
resultados en cada sprint
Fig 1 El flujo de Scrum
Como se puede observar en medio de los participantes del
proceso no quedan claras las responsabilidades del
arquitecto de software Sin embargo como comenta
Charlie Alfred ―la arquitectura es al aceite y el filtro que
lubrica adecuadamente a Scrum
Fig 2 El flujo de Scrum
] INGENIERIacuteA DE SOFTWARE
11
INGENIERIacuteA DE SISTEMAS
Si se compara el rol del arquitecto de edificaciones con el
del arquitecto de software se puede observar que ambos
modelan las construcciones a un alto nivel de abstraccioacuten
proveen posibles soluciones mejoran la comunicacioacuten con
los miembros del equipo de construccioacuten a traveacutes de
modelos visualizan las generalidades del problema
definen los roles y las interacciones entre los componentes
de construccioacuten entre otras tareas Al igual que es
imposible pensar que un rascacielos puede ser construido
sin una arquitectura soacutelida es imposible pensar que
productos de software empresariales puedan ser
implementados sin una arquitectura bien pensada
Seguacuten Bass Clements y Kasman ―La arquitectura de
software de un programa o sistema informaacutetico es la
estructura o estructuras del sistema que incluyen elementos
de software las propiedades externamente visibles de esos
elementos y las relaciones entre ellos Esta definicioacuten nos
lleva a concluir que la arquitectura de software garantiza el
buen desarrollo del software y a tener un sistema que
cumpla con los requerimientos funcionales y no
funcionales del cliente Ademaacutes la arquitectura es clave en
la reutilizacioacuten de artefactos de software en sistemas de
liacutenea de productos de software
Viendo la importancia de la arquitectura en el desarrollo
del software en eacuteste artiacuteculo se presenta una propuesta para
gestionar la arquitectura de Software en Scrum En el
primer capiacutetulo se trata el tema de la localizacioacuten de la
arquitectura de software en el ciclo de desarrollo de Scrum
en el segundo capiacutetulo se describen las tareas del arquitecto
de software en Scrum finalmente se presentan las
conclusiones y el trabajo futuro
III Arquitectura de Software en el ciclo de desarrollo de
Scrum
La idea fundamental de la presente propuesta es adicionar
un sprint inicial llamado ―Sprint 0Prime al inicio del ciclo de
desarrollo El objetivo principal del arquitecto en el Sprint
0 es analizar y disentildear la generalidad del sistema que
satisfaga los requisitos y sea entendible por los miembros
del equipo desde sus diferentes puntos de vista durante el
desarrollo Un punto clave es reutilizar artefactos de
software creados a partir de la arquitectura para ser maacutes
aacutegiles en el desarrollo de productos especiacuteficos
El Sprint 0 comprende tres fases que fueron tomadas del
ciclo de vida de entregas evolutivas En el Sprint 0 se
construye la arquitectura de forma iterativa mediante un
anaacutelisis preliminar de los conductores arquitectoacutenicos
(requisitos funcionales de calidad y del negocio) y de un
estudio de factibilidad del proyecto No se necesita tener
todos los requisitos claros para comenzar la fase de disentildeo
arquitectoacutenico
Para determinar los conductores arquitectoacutenicos se debe
identificar los objetivos del negocio de maacutes alta prioridad
que son pocos Estos objetivos del negocio se convierten en
los escenarios de calidad o casos de uso De esta lista se
deben escoger los que tendraacuten un mayor impacto sobre la
arquitectura El disentildeo arquitectoacutenico puede comenzar una
vez que se encuentran definidos los conductores
arquitectoacutenicos El proceso de anaacutelisis de requisitos seraacute
entonces influenciado por las preguntas generadas durante
el disentildeo arquitectoacutenico
El resultado del Srpint 0 es un documento inicial que
explica la arquitectura El documento puede basarse en los
pasos definidos por el meacutetodo ADD (Attrbute Driver
Design) Este meacutetodo ha sido probado exitosamente en
proyectos anteriores Con ADD se puede definir una
arquitectura de software mediante un proceso de
descomposicioacuten basado en los atributos de calidad de
Software
El documento inicial de la arquitectura se debe avaluar con
el fin de saber si la arquitectura cumple con los requisitos
de calidad Para realizar esta evaluacioacuten se propone el
meacutetodo ATAM (Architecture Tradeoff Analysis Method)
El ATAM revela cuaacuten bien una arquitectura satisface los
objetivos particulares de calidad y provee una
aproximacioacuten de coacutemo los objetivos de calidad interactuacutean
Si la evaluacioacuten de la arquitectura se encuentra que se
deben realizar cambios a la misma entonces eacutesta se debe
refinar hasta llegar a tener como resultado del Sprint 0 el
documento puacuteblico de la arquitectura junto con el sistema
esqueleto Finalmente la arquitectura creada en el Sprint 0
beneficiaraacute el desarrollo en los siguientes sprints
IV Rol del arquitecto de Software en Scrum
El rol y actividades del arquitecto de software cambian de
enfoque dependiendo de si se estaacute en el Sprint 0 o en
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
12
sprints subsecuentes
Fig 3 La Comunicacioacuten
Sprint 0 En sistemas complejos una persona difiacutecilmente
puede cubrir con amplitud teacutecnica las decisiones
arquitectoacutenicas y dar credibilidad a la arquitectura de
software Esto quiere decir que la participacioacuten del equipo
es de vital importancia para la creacioacuten y el mantenimiento
de la arquitectura Un equipo de arquitectos de software
que se aiacutesle del equipo de Scrum puede producir una
arquitectura que corra el riesgo de ser rechazada Es por
esto que recomendamos que el arquitecto o los arquitectos
se software sean miembros del equipo de Scrum Una de
las actividades que se debe realizar en equipo es la
evaluacioacuten de la arquitectura Especiacuteficamente en el
meacutetodo ATAM se requiere la participacioacuten mutua de tres
equipos que trabajan en conjunto con los arquitectos de
software el de evaluacioacuten el de tomadores de decisiones
del proyecto y el de los involucrados en la arquitectura
Sprints subsecuentes El arquitecto de software asegura que
el equipo de Scrum entienda el enfoque y los retos
arquitectoacutenicos maacutes importantes en casa sprint Los
equipos de Scrum realizan construcciones cortas guiados
por las estrategias de la arquitectura A continuacioacuten se
nombran algunas de las responsabilidades del arquitecto de
software desde el Sprint 1 en adelante
El duentildeo del producto y el maestro del Scrum trabajan con
el arquitecto para priorizar los requisitos a implementar en
cada iteracioacuten
El arquitecto comunica las decisiones y facilita las
conversaciones arquitectoacutenicas de distintos puntos de vista
en cada sprint
El arquitecto asegura que haya conformidad entre las
entregas en cada sprint y la arquitectura
El arquitecto responde preguntas y da orientacioacuten
arquitectoacutenica cuando sea necesario
Junto con el maestro de Scrum coordina a los miembros
del equipo para adaptarse a la arquitectura previa
El arquitecto junto con el duentildeo del producto y los
miembros del equipo preparan el Product Backlog
V Conclusioacuten
En el presente artiacuteculo ofrecimos una propuesta para incluir
la arquitectura de software en Scrum En el Sprint 0 se
realizan las actividades concernientes al anaacutelisis y disentildeo
de la arquitectura de software y el sistema esqueleto En
los siguientes sprints el arquitecto de software se asegura
de que la implementacioacuten cumpla con la arquitectura
REFERENCIAS
[3] httpwwwsafecreativeorgwork
[4] Hirotaka Takeuchi es decano de la Graduate School of International
Corporate Strategy en la Universidad Hitotsubashi en Tokio y fue profesor visitante en la Escuela de Negocios Harvard entre 1989 y 1990
[5] Ikujiro NonakaNo soy un guruacute porque me falta carisma
] INGENIERIacuteA DE SOFTWARE
13
INGENIERIacuteA DE SISTEMAS
El futuro de la ingenieriacutea de software Luis E Aguirre
Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 de Octubre esq Belisario Salinas
La Paz - Bolivia leaguirreusfaedubo
Resumen El disentildeo de programas a partir de informacioacuten binaria
significoacute un paso sustantivo para la industria desarrolladora de
software Desde ese hallazgo ocurrido en la deacutecada de los
cincuenta hasta hoy el crecimiento de metodologiacuteas para su
desarrollo ha subido notablemente en complejidad Sin embargo
los ciacuterculos viciosos que acusa hoy la confeccioacuten de programas
informaacuteticos impiden conceptualizar el objeto a un nivel
superior de abstraccioacuten tal y como lo exige el avance tecnoloacutegico
y los procesos de negocios
Palabras clave mdash futuro software ingenieriacutea programador y
desarrollo
I Introduccioacuten
La calidad de los sistemas informaacuteticos satisfaccioacuten de sus
usuarios y clientes son temas ampliamente conocidos
recurrentes y de constante preocupacioacuten por parte de los
practicantes de la Ingenieriacutea de software
Esta joven y dinaacutemica ingenieriacutea siempre estaacute en busca de
mejoras en el desarrollo de sistemas aumento de
productividad del ingeniero de software mayor control del
proceso de desarrollo establecimiento de nuevos meacutetodos de
desarrollo
Fig 1 Primeros programas computacionales en formato de tarjeta perforada
Estos elementos combinados y aplicados de buena forma
logran un buen proceso de desarrollo y en definitiva un buen
producto
Identificar los pasos que ha recorrido esta ingenieriacutea analizar
su contexto actual y finalmente proyectar hacia doacutende se
dirige es el pilar de este artiacuteculo
II iquestSe aplica actualmente la ingenieriacutea del software
La investigacioacuten y el desarrollo de teacutecnicas y meacuteto
dos de ingenieriacutea del software son constantes y suelen suponer
interesantes avances en la resolucioacuten de problemas de
desarrollo de software Sin embargo es habitual que en la
praacutectica diaria profesional no se incluya praacutecticamente
ninguna de las recomendaciones maacutes elementales de la
ingenieriacutea del software En efecto es habitual que el
desarrollo de software se parezca maacutes al descontrol del cuento
de laquosi los programadores fueran albantildeilesraquo ([Novatica
1996]) que a una idiacutelica y bien organizada factoriacutea de
software (concepto de gran vigencia a finales de los ochenta
[Nunamaker et al 1988])
De hecho las evaluaciones de los procesos productivos de
software realizadas a raiacutez de los modelo de procesos de
software (por ejemplo con CMM [Paulk et al 1993])
confirman que el desarrollo de software suele estar
baacutesicamente en estado caoacutetico
Y no soacutelo en como uno podriacutea pensar pequentildeas
organizaciones de un paiacutes mediterraacuteneo como el nuestro sino
en tambieacuten en las empresas adjudicatarias de interesantes
contratos de defensa de paiacuteses laquoavanzadosraquo como EEUU o
Japoacuten Si bien estos modelos de evaluacioacuten auacuten acumulan
distintas acusaciones de rigidez o falta de contraste empiacuterico
los resultados obtenidos en sus evaluaciones resultan
consistentes con la sensacioacuten de constante laquoapagafuegosraquo que
suelen sufrir los profesionales del software Tambieacuten suelen
revelar la praacutectica despreocupacioacuten de los responsables de las
organizaciones de software por la mejora de la calidad de sus
procesos de trabajo o de sus productos bien sea por contar con
una situacioacuten interna de empresa poco propicia porque el
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
14
ambiente del mercado no fomenta la preocupacioacuten por estos
temas o bien por su poco intereacutes real en la buacutesqueda de la
calidad
III La actualidad
La gran mayoriacutea de los sistemas de software creados hoy en
diacutea son los llamados sistemas corporativos es decir son
orientados a formar una parte importante de los negocios de
las grandes empresas
Continuando en nuestro contexto se identifica un nuevo
enfoque del problema de desarrollo el apoyo en la
sincronizacioacuten de los procesos de negocio estructuras
complejas de informacioacuten manejada por el negocio todo esto
entrelazado por restricciones dadas por las reglas del negocio
La tecnologiacutea actual por otro lado ha alejado maacutes todaviacutea los
ingenieros de las maacutequinas sistemas operativos incluso de
las tareas de programacioacuten
El enfoque de la mayoriacutea de los equipos de desarrollo e
ingenieros participes en proyectos sigue siendo con un bajo
nivel de abstraccioacuten cerca de la codificacioacuten Se tiende a
pensar en la base de datos a utilizar establecer la navegacioacuten
de las paacuteginas programar los protocolos de comunicacioacuten etc
Esto lleva a utilizar las tareas de programacioacuten y de pruebas
para validar el entendimiento y cumplimiento de la
funcionalidad de los sistemas
Lo anteriormente expuesto muestra un problema
metodoloacutegico consecuencia de un desfase entre el enfoque
teoacuterico oacuteptimo (anaacutelisis de negocio) y el enfoque praacutectico real
(programacioacuten y pruebas) en los proyectos de hoy En otras
palabras la metodologiacutea actualmente usada estaacute atrasada con
respecto al avance tecnoloacutegico
Desarrollando maacutes esta idea se identifican algunos
problemas concretos de las metodologiacuteas
Ellas no obligan a sus ejecutores a respetar todas las
normas y los procedimientos establecidos especialmente
en las etapas tempranas del proyecto Es muy faacutecil y
tentador ―saltar una o maacutes de estas etapas uno o maacutes
documentos o modelos pasando directamente a
implementacioacuten produccioacuten y posterior correccioacuten de los
sistemas desarrollados
Control de calidad del producto final La codificacioacuten y
complejidad del programa es demasiada para ser revisada
y verificada fehacientemente Por otro lado los coacutedigos
fuentes y los ejecutables actualmente son los uacutenicos
entregables eficientemente verificables
Estos dos problemas al parecer forman una situacioacuten
contradictoria la metodologiacutea tradicional no permite validar
eficientemente la calidad de los sistemas antes de llegar al
coacutedigo fuente y por otro lado tampoco permite llegar
eficientemente a coacutedigos fuentes de calidad
IV Futuro
La salida de este ―ciacuterculo vicioso que se propone es
bastante natural analizar la situacioacuten actual de la ingenieriacutea
de software en la luz de sus tendencias histoacutericas
La primera de ellas relacionada con los problemas que
resuelven los sistemas obviamente presente y muy utilizada
en nuestra realidad los sistemas de hoy no soacutelo resuelven los
problemas del mundo real sino que estaacuten fuertemente influen-
ciando el desarrollo del mundo real
Fig2 Modela
El enfoque de los ingenieros desde hace unos antildeos no se ha
movido significativamente por el camino del aumento de
abstraccioacuten establecido histoacutericamente Se han hecho ciertos
avances en temas puntuales (como arquitecturas de
componentes patrones de disentildeo nuevos lenguajes de
programacioacuten etc) pero conceptualmente
metodoloacutegicamente la tarea de programacioacuten sigue siendo
ejecutada de la misma forma escribiendo coacutedigos fuentes en
forma de los programas textuales
Eacuteste es justamente el ―atraso metodoloacutegico que se
mencionoacute Para disminuir la brecha entre las tendencias
histoacutericas es necesario ajustar la metodologiacutea en teacuterminos de
aumentar la abstraccioacuten del enfoque de los ingenieros de
software y acercarlo a la abstraccioacuten del problema
El aumento de la abstraccioacuten del proceso de desarrollo del
software hace pensar que la proacutexima generacioacuten de meacutetodos
de desarrollo se perfila en un conceptualmente nuevo con-
] INGENIERIacuteA DE SOFTWARE
15
INGENIERIacuteA DE SISTEMAS
junto de herramientas que permitan aumentar en un mayor
grado al actual la abstraccioacuten escondiendo los detalles de maacutes
bajo nivel
Fig3 Probable modelo a futuro
Las nuevas herramientas permitiraacuten ―programar en nivel
de anaacutelisis generando coacutedigos en un lenguaje de
programacioacuten tradicional de forma automaacutetica tal como hoy
los compiladores generan el lenguaje maacutequina a partir del
coacutedigo fuente Nuevos ―lenguajes de programacioacuten
naturalmente seriacutean visuales y se pareceriacutean a las
especificaciones de software en uno de los lenguajes de
modelamiento por ejemplo UML
V Conclusioacuten
Es muy probable que estemos proacuteximos a ver un nuevo
paso evolutivo en la ingenieriacutea de software Tan grande como
el invento de lenguajes de alto nivel o anaacutelisis y disentildeo
orientado a objetos Una nueva generacioacuten que absorberaacute a la
actual automatizando la mayoriacutea de las buenas praacutecticas
usadas actualmente
Una pregunta natural es si una maacutequina puede llegar a
generar programas tan buenos como los hechos por un pro-
gramador experto En vez de ―romper la cabeza con esta
pregunta ahora quizaacutes seriacutea suficiente recordarse otra vez de
la historia Los primeros compiladores de ninguna generacioacuten
alcanzaban de inmediato lo deseable y oacuteptimo Sin embargo
con el paso del tiempo apoyados en la experiencia de los
ingenieros y en el avance tecnoloacutegico se mejoraban hasta el
nivel de superar significativamente las generaciones
anteriores
Es poco factible que hoy en diacutea alguien cuestione la calidad
de los compiladores de por ejemplo Java y la calidad del
coacutedigo de maacutequina generado por ellos
VI Referencias [6] Website [Online]
httpwwwenterpriseanalystnetdownloadmda_informaticap
df
[7] httpwwwslidesharenetamrrochafuturo-del-software-impacto-en-las-organizaciones-y-en-los-profesionales
[8] httpwwwdcubaareventseci2008conferenciasIngSoftHexacta
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
5
INGENIERIacuteA DE SISTEMAS
Fig 3 Referencia a las Meacutetricas cuestan dinero
Que las meacutetricas cuestan dinero en cierto sentido es cierto
Tambieacuten es cierto que ahora es mucho maacutes faacutecil llevar algunas
meacutetricas que hace unos antildeos dado que ahora utilizamos
herramientas que las generan de manera automaacutetica Podriacuteamos
decir que en el presente es mucho menos costoso tener la misma
informacioacuten que hace unas deacutecadas DeMarco consideraba
importante
Que el desarrollo de software es inherentemente diferente de las
ciencias naturales como la fiacutesica tambieacuten es verdad Lo que no
se termina de entender es por queacute nos comparamos con las
Fiacutesicas y no con las Ingenieriacuteas
El disentildeo de una planta de gas en situaciones extremas tambieacuten
es uacutenico y con resultados impredecibles la construccioacuten de una
torre en Dubai alguacuten nuevo prototipo de avioacuten un nuevo
celular etc tambieacuten son inherentemente diferentes de las
ciencias naturales y sin embargo cuentan con presupuestos
meacutetricas de avance de defectos etc O sea es una verdad pero
que no aplica a la conclusioacuten a la que llega
Donde puedo estar maacutes de acuerdo es cuando hablamos del
control de proyectos de software aunque maacutes adelante voy a
definir mi posicioacuten En este caso en mi opinioacuten tambieacuten escribe
algo cierto ―El control no es lo maacutes importante de un proyecto
de software pero cuando toma ejemplos elije dos proyectos en
los que las desviaciones admitidas eran del orden de entre 100
y 1000 ya que o el objetivo era otro o los resultados
esperados eran mucho mayores a una desviacioacuten de 500 en
costos
Fig 1 Referencia de Google Earth
Ambos proyectos (Wikipedia que surge de NuPedia) y
GoogleEarth fueron proyectos en los que hubo inversores
poniendo su dinero durante antildeos sin ver resultados Se puede
buscar en Internet acerca de la historia de NuPedia antecesora
de Wikipedia y a Jimi Wales explicando que despueacutes de haber
gastado 250000 doacutelares solo habiacutea logrado 16 artiacuteculos en su
nueva Enciclopedia Lo mismo pasoacute con GoogleEarth
anteriormente en manos de KeyHole con inversores como Sony
y otros Fondos de Capital En este tipo de proyectos se pueden
asumir peacuterdidas durante antildeos hasta lograr un producto que
puede romper con el mercado o tambieacuten se puede perder todo lo
invertido Se trata de proyectos de inversioacuten de alto riesgo y
determinan proyectos de desarrollo que claramente son poco
comunes
Fig 3 Referencia de WIKIPEDIA
Al menos en mi entorno la mayoriacutea de los proyectos son
internos o externos (para un cliente) Los proyectos externos
tienen presupuestos o se crean luego de llamados a licitacioacuten
Es decir costo fijo tiempo fijo alcance fijo maacutes menos alguna
que otra variacioacuten Es claro que si no contamos con un miacutenimo
de control en estos proyectos la empresa no sabe si estaacute siendo
rentable o no Tampoco sabe si el producto que es desarrollado
le puede traer problemas a futuro por alguna cuestioacuten de calidad
No poner un miacutenimo eacutenfasis en el control de estos proyectos
puede llevar a la empresa a la quiebra sin que esta sea
consciente salvo por los nuacutemeros rojos que aparecen en sus
balances Por lo tanto explicar que un proyecto de software no
hace falta controlarlo mucho y poner como ejemplo dos casos
muy poco relevantes no parece muy serio
Por uacuteltimo cuando dice el desarrollo de software es y siempre
seraacute algo experimental vuelve a caer en las afirmaciones de las
que en 40 antildeos (en caso de estar vivo claro) podriacutea volver a
arrepentirse Es cierto que todaviacutea estamos en una etapa inicial
de la que llamamos ingenieriacutea de software Es cierto que no es
faacutecil gestionar proyectos de software por sus caracteriacutesticas
intriacutensecas (intangibilidad maleabilidad etc) pero cada
ingenieriacutea tiene sus problemas particulares y cada una supo
evolucionar a lo que son ahora Seguramente la ingenieriacutea de
Software con el tiempo encontraraacute su camino
Ahora bien aparte de criticar un poco a DeMarco (que era lo
maacutes faacutecil) vamos a retomar la frase
―No puedes controlar lo que no puedes medir lleva impliacutecita
que el control es un aspecto importante quizaacutes el maacutes
importante de cualquier proyecto de software Pero no lo es
En cierta medida explicaba arriba estoy de acuerdo con esta
afirmacioacuten Un buen proyecto de software con mucho control
pero malos programadores lleva al fracaso inevitablemente (lo
he vivido personalmente y por experiencias de terceros) Por el
contrario un buen equipo de programadores (pero de los
buenos) puede terminar el proyecto maacutes complejo haciendo que
ninguacuten indicador tenga sentido ya que la diferencia de calidad
del producto y la eficiencia del trabajo de este tipo de gente
multiplica por 10 o por 100 la de un equipo estaacutendar
Este tipo de gente piensa las cosas de manera diferente tiene la
calidad incorporada como meacutetodo de trabajo y la capacidad de
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
6
generar soluciones a las distintas situaciones hace que el
esfuerzo estimado pueda acortarse en oacuterdenes de magnitud
Estuve dentro equipos de este estilo y lo que se puede lograr en
un ambiente hiperproductivo difiacutecilmente se logre en una
empresa de desarrollo comuacuten y corriente El problema es que la
gente que tiene estas cualidades escasea y el mercado estaacute lleno
de trabajadores ―estaacutendar que requieren definiciones procesos
un aacuterea de calidad que verifique sus entregables y un PM que le
indique queacute es lo que tiene que hacer De a poco estimo yo la
industria iraacute decantando por rendimiento aquellos profesionales
que hacen la diferencia y los estaacutendares de productividad
calidad base teoacuterica requerida para un puesto iraacuten aumentando
Fue pasando durante estas deacutecadas y seguiraacute pasando en el
futuro
II CONCLUSIONES
En siacutentesis y para terminar con este artiacuteculo medir y controlar
importa importa maacutes en las empresas con gente estaacutendar
importa maacutes en las empresas con proyectos estaacutendar y siempre
que estemos dentro de una empresa algo vamos a tener que
medir pero el control no es condicioacuten necesaria ni menos
suficiente para lograr un proyecto exitoso No es algo
fundamental como tener un buen equipo de programadores
como tener gente que sepa interpretar lo que se pide y
transformarlo de manera natural en la solucioacuten que el cliente
necesita Por eso cuando veo gente que se preocupa por
aumentar el control o aumentar los procesos creo que estaacute
perdiendo el foco cuando lo que deberiacutea buscar es coacutemo hacer
para encontrar y hacer rendir a los verdaderos profesionales del
software
III REFERENCIAS
[1] Software Engenieering an idea whose time has come and gone por Tom
DeMarco [2] CyS Ingenieria de Software El blog del aacuterea de Ingenieriacutea de Software de
CyS Informaacutetica SA
] INGENIERIacuteA DE SOFTWARE
7
INGENIERIacuteA DE SISTEMAS
EXTREME PROGRAMMING PARA DESARROLLO
DE SOFTWARE
Erwin Adaacuten Choque Ulloa Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
Plaza Avaroa esq Belisario Salinas
La paz ndash Bolivia adan_ekinghotmailcom
Resumen
En este articulo se describiraacute algunas de las metodologiacuteas
agiles de desarrollo de software puesto que para asegurar el
eacutexito durante el desarrollo de un software es importante
saber la metodologiacutea de desarrollo la cual nos provee una
guiacutea para la correcta aplicacioacuten y desarrollo de Software
La metodologiacutea Extreme Programming XP que es una de las
metodologiacuteas aacutegiles maacutes extendidas y populares ademaacutes es
considerada como una metodologiacutea posmoderna donde
grandes capacidades se generan a traveacutes de procesos
emergentes
Palabras claves Extreme Programming metodologiacutea software
usuario
1 INTRODUCCION
El esquema tradicional para abordar el desarrollo de
software ha demostrado ser efectivo y necesario en
proyectos de gran tamantildeo respecto a tiempo y recursos
Sin embargo este enfoque no resulta ser el maacutes adecuado
para muchos de los proyectos actuales donde el entorno
del sistema es muy cambiante y en donde se exige
reducir draacutesticamente los tiempos de desarrollo pero
manteniendo una alta calidad Ante este problema las
metodologiacuteas aacutegiles son una posible respuesta para llenar
ese vaciacuteo metodoloacutegico Orientadas para proyectos
pequentildeos las metodologiacuteas aacutegiles constituyen una
solucioacuten
A continuacioacuten se describiraacute cada una de las
metodologiacuteas de desarrollo de software
2 EXTREME PROGRAMMING XP
La metodologiacutea de desarrollo de software XP es la
primera metodologiacutea aacutegil y la que le dio conciencia al
movimiento actual de metodologiacuteas aacutegiles Kent Beck el
padre de la metodologiacutea XP se basa en realimentacioacuten
continua entre el cliente y el equipo de desarrollo
comunicacioacuten fluida entre todos los participantes
simplicidad en las soluciones implementadas y facilidad
para enfrentar los cambios XP se define como
especialmente adecuada para proyectos con requisitos
imprecisos y muy cambiantes y donde existe un alto
riesgo teacutecnico Ahora se describiraacute las caracteriacutesticas
esenciales del Extreme Programming
21 LAS HISTORIAS DEL USUARIO
La red Las historias del usuario es la teacutecnica utilizada
para especificar los requisitos de software son tarjetas de
papel donde el cliente especifica de manera simplificada
las caracteriacutesticas que el sistema debe poseer ya sean
requisitos funcionales o requisitos no funcionales Se
caracteriza por ser dinaacutemica y flexible cada historia de
usuario debe ser comprensible y delimitada para que los
programadores puedan implementarla en pocas semanas
22 ROLES XP
Seguacuten Kent Beck los roles son
Programador El programador se encarga de escribir las
pruebas unitarias y tambieacuten estaacute encargado de producir el
coacutedigo del sistema
Cliente Encargado de escribir las historias de usuario y
los requisitos funcionales y selecciona las historias por
prioridad de conveniencia al negocio
Encargado de pruebas Encargado de ayudar al cliente a
escribir las pruebas funcionales ademaacutes de ejecutar las
pruebas constantemente encargado de de las
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
8
herramientas de soporte de pruebas como tambieacuten
difundir los resultados de dicha prueba
Encargado de seguimiento Es el encargado de la
realimentacioacuten al equipo y realiza el seguimiento del
proceso de cada iteracioacuten
Entrenador Es el encargado de prever guiacuteas al equipo
basadas en XP y de seguir el proceso correctamente
Consultor Es el que posee un conocimiento especifico
en alguacuten tema necesario para el proyecto para solucionar
problemas
Gestor Es la interaccioacuten entre clientes y programadores
ayudando a trabajar de forma adecuada y de esta manera
coordinar de forma correcta
23 PROCESO XP
El ciclo de desarrollo XP consiste en
El cliente define el valor del negocio a implementar
El programador estima el esfuerzo necesario para su
implementacioacuten
El cliente selecciona que construir de acuerdo con sus
propiedades y las restricciones del tiempo
El programador construye ese valor de negocio
Vuelve al principio
En todas las iteraciones de este ciclo tanto el cliente como
el programador aprenden No se debe presionar al
programador a realizar maacutes trabajo que el estimado ya
que se perderaacute calidad en el software o no se cumpliraacuten
los plazos
El ciclo de vida ideal de XP consiste de seis fases
Exploracioacuten
Planificacioacuten de la Entrega (Release)
Iteraciones
Produccioacuten
Mantenimiento y Muerte del Proyecto
24 PRACTICAS XP
Las siguientes praacutecticas ayudan al desarrollo de software
El juego de la planificacioacuten Hay una comunicacioacuten
frecuente el cliente y los programadores El equipo
teacutecnico realiza una estimacioacuten del esfuerzo requerido para
la implementacioacuten de las historias de usuario y los
clientes deciden sobre el aacutembito y el tiempo de entregas y
de cada iteracioacuten
Entregas pequentildeas Producir raacutepidamente versiones del
sistema que sean operativas aunque no cuenten con toda
la funcionalidad del sistema Esta versioacuten ya constituye
un resultado de valor para el negocio Una entrega no
deberiacutea tardar maacutes de tres meses
Metaacutefora El sistema es definido mediante un conjunto
de metaacuteforas compartidas por el cliente y el equipo de
desarrollo Una metaacutefora es una historia compartida que
describe como deberiacutea funcionar el sistema
Disentildeo simple Se disentildea la solucioacuten maacutes simple que
pueda funcionar y ser implementada en un determinado
momento del proyecto
Pruebas La produccioacuten de coacutedigo estaacute dirigida para las
pruebas unitarias Estas son establecidas por el cliente
antes de escribirse el coacutedigo y son ejecutadas
continuamente ante cada modificacioacuten del sistema
Pruebas Es una actividad constante de reestructuracioacuten
del coacutedigo con el objetivo de remover duplicacioacuten de
coacutedigo mejorar su legibilidad simplificarlo y hacerlo
maacutes flexible para facilitar los cambios Se mejora la
estructura interna del coacutedigo sin alterar su
comportamiento externo
Programacioacuten en parejas Toda la produccioacuten del
coacutedigo debe realizarse con trabajo en parejas de
programadores Para tener ventajas como menor tasa de
errores mejor disentildeo etc
Propiedad colectiva del coacutedigo Cualquier programador
puede cambiar cualquier parte del coacutedigo en cualquier
instante
Integracioacuten continua Cada pieza del coacutedigo es
integrada en el sistema una vez que este listaasi el
sistema puede ser integrado y construido varias veces en
un mismo diacutea
40 horas por semana Se debe trabajar un maacuteximo de 40
horas por semana no se trabajan horas extras en dos
semanas seguidas Si esto ocurre estaacute existe un problema
porque el trabajo extra desmotiva al equipo
Cliente in-situ El cliente tiene que estar presente y
disponible todo el tiempo para el equipo este es uno de
los principales factores de eacutexito para el proyecto XP Y
asiacute guiar y disipar cualquier duda de los programadores
donde la comunicacioacuten es maacutes efectiva que la escrita
Estaacutendares de programacioacuten XP enfatiza que la
comunicacioacuten de los programadores es a traveacutes del
coacutedigo por lo que es importante que se sigan estaacutendares
de programacioacuten para mantener el coacutedigo legible
3 CONCLUCIONES
] INGENIERIacuteA DE SOFTWARE
9
INGENIERIacuteA DE SISTEMAS
Las metodologiacuteas aacutegiles ofrecen una solucioacuten casi a
medida para una gran cantidad de proyectos
La metodologiacutea XP es una de las metodologiacuteas aacutegiles maacutes
extendidas y populares ademaacutes es considerada como una
metodologiacutea posmoderna cuyas grandes capacidades se
generan a traveacutes de procesos emergentes
4 REFERENCIAS
httpwwwmetodologiasSoftcomdesarrolloagil
httpwwwwikipediacommetodologiaXP
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
10
Desarrollo de Scrum
Sergio J Guzmaacuten L Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 Octubre Esq Belisario Salinas
La Paz - Bolivia
sjguzmanusfaedubo
Resumenmdash Scrum es una metodologiacutea aacutegil de desarrollo de
proyectos que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ldquocampos de scrumrdquo al
software
Palabras clave mdash scrum metodologiacutea patroacuten software
sprint rol
I Que es Scrum
Scrum es una metodologiacutea aacutegil de desarrollo de proyectos
que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ―campos de scrum al
software
Esta fue la primera definicioacuten de un patroacuten Scrum aplicado
al software disentildeada por Jeff Sutherland y Ken Schwaber y
presentada en Object-Oriented Programming Systems
Languages amp Applications OOPSLA en 1996
II iquestCoacutemo incorporarla
La competitividad del mercado de desarrollo de Software y
la necesidad de los clientes de reducir el tiempo de
mercado obligan a las organizaciones de desarrollo de
software a ser agresivas en sus calendarios de entrega Esto
ha hecho que hayan surgido metodologiacuteas para la gestioacuten y
desarrollo de software basadas en un proceso iterativo e
incremental Su estructura estaacute basada en corto tiempo los
cuales son iteraciones de 1 a 4 semanas Scrum se usa en
proyectos de entorno complejos donde se desea obtener
resultados raacutepidos y la productividad es lo maacutes importante
En los proyectos basados en Scrum se consideran tres
roles
Duentildeo del producto Es quien determina las propiedades de
los entregables
Maestro de Scrum Administra y facilita la ejecucioacuten del
proceso
Equipo de Trabajo Trabajan en conjunto para entregar
resultados en cada sprint
Fig 1 El flujo de Scrum
Como se puede observar en medio de los participantes del
proceso no quedan claras las responsabilidades del
arquitecto de software Sin embargo como comenta
Charlie Alfred ―la arquitectura es al aceite y el filtro que
lubrica adecuadamente a Scrum
Fig 2 El flujo de Scrum
] INGENIERIacuteA DE SOFTWARE
11
INGENIERIacuteA DE SISTEMAS
Si se compara el rol del arquitecto de edificaciones con el
del arquitecto de software se puede observar que ambos
modelan las construcciones a un alto nivel de abstraccioacuten
proveen posibles soluciones mejoran la comunicacioacuten con
los miembros del equipo de construccioacuten a traveacutes de
modelos visualizan las generalidades del problema
definen los roles y las interacciones entre los componentes
de construccioacuten entre otras tareas Al igual que es
imposible pensar que un rascacielos puede ser construido
sin una arquitectura soacutelida es imposible pensar que
productos de software empresariales puedan ser
implementados sin una arquitectura bien pensada
Seguacuten Bass Clements y Kasman ―La arquitectura de
software de un programa o sistema informaacutetico es la
estructura o estructuras del sistema que incluyen elementos
de software las propiedades externamente visibles de esos
elementos y las relaciones entre ellos Esta definicioacuten nos
lleva a concluir que la arquitectura de software garantiza el
buen desarrollo del software y a tener un sistema que
cumpla con los requerimientos funcionales y no
funcionales del cliente Ademaacutes la arquitectura es clave en
la reutilizacioacuten de artefactos de software en sistemas de
liacutenea de productos de software
Viendo la importancia de la arquitectura en el desarrollo
del software en eacuteste artiacuteculo se presenta una propuesta para
gestionar la arquitectura de Software en Scrum En el
primer capiacutetulo se trata el tema de la localizacioacuten de la
arquitectura de software en el ciclo de desarrollo de Scrum
en el segundo capiacutetulo se describen las tareas del arquitecto
de software en Scrum finalmente se presentan las
conclusiones y el trabajo futuro
III Arquitectura de Software en el ciclo de desarrollo de
Scrum
La idea fundamental de la presente propuesta es adicionar
un sprint inicial llamado ―Sprint 0Prime al inicio del ciclo de
desarrollo El objetivo principal del arquitecto en el Sprint
0 es analizar y disentildear la generalidad del sistema que
satisfaga los requisitos y sea entendible por los miembros
del equipo desde sus diferentes puntos de vista durante el
desarrollo Un punto clave es reutilizar artefactos de
software creados a partir de la arquitectura para ser maacutes
aacutegiles en el desarrollo de productos especiacuteficos
El Sprint 0 comprende tres fases que fueron tomadas del
ciclo de vida de entregas evolutivas En el Sprint 0 se
construye la arquitectura de forma iterativa mediante un
anaacutelisis preliminar de los conductores arquitectoacutenicos
(requisitos funcionales de calidad y del negocio) y de un
estudio de factibilidad del proyecto No se necesita tener
todos los requisitos claros para comenzar la fase de disentildeo
arquitectoacutenico
Para determinar los conductores arquitectoacutenicos se debe
identificar los objetivos del negocio de maacutes alta prioridad
que son pocos Estos objetivos del negocio se convierten en
los escenarios de calidad o casos de uso De esta lista se
deben escoger los que tendraacuten un mayor impacto sobre la
arquitectura El disentildeo arquitectoacutenico puede comenzar una
vez que se encuentran definidos los conductores
arquitectoacutenicos El proceso de anaacutelisis de requisitos seraacute
entonces influenciado por las preguntas generadas durante
el disentildeo arquitectoacutenico
El resultado del Srpint 0 es un documento inicial que
explica la arquitectura El documento puede basarse en los
pasos definidos por el meacutetodo ADD (Attrbute Driver
Design) Este meacutetodo ha sido probado exitosamente en
proyectos anteriores Con ADD se puede definir una
arquitectura de software mediante un proceso de
descomposicioacuten basado en los atributos de calidad de
Software
El documento inicial de la arquitectura se debe avaluar con
el fin de saber si la arquitectura cumple con los requisitos
de calidad Para realizar esta evaluacioacuten se propone el
meacutetodo ATAM (Architecture Tradeoff Analysis Method)
El ATAM revela cuaacuten bien una arquitectura satisface los
objetivos particulares de calidad y provee una
aproximacioacuten de coacutemo los objetivos de calidad interactuacutean
Si la evaluacioacuten de la arquitectura se encuentra que se
deben realizar cambios a la misma entonces eacutesta se debe
refinar hasta llegar a tener como resultado del Sprint 0 el
documento puacuteblico de la arquitectura junto con el sistema
esqueleto Finalmente la arquitectura creada en el Sprint 0
beneficiaraacute el desarrollo en los siguientes sprints
IV Rol del arquitecto de Software en Scrum
El rol y actividades del arquitecto de software cambian de
enfoque dependiendo de si se estaacute en el Sprint 0 o en
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
12
sprints subsecuentes
Fig 3 La Comunicacioacuten
Sprint 0 En sistemas complejos una persona difiacutecilmente
puede cubrir con amplitud teacutecnica las decisiones
arquitectoacutenicas y dar credibilidad a la arquitectura de
software Esto quiere decir que la participacioacuten del equipo
es de vital importancia para la creacioacuten y el mantenimiento
de la arquitectura Un equipo de arquitectos de software
que se aiacutesle del equipo de Scrum puede producir una
arquitectura que corra el riesgo de ser rechazada Es por
esto que recomendamos que el arquitecto o los arquitectos
se software sean miembros del equipo de Scrum Una de
las actividades que se debe realizar en equipo es la
evaluacioacuten de la arquitectura Especiacuteficamente en el
meacutetodo ATAM se requiere la participacioacuten mutua de tres
equipos que trabajan en conjunto con los arquitectos de
software el de evaluacioacuten el de tomadores de decisiones
del proyecto y el de los involucrados en la arquitectura
Sprints subsecuentes El arquitecto de software asegura que
el equipo de Scrum entienda el enfoque y los retos
arquitectoacutenicos maacutes importantes en casa sprint Los
equipos de Scrum realizan construcciones cortas guiados
por las estrategias de la arquitectura A continuacioacuten se
nombran algunas de las responsabilidades del arquitecto de
software desde el Sprint 1 en adelante
El duentildeo del producto y el maestro del Scrum trabajan con
el arquitecto para priorizar los requisitos a implementar en
cada iteracioacuten
El arquitecto comunica las decisiones y facilita las
conversaciones arquitectoacutenicas de distintos puntos de vista
en cada sprint
El arquitecto asegura que haya conformidad entre las
entregas en cada sprint y la arquitectura
El arquitecto responde preguntas y da orientacioacuten
arquitectoacutenica cuando sea necesario
Junto con el maestro de Scrum coordina a los miembros
del equipo para adaptarse a la arquitectura previa
El arquitecto junto con el duentildeo del producto y los
miembros del equipo preparan el Product Backlog
V Conclusioacuten
En el presente artiacuteculo ofrecimos una propuesta para incluir
la arquitectura de software en Scrum En el Sprint 0 se
realizan las actividades concernientes al anaacutelisis y disentildeo
de la arquitectura de software y el sistema esqueleto En
los siguientes sprints el arquitecto de software se asegura
de que la implementacioacuten cumpla con la arquitectura
REFERENCIAS
[3] httpwwwsafecreativeorgwork
[4] Hirotaka Takeuchi es decano de la Graduate School of International
Corporate Strategy en la Universidad Hitotsubashi en Tokio y fue profesor visitante en la Escuela de Negocios Harvard entre 1989 y 1990
[5] Ikujiro NonakaNo soy un guruacute porque me falta carisma
] INGENIERIacuteA DE SOFTWARE
13
INGENIERIacuteA DE SISTEMAS
El futuro de la ingenieriacutea de software Luis E Aguirre
Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 de Octubre esq Belisario Salinas
La Paz - Bolivia leaguirreusfaedubo
Resumen El disentildeo de programas a partir de informacioacuten binaria
significoacute un paso sustantivo para la industria desarrolladora de
software Desde ese hallazgo ocurrido en la deacutecada de los
cincuenta hasta hoy el crecimiento de metodologiacuteas para su
desarrollo ha subido notablemente en complejidad Sin embargo
los ciacuterculos viciosos que acusa hoy la confeccioacuten de programas
informaacuteticos impiden conceptualizar el objeto a un nivel
superior de abstraccioacuten tal y como lo exige el avance tecnoloacutegico
y los procesos de negocios
Palabras clave mdash futuro software ingenieriacutea programador y
desarrollo
I Introduccioacuten
La calidad de los sistemas informaacuteticos satisfaccioacuten de sus
usuarios y clientes son temas ampliamente conocidos
recurrentes y de constante preocupacioacuten por parte de los
practicantes de la Ingenieriacutea de software
Esta joven y dinaacutemica ingenieriacutea siempre estaacute en busca de
mejoras en el desarrollo de sistemas aumento de
productividad del ingeniero de software mayor control del
proceso de desarrollo establecimiento de nuevos meacutetodos de
desarrollo
Fig 1 Primeros programas computacionales en formato de tarjeta perforada
Estos elementos combinados y aplicados de buena forma
logran un buen proceso de desarrollo y en definitiva un buen
producto
Identificar los pasos que ha recorrido esta ingenieriacutea analizar
su contexto actual y finalmente proyectar hacia doacutende se
dirige es el pilar de este artiacuteculo
II iquestSe aplica actualmente la ingenieriacutea del software
La investigacioacuten y el desarrollo de teacutecnicas y meacuteto
dos de ingenieriacutea del software son constantes y suelen suponer
interesantes avances en la resolucioacuten de problemas de
desarrollo de software Sin embargo es habitual que en la
praacutectica diaria profesional no se incluya praacutecticamente
ninguna de las recomendaciones maacutes elementales de la
ingenieriacutea del software En efecto es habitual que el
desarrollo de software se parezca maacutes al descontrol del cuento
de laquosi los programadores fueran albantildeilesraquo ([Novatica
1996]) que a una idiacutelica y bien organizada factoriacutea de
software (concepto de gran vigencia a finales de los ochenta
[Nunamaker et al 1988])
De hecho las evaluaciones de los procesos productivos de
software realizadas a raiacutez de los modelo de procesos de
software (por ejemplo con CMM [Paulk et al 1993])
confirman que el desarrollo de software suele estar
baacutesicamente en estado caoacutetico
Y no soacutelo en como uno podriacutea pensar pequentildeas
organizaciones de un paiacutes mediterraacuteneo como el nuestro sino
en tambieacuten en las empresas adjudicatarias de interesantes
contratos de defensa de paiacuteses laquoavanzadosraquo como EEUU o
Japoacuten Si bien estos modelos de evaluacioacuten auacuten acumulan
distintas acusaciones de rigidez o falta de contraste empiacuterico
los resultados obtenidos en sus evaluaciones resultan
consistentes con la sensacioacuten de constante laquoapagafuegosraquo que
suelen sufrir los profesionales del software Tambieacuten suelen
revelar la praacutectica despreocupacioacuten de los responsables de las
organizaciones de software por la mejora de la calidad de sus
procesos de trabajo o de sus productos bien sea por contar con
una situacioacuten interna de empresa poco propicia porque el
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
14
ambiente del mercado no fomenta la preocupacioacuten por estos
temas o bien por su poco intereacutes real en la buacutesqueda de la
calidad
III La actualidad
La gran mayoriacutea de los sistemas de software creados hoy en
diacutea son los llamados sistemas corporativos es decir son
orientados a formar una parte importante de los negocios de
las grandes empresas
Continuando en nuestro contexto se identifica un nuevo
enfoque del problema de desarrollo el apoyo en la
sincronizacioacuten de los procesos de negocio estructuras
complejas de informacioacuten manejada por el negocio todo esto
entrelazado por restricciones dadas por las reglas del negocio
La tecnologiacutea actual por otro lado ha alejado maacutes todaviacutea los
ingenieros de las maacutequinas sistemas operativos incluso de
las tareas de programacioacuten
El enfoque de la mayoriacutea de los equipos de desarrollo e
ingenieros participes en proyectos sigue siendo con un bajo
nivel de abstraccioacuten cerca de la codificacioacuten Se tiende a
pensar en la base de datos a utilizar establecer la navegacioacuten
de las paacuteginas programar los protocolos de comunicacioacuten etc
Esto lleva a utilizar las tareas de programacioacuten y de pruebas
para validar el entendimiento y cumplimiento de la
funcionalidad de los sistemas
Lo anteriormente expuesto muestra un problema
metodoloacutegico consecuencia de un desfase entre el enfoque
teoacuterico oacuteptimo (anaacutelisis de negocio) y el enfoque praacutectico real
(programacioacuten y pruebas) en los proyectos de hoy En otras
palabras la metodologiacutea actualmente usada estaacute atrasada con
respecto al avance tecnoloacutegico
Desarrollando maacutes esta idea se identifican algunos
problemas concretos de las metodologiacuteas
Ellas no obligan a sus ejecutores a respetar todas las
normas y los procedimientos establecidos especialmente
en las etapas tempranas del proyecto Es muy faacutecil y
tentador ―saltar una o maacutes de estas etapas uno o maacutes
documentos o modelos pasando directamente a
implementacioacuten produccioacuten y posterior correccioacuten de los
sistemas desarrollados
Control de calidad del producto final La codificacioacuten y
complejidad del programa es demasiada para ser revisada
y verificada fehacientemente Por otro lado los coacutedigos
fuentes y los ejecutables actualmente son los uacutenicos
entregables eficientemente verificables
Estos dos problemas al parecer forman una situacioacuten
contradictoria la metodologiacutea tradicional no permite validar
eficientemente la calidad de los sistemas antes de llegar al
coacutedigo fuente y por otro lado tampoco permite llegar
eficientemente a coacutedigos fuentes de calidad
IV Futuro
La salida de este ―ciacuterculo vicioso que se propone es
bastante natural analizar la situacioacuten actual de la ingenieriacutea
de software en la luz de sus tendencias histoacutericas
La primera de ellas relacionada con los problemas que
resuelven los sistemas obviamente presente y muy utilizada
en nuestra realidad los sistemas de hoy no soacutelo resuelven los
problemas del mundo real sino que estaacuten fuertemente influen-
ciando el desarrollo del mundo real
Fig2 Modela
El enfoque de los ingenieros desde hace unos antildeos no se ha
movido significativamente por el camino del aumento de
abstraccioacuten establecido histoacutericamente Se han hecho ciertos
avances en temas puntuales (como arquitecturas de
componentes patrones de disentildeo nuevos lenguajes de
programacioacuten etc) pero conceptualmente
metodoloacutegicamente la tarea de programacioacuten sigue siendo
ejecutada de la misma forma escribiendo coacutedigos fuentes en
forma de los programas textuales
Eacuteste es justamente el ―atraso metodoloacutegico que se
mencionoacute Para disminuir la brecha entre las tendencias
histoacutericas es necesario ajustar la metodologiacutea en teacuterminos de
aumentar la abstraccioacuten del enfoque de los ingenieros de
software y acercarlo a la abstraccioacuten del problema
El aumento de la abstraccioacuten del proceso de desarrollo del
software hace pensar que la proacutexima generacioacuten de meacutetodos
de desarrollo se perfila en un conceptualmente nuevo con-
] INGENIERIacuteA DE SOFTWARE
15
INGENIERIacuteA DE SISTEMAS
junto de herramientas que permitan aumentar en un mayor
grado al actual la abstraccioacuten escondiendo los detalles de maacutes
bajo nivel
Fig3 Probable modelo a futuro
Las nuevas herramientas permitiraacuten ―programar en nivel
de anaacutelisis generando coacutedigos en un lenguaje de
programacioacuten tradicional de forma automaacutetica tal como hoy
los compiladores generan el lenguaje maacutequina a partir del
coacutedigo fuente Nuevos ―lenguajes de programacioacuten
naturalmente seriacutean visuales y se pareceriacutean a las
especificaciones de software en uno de los lenguajes de
modelamiento por ejemplo UML
V Conclusioacuten
Es muy probable que estemos proacuteximos a ver un nuevo
paso evolutivo en la ingenieriacutea de software Tan grande como
el invento de lenguajes de alto nivel o anaacutelisis y disentildeo
orientado a objetos Una nueva generacioacuten que absorberaacute a la
actual automatizando la mayoriacutea de las buenas praacutecticas
usadas actualmente
Una pregunta natural es si una maacutequina puede llegar a
generar programas tan buenos como los hechos por un pro-
gramador experto En vez de ―romper la cabeza con esta
pregunta ahora quizaacutes seriacutea suficiente recordarse otra vez de
la historia Los primeros compiladores de ninguna generacioacuten
alcanzaban de inmediato lo deseable y oacuteptimo Sin embargo
con el paso del tiempo apoyados en la experiencia de los
ingenieros y en el avance tecnoloacutegico se mejoraban hasta el
nivel de superar significativamente las generaciones
anteriores
Es poco factible que hoy en diacutea alguien cuestione la calidad
de los compiladores de por ejemplo Java y la calidad del
coacutedigo de maacutequina generado por ellos
VI Referencias [6] Website [Online]
httpwwwenterpriseanalystnetdownloadmda_informaticap
df
[7] httpwwwslidesharenetamrrochafuturo-del-software-impacto-en-las-organizaciones-y-en-los-profesionales
[8] httpwwwdcubaareventseci2008conferenciasIngSoftHexacta
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
6
generar soluciones a las distintas situaciones hace que el
esfuerzo estimado pueda acortarse en oacuterdenes de magnitud
Estuve dentro equipos de este estilo y lo que se puede lograr en
un ambiente hiperproductivo difiacutecilmente se logre en una
empresa de desarrollo comuacuten y corriente El problema es que la
gente que tiene estas cualidades escasea y el mercado estaacute lleno
de trabajadores ―estaacutendar que requieren definiciones procesos
un aacuterea de calidad que verifique sus entregables y un PM que le
indique queacute es lo que tiene que hacer De a poco estimo yo la
industria iraacute decantando por rendimiento aquellos profesionales
que hacen la diferencia y los estaacutendares de productividad
calidad base teoacuterica requerida para un puesto iraacuten aumentando
Fue pasando durante estas deacutecadas y seguiraacute pasando en el
futuro
II CONCLUSIONES
En siacutentesis y para terminar con este artiacuteculo medir y controlar
importa importa maacutes en las empresas con gente estaacutendar
importa maacutes en las empresas con proyectos estaacutendar y siempre
que estemos dentro de una empresa algo vamos a tener que
medir pero el control no es condicioacuten necesaria ni menos
suficiente para lograr un proyecto exitoso No es algo
fundamental como tener un buen equipo de programadores
como tener gente que sepa interpretar lo que se pide y
transformarlo de manera natural en la solucioacuten que el cliente
necesita Por eso cuando veo gente que se preocupa por
aumentar el control o aumentar los procesos creo que estaacute
perdiendo el foco cuando lo que deberiacutea buscar es coacutemo hacer
para encontrar y hacer rendir a los verdaderos profesionales del
software
III REFERENCIAS
[1] Software Engenieering an idea whose time has come and gone por Tom
DeMarco [2] CyS Ingenieria de Software El blog del aacuterea de Ingenieriacutea de Software de
CyS Informaacutetica SA
] INGENIERIacuteA DE SOFTWARE
7
INGENIERIacuteA DE SISTEMAS
EXTREME PROGRAMMING PARA DESARROLLO
DE SOFTWARE
Erwin Adaacuten Choque Ulloa Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
Plaza Avaroa esq Belisario Salinas
La paz ndash Bolivia adan_ekinghotmailcom
Resumen
En este articulo se describiraacute algunas de las metodologiacuteas
agiles de desarrollo de software puesto que para asegurar el
eacutexito durante el desarrollo de un software es importante
saber la metodologiacutea de desarrollo la cual nos provee una
guiacutea para la correcta aplicacioacuten y desarrollo de Software
La metodologiacutea Extreme Programming XP que es una de las
metodologiacuteas aacutegiles maacutes extendidas y populares ademaacutes es
considerada como una metodologiacutea posmoderna donde
grandes capacidades se generan a traveacutes de procesos
emergentes
Palabras claves Extreme Programming metodologiacutea software
usuario
1 INTRODUCCION
El esquema tradicional para abordar el desarrollo de
software ha demostrado ser efectivo y necesario en
proyectos de gran tamantildeo respecto a tiempo y recursos
Sin embargo este enfoque no resulta ser el maacutes adecuado
para muchos de los proyectos actuales donde el entorno
del sistema es muy cambiante y en donde se exige
reducir draacutesticamente los tiempos de desarrollo pero
manteniendo una alta calidad Ante este problema las
metodologiacuteas aacutegiles son una posible respuesta para llenar
ese vaciacuteo metodoloacutegico Orientadas para proyectos
pequentildeos las metodologiacuteas aacutegiles constituyen una
solucioacuten
A continuacioacuten se describiraacute cada una de las
metodologiacuteas de desarrollo de software
2 EXTREME PROGRAMMING XP
La metodologiacutea de desarrollo de software XP es la
primera metodologiacutea aacutegil y la que le dio conciencia al
movimiento actual de metodologiacuteas aacutegiles Kent Beck el
padre de la metodologiacutea XP se basa en realimentacioacuten
continua entre el cliente y el equipo de desarrollo
comunicacioacuten fluida entre todos los participantes
simplicidad en las soluciones implementadas y facilidad
para enfrentar los cambios XP se define como
especialmente adecuada para proyectos con requisitos
imprecisos y muy cambiantes y donde existe un alto
riesgo teacutecnico Ahora se describiraacute las caracteriacutesticas
esenciales del Extreme Programming
21 LAS HISTORIAS DEL USUARIO
La red Las historias del usuario es la teacutecnica utilizada
para especificar los requisitos de software son tarjetas de
papel donde el cliente especifica de manera simplificada
las caracteriacutesticas que el sistema debe poseer ya sean
requisitos funcionales o requisitos no funcionales Se
caracteriza por ser dinaacutemica y flexible cada historia de
usuario debe ser comprensible y delimitada para que los
programadores puedan implementarla en pocas semanas
22 ROLES XP
Seguacuten Kent Beck los roles son
Programador El programador se encarga de escribir las
pruebas unitarias y tambieacuten estaacute encargado de producir el
coacutedigo del sistema
Cliente Encargado de escribir las historias de usuario y
los requisitos funcionales y selecciona las historias por
prioridad de conveniencia al negocio
Encargado de pruebas Encargado de ayudar al cliente a
escribir las pruebas funcionales ademaacutes de ejecutar las
pruebas constantemente encargado de de las
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
8
herramientas de soporte de pruebas como tambieacuten
difundir los resultados de dicha prueba
Encargado de seguimiento Es el encargado de la
realimentacioacuten al equipo y realiza el seguimiento del
proceso de cada iteracioacuten
Entrenador Es el encargado de prever guiacuteas al equipo
basadas en XP y de seguir el proceso correctamente
Consultor Es el que posee un conocimiento especifico
en alguacuten tema necesario para el proyecto para solucionar
problemas
Gestor Es la interaccioacuten entre clientes y programadores
ayudando a trabajar de forma adecuada y de esta manera
coordinar de forma correcta
23 PROCESO XP
El ciclo de desarrollo XP consiste en
El cliente define el valor del negocio a implementar
El programador estima el esfuerzo necesario para su
implementacioacuten
El cliente selecciona que construir de acuerdo con sus
propiedades y las restricciones del tiempo
El programador construye ese valor de negocio
Vuelve al principio
En todas las iteraciones de este ciclo tanto el cliente como
el programador aprenden No se debe presionar al
programador a realizar maacutes trabajo que el estimado ya
que se perderaacute calidad en el software o no se cumpliraacuten
los plazos
El ciclo de vida ideal de XP consiste de seis fases
Exploracioacuten
Planificacioacuten de la Entrega (Release)
Iteraciones
Produccioacuten
Mantenimiento y Muerte del Proyecto
24 PRACTICAS XP
Las siguientes praacutecticas ayudan al desarrollo de software
El juego de la planificacioacuten Hay una comunicacioacuten
frecuente el cliente y los programadores El equipo
teacutecnico realiza una estimacioacuten del esfuerzo requerido para
la implementacioacuten de las historias de usuario y los
clientes deciden sobre el aacutembito y el tiempo de entregas y
de cada iteracioacuten
Entregas pequentildeas Producir raacutepidamente versiones del
sistema que sean operativas aunque no cuenten con toda
la funcionalidad del sistema Esta versioacuten ya constituye
un resultado de valor para el negocio Una entrega no
deberiacutea tardar maacutes de tres meses
Metaacutefora El sistema es definido mediante un conjunto
de metaacuteforas compartidas por el cliente y el equipo de
desarrollo Una metaacutefora es una historia compartida que
describe como deberiacutea funcionar el sistema
Disentildeo simple Se disentildea la solucioacuten maacutes simple que
pueda funcionar y ser implementada en un determinado
momento del proyecto
Pruebas La produccioacuten de coacutedigo estaacute dirigida para las
pruebas unitarias Estas son establecidas por el cliente
antes de escribirse el coacutedigo y son ejecutadas
continuamente ante cada modificacioacuten del sistema
Pruebas Es una actividad constante de reestructuracioacuten
del coacutedigo con el objetivo de remover duplicacioacuten de
coacutedigo mejorar su legibilidad simplificarlo y hacerlo
maacutes flexible para facilitar los cambios Se mejora la
estructura interna del coacutedigo sin alterar su
comportamiento externo
Programacioacuten en parejas Toda la produccioacuten del
coacutedigo debe realizarse con trabajo en parejas de
programadores Para tener ventajas como menor tasa de
errores mejor disentildeo etc
Propiedad colectiva del coacutedigo Cualquier programador
puede cambiar cualquier parte del coacutedigo en cualquier
instante
Integracioacuten continua Cada pieza del coacutedigo es
integrada en el sistema una vez que este listaasi el
sistema puede ser integrado y construido varias veces en
un mismo diacutea
40 horas por semana Se debe trabajar un maacuteximo de 40
horas por semana no se trabajan horas extras en dos
semanas seguidas Si esto ocurre estaacute existe un problema
porque el trabajo extra desmotiva al equipo
Cliente in-situ El cliente tiene que estar presente y
disponible todo el tiempo para el equipo este es uno de
los principales factores de eacutexito para el proyecto XP Y
asiacute guiar y disipar cualquier duda de los programadores
donde la comunicacioacuten es maacutes efectiva que la escrita
Estaacutendares de programacioacuten XP enfatiza que la
comunicacioacuten de los programadores es a traveacutes del
coacutedigo por lo que es importante que se sigan estaacutendares
de programacioacuten para mantener el coacutedigo legible
3 CONCLUCIONES
] INGENIERIacuteA DE SOFTWARE
9
INGENIERIacuteA DE SISTEMAS
Las metodologiacuteas aacutegiles ofrecen una solucioacuten casi a
medida para una gran cantidad de proyectos
La metodologiacutea XP es una de las metodologiacuteas aacutegiles maacutes
extendidas y populares ademaacutes es considerada como una
metodologiacutea posmoderna cuyas grandes capacidades se
generan a traveacutes de procesos emergentes
4 REFERENCIAS
httpwwwmetodologiasSoftcomdesarrolloagil
httpwwwwikipediacommetodologiaXP
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
10
Desarrollo de Scrum
Sergio J Guzmaacuten L Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 Octubre Esq Belisario Salinas
La Paz - Bolivia
sjguzmanusfaedubo
Resumenmdash Scrum es una metodologiacutea aacutegil de desarrollo de
proyectos que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ldquocampos de scrumrdquo al
software
Palabras clave mdash scrum metodologiacutea patroacuten software
sprint rol
I Que es Scrum
Scrum es una metodologiacutea aacutegil de desarrollo de proyectos
que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ―campos de scrum al
software
Esta fue la primera definicioacuten de un patroacuten Scrum aplicado
al software disentildeada por Jeff Sutherland y Ken Schwaber y
presentada en Object-Oriented Programming Systems
Languages amp Applications OOPSLA en 1996
II iquestCoacutemo incorporarla
La competitividad del mercado de desarrollo de Software y
la necesidad de los clientes de reducir el tiempo de
mercado obligan a las organizaciones de desarrollo de
software a ser agresivas en sus calendarios de entrega Esto
ha hecho que hayan surgido metodologiacuteas para la gestioacuten y
desarrollo de software basadas en un proceso iterativo e
incremental Su estructura estaacute basada en corto tiempo los
cuales son iteraciones de 1 a 4 semanas Scrum se usa en
proyectos de entorno complejos donde se desea obtener
resultados raacutepidos y la productividad es lo maacutes importante
En los proyectos basados en Scrum se consideran tres
roles
Duentildeo del producto Es quien determina las propiedades de
los entregables
Maestro de Scrum Administra y facilita la ejecucioacuten del
proceso
Equipo de Trabajo Trabajan en conjunto para entregar
resultados en cada sprint
Fig 1 El flujo de Scrum
Como se puede observar en medio de los participantes del
proceso no quedan claras las responsabilidades del
arquitecto de software Sin embargo como comenta
Charlie Alfred ―la arquitectura es al aceite y el filtro que
lubrica adecuadamente a Scrum
Fig 2 El flujo de Scrum
] INGENIERIacuteA DE SOFTWARE
11
INGENIERIacuteA DE SISTEMAS
Si se compara el rol del arquitecto de edificaciones con el
del arquitecto de software se puede observar que ambos
modelan las construcciones a un alto nivel de abstraccioacuten
proveen posibles soluciones mejoran la comunicacioacuten con
los miembros del equipo de construccioacuten a traveacutes de
modelos visualizan las generalidades del problema
definen los roles y las interacciones entre los componentes
de construccioacuten entre otras tareas Al igual que es
imposible pensar que un rascacielos puede ser construido
sin una arquitectura soacutelida es imposible pensar que
productos de software empresariales puedan ser
implementados sin una arquitectura bien pensada
Seguacuten Bass Clements y Kasman ―La arquitectura de
software de un programa o sistema informaacutetico es la
estructura o estructuras del sistema que incluyen elementos
de software las propiedades externamente visibles de esos
elementos y las relaciones entre ellos Esta definicioacuten nos
lleva a concluir que la arquitectura de software garantiza el
buen desarrollo del software y a tener un sistema que
cumpla con los requerimientos funcionales y no
funcionales del cliente Ademaacutes la arquitectura es clave en
la reutilizacioacuten de artefactos de software en sistemas de
liacutenea de productos de software
Viendo la importancia de la arquitectura en el desarrollo
del software en eacuteste artiacuteculo se presenta una propuesta para
gestionar la arquitectura de Software en Scrum En el
primer capiacutetulo se trata el tema de la localizacioacuten de la
arquitectura de software en el ciclo de desarrollo de Scrum
en el segundo capiacutetulo se describen las tareas del arquitecto
de software en Scrum finalmente se presentan las
conclusiones y el trabajo futuro
III Arquitectura de Software en el ciclo de desarrollo de
Scrum
La idea fundamental de la presente propuesta es adicionar
un sprint inicial llamado ―Sprint 0Prime al inicio del ciclo de
desarrollo El objetivo principal del arquitecto en el Sprint
0 es analizar y disentildear la generalidad del sistema que
satisfaga los requisitos y sea entendible por los miembros
del equipo desde sus diferentes puntos de vista durante el
desarrollo Un punto clave es reutilizar artefactos de
software creados a partir de la arquitectura para ser maacutes
aacutegiles en el desarrollo de productos especiacuteficos
El Sprint 0 comprende tres fases que fueron tomadas del
ciclo de vida de entregas evolutivas En el Sprint 0 se
construye la arquitectura de forma iterativa mediante un
anaacutelisis preliminar de los conductores arquitectoacutenicos
(requisitos funcionales de calidad y del negocio) y de un
estudio de factibilidad del proyecto No se necesita tener
todos los requisitos claros para comenzar la fase de disentildeo
arquitectoacutenico
Para determinar los conductores arquitectoacutenicos se debe
identificar los objetivos del negocio de maacutes alta prioridad
que son pocos Estos objetivos del negocio se convierten en
los escenarios de calidad o casos de uso De esta lista se
deben escoger los que tendraacuten un mayor impacto sobre la
arquitectura El disentildeo arquitectoacutenico puede comenzar una
vez que se encuentran definidos los conductores
arquitectoacutenicos El proceso de anaacutelisis de requisitos seraacute
entonces influenciado por las preguntas generadas durante
el disentildeo arquitectoacutenico
El resultado del Srpint 0 es un documento inicial que
explica la arquitectura El documento puede basarse en los
pasos definidos por el meacutetodo ADD (Attrbute Driver
Design) Este meacutetodo ha sido probado exitosamente en
proyectos anteriores Con ADD se puede definir una
arquitectura de software mediante un proceso de
descomposicioacuten basado en los atributos de calidad de
Software
El documento inicial de la arquitectura se debe avaluar con
el fin de saber si la arquitectura cumple con los requisitos
de calidad Para realizar esta evaluacioacuten se propone el
meacutetodo ATAM (Architecture Tradeoff Analysis Method)
El ATAM revela cuaacuten bien una arquitectura satisface los
objetivos particulares de calidad y provee una
aproximacioacuten de coacutemo los objetivos de calidad interactuacutean
Si la evaluacioacuten de la arquitectura se encuentra que se
deben realizar cambios a la misma entonces eacutesta se debe
refinar hasta llegar a tener como resultado del Sprint 0 el
documento puacuteblico de la arquitectura junto con el sistema
esqueleto Finalmente la arquitectura creada en el Sprint 0
beneficiaraacute el desarrollo en los siguientes sprints
IV Rol del arquitecto de Software en Scrum
El rol y actividades del arquitecto de software cambian de
enfoque dependiendo de si se estaacute en el Sprint 0 o en
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
12
sprints subsecuentes
Fig 3 La Comunicacioacuten
Sprint 0 En sistemas complejos una persona difiacutecilmente
puede cubrir con amplitud teacutecnica las decisiones
arquitectoacutenicas y dar credibilidad a la arquitectura de
software Esto quiere decir que la participacioacuten del equipo
es de vital importancia para la creacioacuten y el mantenimiento
de la arquitectura Un equipo de arquitectos de software
que se aiacutesle del equipo de Scrum puede producir una
arquitectura que corra el riesgo de ser rechazada Es por
esto que recomendamos que el arquitecto o los arquitectos
se software sean miembros del equipo de Scrum Una de
las actividades que se debe realizar en equipo es la
evaluacioacuten de la arquitectura Especiacuteficamente en el
meacutetodo ATAM se requiere la participacioacuten mutua de tres
equipos que trabajan en conjunto con los arquitectos de
software el de evaluacioacuten el de tomadores de decisiones
del proyecto y el de los involucrados en la arquitectura
Sprints subsecuentes El arquitecto de software asegura que
el equipo de Scrum entienda el enfoque y los retos
arquitectoacutenicos maacutes importantes en casa sprint Los
equipos de Scrum realizan construcciones cortas guiados
por las estrategias de la arquitectura A continuacioacuten se
nombran algunas de las responsabilidades del arquitecto de
software desde el Sprint 1 en adelante
El duentildeo del producto y el maestro del Scrum trabajan con
el arquitecto para priorizar los requisitos a implementar en
cada iteracioacuten
El arquitecto comunica las decisiones y facilita las
conversaciones arquitectoacutenicas de distintos puntos de vista
en cada sprint
El arquitecto asegura que haya conformidad entre las
entregas en cada sprint y la arquitectura
El arquitecto responde preguntas y da orientacioacuten
arquitectoacutenica cuando sea necesario
Junto con el maestro de Scrum coordina a los miembros
del equipo para adaptarse a la arquitectura previa
El arquitecto junto con el duentildeo del producto y los
miembros del equipo preparan el Product Backlog
V Conclusioacuten
En el presente artiacuteculo ofrecimos una propuesta para incluir
la arquitectura de software en Scrum En el Sprint 0 se
realizan las actividades concernientes al anaacutelisis y disentildeo
de la arquitectura de software y el sistema esqueleto En
los siguientes sprints el arquitecto de software se asegura
de que la implementacioacuten cumpla con la arquitectura
REFERENCIAS
[3] httpwwwsafecreativeorgwork
[4] Hirotaka Takeuchi es decano de la Graduate School of International
Corporate Strategy en la Universidad Hitotsubashi en Tokio y fue profesor visitante en la Escuela de Negocios Harvard entre 1989 y 1990
[5] Ikujiro NonakaNo soy un guruacute porque me falta carisma
] INGENIERIacuteA DE SOFTWARE
13
INGENIERIacuteA DE SISTEMAS
El futuro de la ingenieriacutea de software Luis E Aguirre
Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 de Octubre esq Belisario Salinas
La Paz - Bolivia leaguirreusfaedubo
Resumen El disentildeo de programas a partir de informacioacuten binaria
significoacute un paso sustantivo para la industria desarrolladora de
software Desde ese hallazgo ocurrido en la deacutecada de los
cincuenta hasta hoy el crecimiento de metodologiacuteas para su
desarrollo ha subido notablemente en complejidad Sin embargo
los ciacuterculos viciosos que acusa hoy la confeccioacuten de programas
informaacuteticos impiden conceptualizar el objeto a un nivel
superior de abstraccioacuten tal y como lo exige el avance tecnoloacutegico
y los procesos de negocios
Palabras clave mdash futuro software ingenieriacutea programador y
desarrollo
I Introduccioacuten
La calidad de los sistemas informaacuteticos satisfaccioacuten de sus
usuarios y clientes son temas ampliamente conocidos
recurrentes y de constante preocupacioacuten por parte de los
practicantes de la Ingenieriacutea de software
Esta joven y dinaacutemica ingenieriacutea siempre estaacute en busca de
mejoras en el desarrollo de sistemas aumento de
productividad del ingeniero de software mayor control del
proceso de desarrollo establecimiento de nuevos meacutetodos de
desarrollo
Fig 1 Primeros programas computacionales en formato de tarjeta perforada
Estos elementos combinados y aplicados de buena forma
logran un buen proceso de desarrollo y en definitiva un buen
producto
Identificar los pasos que ha recorrido esta ingenieriacutea analizar
su contexto actual y finalmente proyectar hacia doacutende se
dirige es el pilar de este artiacuteculo
II iquestSe aplica actualmente la ingenieriacutea del software
La investigacioacuten y el desarrollo de teacutecnicas y meacuteto
dos de ingenieriacutea del software son constantes y suelen suponer
interesantes avances en la resolucioacuten de problemas de
desarrollo de software Sin embargo es habitual que en la
praacutectica diaria profesional no se incluya praacutecticamente
ninguna de las recomendaciones maacutes elementales de la
ingenieriacutea del software En efecto es habitual que el
desarrollo de software se parezca maacutes al descontrol del cuento
de laquosi los programadores fueran albantildeilesraquo ([Novatica
1996]) que a una idiacutelica y bien organizada factoriacutea de
software (concepto de gran vigencia a finales de los ochenta
[Nunamaker et al 1988])
De hecho las evaluaciones de los procesos productivos de
software realizadas a raiacutez de los modelo de procesos de
software (por ejemplo con CMM [Paulk et al 1993])
confirman que el desarrollo de software suele estar
baacutesicamente en estado caoacutetico
Y no soacutelo en como uno podriacutea pensar pequentildeas
organizaciones de un paiacutes mediterraacuteneo como el nuestro sino
en tambieacuten en las empresas adjudicatarias de interesantes
contratos de defensa de paiacuteses laquoavanzadosraquo como EEUU o
Japoacuten Si bien estos modelos de evaluacioacuten auacuten acumulan
distintas acusaciones de rigidez o falta de contraste empiacuterico
los resultados obtenidos en sus evaluaciones resultan
consistentes con la sensacioacuten de constante laquoapagafuegosraquo que
suelen sufrir los profesionales del software Tambieacuten suelen
revelar la praacutectica despreocupacioacuten de los responsables de las
organizaciones de software por la mejora de la calidad de sus
procesos de trabajo o de sus productos bien sea por contar con
una situacioacuten interna de empresa poco propicia porque el
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
14
ambiente del mercado no fomenta la preocupacioacuten por estos
temas o bien por su poco intereacutes real en la buacutesqueda de la
calidad
III La actualidad
La gran mayoriacutea de los sistemas de software creados hoy en
diacutea son los llamados sistemas corporativos es decir son
orientados a formar una parte importante de los negocios de
las grandes empresas
Continuando en nuestro contexto se identifica un nuevo
enfoque del problema de desarrollo el apoyo en la
sincronizacioacuten de los procesos de negocio estructuras
complejas de informacioacuten manejada por el negocio todo esto
entrelazado por restricciones dadas por las reglas del negocio
La tecnologiacutea actual por otro lado ha alejado maacutes todaviacutea los
ingenieros de las maacutequinas sistemas operativos incluso de
las tareas de programacioacuten
El enfoque de la mayoriacutea de los equipos de desarrollo e
ingenieros participes en proyectos sigue siendo con un bajo
nivel de abstraccioacuten cerca de la codificacioacuten Se tiende a
pensar en la base de datos a utilizar establecer la navegacioacuten
de las paacuteginas programar los protocolos de comunicacioacuten etc
Esto lleva a utilizar las tareas de programacioacuten y de pruebas
para validar el entendimiento y cumplimiento de la
funcionalidad de los sistemas
Lo anteriormente expuesto muestra un problema
metodoloacutegico consecuencia de un desfase entre el enfoque
teoacuterico oacuteptimo (anaacutelisis de negocio) y el enfoque praacutectico real
(programacioacuten y pruebas) en los proyectos de hoy En otras
palabras la metodologiacutea actualmente usada estaacute atrasada con
respecto al avance tecnoloacutegico
Desarrollando maacutes esta idea se identifican algunos
problemas concretos de las metodologiacuteas
Ellas no obligan a sus ejecutores a respetar todas las
normas y los procedimientos establecidos especialmente
en las etapas tempranas del proyecto Es muy faacutecil y
tentador ―saltar una o maacutes de estas etapas uno o maacutes
documentos o modelos pasando directamente a
implementacioacuten produccioacuten y posterior correccioacuten de los
sistemas desarrollados
Control de calidad del producto final La codificacioacuten y
complejidad del programa es demasiada para ser revisada
y verificada fehacientemente Por otro lado los coacutedigos
fuentes y los ejecutables actualmente son los uacutenicos
entregables eficientemente verificables
Estos dos problemas al parecer forman una situacioacuten
contradictoria la metodologiacutea tradicional no permite validar
eficientemente la calidad de los sistemas antes de llegar al
coacutedigo fuente y por otro lado tampoco permite llegar
eficientemente a coacutedigos fuentes de calidad
IV Futuro
La salida de este ―ciacuterculo vicioso que se propone es
bastante natural analizar la situacioacuten actual de la ingenieriacutea
de software en la luz de sus tendencias histoacutericas
La primera de ellas relacionada con los problemas que
resuelven los sistemas obviamente presente y muy utilizada
en nuestra realidad los sistemas de hoy no soacutelo resuelven los
problemas del mundo real sino que estaacuten fuertemente influen-
ciando el desarrollo del mundo real
Fig2 Modela
El enfoque de los ingenieros desde hace unos antildeos no se ha
movido significativamente por el camino del aumento de
abstraccioacuten establecido histoacutericamente Se han hecho ciertos
avances en temas puntuales (como arquitecturas de
componentes patrones de disentildeo nuevos lenguajes de
programacioacuten etc) pero conceptualmente
metodoloacutegicamente la tarea de programacioacuten sigue siendo
ejecutada de la misma forma escribiendo coacutedigos fuentes en
forma de los programas textuales
Eacuteste es justamente el ―atraso metodoloacutegico que se
mencionoacute Para disminuir la brecha entre las tendencias
histoacutericas es necesario ajustar la metodologiacutea en teacuterminos de
aumentar la abstraccioacuten del enfoque de los ingenieros de
software y acercarlo a la abstraccioacuten del problema
El aumento de la abstraccioacuten del proceso de desarrollo del
software hace pensar que la proacutexima generacioacuten de meacutetodos
de desarrollo se perfila en un conceptualmente nuevo con-
] INGENIERIacuteA DE SOFTWARE
15
INGENIERIacuteA DE SISTEMAS
junto de herramientas que permitan aumentar en un mayor
grado al actual la abstraccioacuten escondiendo los detalles de maacutes
bajo nivel
Fig3 Probable modelo a futuro
Las nuevas herramientas permitiraacuten ―programar en nivel
de anaacutelisis generando coacutedigos en un lenguaje de
programacioacuten tradicional de forma automaacutetica tal como hoy
los compiladores generan el lenguaje maacutequina a partir del
coacutedigo fuente Nuevos ―lenguajes de programacioacuten
naturalmente seriacutean visuales y se pareceriacutean a las
especificaciones de software en uno de los lenguajes de
modelamiento por ejemplo UML
V Conclusioacuten
Es muy probable que estemos proacuteximos a ver un nuevo
paso evolutivo en la ingenieriacutea de software Tan grande como
el invento de lenguajes de alto nivel o anaacutelisis y disentildeo
orientado a objetos Una nueva generacioacuten que absorberaacute a la
actual automatizando la mayoriacutea de las buenas praacutecticas
usadas actualmente
Una pregunta natural es si una maacutequina puede llegar a
generar programas tan buenos como los hechos por un pro-
gramador experto En vez de ―romper la cabeza con esta
pregunta ahora quizaacutes seriacutea suficiente recordarse otra vez de
la historia Los primeros compiladores de ninguna generacioacuten
alcanzaban de inmediato lo deseable y oacuteptimo Sin embargo
con el paso del tiempo apoyados en la experiencia de los
ingenieros y en el avance tecnoloacutegico se mejoraban hasta el
nivel de superar significativamente las generaciones
anteriores
Es poco factible que hoy en diacutea alguien cuestione la calidad
de los compiladores de por ejemplo Java y la calidad del
coacutedigo de maacutequina generado por ellos
VI Referencias [6] Website [Online]
httpwwwenterpriseanalystnetdownloadmda_informaticap
df
[7] httpwwwslidesharenetamrrochafuturo-del-software-impacto-en-las-organizaciones-y-en-los-profesionales
[8] httpwwwdcubaareventseci2008conferenciasIngSoftHexacta
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
7
INGENIERIacuteA DE SISTEMAS
EXTREME PROGRAMMING PARA DESARROLLO
DE SOFTWARE
Erwin Adaacuten Choque Ulloa Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
Plaza Avaroa esq Belisario Salinas
La paz ndash Bolivia adan_ekinghotmailcom
Resumen
En este articulo se describiraacute algunas de las metodologiacuteas
agiles de desarrollo de software puesto que para asegurar el
eacutexito durante el desarrollo de un software es importante
saber la metodologiacutea de desarrollo la cual nos provee una
guiacutea para la correcta aplicacioacuten y desarrollo de Software
La metodologiacutea Extreme Programming XP que es una de las
metodologiacuteas aacutegiles maacutes extendidas y populares ademaacutes es
considerada como una metodologiacutea posmoderna donde
grandes capacidades se generan a traveacutes de procesos
emergentes
Palabras claves Extreme Programming metodologiacutea software
usuario
1 INTRODUCCION
El esquema tradicional para abordar el desarrollo de
software ha demostrado ser efectivo y necesario en
proyectos de gran tamantildeo respecto a tiempo y recursos
Sin embargo este enfoque no resulta ser el maacutes adecuado
para muchos de los proyectos actuales donde el entorno
del sistema es muy cambiante y en donde se exige
reducir draacutesticamente los tiempos de desarrollo pero
manteniendo una alta calidad Ante este problema las
metodologiacuteas aacutegiles son una posible respuesta para llenar
ese vaciacuteo metodoloacutegico Orientadas para proyectos
pequentildeos las metodologiacuteas aacutegiles constituyen una
solucioacuten
A continuacioacuten se describiraacute cada una de las
metodologiacuteas de desarrollo de software
2 EXTREME PROGRAMMING XP
La metodologiacutea de desarrollo de software XP es la
primera metodologiacutea aacutegil y la que le dio conciencia al
movimiento actual de metodologiacuteas aacutegiles Kent Beck el
padre de la metodologiacutea XP se basa en realimentacioacuten
continua entre el cliente y el equipo de desarrollo
comunicacioacuten fluida entre todos los participantes
simplicidad en las soluciones implementadas y facilidad
para enfrentar los cambios XP se define como
especialmente adecuada para proyectos con requisitos
imprecisos y muy cambiantes y donde existe un alto
riesgo teacutecnico Ahora se describiraacute las caracteriacutesticas
esenciales del Extreme Programming
21 LAS HISTORIAS DEL USUARIO
La red Las historias del usuario es la teacutecnica utilizada
para especificar los requisitos de software son tarjetas de
papel donde el cliente especifica de manera simplificada
las caracteriacutesticas que el sistema debe poseer ya sean
requisitos funcionales o requisitos no funcionales Se
caracteriza por ser dinaacutemica y flexible cada historia de
usuario debe ser comprensible y delimitada para que los
programadores puedan implementarla en pocas semanas
22 ROLES XP
Seguacuten Kent Beck los roles son
Programador El programador se encarga de escribir las
pruebas unitarias y tambieacuten estaacute encargado de producir el
coacutedigo del sistema
Cliente Encargado de escribir las historias de usuario y
los requisitos funcionales y selecciona las historias por
prioridad de conveniencia al negocio
Encargado de pruebas Encargado de ayudar al cliente a
escribir las pruebas funcionales ademaacutes de ejecutar las
pruebas constantemente encargado de de las
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
8
herramientas de soporte de pruebas como tambieacuten
difundir los resultados de dicha prueba
Encargado de seguimiento Es el encargado de la
realimentacioacuten al equipo y realiza el seguimiento del
proceso de cada iteracioacuten
Entrenador Es el encargado de prever guiacuteas al equipo
basadas en XP y de seguir el proceso correctamente
Consultor Es el que posee un conocimiento especifico
en alguacuten tema necesario para el proyecto para solucionar
problemas
Gestor Es la interaccioacuten entre clientes y programadores
ayudando a trabajar de forma adecuada y de esta manera
coordinar de forma correcta
23 PROCESO XP
El ciclo de desarrollo XP consiste en
El cliente define el valor del negocio a implementar
El programador estima el esfuerzo necesario para su
implementacioacuten
El cliente selecciona que construir de acuerdo con sus
propiedades y las restricciones del tiempo
El programador construye ese valor de negocio
Vuelve al principio
En todas las iteraciones de este ciclo tanto el cliente como
el programador aprenden No se debe presionar al
programador a realizar maacutes trabajo que el estimado ya
que se perderaacute calidad en el software o no se cumpliraacuten
los plazos
El ciclo de vida ideal de XP consiste de seis fases
Exploracioacuten
Planificacioacuten de la Entrega (Release)
Iteraciones
Produccioacuten
Mantenimiento y Muerte del Proyecto
24 PRACTICAS XP
Las siguientes praacutecticas ayudan al desarrollo de software
El juego de la planificacioacuten Hay una comunicacioacuten
frecuente el cliente y los programadores El equipo
teacutecnico realiza una estimacioacuten del esfuerzo requerido para
la implementacioacuten de las historias de usuario y los
clientes deciden sobre el aacutembito y el tiempo de entregas y
de cada iteracioacuten
Entregas pequentildeas Producir raacutepidamente versiones del
sistema que sean operativas aunque no cuenten con toda
la funcionalidad del sistema Esta versioacuten ya constituye
un resultado de valor para el negocio Una entrega no
deberiacutea tardar maacutes de tres meses
Metaacutefora El sistema es definido mediante un conjunto
de metaacuteforas compartidas por el cliente y el equipo de
desarrollo Una metaacutefora es una historia compartida que
describe como deberiacutea funcionar el sistema
Disentildeo simple Se disentildea la solucioacuten maacutes simple que
pueda funcionar y ser implementada en un determinado
momento del proyecto
Pruebas La produccioacuten de coacutedigo estaacute dirigida para las
pruebas unitarias Estas son establecidas por el cliente
antes de escribirse el coacutedigo y son ejecutadas
continuamente ante cada modificacioacuten del sistema
Pruebas Es una actividad constante de reestructuracioacuten
del coacutedigo con el objetivo de remover duplicacioacuten de
coacutedigo mejorar su legibilidad simplificarlo y hacerlo
maacutes flexible para facilitar los cambios Se mejora la
estructura interna del coacutedigo sin alterar su
comportamiento externo
Programacioacuten en parejas Toda la produccioacuten del
coacutedigo debe realizarse con trabajo en parejas de
programadores Para tener ventajas como menor tasa de
errores mejor disentildeo etc
Propiedad colectiva del coacutedigo Cualquier programador
puede cambiar cualquier parte del coacutedigo en cualquier
instante
Integracioacuten continua Cada pieza del coacutedigo es
integrada en el sistema una vez que este listaasi el
sistema puede ser integrado y construido varias veces en
un mismo diacutea
40 horas por semana Se debe trabajar un maacuteximo de 40
horas por semana no se trabajan horas extras en dos
semanas seguidas Si esto ocurre estaacute existe un problema
porque el trabajo extra desmotiva al equipo
Cliente in-situ El cliente tiene que estar presente y
disponible todo el tiempo para el equipo este es uno de
los principales factores de eacutexito para el proyecto XP Y
asiacute guiar y disipar cualquier duda de los programadores
donde la comunicacioacuten es maacutes efectiva que la escrita
Estaacutendares de programacioacuten XP enfatiza que la
comunicacioacuten de los programadores es a traveacutes del
coacutedigo por lo que es importante que se sigan estaacutendares
de programacioacuten para mantener el coacutedigo legible
3 CONCLUCIONES
] INGENIERIacuteA DE SOFTWARE
9
INGENIERIacuteA DE SISTEMAS
Las metodologiacuteas aacutegiles ofrecen una solucioacuten casi a
medida para una gran cantidad de proyectos
La metodologiacutea XP es una de las metodologiacuteas aacutegiles maacutes
extendidas y populares ademaacutes es considerada como una
metodologiacutea posmoderna cuyas grandes capacidades se
generan a traveacutes de procesos emergentes
4 REFERENCIAS
httpwwwmetodologiasSoftcomdesarrolloagil
httpwwwwikipediacommetodologiaXP
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
10
Desarrollo de Scrum
Sergio J Guzmaacuten L Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 Octubre Esq Belisario Salinas
La Paz - Bolivia
sjguzmanusfaedubo
Resumenmdash Scrum es una metodologiacutea aacutegil de desarrollo de
proyectos que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ldquocampos de scrumrdquo al
software
Palabras clave mdash scrum metodologiacutea patroacuten software
sprint rol
I Que es Scrum
Scrum es una metodologiacutea aacutegil de desarrollo de proyectos
que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ―campos de scrum al
software
Esta fue la primera definicioacuten de un patroacuten Scrum aplicado
al software disentildeada por Jeff Sutherland y Ken Schwaber y
presentada en Object-Oriented Programming Systems
Languages amp Applications OOPSLA en 1996
II iquestCoacutemo incorporarla
La competitividad del mercado de desarrollo de Software y
la necesidad de los clientes de reducir el tiempo de
mercado obligan a las organizaciones de desarrollo de
software a ser agresivas en sus calendarios de entrega Esto
ha hecho que hayan surgido metodologiacuteas para la gestioacuten y
desarrollo de software basadas en un proceso iterativo e
incremental Su estructura estaacute basada en corto tiempo los
cuales son iteraciones de 1 a 4 semanas Scrum se usa en
proyectos de entorno complejos donde se desea obtener
resultados raacutepidos y la productividad es lo maacutes importante
En los proyectos basados en Scrum se consideran tres
roles
Duentildeo del producto Es quien determina las propiedades de
los entregables
Maestro de Scrum Administra y facilita la ejecucioacuten del
proceso
Equipo de Trabajo Trabajan en conjunto para entregar
resultados en cada sprint
Fig 1 El flujo de Scrum
Como se puede observar en medio de los participantes del
proceso no quedan claras las responsabilidades del
arquitecto de software Sin embargo como comenta
Charlie Alfred ―la arquitectura es al aceite y el filtro que
lubrica adecuadamente a Scrum
Fig 2 El flujo de Scrum
] INGENIERIacuteA DE SOFTWARE
11
INGENIERIacuteA DE SISTEMAS
Si se compara el rol del arquitecto de edificaciones con el
del arquitecto de software se puede observar que ambos
modelan las construcciones a un alto nivel de abstraccioacuten
proveen posibles soluciones mejoran la comunicacioacuten con
los miembros del equipo de construccioacuten a traveacutes de
modelos visualizan las generalidades del problema
definen los roles y las interacciones entre los componentes
de construccioacuten entre otras tareas Al igual que es
imposible pensar que un rascacielos puede ser construido
sin una arquitectura soacutelida es imposible pensar que
productos de software empresariales puedan ser
implementados sin una arquitectura bien pensada
Seguacuten Bass Clements y Kasman ―La arquitectura de
software de un programa o sistema informaacutetico es la
estructura o estructuras del sistema que incluyen elementos
de software las propiedades externamente visibles de esos
elementos y las relaciones entre ellos Esta definicioacuten nos
lleva a concluir que la arquitectura de software garantiza el
buen desarrollo del software y a tener un sistema que
cumpla con los requerimientos funcionales y no
funcionales del cliente Ademaacutes la arquitectura es clave en
la reutilizacioacuten de artefactos de software en sistemas de
liacutenea de productos de software
Viendo la importancia de la arquitectura en el desarrollo
del software en eacuteste artiacuteculo se presenta una propuesta para
gestionar la arquitectura de Software en Scrum En el
primer capiacutetulo se trata el tema de la localizacioacuten de la
arquitectura de software en el ciclo de desarrollo de Scrum
en el segundo capiacutetulo se describen las tareas del arquitecto
de software en Scrum finalmente se presentan las
conclusiones y el trabajo futuro
III Arquitectura de Software en el ciclo de desarrollo de
Scrum
La idea fundamental de la presente propuesta es adicionar
un sprint inicial llamado ―Sprint 0Prime al inicio del ciclo de
desarrollo El objetivo principal del arquitecto en el Sprint
0 es analizar y disentildear la generalidad del sistema que
satisfaga los requisitos y sea entendible por los miembros
del equipo desde sus diferentes puntos de vista durante el
desarrollo Un punto clave es reutilizar artefactos de
software creados a partir de la arquitectura para ser maacutes
aacutegiles en el desarrollo de productos especiacuteficos
El Sprint 0 comprende tres fases que fueron tomadas del
ciclo de vida de entregas evolutivas En el Sprint 0 se
construye la arquitectura de forma iterativa mediante un
anaacutelisis preliminar de los conductores arquitectoacutenicos
(requisitos funcionales de calidad y del negocio) y de un
estudio de factibilidad del proyecto No se necesita tener
todos los requisitos claros para comenzar la fase de disentildeo
arquitectoacutenico
Para determinar los conductores arquitectoacutenicos se debe
identificar los objetivos del negocio de maacutes alta prioridad
que son pocos Estos objetivos del negocio se convierten en
los escenarios de calidad o casos de uso De esta lista se
deben escoger los que tendraacuten un mayor impacto sobre la
arquitectura El disentildeo arquitectoacutenico puede comenzar una
vez que se encuentran definidos los conductores
arquitectoacutenicos El proceso de anaacutelisis de requisitos seraacute
entonces influenciado por las preguntas generadas durante
el disentildeo arquitectoacutenico
El resultado del Srpint 0 es un documento inicial que
explica la arquitectura El documento puede basarse en los
pasos definidos por el meacutetodo ADD (Attrbute Driver
Design) Este meacutetodo ha sido probado exitosamente en
proyectos anteriores Con ADD se puede definir una
arquitectura de software mediante un proceso de
descomposicioacuten basado en los atributos de calidad de
Software
El documento inicial de la arquitectura se debe avaluar con
el fin de saber si la arquitectura cumple con los requisitos
de calidad Para realizar esta evaluacioacuten se propone el
meacutetodo ATAM (Architecture Tradeoff Analysis Method)
El ATAM revela cuaacuten bien una arquitectura satisface los
objetivos particulares de calidad y provee una
aproximacioacuten de coacutemo los objetivos de calidad interactuacutean
Si la evaluacioacuten de la arquitectura se encuentra que se
deben realizar cambios a la misma entonces eacutesta se debe
refinar hasta llegar a tener como resultado del Sprint 0 el
documento puacuteblico de la arquitectura junto con el sistema
esqueleto Finalmente la arquitectura creada en el Sprint 0
beneficiaraacute el desarrollo en los siguientes sprints
IV Rol del arquitecto de Software en Scrum
El rol y actividades del arquitecto de software cambian de
enfoque dependiendo de si se estaacute en el Sprint 0 o en
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
12
sprints subsecuentes
Fig 3 La Comunicacioacuten
Sprint 0 En sistemas complejos una persona difiacutecilmente
puede cubrir con amplitud teacutecnica las decisiones
arquitectoacutenicas y dar credibilidad a la arquitectura de
software Esto quiere decir que la participacioacuten del equipo
es de vital importancia para la creacioacuten y el mantenimiento
de la arquitectura Un equipo de arquitectos de software
que se aiacutesle del equipo de Scrum puede producir una
arquitectura que corra el riesgo de ser rechazada Es por
esto que recomendamos que el arquitecto o los arquitectos
se software sean miembros del equipo de Scrum Una de
las actividades que se debe realizar en equipo es la
evaluacioacuten de la arquitectura Especiacuteficamente en el
meacutetodo ATAM se requiere la participacioacuten mutua de tres
equipos que trabajan en conjunto con los arquitectos de
software el de evaluacioacuten el de tomadores de decisiones
del proyecto y el de los involucrados en la arquitectura
Sprints subsecuentes El arquitecto de software asegura que
el equipo de Scrum entienda el enfoque y los retos
arquitectoacutenicos maacutes importantes en casa sprint Los
equipos de Scrum realizan construcciones cortas guiados
por las estrategias de la arquitectura A continuacioacuten se
nombran algunas de las responsabilidades del arquitecto de
software desde el Sprint 1 en adelante
El duentildeo del producto y el maestro del Scrum trabajan con
el arquitecto para priorizar los requisitos a implementar en
cada iteracioacuten
El arquitecto comunica las decisiones y facilita las
conversaciones arquitectoacutenicas de distintos puntos de vista
en cada sprint
El arquitecto asegura que haya conformidad entre las
entregas en cada sprint y la arquitectura
El arquitecto responde preguntas y da orientacioacuten
arquitectoacutenica cuando sea necesario
Junto con el maestro de Scrum coordina a los miembros
del equipo para adaptarse a la arquitectura previa
El arquitecto junto con el duentildeo del producto y los
miembros del equipo preparan el Product Backlog
V Conclusioacuten
En el presente artiacuteculo ofrecimos una propuesta para incluir
la arquitectura de software en Scrum En el Sprint 0 se
realizan las actividades concernientes al anaacutelisis y disentildeo
de la arquitectura de software y el sistema esqueleto En
los siguientes sprints el arquitecto de software se asegura
de que la implementacioacuten cumpla con la arquitectura
REFERENCIAS
[3] httpwwwsafecreativeorgwork
[4] Hirotaka Takeuchi es decano de la Graduate School of International
Corporate Strategy en la Universidad Hitotsubashi en Tokio y fue profesor visitante en la Escuela de Negocios Harvard entre 1989 y 1990
[5] Ikujiro NonakaNo soy un guruacute porque me falta carisma
] INGENIERIacuteA DE SOFTWARE
13
INGENIERIacuteA DE SISTEMAS
El futuro de la ingenieriacutea de software Luis E Aguirre
Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 de Octubre esq Belisario Salinas
La Paz - Bolivia leaguirreusfaedubo
Resumen El disentildeo de programas a partir de informacioacuten binaria
significoacute un paso sustantivo para la industria desarrolladora de
software Desde ese hallazgo ocurrido en la deacutecada de los
cincuenta hasta hoy el crecimiento de metodologiacuteas para su
desarrollo ha subido notablemente en complejidad Sin embargo
los ciacuterculos viciosos que acusa hoy la confeccioacuten de programas
informaacuteticos impiden conceptualizar el objeto a un nivel
superior de abstraccioacuten tal y como lo exige el avance tecnoloacutegico
y los procesos de negocios
Palabras clave mdash futuro software ingenieriacutea programador y
desarrollo
I Introduccioacuten
La calidad de los sistemas informaacuteticos satisfaccioacuten de sus
usuarios y clientes son temas ampliamente conocidos
recurrentes y de constante preocupacioacuten por parte de los
practicantes de la Ingenieriacutea de software
Esta joven y dinaacutemica ingenieriacutea siempre estaacute en busca de
mejoras en el desarrollo de sistemas aumento de
productividad del ingeniero de software mayor control del
proceso de desarrollo establecimiento de nuevos meacutetodos de
desarrollo
Fig 1 Primeros programas computacionales en formato de tarjeta perforada
Estos elementos combinados y aplicados de buena forma
logran un buen proceso de desarrollo y en definitiva un buen
producto
Identificar los pasos que ha recorrido esta ingenieriacutea analizar
su contexto actual y finalmente proyectar hacia doacutende se
dirige es el pilar de este artiacuteculo
II iquestSe aplica actualmente la ingenieriacutea del software
La investigacioacuten y el desarrollo de teacutecnicas y meacuteto
dos de ingenieriacutea del software son constantes y suelen suponer
interesantes avances en la resolucioacuten de problemas de
desarrollo de software Sin embargo es habitual que en la
praacutectica diaria profesional no se incluya praacutecticamente
ninguna de las recomendaciones maacutes elementales de la
ingenieriacutea del software En efecto es habitual que el
desarrollo de software se parezca maacutes al descontrol del cuento
de laquosi los programadores fueran albantildeilesraquo ([Novatica
1996]) que a una idiacutelica y bien organizada factoriacutea de
software (concepto de gran vigencia a finales de los ochenta
[Nunamaker et al 1988])
De hecho las evaluaciones de los procesos productivos de
software realizadas a raiacutez de los modelo de procesos de
software (por ejemplo con CMM [Paulk et al 1993])
confirman que el desarrollo de software suele estar
baacutesicamente en estado caoacutetico
Y no soacutelo en como uno podriacutea pensar pequentildeas
organizaciones de un paiacutes mediterraacuteneo como el nuestro sino
en tambieacuten en las empresas adjudicatarias de interesantes
contratos de defensa de paiacuteses laquoavanzadosraquo como EEUU o
Japoacuten Si bien estos modelos de evaluacioacuten auacuten acumulan
distintas acusaciones de rigidez o falta de contraste empiacuterico
los resultados obtenidos en sus evaluaciones resultan
consistentes con la sensacioacuten de constante laquoapagafuegosraquo que
suelen sufrir los profesionales del software Tambieacuten suelen
revelar la praacutectica despreocupacioacuten de los responsables de las
organizaciones de software por la mejora de la calidad de sus
procesos de trabajo o de sus productos bien sea por contar con
una situacioacuten interna de empresa poco propicia porque el
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
14
ambiente del mercado no fomenta la preocupacioacuten por estos
temas o bien por su poco intereacutes real en la buacutesqueda de la
calidad
III La actualidad
La gran mayoriacutea de los sistemas de software creados hoy en
diacutea son los llamados sistemas corporativos es decir son
orientados a formar una parte importante de los negocios de
las grandes empresas
Continuando en nuestro contexto se identifica un nuevo
enfoque del problema de desarrollo el apoyo en la
sincronizacioacuten de los procesos de negocio estructuras
complejas de informacioacuten manejada por el negocio todo esto
entrelazado por restricciones dadas por las reglas del negocio
La tecnologiacutea actual por otro lado ha alejado maacutes todaviacutea los
ingenieros de las maacutequinas sistemas operativos incluso de
las tareas de programacioacuten
El enfoque de la mayoriacutea de los equipos de desarrollo e
ingenieros participes en proyectos sigue siendo con un bajo
nivel de abstraccioacuten cerca de la codificacioacuten Se tiende a
pensar en la base de datos a utilizar establecer la navegacioacuten
de las paacuteginas programar los protocolos de comunicacioacuten etc
Esto lleva a utilizar las tareas de programacioacuten y de pruebas
para validar el entendimiento y cumplimiento de la
funcionalidad de los sistemas
Lo anteriormente expuesto muestra un problema
metodoloacutegico consecuencia de un desfase entre el enfoque
teoacuterico oacuteptimo (anaacutelisis de negocio) y el enfoque praacutectico real
(programacioacuten y pruebas) en los proyectos de hoy En otras
palabras la metodologiacutea actualmente usada estaacute atrasada con
respecto al avance tecnoloacutegico
Desarrollando maacutes esta idea se identifican algunos
problemas concretos de las metodologiacuteas
Ellas no obligan a sus ejecutores a respetar todas las
normas y los procedimientos establecidos especialmente
en las etapas tempranas del proyecto Es muy faacutecil y
tentador ―saltar una o maacutes de estas etapas uno o maacutes
documentos o modelos pasando directamente a
implementacioacuten produccioacuten y posterior correccioacuten de los
sistemas desarrollados
Control de calidad del producto final La codificacioacuten y
complejidad del programa es demasiada para ser revisada
y verificada fehacientemente Por otro lado los coacutedigos
fuentes y los ejecutables actualmente son los uacutenicos
entregables eficientemente verificables
Estos dos problemas al parecer forman una situacioacuten
contradictoria la metodologiacutea tradicional no permite validar
eficientemente la calidad de los sistemas antes de llegar al
coacutedigo fuente y por otro lado tampoco permite llegar
eficientemente a coacutedigos fuentes de calidad
IV Futuro
La salida de este ―ciacuterculo vicioso que se propone es
bastante natural analizar la situacioacuten actual de la ingenieriacutea
de software en la luz de sus tendencias histoacutericas
La primera de ellas relacionada con los problemas que
resuelven los sistemas obviamente presente y muy utilizada
en nuestra realidad los sistemas de hoy no soacutelo resuelven los
problemas del mundo real sino que estaacuten fuertemente influen-
ciando el desarrollo del mundo real
Fig2 Modela
El enfoque de los ingenieros desde hace unos antildeos no se ha
movido significativamente por el camino del aumento de
abstraccioacuten establecido histoacutericamente Se han hecho ciertos
avances en temas puntuales (como arquitecturas de
componentes patrones de disentildeo nuevos lenguajes de
programacioacuten etc) pero conceptualmente
metodoloacutegicamente la tarea de programacioacuten sigue siendo
ejecutada de la misma forma escribiendo coacutedigos fuentes en
forma de los programas textuales
Eacuteste es justamente el ―atraso metodoloacutegico que se
mencionoacute Para disminuir la brecha entre las tendencias
histoacutericas es necesario ajustar la metodologiacutea en teacuterminos de
aumentar la abstraccioacuten del enfoque de los ingenieros de
software y acercarlo a la abstraccioacuten del problema
El aumento de la abstraccioacuten del proceso de desarrollo del
software hace pensar que la proacutexima generacioacuten de meacutetodos
de desarrollo se perfila en un conceptualmente nuevo con-
] INGENIERIacuteA DE SOFTWARE
15
INGENIERIacuteA DE SISTEMAS
junto de herramientas que permitan aumentar en un mayor
grado al actual la abstraccioacuten escondiendo los detalles de maacutes
bajo nivel
Fig3 Probable modelo a futuro
Las nuevas herramientas permitiraacuten ―programar en nivel
de anaacutelisis generando coacutedigos en un lenguaje de
programacioacuten tradicional de forma automaacutetica tal como hoy
los compiladores generan el lenguaje maacutequina a partir del
coacutedigo fuente Nuevos ―lenguajes de programacioacuten
naturalmente seriacutean visuales y se pareceriacutean a las
especificaciones de software en uno de los lenguajes de
modelamiento por ejemplo UML
V Conclusioacuten
Es muy probable que estemos proacuteximos a ver un nuevo
paso evolutivo en la ingenieriacutea de software Tan grande como
el invento de lenguajes de alto nivel o anaacutelisis y disentildeo
orientado a objetos Una nueva generacioacuten que absorberaacute a la
actual automatizando la mayoriacutea de las buenas praacutecticas
usadas actualmente
Una pregunta natural es si una maacutequina puede llegar a
generar programas tan buenos como los hechos por un pro-
gramador experto En vez de ―romper la cabeza con esta
pregunta ahora quizaacutes seriacutea suficiente recordarse otra vez de
la historia Los primeros compiladores de ninguna generacioacuten
alcanzaban de inmediato lo deseable y oacuteptimo Sin embargo
con el paso del tiempo apoyados en la experiencia de los
ingenieros y en el avance tecnoloacutegico se mejoraban hasta el
nivel de superar significativamente las generaciones
anteriores
Es poco factible que hoy en diacutea alguien cuestione la calidad
de los compiladores de por ejemplo Java y la calidad del
coacutedigo de maacutequina generado por ellos
VI Referencias [6] Website [Online]
httpwwwenterpriseanalystnetdownloadmda_informaticap
df
[7] httpwwwslidesharenetamrrochafuturo-del-software-impacto-en-las-organizaciones-y-en-los-profesionales
[8] httpwwwdcubaareventseci2008conferenciasIngSoftHexacta
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
8
herramientas de soporte de pruebas como tambieacuten
difundir los resultados de dicha prueba
Encargado de seguimiento Es el encargado de la
realimentacioacuten al equipo y realiza el seguimiento del
proceso de cada iteracioacuten
Entrenador Es el encargado de prever guiacuteas al equipo
basadas en XP y de seguir el proceso correctamente
Consultor Es el que posee un conocimiento especifico
en alguacuten tema necesario para el proyecto para solucionar
problemas
Gestor Es la interaccioacuten entre clientes y programadores
ayudando a trabajar de forma adecuada y de esta manera
coordinar de forma correcta
23 PROCESO XP
El ciclo de desarrollo XP consiste en
El cliente define el valor del negocio a implementar
El programador estima el esfuerzo necesario para su
implementacioacuten
El cliente selecciona que construir de acuerdo con sus
propiedades y las restricciones del tiempo
El programador construye ese valor de negocio
Vuelve al principio
En todas las iteraciones de este ciclo tanto el cliente como
el programador aprenden No se debe presionar al
programador a realizar maacutes trabajo que el estimado ya
que se perderaacute calidad en el software o no se cumpliraacuten
los plazos
El ciclo de vida ideal de XP consiste de seis fases
Exploracioacuten
Planificacioacuten de la Entrega (Release)
Iteraciones
Produccioacuten
Mantenimiento y Muerte del Proyecto
24 PRACTICAS XP
Las siguientes praacutecticas ayudan al desarrollo de software
El juego de la planificacioacuten Hay una comunicacioacuten
frecuente el cliente y los programadores El equipo
teacutecnico realiza una estimacioacuten del esfuerzo requerido para
la implementacioacuten de las historias de usuario y los
clientes deciden sobre el aacutembito y el tiempo de entregas y
de cada iteracioacuten
Entregas pequentildeas Producir raacutepidamente versiones del
sistema que sean operativas aunque no cuenten con toda
la funcionalidad del sistema Esta versioacuten ya constituye
un resultado de valor para el negocio Una entrega no
deberiacutea tardar maacutes de tres meses
Metaacutefora El sistema es definido mediante un conjunto
de metaacuteforas compartidas por el cliente y el equipo de
desarrollo Una metaacutefora es una historia compartida que
describe como deberiacutea funcionar el sistema
Disentildeo simple Se disentildea la solucioacuten maacutes simple que
pueda funcionar y ser implementada en un determinado
momento del proyecto
Pruebas La produccioacuten de coacutedigo estaacute dirigida para las
pruebas unitarias Estas son establecidas por el cliente
antes de escribirse el coacutedigo y son ejecutadas
continuamente ante cada modificacioacuten del sistema
Pruebas Es una actividad constante de reestructuracioacuten
del coacutedigo con el objetivo de remover duplicacioacuten de
coacutedigo mejorar su legibilidad simplificarlo y hacerlo
maacutes flexible para facilitar los cambios Se mejora la
estructura interna del coacutedigo sin alterar su
comportamiento externo
Programacioacuten en parejas Toda la produccioacuten del
coacutedigo debe realizarse con trabajo en parejas de
programadores Para tener ventajas como menor tasa de
errores mejor disentildeo etc
Propiedad colectiva del coacutedigo Cualquier programador
puede cambiar cualquier parte del coacutedigo en cualquier
instante
Integracioacuten continua Cada pieza del coacutedigo es
integrada en el sistema una vez que este listaasi el
sistema puede ser integrado y construido varias veces en
un mismo diacutea
40 horas por semana Se debe trabajar un maacuteximo de 40
horas por semana no se trabajan horas extras en dos
semanas seguidas Si esto ocurre estaacute existe un problema
porque el trabajo extra desmotiva al equipo
Cliente in-situ El cliente tiene que estar presente y
disponible todo el tiempo para el equipo este es uno de
los principales factores de eacutexito para el proyecto XP Y
asiacute guiar y disipar cualquier duda de los programadores
donde la comunicacioacuten es maacutes efectiva que la escrita
Estaacutendares de programacioacuten XP enfatiza que la
comunicacioacuten de los programadores es a traveacutes del
coacutedigo por lo que es importante que se sigan estaacutendares
de programacioacuten para mantener el coacutedigo legible
3 CONCLUCIONES
] INGENIERIacuteA DE SOFTWARE
9
INGENIERIacuteA DE SISTEMAS
Las metodologiacuteas aacutegiles ofrecen una solucioacuten casi a
medida para una gran cantidad de proyectos
La metodologiacutea XP es una de las metodologiacuteas aacutegiles maacutes
extendidas y populares ademaacutes es considerada como una
metodologiacutea posmoderna cuyas grandes capacidades se
generan a traveacutes de procesos emergentes
4 REFERENCIAS
httpwwwmetodologiasSoftcomdesarrolloagil
httpwwwwikipediacommetodologiaXP
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
10
Desarrollo de Scrum
Sergio J Guzmaacuten L Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 Octubre Esq Belisario Salinas
La Paz - Bolivia
sjguzmanusfaedubo
Resumenmdash Scrum es una metodologiacutea aacutegil de desarrollo de
proyectos que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ldquocampos de scrumrdquo al
software
Palabras clave mdash scrum metodologiacutea patroacuten software
sprint rol
I Que es Scrum
Scrum es una metodologiacutea aacutegil de desarrollo de proyectos
que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ―campos de scrum al
software
Esta fue la primera definicioacuten de un patroacuten Scrum aplicado
al software disentildeada por Jeff Sutherland y Ken Schwaber y
presentada en Object-Oriented Programming Systems
Languages amp Applications OOPSLA en 1996
II iquestCoacutemo incorporarla
La competitividad del mercado de desarrollo de Software y
la necesidad de los clientes de reducir el tiempo de
mercado obligan a las organizaciones de desarrollo de
software a ser agresivas en sus calendarios de entrega Esto
ha hecho que hayan surgido metodologiacuteas para la gestioacuten y
desarrollo de software basadas en un proceso iterativo e
incremental Su estructura estaacute basada en corto tiempo los
cuales son iteraciones de 1 a 4 semanas Scrum se usa en
proyectos de entorno complejos donde se desea obtener
resultados raacutepidos y la productividad es lo maacutes importante
En los proyectos basados en Scrum se consideran tres
roles
Duentildeo del producto Es quien determina las propiedades de
los entregables
Maestro de Scrum Administra y facilita la ejecucioacuten del
proceso
Equipo de Trabajo Trabajan en conjunto para entregar
resultados en cada sprint
Fig 1 El flujo de Scrum
Como se puede observar en medio de los participantes del
proceso no quedan claras las responsabilidades del
arquitecto de software Sin embargo como comenta
Charlie Alfred ―la arquitectura es al aceite y el filtro que
lubrica adecuadamente a Scrum
Fig 2 El flujo de Scrum
] INGENIERIacuteA DE SOFTWARE
11
INGENIERIacuteA DE SISTEMAS
Si se compara el rol del arquitecto de edificaciones con el
del arquitecto de software se puede observar que ambos
modelan las construcciones a un alto nivel de abstraccioacuten
proveen posibles soluciones mejoran la comunicacioacuten con
los miembros del equipo de construccioacuten a traveacutes de
modelos visualizan las generalidades del problema
definen los roles y las interacciones entre los componentes
de construccioacuten entre otras tareas Al igual que es
imposible pensar que un rascacielos puede ser construido
sin una arquitectura soacutelida es imposible pensar que
productos de software empresariales puedan ser
implementados sin una arquitectura bien pensada
Seguacuten Bass Clements y Kasman ―La arquitectura de
software de un programa o sistema informaacutetico es la
estructura o estructuras del sistema que incluyen elementos
de software las propiedades externamente visibles de esos
elementos y las relaciones entre ellos Esta definicioacuten nos
lleva a concluir que la arquitectura de software garantiza el
buen desarrollo del software y a tener un sistema que
cumpla con los requerimientos funcionales y no
funcionales del cliente Ademaacutes la arquitectura es clave en
la reutilizacioacuten de artefactos de software en sistemas de
liacutenea de productos de software
Viendo la importancia de la arquitectura en el desarrollo
del software en eacuteste artiacuteculo se presenta una propuesta para
gestionar la arquitectura de Software en Scrum En el
primer capiacutetulo se trata el tema de la localizacioacuten de la
arquitectura de software en el ciclo de desarrollo de Scrum
en el segundo capiacutetulo se describen las tareas del arquitecto
de software en Scrum finalmente se presentan las
conclusiones y el trabajo futuro
III Arquitectura de Software en el ciclo de desarrollo de
Scrum
La idea fundamental de la presente propuesta es adicionar
un sprint inicial llamado ―Sprint 0Prime al inicio del ciclo de
desarrollo El objetivo principal del arquitecto en el Sprint
0 es analizar y disentildear la generalidad del sistema que
satisfaga los requisitos y sea entendible por los miembros
del equipo desde sus diferentes puntos de vista durante el
desarrollo Un punto clave es reutilizar artefactos de
software creados a partir de la arquitectura para ser maacutes
aacutegiles en el desarrollo de productos especiacuteficos
El Sprint 0 comprende tres fases que fueron tomadas del
ciclo de vida de entregas evolutivas En el Sprint 0 se
construye la arquitectura de forma iterativa mediante un
anaacutelisis preliminar de los conductores arquitectoacutenicos
(requisitos funcionales de calidad y del negocio) y de un
estudio de factibilidad del proyecto No se necesita tener
todos los requisitos claros para comenzar la fase de disentildeo
arquitectoacutenico
Para determinar los conductores arquitectoacutenicos se debe
identificar los objetivos del negocio de maacutes alta prioridad
que son pocos Estos objetivos del negocio se convierten en
los escenarios de calidad o casos de uso De esta lista se
deben escoger los que tendraacuten un mayor impacto sobre la
arquitectura El disentildeo arquitectoacutenico puede comenzar una
vez que se encuentran definidos los conductores
arquitectoacutenicos El proceso de anaacutelisis de requisitos seraacute
entonces influenciado por las preguntas generadas durante
el disentildeo arquitectoacutenico
El resultado del Srpint 0 es un documento inicial que
explica la arquitectura El documento puede basarse en los
pasos definidos por el meacutetodo ADD (Attrbute Driver
Design) Este meacutetodo ha sido probado exitosamente en
proyectos anteriores Con ADD se puede definir una
arquitectura de software mediante un proceso de
descomposicioacuten basado en los atributos de calidad de
Software
El documento inicial de la arquitectura se debe avaluar con
el fin de saber si la arquitectura cumple con los requisitos
de calidad Para realizar esta evaluacioacuten se propone el
meacutetodo ATAM (Architecture Tradeoff Analysis Method)
El ATAM revela cuaacuten bien una arquitectura satisface los
objetivos particulares de calidad y provee una
aproximacioacuten de coacutemo los objetivos de calidad interactuacutean
Si la evaluacioacuten de la arquitectura se encuentra que se
deben realizar cambios a la misma entonces eacutesta se debe
refinar hasta llegar a tener como resultado del Sprint 0 el
documento puacuteblico de la arquitectura junto con el sistema
esqueleto Finalmente la arquitectura creada en el Sprint 0
beneficiaraacute el desarrollo en los siguientes sprints
IV Rol del arquitecto de Software en Scrum
El rol y actividades del arquitecto de software cambian de
enfoque dependiendo de si se estaacute en el Sprint 0 o en
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
12
sprints subsecuentes
Fig 3 La Comunicacioacuten
Sprint 0 En sistemas complejos una persona difiacutecilmente
puede cubrir con amplitud teacutecnica las decisiones
arquitectoacutenicas y dar credibilidad a la arquitectura de
software Esto quiere decir que la participacioacuten del equipo
es de vital importancia para la creacioacuten y el mantenimiento
de la arquitectura Un equipo de arquitectos de software
que se aiacutesle del equipo de Scrum puede producir una
arquitectura que corra el riesgo de ser rechazada Es por
esto que recomendamos que el arquitecto o los arquitectos
se software sean miembros del equipo de Scrum Una de
las actividades que se debe realizar en equipo es la
evaluacioacuten de la arquitectura Especiacuteficamente en el
meacutetodo ATAM se requiere la participacioacuten mutua de tres
equipos que trabajan en conjunto con los arquitectos de
software el de evaluacioacuten el de tomadores de decisiones
del proyecto y el de los involucrados en la arquitectura
Sprints subsecuentes El arquitecto de software asegura que
el equipo de Scrum entienda el enfoque y los retos
arquitectoacutenicos maacutes importantes en casa sprint Los
equipos de Scrum realizan construcciones cortas guiados
por las estrategias de la arquitectura A continuacioacuten se
nombran algunas de las responsabilidades del arquitecto de
software desde el Sprint 1 en adelante
El duentildeo del producto y el maestro del Scrum trabajan con
el arquitecto para priorizar los requisitos a implementar en
cada iteracioacuten
El arquitecto comunica las decisiones y facilita las
conversaciones arquitectoacutenicas de distintos puntos de vista
en cada sprint
El arquitecto asegura que haya conformidad entre las
entregas en cada sprint y la arquitectura
El arquitecto responde preguntas y da orientacioacuten
arquitectoacutenica cuando sea necesario
Junto con el maestro de Scrum coordina a los miembros
del equipo para adaptarse a la arquitectura previa
El arquitecto junto con el duentildeo del producto y los
miembros del equipo preparan el Product Backlog
V Conclusioacuten
En el presente artiacuteculo ofrecimos una propuesta para incluir
la arquitectura de software en Scrum En el Sprint 0 se
realizan las actividades concernientes al anaacutelisis y disentildeo
de la arquitectura de software y el sistema esqueleto En
los siguientes sprints el arquitecto de software se asegura
de que la implementacioacuten cumpla con la arquitectura
REFERENCIAS
[3] httpwwwsafecreativeorgwork
[4] Hirotaka Takeuchi es decano de la Graduate School of International
Corporate Strategy en la Universidad Hitotsubashi en Tokio y fue profesor visitante en la Escuela de Negocios Harvard entre 1989 y 1990
[5] Ikujiro NonakaNo soy un guruacute porque me falta carisma
] INGENIERIacuteA DE SOFTWARE
13
INGENIERIacuteA DE SISTEMAS
El futuro de la ingenieriacutea de software Luis E Aguirre
Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 de Octubre esq Belisario Salinas
La Paz - Bolivia leaguirreusfaedubo
Resumen El disentildeo de programas a partir de informacioacuten binaria
significoacute un paso sustantivo para la industria desarrolladora de
software Desde ese hallazgo ocurrido en la deacutecada de los
cincuenta hasta hoy el crecimiento de metodologiacuteas para su
desarrollo ha subido notablemente en complejidad Sin embargo
los ciacuterculos viciosos que acusa hoy la confeccioacuten de programas
informaacuteticos impiden conceptualizar el objeto a un nivel
superior de abstraccioacuten tal y como lo exige el avance tecnoloacutegico
y los procesos de negocios
Palabras clave mdash futuro software ingenieriacutea programador y
desarrollo
I Introduccioacuten
La calidad de los sistemas informaacuteticos satisfaccioacuten de sus
usuarios y clientes son temas ampliamente conocidos
recurrentes y de constante preocupacioacuten por parte de los
practicantes de la Ingenieriacutea de software
Esta joven y dinaacutemica ingenieriacutea siempre estaacute en busca de
mejoras en el desarrollo de sistemas aumento de
productividad del ingeniero de software mayor control del
proceso de desarrollo establecimiento de nuevos meacutetodos de
desarrollo
Fig 1 Primeros programas computacionales en formato de tarjeta perforada
Estos elementos combinados y aplicados de buena forma
logran un buen proceso de desarrollo y en definitiva un buen
producto
Identificar los pasos que ha recorrido esta ingenieriacutea analizar
su contexto actual y finalmente proyectar hacia doacutende se
dirige es el pilar de este artiacuteculo
II iquestSe aplica actualmente la ingenieriacutea del software
La investigacioacuten y el desarrollo de teacutecnicas y meacuteto
dos de ingenieriacutea del software son constantes y suelen suponer
interesantes avances en la resolucioacuten de problemas de
desarrollo de software Sin embargo es habitual que en la
praacutectica diaria profesional no se incluya praacutecticamente
ninguna de las recomendaciones maacutes elementales de la
ingenieriacutea del software En efecto es habitual que el
desarrollo de software se parezca maacutes al descontrol del cuento
de laquosi los programadores fueran albantildeilesraquo ([Novatica
1996]) que a una idiacutelica y bien organizada factoriacutea de
software (concepto de gran vigencia a finales de los ochenta
[Nunamaker et al 1988])
De hecho las evaluaciones de los procesos productivos de
software realizadas a raiacutez de los modelo de procesos de
software (por ejemplo con CMM [Paulk et al 1993])
confirman que el desarrollo de software suele estar
baacutesicamente en estado caoacutetico
Y no soacutelo en como uno podriacutea pensar pequentildeas
organizaciones de un paiacutes mediterraacuteneo como el nuestro sino
en tambieacuten en las empresas adjudicatarias de interesantes
contratos de defensa de paiacuteses laquoavanzadosraquo como EEUU o
Japoacuten Si bien estos modelos de evaluacioacuten auacuten acumulan
distintas acusaciones de rigidez o falta de contraste empiacuterico
los resultados obtenidos en sus evaluaciones resultan
consistentes con la sensacioacuten de constante laquoapagafuegosraquo que
suelen sufrir los profesionales del software Tambieacuten suelen
revelar la praacutectica despreocupacioacuten de los responsables de las
organizaciones de software por la mejora de la calidad de sus
procesos de trabajo o de sus productos bien sea por contar con
una situacioacuten interna de empresa poco propicia porque el
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
14
ambiente del mercado no fomenta la preocupacioacuten por estos
temas o bien por su poco intereacutes real en la buacutesqueda de la
calidad
III La actualidad
La gran mayoriacutea de los sistemas de software creados hoy en
diacutea son los llamados sistemas corporativos es decir son
orientados a formar una parte importante de los negocios de
las grandes empresas
Continuando en nuestro contexto se identifica un nuevo
enfoque del problema de desarrollo el apoyo en la
sincronizacioacuten de los procesos de negocio estructuras
complejas de informacioacuten manejada por el negocio todo esto
entrelazado por restricciones dadas por las reglas del negocio
La tecnologiacutea actual por otro lado ha alejado maacutes todaviacutea los
ingenieros de las maacutequinas sistemas operativos incluso de
las tareas de programacioacuten
El enfoque de la mayoriacutea de los equipos de desarrollo e
ingenieros participes en proyectos sigue siendo con un bajo
nivel de abstraccioacuten cerca de la codificacioacuten Se tiende a
pensar en la base de datos a utilizar establecer la navegacioacuten
de las paacuteginas programar los protocolos de comunicacioacuten etc
Esto lleva a utilizar las tareas de programacioacuten y de pruebas
para validar el entendimiento y cumplimiento de la
funcionalidad de los sistemas
Lo anteriormente expuesto muestra un problema
metodoloacutegico consecuencia de un desfase entre el enfoque
teoacuterico oacuteptimo (anaacutelisis de negocio) y el enfoque praacutectico real
(programacioacuten y pruebas) en los proyectos de hoy En otras
palabras la metodologiacutea actualmente usada estaacute atrasada con
respecto al avance tecnoloacutegico
Desarrollando maacutes esta idea se identifican algunos
problemas concretos de las metodologiacuteas
Ellas no obligan a sus ejecutores a respetar todas las
normas y los procedimientos establecidos especialmente
en las etapas tempranas del proyecto Es muy faacutecil y
tentador ―saltar una o maacutes de estas etapas uno o maacutes
documentos o modelos pasando directamente a
implementacioacuten produccioacuten y posterior correccioacuten de los
sistemas desarrollados
Control de calidad del producto final La codificacioacuten y
complejidad del programa es demasiada para ser revisada
y verificada fehacientemente Por otro lado los coacutedigos
fuentes y los ejecutables actualmente son los uacutenicos
entregables eficientemente verificables
Estos dos problemas al parecer forman una situacioacuten
contradictoria la metodologiacutea tradicional no permite validar
eficientemente la calidad de los sistemas antes de llegar al
coacutedigo fuente y por otro lado tampoco permite llegar
eficientemente a coacutedigos fuentes de calidad
IV Futuro
La salida de este ―ciacuterculo vicioso que se propone es
bastante natural analizar la situacioacuten actual de la ingenieriacutea
de software en la luz de sus tendencias histoacutericas
La primera de ellas relacionada con los problemas que
resuelven los sistemas obviamente presente y muy utilizada
en nuestra realidad los sistemas de hoy no soacutelo resuelven los
problemas del mundo real sino que estaacuten fuertemente influen-
ciando el desarrollo del mundo real
Fig2 Modela
El enfoque de los ingenieros desde hace unos antildeos no se ha
movido significativamente por el camino del aumento de
abstraccioacuten establecido histoacutericamente Se han hecho ciertos
avances en temas puntuales (como arquitecturas de
componentes patrones de disentildeo nuevos lenguajes de
programacioacuten etc) pero conceptualmente
metodoloacutegicamente la tarea de programacioacuten sigue siendo
ejecutada de la misma forma escribiendo coacutedigos fuentes en
forma de los programas textuales
Eacuteste es justamente el ―atraso metodoloacutegico que se
mencionoacute Para disminuir la brecha entre las tendencias
histoacutericas es necesario ajustar la metodologiacutea en teacuterminos de
aumentar la abstraccioacuten del enfoque de los ingenieros de
software y acercarlo a la abstraccioacuten del problema
El aumento de la abstraccioacuten del proceso de desarrollo del
software hace pensar que la proacutexima generacioacuten de meacutetodos
de desarrollo se perfila en un conceptualmente nuevo con-
] INGENIERIacuteA DE SOFTWARE
15
INGENIERIacuteA DE SISTEMAS
junto de herramientas que permitan aumentar en un mayor
grado al actual la abstraccioacuten escondiendo los detalles de maacutes
bajo nivel
Fig3 Probable modelo a futuro
Las nuevas herramientas permitiraacuten ―programar en nivel
de anaacutelisis generando coacutedigos en un lenguaje de
programacioacuten tradicional de forma automaacutetica tal como hoy
los compiladores generan el lenguaje maacutequina a partir del
coacutedigo fuente Nuevos ―lenguajes de programacioacuten
naturalmente seriacutean visuales y se pareceriacutean a las
especificaciones de software en uno de los lenguajes de
modelamiento por ejemplo UML
V Conclusioacuten
Es muy probable que estemos proacuteximos a ver un nuevo
paso evolutivo en la ingenieriacutea de software Tan grande como
el invento de lenguajes de alto nivel o anaacutelisis y disentildeo
orientado a objetos Una nueva generacioacuten que absorberaacute a la
actual automatizando la mayoriacutea de las buenas praacutecticas
usadas actualmente
Una pregunta natural es si una maacutequina puede llegar a
generar programas tan buenos como los hechos por un pro-
gramador experto En vez de ―romper la cabeza con esta
pregunta ahora quizaacutes seriacutea suficiente recordarse otra vez de
la historia Los primeros compiladores de ninguna generacioacuten
alcanzaban de inmediato lo deseable y oacuteptimo Sin embargo
con el paso del tiempo apoyados en la experiencia de los
ingenieros y en el avance tecnoloacutegico se mejoraban hasta el
nivel de superar significativamente las generaciones
anteriores
Es poco factible que hoy en diacutea alguien cuestione la calidad
de los compiladores de por ejemplo Java y la calidad del
coacutedigo de maacutequina generado por ellos
VI Referencias [6] Website [Online]
httpwwwenterpriseanalystnetdownloadmda_informaticap
df
[7] httpwwwslidesharenetamrrochafuturo-del-software-impacto-en-las-organizaciones-y-en-los-profesionales
[8] httpwwwdcubaareventseci2008conferenciasIngSoftHexacta
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
9
INGENIERIacuteA DE SISTEMAS
Las metodologiacuteas aacutegiles ofrecen una solucioacuten casi a
medida para una gran cantidad de proyectos
La metodologiacutea XP es una de las metodologiacuteas aacutegiles maacutes
extendidas y populares ademaacutes es considerada como una
metodologiacutea posmoderna cuyas grandes capacidades se
generan a traveacutes de procesos emergentes
4 REFERENCIAS
httpwwwmetodologiasSoftcomdesarrolloagil
httpwwwwikipediacommetodologiaXP
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
10
Desarrollo de Scrum
Sergio J Guzmaacuten L Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 Octubre Esq Belisario Salinas
La Paz - Bolivia
sjguzmanusfaedubo
Resumenmdash Scrum es una metodologiacutea aacutegil de desarrollo de
proyectos que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ldquocampos de scrumrdquo al
software
Palabras clave mdash scrum metodologiacutea patroacuten software
sprint rol
I Que es Scrum
Scrum es una metodologiacutea aacutegil de desarrollo de proyectos
que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ―campos de scrum al
software
Esta fue la primera definicioacuten de un patroacuten Scrum aplicado
al software disentildeada por Jeff Sutherland y Ken Schwaber y
presentada en Object-Oriented Programming Systems
Languages amp Applications OOPSLA en 1996
II iquestCoacutemo incorporarla
La competitividad del mercado de desarrollo de Software y
la necesidad de los clientes de reducir el tiempo de
mercado obligan a las organizaciones de desarrollo de
software a ser agresivas en sus calendarios de entrega Esto
ha hecho que hayan surgido metodologiacuteas para la gestioacuten y
desarrollo de software basadas en un proceso iterativo e
incremental Su estructura estaacute basada en corto tiempo los
cuales son iteraciones de 1 a 4 semanas Scrum se usa en
proyectos de entorno complejos donde se desea obtener
resultados raacutepidos y la productividad es lo maacutes importante
En los proyectos basados en Scrum se consideran tres
roles
Duentildeo del producto Es quien determina las propiedades de
los entregables
Maestro de Scrum Administra y facilita la ejecucioacuten del
proceso
Equipo de Trabajo Trabajan en conjunto para entregar
resultados en cada sprint
Fig 1 El flujo de Scrum
Como se puede observar en medio de los participantes del
proceso no quedan claras las responsabilidades del
arquitecto de software Sin embargo como comenta
Charlie Alfred ―la arquitectura es al aceite y el filtro que
lubrica adecuadamente a Scrum
Fig 2 El flujo de Scrum
] INGENIERIacuteA DE SOFTWARE
11
INGENIERIacuteA DE SISTEMAS
Si se compara el rol del arquitecto de edificaciones con el
del arquitecto de software se puede observar que ambos
modelan las construcciones a un alto nivel de abstraccioacuten
proveen posibles soluciones mejoran la comunicacioacuten con
los miembros del equipo de construccioacuten a traveacutes de
modelos visualizan las generalidades del problema
definen los roles y las interacciones entre los componentes
de construccioacuten entre otras tareas Al igual que es
imposible pensar que un rascacielos puede ser construido
sin una arquitectura soacutelida es imposible pensar que
productos de software empresariales puedan ser
implementados sin una arquitectura bien pensada
Seguacuten Bass Clements y Kasman ―La arquitectura de
software de un programa o sistema informaacutetico es la
estructura o estructuras del sistema que incluyen elementos
de software las propiedades externamente visibles de esos
elementos y las relaciones entre ellos Esta definicioacuten nos
lleva a concluir que la arquitectura de software garantiza el
buen desarrollo del software y a tener un sistema que
cumpla con los requerimientos funcionales y no
funcionales del cliente Ademaacutes la arquitectura es clave en
la reutilizacioacuten de artefactos de software en sistemas de
liacutenea de productos de software
Viendo la importancia de la arquitectura en el desarrollo
del software en eacuteste artiacuteculo se presenta una propuesta para
gestionar la arquitectura de Software en Scrum En el
primer capiacutetulo se trata el tema de la localizacioacuten de la
arquitectura de software en el ciclo de desarrollo de Scrum
en el segundo capiacutetulo se describen las tareas del arquitecto
de software en Scrum finalmente se presentan las
conclusiones y el trabajo futuro
III Arquitectura de Software en el ciclo de desarrollo de
Scrum
La idea fundamental de la presente propuesta es adicionar
un sprint inicial llamado ―Sprint 0Prime al inicio del ciclo de
desarrollo El objetivo principal del arquitecto en el Sprint
0 es analizar y disentildear la generalidad del sistema que
satisfaga los requisitos y sea entendible por los miembros
del equipo desde sus diferentes puntos de vista durante el
desarrollo Un punto clave es reutilizar artefactos de
software creados a partir de la arquitectura para ser maacutes
aacutegiles en el desarrollo de productos especiacuteficos
El Sprint 0 comprende tres fases que fueron tomadas del
ciclo de vida de entregas evolutivas En el Sprint 0 se
construye la arquitectura de forma iterativa mediante un
anaacutelisis preliminar de los conductores arquitectoacutenicos
(requisitos funcionales de calidad y del negocio) y de un
estudio de factibilidad del proyecto No se necesita tener
todos los requisitos claros para comenzar la fase de disentildeo
arquitectoacutenico
Para determinar los conductores arquitectoacutenicos se debe
identificar los objetivos del negocio de maacutes alta prioridad
que son pocos Estos objetivos del negocio se convierten en
los escenarios de calidad o casos de uso De esta lista se
deben escoger los que tendraacuten un mayor impacto sobre la
arquitectura El disentildeo arquitectoacutenico puede comenzar una
vez que se encuentran definidos los conductores
arquitectoacutenicos El proceso de anaacutelisis de requisitos seraacute
entonces influenciado por las preguntas generadas durante
el disentildeo arquitectoacutenico
El resultado del Srpint 0 es un documento inicial que
explica la arquitectura El documento puede basarse en los
pasos definidos por el meacutetodo ADD (Attrbute Driver
Design) Este meacutetodo ha sido probado exitosamente en
proyectos anteriores Con ADD se puede definir una
arquitectura de software mediante un proceso de
descomposicioacuten basado en los atributos de calidad de
Software
El documento inicial de la arquitectura se debe avaluar con
el fin de saber si la arquitectura cumple con los requisitos
de calidad Para realizar esta evaluacioacuten se propone el
meacutetodo ATAM (Architecture Tradeoff Analysis Method)
El ATAM revela cuaacuten bien una arquitectura satisface los
objetivos particulares de calidad y provee una
aproximacioacuten de coacutemo los objetivos de calidad interactuacutean
Si la evaluacioacuten de la arquitectura se encuentra que se
deben realizar cambios a la misma entonces eacutesta se debe
refinar hasta llegar a tener como resultado del Sprint 0 el
documento puacuteblico de la arquitectura junto con el sistema
esqueleto Finalmente la arquitectura creada en el Sprint 0
beneficiaraacute el desarrollo en los siguientes sprints
IV Rol del arquitecto de Software en Scrum
El rol y actividades del arquitecto de software cambian de
enfoque dependiendo de si se estaacute en el Sprint 0 o en
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
12
sprints subsecuentes
Fig 3 La Comunicacioacuten
Sprint 0 En sistemas complejos una persona difiacutecilmente
puede cubrir con amplitud teacutecnica las decisiones
arquitectoacutenicas y dar credibilidad a la arquitectura de
software Esto quiere decir que la participacioacuten del equipo
es de vital importancia para la creacioacuten y el mantenimiento
de la arquitectura Un equipo de arquitectos de software
que se aiacutesle del equipo de Scrum puede producir una
arquitectura que corra el riesgo de ser rechazada Es por
esto que recomendamos que el arquitecto o los arquitectos
se software sean miembros del equipo de Scrum Una de
las actividades que se debe realizar en equipo es la
evaluacioacuten de la arquitectura Especiacuteficamente en el
meacutetodo ATAM se requiere la participacioacuten mutua de tres
equipos que trabajan en conjunto con los arquitectos de
software el de evaluacioacuten el de tomadores de decisiones
del proyecto y el de los involucrados en la arquitectura
Sprints subsecuentes El arquitecto de software asegura que
el equipo de Scrum entienda el enfoque y los retos
arquitectoacutenicos maacutes importantes en casa sprint Los
equipos de Scrum realizan construcciones cortas guiados
por las estrategias de la arquitectura A continuacioacuten se
nombran algunas de las responsabilidades del arquitecto de
software desde el Sprint 1 en adelante
El duentildeo del producto y el maestro del Scrum trabajan con
el arquitecto para priorizar los requisitos a implementar en
cada iteracioacuten
El arquitecto comunica las decisiones y facilita las
conversaciones arquitectoacutenicas de distintos puntos de vista
en cada sprint
El arquitecto asegura que haya conformidad entre las
entregas en cada sprint y la arquitectura
El arquitecto responde preguntas y da orientacioacuten
arquitectoacutenica cuando sea necesario
Junto con el maestro de Scrum coordina a los miembros
del equipo para adaptarse a la arquitectura previa
El arquitecto junto con el duentildeo del producto y los
miembros del equipo preparan el Product Backlog
V Conclusioacuten
En el presente artiacuteculo ofrecimos una propuesta para incluir
la arquitectura de software en Scrum En el Sprint 0 se
realizan las actividades concernientes al anaacutelisis y disentildeo
de la arquitectura de software y el sistema esqueleto En
los siguientes sprints el arquitecto de software se asegura
de que la implementacioacuten cumpla con la arquitectura
REFERENCIAS
[3] httpwwwsafecreativeorgwork
[4] Hirotaka Takeuchi es decano de la Graduate School of International
Corporate Strategy en la Universidad Hitotsubashi en Tokio y fue profesor visitante en la Escuela de Negocios Harvard entre 1989 y 1990
[5] Ikujiro NonakaNo soy un guruacute porque me falta carisma
] INGENIERIacuteA DE SOFTWARE
13
INGENIERIacuteA DE SISTEMAS
El futuro de la ingenieriacutea de software Luis E Aguirre
Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 de Octubre esq Belisario Salinas
La Paz - Bolivia leaguirreusfaedubo
Resumen El disentildeo de programas a partir de informacioacuten binaria
significoacute un paso sustantivo para la industria desarrolladora de
software Desde ese hallazgo ocurrido en la deacutecada de los
cincuenta hasta hoy el crecimiento de metodologiacuteas para su
desarrollo ha subido notablemente en complejidad Sin embargo
los ciacuterculos viciosos que acusa hoy la confeccioacuten de programas
informaacuteticos impiden conceptualizar el objeto a un nivel
superior de abstraccioacuten tal y como lo exige el avance tecnoloacutegico
y los procesos de negocios
Palabras clave mdash futuro software ingenieriacutea programador y
desarrollo
I Introduccioacuten
La calidad de los sistemas informaacuteticos satisfaccioacuten de sus
usuarios y clientes son temas ampliamente conocidos
recurrentes y de constante preocupacioacuten por parte de los
practicantes de la Ingenieriacutea de software
Esta joven y dinaacutemica ingenieriacutea siempre estaacute en busca de
mejoras en el desarrollo de sistemas aumento de
productividad del ingeniero de software mayor control del
proceso de desarrollo establecimiento de nuevos meacutetodos de
desarrollo
Fig 1 Primeros programas computacionales en formato de tarjeta perforada
Estos elementos combinados y aplicados de buena forma
logran un buen proceso de desarrollo y en definitiva un buen
producto
Identificar los pasos que ha recorrido esta ingenieriacutea analizar
su contexto actual y finalmente proyectar hacia doacutende se
dirige es el pilar de este artiacuteculo
II iquestSe aplica actualmente la ingenieriacutea del software
La investigacioacuten y el desarrollo de teacutecnicas y meacuteto
dos de ingenieriacutea del software son constantes y suelen suponer
interesantes avances en la resolucioacuten de problemas de
desarrollo de software Sin embargo es habitual que en la
praacutectica diaria profesional no se incluya praacutecticamente
ninguna de las recomendaciones maacutes elementales de la
ingenieriacutea del software En efecto es habitual que el
desarrollo de software se parezca maacutes al descontrol del cuento
de laquosi los programadores fueran albantildeilesraquo ([Novatica
1996]) que a una idiacutelica y bien organizada factoriacutea de
software (concepto de gran vigencia a finales de los ochenta
[Nunamaker et al 1988])
De hecho las evaluaciones de los procesos productivos de
software realizadas a raiacutez de los modelo de procesos de
software (por ejemplo con CMM [Paulk et al 1993])
confirman que el desarrollo de software suele estar
baacutesicamente en estado caoacutetico
Y no soacutelo en como uno podriacutea pensar pequentildeas
organizaciones de un paiacutes mediterraacuteneo como el nuestro sino
en tambieacuten en las empresas adjudicatarias de interesantes
contratos de defensa de paiacuteses laquoavanzadosraquo como EEUU o
Japoacuten Si bien estos modelos de evaluacioacuten auacuten acumulan
distintas acusaciones de rigidez o falta de contraste empiacuterico
los resultados obtenidos en sus evaluaciones resultan
consistentes con la sensacioacuten de constante laquoapagafuegosraquo que
suelen sufrir los profesionales del software Tambieacuten suelen
revelar la praacutectica despreocupacioacuten de los responsables de las
organizaciones de software por la mejora de la calidad de sus
procesos de trabajo o de sus productos bien sea por contar con
una situacioacuten interna de empresa poco propicia porque el
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
14
ambiente del mercado no fomenta la preocupacioacuten por estos
temas o bien por su poco intereacutes real en la buacutesqueda de la
calidad
III La actualidad
La gran mayoriacutea de los sistemas de software creados hoy en
diacutea son los llamados sistemas corporativos es decir son
orientados a formar una parte importante de los negocios de
las grandes empresas
Continuando en nuestro contexto se identifica un nuevo
enfoque del problema de desarrollo el apoyo en la
sincronizacioacuten de los procesos de negocio estructuras
complejas de informacioacuten manejada por el negocio todo esto
entrelazado por restricciones dadas por las reglas del negocio
La tecnologiacutea actual por otro lado ha alejado maacutes todaviacutea los
ingenieros de las maacutequinas sistemas operativos incluso de
las tareas de programacioacuten
El enfoque de la mayoriacutea de los equipos de desarrollo e
ingenieros participes en proyectos sigue siendo con un bajo
nivel de abstraccioacuten cerca de la codificacioacuten Se tiende a
pensar en la base de datos a utilizar establecer la navegacioacuten
de las paacuteginas programar los protocolos de comunicacioacuten etc
Esto lleva a utilizar las tareas de programacioacuten y de pruebas
para validar el entendimiento y cumplimiento de la
funcionalidad de los sistemas
Lo anteriormente expuesto muestra un problema
metodoloacutegico consecuencia de un desfase entre el enfoque
teoacuterico oacuteptimo (anaacutelisis de negocio) y el enfoque praacutectico real
(programacioacuten y pruebas) en los proyectos de hoy En otras
palabras la metodologiacutea actualmente usada estaacute atrasada con
respecto al avance tecnoloacutegico
Desarrollando maacutes esta idea se identifican algunos
problemas concretos de las metodologiacuteas
Ellas no obligan a sus ejecutores a respetar todas las
normas y los procedimientos establecidos especialmente
en las etapas tempranas del proyecto Es muy faacutecil y
tentador ―saltar una o maacutes de estas etapas uno o maacutes
documentos o modelos pasando directamente a
implementacioacuten produccioacuten y posterior correccioacuten de los
sistemas desarrollados
Control de calidad del producto final La codificacioacuten y
complejidad del programa es demasiada para ser revisada
y verificada fehacientemente Por otro lado los coacutedigos
fuentes y los ejecutables actualmente son los uacutenicos
entregables eficientemente verificables
Estos dos problemas al parecer forman una situacioacuten
contradictoria la metodologiacutea tradicional no permite validar
eficientemente la calidad de los sistemas antes de llegar al
coacutedigo fuente y por otro lado tampoco permite llegar
eficientemente a coacutedigos fuentes de calidad
IV Futuro
La salida de este ―ciacuterculo vicioso que se propone es
bastante natural analizar la situacioacuten actual de la ingenieriacutea
de software en la luz de sus tendencias histoacutericas
La primera de ellas relacionada con los problemas que
resuelven los sistemas obviamente presente y muy utilizada
en nuestra realidad los sistemas de hoy no soacutelo resuelven los
problemas del mundo real sino que estaacuten fuertemente influen-
ciando el desarrollo del mundo real
Fig2 Modela
El enfoque de los ingenieros desde hace unos antildeos no se ha
movido significativamente por el camino del aumento de
abstraccioacuten establecido histoacutericamente Se han hecho ciertos
avances en temas puntuales (como arquitecturas de
componentes patrones de disentildeo nuevos lenguajes de
programacioacuten etc) pero conceptualmente
metodoloacutegicamente la tarea de programacioacuten sigue siendo
ejecutada de la misma forma escribiendo coacutedigos fuentes en
forma de los programas textuales
Eacuteste es justamente el ―atraso metodoloacutegico que se
mencionoacute Para disminuir la brecha entre las tendencias
histoacutericas es necesario ajustar la metodologiacutea en teacuterminos de
aumentar la abstraccioacuten del enfoque de los ingenieros de
software y acercarlo a la abstraccioacuten del problema
El aumento de la abstraccioacuten del proceso de desarrollo del
software hace pensar que la proacutexima generacioacuten de meacutetodos
de desarrollo se perfila en un conceptualmente nuevo con-
] INGENIERIacuteA DE SOFTWARE
15
INGENIERIacuteA DE SISTEMAS
junto de herramientas que permitan aumentar en un mayor
grado al actual la abstraccioacuten escondiendo los detalles de maacutes
bajo nivel
Fig3 Probable modelo a futuro
Las nuevas herramientas permitiraacuten ―programar en nivel
de anaacutelisis generando coacutedigos en un lenguaje de
programacioacuten tradicional de forma automaacutetica tal como hoy
los compiladores generan el lenguaje maacutequina a partir del
coacutedigo fuente Nuevos ―lenguajes de programacioacuten
naturalmente seriacutean visuales y se pareceriacutean a las
especificaciones de software en uno de los lenguajes de
modelamiento por ejemplo UML
V Conclusioacuten
Es muy probable que estemos proacuteximos a ver un nuevo
paso evolutivo en la ingenieriacutea de software Tan grande como
el invento de lenguajes de alto nivel o anaacutelisis y disentildeo
orientado a objetos Una nueva generacioacuten que absorberaacute a la
actual automatizando la mayoriacutea de las buenas praacutecticas
usadas actualmente
Una pregunta natural es si una maacutequina puede llegar a
generar programas tan buenos como los hechos por un pro-
gramador experto En vez de ―romper la cabeza con esta
pregunta ahora quizaacutes seriacutea suficiente recordarse otra vez de
la historia Los primeros compiladores de ninguna generacioacuten
alcanzaban de inmediato lo deseable y oacuteptimo Sin embargo
con el paso del tiempo apoyados en la experiencia de los
ingenieros y en el avance tecnoloacutegico se mejoraban hasta el
nivel de superar significativamente las generaciones
anteriores
Es poco factible que hoy en diacutea alguien cuestione la calidad
de los compiladores de por ejemplo Java y la calidad del
coacutedigo de maacutequina generado por ellos
VI Referencias [6] Website [Online]
httpwwwenterpriseanalystnetdownloadmda_informaticap
df
[7] httpwwwslidesharenetamrrochafuturo-del-software-impacto-en-las-organizaciones-y-en-los-profesionales
[8] httpwwwdcubaareventseci2008conferenciasIngSoftHexacta
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
10
Desarrollo de Scrum
Sergio J Guzmaacuten L Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 Octubre Esq Belisario Salinas
La Paz - Bolivia
sjguzmanusfaedubo
Resumenmdash Scrum es una metodologiacutea aacutegil de desarrollo de
proyectos que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ldquocampos de scrumrdquo al
software
Palabras clave mdash scrum metodologiacutea patroacuten software
sprint rol
I Que es Scrum
Scrum es una metodologiacutea aacutegil de desarrollo de proyectos
que toma su nombre y principios de los estudios
realizados sobre nuevas praacutecticas de produccioacuten por
Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80
En 1996 se definioacute por primera vez un patroacuten para aplicar
esos principios de desarrollo en ―campos de scrum al
software
Esta fue la primera definicioacuten de un patroacuten Scrum aplicado
al software disentildeada por Jeff Sutherland y Ken Schwaber y
presentada en Object-Oriented Programming Systems
Languages amp Applications OOPSLA en 1996
II iquestCoacutemo incorporarla
La competitividad del mercado de desarrollo de Software y
la necesidad de los clientes de reducir el tiempo de
mercado obligan a las organizaciones de desarrollo de
software a ser agresivas en sus calendarios de entrega Esto
ha hecho que hayan surgido metodologiacuteas para la gestioacuten y
desarrollo de software basadas en un proceso iterativo e
incremental Su estructura estaacute basada en corto tiempo los
cuales son iteraciones de 1 a 4 semanas Scrum se usa en
proyectos de entorno complejos donde se desea obtener
resultados raacutepidos y la productividad es lo maacutes importante
En los proyectos basados en Scrum se consideran tres
roles
Duentildeo del producto Es quien determina las propiedades de
los entregables
Maestro de Scrum Administra y facilita la ejecucioacuten del
proceso
Equipo de Trabajo Trabajan en conjunto para entregar
resultados en cada sprint
Fig 1 El flujo de Scrum
Como se puede observar en medio de los participantes del
proceso no quedan claras las responsabilidades del
arquitecto de software Sin embargo como comenta
Charlie Alfred ―la arquitectura es al aceite y el filtro que
lubrica adecuadamente a Scrum
Fig 2 El flujo de Scrum
] INGENIERIacuteA DE SOFTWARE
11
INGENIERIacuteA DE SISTEMAS
Si se compara el rol del arquitecto de edificaciones con el
del arquitecto de software se puede observar que ambos
modelan las construcciones a un alto nivel de abstraccioacuten
proveen posibles soluciones mejoran la comunicacioacuten con
los miembros del equipo de construccioacuten a traveacutes de
modelos visualizan las generalidades del problema
definen los roles y las interacciones entre los componentes
de construccioacuten entre otras tareas Al igual que es
imposible pensar que un rascacielos puede ser construido
sin una arquitectura soacutelida es imposible pensar que
productos de software empresariales puedan ser
implementados sin una arquitectura bien pensada
Seguacuten Bass Clements y Kasman ―La arquitectura de
software de un programa o sistema informaacutetico es la
estructura o estructuras del sistema que incluyen elementos
de software las propiedades externamente visibles de esos
elementos y las relaciones entre ellos Esta definicioacuten nos
lleva a concluir que la arquitectura de software garantiza el
buen desarrollo del software y a tener un sistema que
cumpla con los requerimientos funcionales y no
funcionales del cliente Ademaacutes la arquitectura es clave en
la reutilizacioacuten de artefactos de software en sistemas de
liacutenea de productos de software
Viendo la importancia de la arquitectura en el desarrollo
del software en eacuteste artiacuteculo se presenta una propuesta para
gestionar la arquitectura de Software en Scrum En el
primer capiacutetulo se trata el tema de la localizacioacuten de la
arquitectura de software en el ciclo de desarrollo de Scrum
en el segundo capiacutetulo se describen las tareas del arquitecto
de software en Scrum finalmente se presentan las
conclusiones y el trabajo futuro
III Arquitectura de Software en el ciclo de desarrollo de
Scrum
La idea fundamental de la presente propuesta es adicionar
un sprint inicial llamado ―Sprint 0Prime al inicio del ciclo de
desarrollo El objetivo principal del arquitecto en el Sprint
0 es analizar y disentildear la generalidad del sistema que
satisfaga los requisitos y sea entendible por los miembros
del equipo desde sus diferentes puntos de vista durante el
desarrollo Un punto clave es reutilizar artefactos de
software creados a partir de la arquitectura para ser maacutes
aacutegiles en el desarrollo de productos especiacuteficos
El Sprint 0 comprende tres fases que fueron tomadas del
ciclo de vida de entregas evolutivas En el Sprint 0 se
construye la arquitectura de forma iterativa mediante un
anaacutelisis preliminar de los conductores arquitectoacutenicos
(requisitos funcionales de calidad y del negocio) y de un
estudio de factibilidad del proyecto No se necesita tener
todos los requisitos claros para comenzar la fase de disentildeo
arquitectoacutenico
Para determinar los conductores arquitectoacutenicos se debe
identificar los objetivos del negocio de maacutes alta prioridad
que son pocos Estos objetivos del negocio se convierten en
los escenarios de calidad o casos de uso De esta lista se
deben escoger los que tendraacuten un mayor impacto sobre la
arquitectura El disentildeo arquitectoacutenico puede comenzar una
vez que se encuentran definidos los conductores
arquitectoacutenicos El proceso de anaacutelisis de requisitos seraacute
entonces influenciado por las preguntas generadas durante
el disentildeo arquitectoacutenico
El resultado del Srpint 0 es un documento inicial que
explica la arquitectura El documento puede basarse en los
pasos definidos por el meacutetodo ADD (Attrbute Driver
Design) Este meacutetodo ha sido probado exitosamente en
proyectos anteriores Con ADD se puede definir una
arquitectura de software mediante un proceso de
descomposicioacuten basado en los atributos de calidad de
Software
El documento inicial de la arquitectura se debe avaluar con
el fin de saber si la arquitectura cumple con los requisitos
de calidad Para realizar esta evaluacioacuten se propone el
meacutetodo ATAM (Architecture Tradeoff Analysis Method)
El ATAM revela cuaacuten bien una arquitectura satisface los
objetivos particulares de calidad y provee una
aproximacioacuten de coacutemo los objetivos de calidad interactuacutean
Si la evaluacioacuten de la arquitectura se encuentra que se
deben realizar cambios a la misma entonces eacutesta se debe
refinar hasta llegar a tener como resultado del Sprint 0 el
documento puacuteblico de la arquitectura junto con el sistema
esqueleto Finalmente la arquitectura creada en el Sprint 0
beneficiaraacute el desarrollo en los siguientes sprints
IV Rol del arquitecto de Software en Scrum
El rol y actividades del arquitecto de software cambian de
enfoque dependiendo de si se estaacute en el Sprint 0 o en
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
12
sprints subsecuentes
Fig 3 La Comunicacioacuten
Sprint 0 En sistemas complejos una persona difiacutecilmente
puede cubrir con amplitud teacutecnica las decisiones
arquitectoacutenicas y dar credibilidad a la arquitectura de
software Esto quiere decir que la participacioacuten del equipo
es de vital importancia para la creacioacuten y el mantenimiento
de la arquitectura Un equipo de arquitectos de software
que se aiacutesle del equipo de Scrum puede producir una
arquitectura que corra el riesgo de ser rechazada Es por
esto que recomendamos que el arquitecto o los arquitectos
se software sean miembros del equipo de Scrum Una de
las actividades que se debe realizar en equipo es la
evaluacioacuten de la arquitectura Especiacuteficamente en el
meacutetodo ATAM se requiere la participacioacuten mutua de tres
equipos que trabajan en conjunto con los arquitectos de
software el de evaluacioacuten el de tomadores de decisiones
del proyecto y el de los involucrados en la arquitectura
Sprints subsecuentes El arquitecto de software asegura que
el equipo de Scrum entienda el enfoque y los retos
arquitectoacutenicos maacutes importantes en casa sprint Los
equipos de Scrum realizan construcciones cortas guiados
por las estrategias de la arquitectura A continuacioacuten se
nombran algunas de las responsabilidades del arquitecto de
software desde el Sprint 1 en adelante
El duentildeo del producto y el maestro del Scrum trabajan con
el arquitecto para priorizar los requisitos a implementar en
cada iteracioacuten
El arquitecto comunica las decisiones y facilita las
conversaciones arquitectoacutenicas de distintos puntos de vista
en cada sprint
El arquitecto asegura que haya conformidad entre las
entregas en cada sprint y la arquitectura
El arquitecto responde preguntas y da orientacioacuten
arquitectoacutenica cuando sea necesario
Junto con el maestro de Scrum coordina a los miembros
del equipo para adaptarse a la arquitectura previa
El arquitecto junto con el duentildeo del producto y los
miembros del equipo preparan el Product Backlog
V Conclusioacuten
En el presente artiacuteculo ofrecimos una propuesta para incluir
la arquitectura de software en Scrum En el Sprint 0 se
realizan las actividades concernientes al anaacutelisis y disentildeo
de la arquitectura de software y el sistema esqueleto En
los siguientes sprints el arquitecto de software se asegura
de que la implementacioacuten cumpla con la arquitectura
REFERENCIAS
[3] httpwwwsafecreativeorgwork
[4] Hirotaka Takeuchi es decano de la Graduate School of International
Corporate Strategy en la Universidad Hitotsubashi en Tokio y fue profesor visitante en la Escuela de Negocios Harvard entre 1989 y 1990
[5] Ikujiro NonakaNo soy un guruacute porque me falta carisma
] INGENIERIacuteA DE SOFTWARE
13
INGENIERIacuteA DE SISTEMAS
El futuro de la ingenieriacutea de software Luis E Aguirre
Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 de Octubre esq Belisario Salinas
La Paz - Bolivia leaguirreusfaedubo
Resumen El disentildeo de programas a partir de informacioacuten binaria
significoacute un paso sustantivo para la industria desarrolladora de
software Desde ese hallazgo ocurrido en la deacutecada de los
cincuenta hasta hoy el crecimiento de metodologiacuteas para su
desarrollo ha subido notablemente en complejidad Sin embargo
los ciacuterculos viciosos que acusa hoy la confeccioacuten de programas
informaacuteticos impiden conceptualizar el objeto a un nivel
superior de abstraccioacuten tal y como lo exige el avance tecnoloacutegico
y los procesos de negocios
Palabras clave mdash futuro software ingenieriacutea programador y
desarrollo
I Introduccioacuten
La calidad de los sistemas informaacuteticos satisfaccioacuten de sus
usuarios y clientes son temas ampliamente conocidos
recurrentes y de constante preocupacioacuten por parte de los
practicantes de la Ingenieriacutea de software
Esta joven y dinaacutemica ingenieriacutea siempre estaacute en busca de
mejoras en el desarrollo de sistemas aumento de
productividad del ingeniero de software mayor control del
proceso de desarrollo establecimiento de nuevos meacutetodos de
desarrollo
Fig 1 Primeros programas computacionales en formato de tarjeta perforada
Estos elementos combinados y aplicados de buena forma
logran un buen proceso de desarrollo y en definitiva un buen
producto
Identificar los pasos que ha recorrido esta ingenieriacutea analizar
su contexto actual y finalmente proyectar hacia doacutende se
dirige es el pilar de este artiacuteculo
II iquestSe aplica actualmente la ingenieriacutea del software
La investigacioacuten y el desarrollo de teacutecnicas y meacuteto
dos de ingenieriacutea del software son constantes y suelen suponer
interesantes avances en la resolucioacuten de problemas de
desarrollo de software Sin embargo es habitual que en la
praacutectica diaria profesional no se incluya praacutecticamente
ninguna de las recomendaciones maacutes elementales de la
ingenieriacutea del software En efecto es habitual que el
desarrollo de software se parezca maacutes al descontrol del cuento
de laquosi los programadores fueran albantildeilesraquo ([Novatica
1996]) que a una idiacutelica y bien organizada factoriacutea de
software (concepto de gran vigencia a finales de los ochenta
[Nunamaker et al 1988])
De hecho las evaluaciones de los procesos productivos de
software realizadas a raiacutez de los modelo de procesos de
software (por ejemplo con CMM [Paulk et al 1993])
confirman que el desarrollo de software suele estar
baacutesicamente en estado caoacutetico
Y no soacutelo en como uno podriacutea pensar pequentildeas
organizaciones de un paiacutes mediterraacuteneo como el nuestro sino
en tambieacuten en las empresas adjudicatarias de interesantes
contratos de defensa de paiacuteses laquoavanzadosraquo como EEUU o
Japoacuten Si bien estos modelos de evaluacioacuten auacuten acumulan
distintas acusaciones de rigidez o falta de contraste empiacuterico
los resultados obtenidos en sus evaluaciones resultan
consistentes con la sensacioacuten de constante laquoapagafuegosraquo que
suelen sufrir los profesionales del software Tambieacuten suelen
revelar la praacutectica despreocupacioacuten de los responsables de las
organizaciones de software por la mejora de la calidad de sus
procesos de trabajo o de sus productos bien sea por contar con
una situacioacuten interna de empresa poco propicia porque el
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
14
ambiente del mercado no fomenta la preocupacioacuten por estos
temas o bien por su poco intereacutes real en la buacutesqueda de la
calidad
III La actualidad
La gran mayoriacutea de los sistemas de software creados hoy en
diacutea son los llamados sistemas corporativos es decir son
orientados a formar una parte importante de los negocios de
las grandes empresas
Continuando en nuestro contexto se identifica un nuevo
enfoque del problema de desarrollo el apoyo en la
sincronizacioacuten de los procesos de negocio estructuras
complejas de informacioacuten manejada por el negocio todo esto
entrelazado por restricciones dadas por las reglas del negocio
La tecnologiacutea actual por otro lado ha alejado maacutes todaviacutea los
ingenieros de las maacutequinas sistemas operativos incluso de
las tareas de programacioacuten
El enfoque de la mayoriacutea de los equipos de desarrollo e
ingenieros participes en proyectos sigue siendo con un bajo
nivel de abstraccioacuten cerca de la codificacioacuten Se tiende a
pensar en la base de datos a utilizar establecer la navegacioacuten
de las paacuteginas programar los protocolos de comunicacioacuten etc
Esto lleva a utilizar las tareas de programacioacuten y de pruebas
para validar el entendimiento y cumplimiento de la
funcionalidad de los sistemas
Lo anteriormente expuesto muestra un problema
metodoloacutegico consecuencia de un desfase entre el enfoque
teoacuterico oacuteptimo (anaacutelisis de negocio) y el enfoque praacutectico real
(programacioacuten y pruebas) en los proyectos de hoy En otras
palabras la metodologiacutea actualmente usada estaacute atrasada con
respecto al avance tecnoloacutegico
Desarrollando maacutes esta idea se identifican algunos
problemas concretos de las metodologiacuteas
Ellas no obligan a sus ejecutores a respetar todas las
normas y los procedimientos establecidos especialmente
en las etapas tempranas del proyecto Es muy faacutecil y
tentador ―saltar una o maacutes de estas etapas uno o maacutes
documentos o modelos pasando directamente a
implementacioacuten produccioacuten y posterior correccioacuten de los
sistemas desarrollados
Control de calidad del producto final La codificacioacuten y
complejidad del programa es demasiada para ser revisada
y verificada fehacientemente Por otro lado los coacutedigos
fuentes y los ejecutables actualmente son los uacutenicos
entregables eficientemente verificables
Estos dos problemas al parecer forman una situacioacuten
contradictoria la metodologiacutea tradicional no permite validar
eficientemente la calidad de los sistemas antes de llegar al
coacutedigo fuente y por otro lado tampoco permite llegar
eficientemente a coacutedigos fuentes de calidad
IV Futuro
La salida de este ―ciacuterculo vicioso que se propone es
bastante natural analizar la situacioacuten actual de la ingenieriacutea
de software en la luz de sus tendencias histoacutericas
La primera de ellas relacionada con los problemas que
resuelven los sistemas obviamente presente y muy utilizada
en nuestra realidad los sistemas de hoy no soacutelo resuelven los
problemas del mundo real sino que estaacuten fuertemente influen-
ciando el desarrollo del mundo real
Fig2 Modela
El enfoque de los ingenieros desde hace unos antildeos no se ha
movido significativamente por el camino del aumento de
abstraccioacuten establecido histoacutericamente Se han hecho ciertos
avances en temas puntuales (como arquitecturas de
componentes patrones de disentildeo nuevos lenguajes de
programacioacuten etc) pero conceptualmente
metodoloacutegicamente la tarea de programacioacuten sigue siendo
ejecutada de la misma forma escribiendo coacutedigos fuentes en
forma de los programas textuales
Eacuteste es justamente el ―atraso metodoloacutegico que se
mencionoacute Para disminuir la brecha entre las tendencias
histoacutericas es necesario ajustar la metodologiacutea en teacuterminos de
aumentar la abstraccioacuten del enfoque de los ingenieros de
software y acercarlo a la abstraccioacuten del problema
El aumento de la abstraccioacuten del proceso de desarrollo del
software hace pensar que la proacutexima generacioacuten de meacutetodos
de desarrollo se perfila en un conceptualmente nuevo con-
] INGENIERIacuteA DE SOFTWARE
15
INGENIERIacuteA DE SISTEMAS
junto de herramientas que permitan aumentar en un mayor
grado al actual la abstraccioacuten escondiendo los detalles de maacutes
bajo nivel
Fig3 Probable modelo a futuro
Las nuevas herramientas permitiraacuten ―programar en nivel
de anaacutelisis generando coacutedigos en un lenguaje de
programacioacuten tradicional de forma automaacutetica tal como hoy
los compiladores generan el lenguaje maacutequina a partir del
coacutedigo fuente Nuevos ―lenguajes de programacioacuten
naturalmente seriacutean visuales y se pareceriacutean a las
especificaciones de software en uno de los lenguajes de
modelamiento por ejemplo UML
V Conclusioacuten
Es muy probable que estemos proacuteximos a ver un nuevo
paso evolutivo en la ingenieriacutea de software Tan grande como
el invento de lenguajes de alto nivel o anaacutelisis y disentildeo
orientado a objetos Una nueva generacioacuten que absorberaacute a la
actual automatizando la mayoriacutea de las buenas praacutecticas
usadas actualmente
Una pregunta natural es si una maacutequina puede llegar a
generar programas tan buenos como los hechos por un pro-
gramador experto En vez de ―romper la cabeza con esta
pregunta ahora quizaacutes seriacutea suficiente recordarse otra vez de
la historia Los primeros compiladores de ninguna generacioacuten
alcanzaban de inmediato lo deseable y oacuteptimo Sin embargo
con el paso del tiempo apoyados en la experiencia de los
ingenieros y en el avance tecnoloacutegico se mejoraban hasta el
nivel de superar significativamente las generaciones
anteriores
Es poco factible que hoy en diacutea alguien cuestione la calidad
de los compiladores de por ejemplo Java y la calidad del
coacutedigo de maacutequina generado por ellos
VI Referencias [6] Website [Online]
httpwwwenterpriseanalystnetdownloadmda_informaticap
df
[7] httpwwwslidesharenetamrrochafuturo-del-software-impacto-en-las-organizaciones-y-en-los-profesionales
[8] httpwwwdcubaareventseci2008conferenciasIngSoftHexacta
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
11
INGENIERIacuteA DE SISTEMAS
Si se compara el rol del arquitecto de edificaciones con el
del arquitecto de software se puede observar que ambos
modelan las construcciones a un alto nivel de abstraccioacuten
proveen posibles soluciones mejoran la comunicacioacuten con
los miembros del equipo de construccioacuten a traveacutes de
modelos visualizan las generalidades del problema
definen los roles y las interacciones entre los componentes
de construccioacuten entre otras tareas Al igual que es
imposible pensar que un rascacielos puede ser construido
sin una arquitectura soacutelida es imposible pensar que
productos de software empresariales puedan ser
implementados sin una arquitectura bien pensada
Seguacuten Bass Clements y Kasman ―La arquitectura de
software de un programa o sistema informaacutetico es la
estructura o estructuras del sistema que incluyen elementos
de software las propiedades externamente visibles de esos
elementos y las relaciones entre ellos Esta definicioacuten nos
lleva a concluir que la arquitectura de software garantiza el
buen desarrollo del software y a tener un sistema que
cumpla con los requerimientos funcionales y no
funcionales del cliente Ademaacutes la arquitectura es clave en
la reutilizacioacuten de artefactos de software en sistemas de
liacutenea de productos de software
Viendo la importancia de la arquitectura en el desarrollo
del software en eacuteste artiacuteculo se presenta una propuesta para
gestionar la arquitectura de Software en Scrum En el
primer capiacutetulo se trata el tema de la localizacioacuten de la
arquitectura de software en el ciclo de desarrollo de Scrum
en el segundo capiacutetulo se describen las tareas del arquitecto
de software en Scrum finalmente se presentan las
conclusiones y el trabajo futuro
III Arquitectura de Software en el ciclo de desarrollo de
Scrum
La idea fundamental de la presente propuesta es adicionar
un sprint inicial llamado ―Sprint 0Prime al inicio del ciclo de
desarrollo El objetivo principal del arquitecto en el Sprint
0 es analizar y disentildear la generalidad del sistema que
satisfaga los requisitos y sea entendible por los miembros
del equipo desde sus diferentes puntos de vista durante el
desarrollo Un punto clave es reutilizar artefactos de
software creados a partir de la arquitectura para ser maacutes
aacutegiles en el desarrollo de productos especiacuteficos
El Sprint 0 comprende tres fases que fueron tomadas del
ciclo de vida de entregas evolutivas En el Sprint 0 se
construye la arquitectura de forma iterativa mediante un
anaacutelisis preliminar de los conductores arquitectoacutenicos
(requisitos funcionales de calidad y del negocio) y de un
estudio de factibilidad del proyecto No se necesita tener
todos los requisitos claros para comenzar la fase de disentildeo
arquitectoacutenico
Para determinar los conductores arquitectoacutenicos se debe
identificar los objetivos del negocio de maacutes alta prioridad
que son pocos Estos objetivos del negocio se convierten en
los escenarios de calidad o casos de uso De esta lista se
deben escoger los que tendraacuten un mayor impacto sobre la
arquitectura El disentildeo arquitectoacutenico puede comenzar una
vez que se encuentran definidos los conductores
arquitectoacutenicos El proceso de anaacutelisis de requisitos seraacute
entonces influenciado por las preguntas generadas durante
el disentildeo arquitectoacutenico
El resultado del Srpint 0 es un documento inicial que
explica la arquitectura El documento puede basarse en los
pasos definidos por el meacutetodo ADD (Attrbute Driver
Design) Este meacutetodo ha sido probado exitosamente en
proyectos anteriores Con ADD se puede definir una
arquitectura de software mediante un proceso de
descomposicioacuten basado en los atributos de calidad de
Software
El documento inicial de la arquitectura se debe avaluar con
el fin de saber si la arquitectura cumple con los requisitos
de calidad Para realizar esta evaluacioacuten se propone el
meacutetodo ATAM (Architecture Tradeoff Analysis Method)
El ATAM revela cuaacuten bien una arquitectura satisface los
objetivos particulares de calidad y provee una
aproximacioacuten de coacutemo los objetivos de calidad interactuacutean
Si la evaluacioacuten de la arquitectura se encuentra que se
deben realizar cambios a la misma entonces eacutesta se debe
refinar hasta llegar a tener como resultado del Sprint 0 el
documento puacuteblico de la arquitectura junto con el sistema
esqueleto Finalmente la arquitectura creada en el Sprint 0
beneficiaraacute el desarrollo en los siguientes sprints
IV Rol del arquitecto de Software en Scrum
El rol y actividades del arquitecto de software cambian de
enfoque dependiendo de si se estaacute en el Sprint 0 o en
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
12
sprints subsecuentes
Fig 3 La Comunicacioacuten
Sprint 0 En sistemas complejos una persona difiacutecilmente
puede cubrir con amplitud teacutecnica las decisiones
arquitectoacutenicas y dar credibilidad a la arquitectura de
software Esto quiere decir que la participacioacuten del equipo
es de vital importancia para la creacioacuten y el mantenimiento
de la arquitectura Un equipo de arquitectos de software
que se aiacutesle del equipo de Scrum puede producir una
arquitectura que corra el riesgo de ser rechazada Es por
esto que recomendamos que el arquitecto o los arquitectos
se software sean miembros del equipo de Scrum Una de
las actividades que se debe realizar en equipo es la
evaluacioacuten de la arquitectura Especiacuteficamente en el
meacutetodo ATAM se requiere la participacioacuten mutua de tres
equipos que trabajan en conjunto con los arquitectos de
software el de evaluacioacuten el de tomadores de decisiones
del proyecto y el de los involucrados en la arquitectura
Sprints subsecuentes El arquitecto de software asegura que
el equipo de Scrum entienda el enfoque y los retos
arquitectoacutenicos maacutes importantes en casa sprint Los
equipos de Scrum realizan construcciones cortas guiados
por las estrategias de la arquitectura A continuacioacuten se
nombran algunas de las responsabilidades del arquitecto de
software desde el Sprint 1 en adelante
El duentildeo del producto y el maestro del Scrum trabajan con
el arquitecto para priorizar los requisitos a implementar en
cada iteracioacuten
El arquitecto comunica las decisiones y facilita las
conversaciones arquitectoacutenicas de distintos puntos de vista
en cada sprint
El arquitecto asegura que haya conformidad entre las
entregas en cada sprint y la arquitectura
El arquitecto responde preguntas y da orientacioacuten
arquitectoacutenica cuando sea necesario
Junto con el maestro de Scrum coordina a los miembros
del equipo para adaptarse a la arquitectura previa
El arquitecto junto con el duentildeo del producto y los
miembros del equipo preparan el Product Backlog
V Conclusioacuten
En el presente artiacuteculo ofrecimos una propuesta para incluir
la arquitectura de software en Scrum En el Sprint 0 se
realizan las actividades concernientes al anaacutelisis y disentildeo
de la arquitectura de software y el sistema esqueleto En
los siguientes sprints el arquitecto de software se asegura
de que la implementacioacuten cumpla con la arquitectura
REFERENCIAS
[3] httpwwwsafecreativeorgwork
[4] Hirotaka Takeuchi es decano de la Graduate School of International
Corporate Strategy en la Universidad Hitotsubashi en Tokio y fue profesor visitante en la Escuela de Negocios Harvard entre 1989 y 1990
[5] Ikujiro NonakaNo soy un guruacute porque me falta carisma
] INGENIERIacuteA DE SOFTWARE
13
INGENIERIacuteA DE SISTEMAS
El futuro de la ingenieriacutea de software Luis E Aguirre
Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 de Octubre esq Belisario Salinas
La Paz - Bolivia leaguirreusfaedubo
Resumen El disentildeo de programas a partir de informacioacuten binaria
significoacute un paso sustantivo para la industria desarrolladora de
software Desde ese hallazgo ocurrido en la deacutecada de los
cincuenta hasta hoy el crecimiento de metodologiacuteas para su
desarrollo ha subido notablemente en complejidad Sin embargo
los ciacuterculos viciosos que acusa hoy la confeccioacuten de programas
informaacuteticos impiden conceptualizar el objeto a un nivel
superior de abstraccioacuten tal y como lo exige el avance tecnoloacutegico
y los procesos de negocios
Palabras clave mdash futuro software ingenieriacutea programador y
desarrollo
I Introduccioacuten
La calidad de los sistemas informaacuteticos satisfaccioacuten de sus
usuarios y clientes son temas ampliamente conocidos
recurrentes y de constante preocupacioacuten por parte de los
practicantes de la Ingenieriacutea de software
Esta joven y dinaacutemica ingenieriacutea siempre estaacute en busca de
mejoras en el desarrollo de sistemas aumento de
productividad del ingeniero de software mayor control del
proceso de desarrollo establecimiento de nuevos meacutetodos de
desarrollo
Fig 1 Primeros programas computacionales en formato de tarjeta perforada
Estos elementos combinados y aplicados de buena forma
logran un buen proceso de desarrollo y en definitiva un buen
producto
Identificar los pasos que ha recorrido esta ingenieriacutea analizar
su contexto actual y finalmente proyectar hacia doacutende se
dirige es el pilar de este artiacuteculo
II iquestSe aplica actualmente la ingenieriacutea del software
La investigacioacuten y el desarrollo de teacutecnicas y meacuteto
dos de ingenieriacutea del software son constantes y suelen suponer
interesantes avances en la resolucioacuten de problemas de
desarrollo de software Sin embargo es habitual que en la
praacutectica diaria profesional no se incluya praacutecticamente
ninguna de las recomendaciones maacutes elementales de la
ingenieriacutea del software En efecto es habitual que el
desarrollo de software se parezca maacutes al descontrol del cuento
de laquosi los programadores fueran albantildeilesraquo ([Novatica
1996]) que a una idiacutelica y bien organizada factoriacutea de
software (concepto de gran vigencia a finales de los ochenta
[Nunamaker et al 1988])
De hecho las evaluaciones de los procesos productivos de
software realizadas a raiacutez de los modelo de procesos de
software (por ejemplo con CMM [Paulk et al 1993])
confirman que el desarrollo de software suele estar
baacutesicamente en estado caoacutetico
Y no soacutelo en como uno podriacutea pensar pequentildeas
organizaciones de un paiacutes mediterraacuteneo como el nuestro sino
en tambieacuten en las empresas adjudicatarias de interesantes
contratos de defensa de paiacuteses laquoavanzadosraquo como EEUU o
Japoacuten Si bien estos modelos de evaluacioacuten auacuten acumulan
distintas acusaciones de rigidez o falta de contraste empiacuterico
los resultados obtenidos en sus evaluaciones resultan
consistentes con la sensacioacuten de constante laquoapagafuegosraquo que
suelen sufrir los profesionales del software Tambieacuten suelen
revelar la praacutectica despreocupacioacuten de los responsables de las
organizaciones de software por la mejora de la calidad de sus
procesos de trabajo o de sus productos bien sea por contar con
una situacioacuten interna de empresa poco propicia porque el
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
14
ambiente del mercado no fomenta la preocupacioacuten por estos
temas o bien por su poco intereacutes real en la buacutesqueda de la
calidad
III La actualidad
La gran mayoriacutea de los sistemas de software creados hoy en
diacutea son los llamados sistemas corporativos es decir son
orientados a formar una parte importante de los negocios de
las grandes empresas
Continuando en nuestro contexto se identifica un nuevo
enfoque del problema de desarrollo el apoyo en la
sincronizacioacuten de los procesos de negocio estructuras
complejas de informacioacuten manejada por el negocio todo esto
entrelazado por restricciones dadas por las reglas del negocio
La tecnologiacutea actual por otro lado ha alejado maacutes todaviacutea los
ingenieros de las maacutequinas sistemas operativos incluso de
las tareas de programacioacuten
El enfoque de la mayoriacutea de los equipos de desarrollo e
ingenieros participes en proyectos sigue siendo con un bajo
nivel de abstraccioacuten cerca de la codificacioacuten Se tiende a
pensar en la base de datos a utilizar establecer la navegacioacuten
de las paacuteginas programar los protocolos de comunicacioacuten etc
Esto lleva a utilizar las tareas de programacioacuten y de pruebas
para validar el entendimiento y cumplimiento de la
funcionalidad de los sistemas
Lo anteriormente expuesto muestra un problema
metodoloacutegico consecuencia de un desfase entre el enfoque
teoacuterico oacuteptimo (anaacutelisis de negocio) y el enfoque praacutectico real
(programacioacuten y pruebas) en los proyectos de hoy En otras
palabras la metodologiacutea actualmente usada estaacute atrasada con
respecto al avance tecnoloacutegico
Desarrollando maacutes esta idea se identifican algunos
problemas concretos de las metodologiacuteas
Ellas no obligan a sus ejecutores a respetar todas las
normas y los procedimientos establecidos especialmente
en las etapas tempranas del proyecto Es muy faacutecil y
tentador ―saltar una o maacutes de estas etapas uno o maacutes
documentos o modelos pasando directamente a
implementacioacuten produccioacuten y posterior correccioacuten de los
sistemas desarrollados
Control de calidad del producto final La codificacioacuten y
complejidad del programa es demasiada para ser revisada
y verificada fehacientemente Por otro lado los coacutedigos
fuentes y los ejecutables actualmente son los uacutenicos
entregables eficientemente verificables
Estos dos problemas al parecer forman una situacioacuten
contradictoria la metodologiacutea tradicional no permite validar
eficientemente la calidad de los sistemas antes de llegar al
coacutedigo fuente y por otro lado tampoco permite llegar
eficientemente a coacutedigos fuentes de calidad
IV Futuro
La salida de este ―ciacuterculo vicioso que se propone es
bastante natural analizar la situacioacuten actual de la ingenieriacutea
de software en la luz de sus tendencias histoacutericas
La primera de ellas relacionada con los problemas que
resuelven los sistemas obviamente presente y muy utilizada
en nuestra realidad los sistemas de hoy no soacutelo resuelven los
problemas del mundo real sino que estaacuten fuertemente influen-
ciando el desarrollo del mundo real
Fig2 Modela
El enfoque de los ingenieros desde hace unos antildeos no se ha
movido significativamente por el camino del aumento de
abstraccioacuten establecido histoacutericamente Se han hecho ciertos
avances en temas puntuales (como arquitecturas de
componentes patrones de disentildeo nuevos lenguajes de
programacioacuten etc) pero conceptualmente
metodoloacutegicamente la tarea de programacioacuten sigue siendo
ejecutada de la misma forma escribiendo coacutedigos fuentes en
forma de los programas textuales
Eacuteste es justamente el ―atraso metodoloacutegico que se
mencionoacute Para disminuir la brecha entre las tendencias
histoacutericas es necesario ajustar la metodologiacutea en teacuterminos de
aumentar la abstraccioacuten del enfoque de los ingenieros de
software y acercarlo a la abstraccioacuten del problema
El aumento de la abstraccioacuten del proceso de desarrollo del
software hace pensar que la proacutexima generacioacuten de meacutetodos
de desarrollo se perfila en un conceptualmente nuevo con-
] INGENIERIacuteA DE SOFTWARE
15
INGENIERIacuteA DE SISTEMAS
junto de herramientas que permitan aumentar en un mayor
grado al actual la abstraccioacuten escondiendo los detalles de maacutes
bajo nivel
Fig3 Probable modelo a futuro
Las nuevas herramientas permitiraacuten ―programar en nivel
de anaacutelisis generando coacutedigos en un lenguaje de
programacioacuten tradicional de forma automaacutetica tal como hoy
los compiladores generan el lenguaje maacutequina a partir del
coacutedigo fuente Nuevos ―lenguajes de programacioacuten
naturalmente seriacutean visuales y se pareceriacutean a las
especificaciones de software en uno de los lenguajes de
modelamiento por ejemplo UML
V Conclusioacuten
Es muy probable que estemos proacuteximos a ver un nuevo
paso evolutivo en la ingenieriacutea de software Tan grande como
el invento de lenguajes de alto nivel o anaacutelisis y disentildeo
orientado a objetos Una nueva generacioacuten que absorberaacute a la
actual automatizando la mayoriacutea de las buenas praacutecticas
usadas actualmente
Una pregunta natural es si una maacutequina puede llegar a
generar programas tan buenos como los hechos por un pro-
gramador experto En vez de ―romper la cabeza con esta
pregunta ahora quizaacutes seriacutea suficiente recordarse otra vez de
la historia Los primeros compiladores de ninguna generacioacuten
alcanzaban de inmediato lo deseable y oacuteptimo Sin embargo
con el paso del tiempo apoyados en la experiencia de los
ingenieros y en el avance tecnoloacutegico se mejoraban hasta el
nivel de superar significativamente las generaciones
anteriores
Es poco factible que hoy en diacutea alguien cuestione la calidad
de los compiladores de por ejemplo Java y la calidad del
coacutedigo de maacutequina generado por ellos
VI Referencias [6] Website [Online]
httpwwwenterpriseanalystnetdownloadmda_informaticap
df
[7] httpwwwslidesharenetamrrochafuturo-del-software-impacto-en-las-organizaciones-y-en-los-profesionales
[8] httpwwwdcubaareventseci2008conferenciasIngSoftHexacta
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
12
sprints subsecuentes
Fig 3 La Comunicacioacuten
Sprint 0 En sistemas complejos una persona difiacutecilmente
puede cubrir con amplitud teacutecnica las decisiones
arquitectoacutenicas y dar credibilidad a la arquitectura de
software Esto quiere decir que la participacioacuten del equipo
es de vital importancia para la creacioacuten y el mantenimiento
de la arquitectura Un equipo de arquitectos de software
que se aiacutesle del equipo de Scrum puede producir una
arquitectura que corra el riesgo de ser rechazada Es por
esto que recomendamos que el arquitecto o los arquitectos
se software sean miembros del equipo de Scrum Una de
las actividades que se debe realizar en equipo es la
evaluacioacuten de la arquitectura Especiacuteficamente en el
meacutetodo ATAM se requiere la participacioacuten mutua de tres
equipos que trabajan en conjunto con los arquitectos de
software el de evaluacioacuten el de tomadores de decisiones
del proyecto y el de los involucrados en la arquitectura
Sprints subsecuentes El arquitecto de software asegura que
el equipo de Scrum entienda el enfoque y los retos
arquitectoacutenicos maacutes importantes en casa sprint Los
equipos de Scrum realizan construcciones cortas guiados
por las estrategias de la arquitectura A continuacioacuten se
nombran algunas de las responsabilidades del arquitecto de
software desde el Sprint 1 en adelante
El duentildeo del producto y el maestro del Scrum trabajan con
el arquitecto para priorizar los requisitos a implementar en
cada iteracioacuten
El arquitecto comunica las decisiones y facilita las
conversaciones arquitectoacutenicas de distintos puntos de vista
en cada sprint
El arquitecto asegura que haya conformidad entre las
entregas en cada sprint y la arquitectura
El arquitecto responde preguntas y da orientacioacuten
arquitectoacutenica cuando sea necesario
Junto con el maestro de Scrum coordina a los miembros
del equipo para adaptarse a la arquitectura previa
El arquitecto junto con el duentildeo del producto y los
miembros del equipo preparan el Product Backlog
V Conclusioacuten
En el presente artiacuteculo ofrecimos una propuesta para incluir
la arquitectura de software en Scrum En el Sprint 0 se
realizan las actividades concernientes al anaacutelisis y disentildeo
de la arquitectura de software y el sistema esqueleto En
los siguientes sprints el arquitecto de software se asegura
de que la implementacioacuten cumpla con la arquitectura
REFERENCIAS
[3] httpwwwsafecreativeorgwork
[4] Hirotaka Takeuchi es decano de la Graduate School of International
Corporate Strategy en la Universidad Hitotsubashi en Tokio y fue profesor visitante en la Escuela de Negocios Harvard entre 1989 y 1990
[5] Ikujiro NonakaNo soy un guruacute porque me falta carisma
] INGENIERIacuteA DE SOFTWARE
13
INGENIERIacuteA DE SISTEMAS
El futuro de la ingenieriacutea de software Luis E Aguirre
Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 de Octubre esq Belisario Salinas
La Paz - Bolivia leaguirreusfaedubo
Resumen El disentildeo de programas a partir de informacioacuten binaria
significoacute un paso sustantivo para la industria desarrolladora de
software Desde ese hallazgo ocurrido en la deacutecada de los
cincuenta hasta hoy el crecimiento de metodologiacuteas para su
desarrollo ha subido notablemente en complejidad Sin embargo
los ciacuterculos viciosos que acusa hoy la confeccioacuten de programas
informaacuteticos impiden conceptualizar el objeto a un nivel
superior de abstraccioacuten tal y como lo exige el avance tecnoloacutegico
y los procesos de negocios
Palabras clave mdash futuro software ingenieriacutea programador y
desarrollo
I Introduccioacuten
La calidad de los sistemas informaacuteticos satisfaccioacuten de sus
usuarios y clientes son temas ampliamente conocidos
recurrentes y de constante preocupacioacuten por parte de los
practicantes de la Ingenieriacutea de software
Esta joven y dinaacutemica ingenieriacutea siempre estaacute en busca de
mejoras en el desarrollo de sistemas aumento de
productividad del ingeniero de software mayor control del
proceso de desarrollo establecimiento de nuevos meacutetodos de
desarrollo
Fig 1 Primeros programas computacionales en formato de tarjeta perforada
Estos elementos combinados y aplicados de buena forma
logran un buen proceso de desarrollo y en definitiva un buen
producto
Identificar los pasos que ha recorrido esta ingenieriacutea analizar
su contexto actual y finalmente proyectar hacia doacutende se
dirige es el pilar de este artiacuteculo
II iquestSe aplica actualmente la ingenieriacutea del software
La investigacioacuten y el desarrollo de teacutecnicas y meacuteto
dos de ingenieriacutea del software son constantes y suelen suponer
interesantes avances en la resolucioacuten de problemas de
desarrollo de software Sin embargo es habitual que en la
praacutectica diaria profesional no se incluya praacutecticamente
ninguna de las recomendaciones maacutes elementales de la
ingenieriacutea del software En efecto es habitual que el
desarrollo de software se parezca maacutes al descontrol del cuento
de laquosi los programadores fueran albantildeilesraquo ([Novatica
1996]) que a una idiacutelica y bien organizada factoriacutea de
software (concepto de gran vigencia a finales de los ochenta
[Nunamaker et al 1988])
De hecho las evaluaciones de los procesos productivos de
software realizadas a raiacutez de los modelo de procesos de
software (por ejemplo con CMM [Paulk et al 1993])
confirman que el desarrollo de software suele estar
baacutesicamente en estado caoacutetico
Y no soacutelo en como uno podriacutea pensar pequentildeas
organizaciones de un paiacutes mediterraacuteneo como el nuestro sino
en tambieacuten en las empresas adjudicatarias de interesantes
contratos de defensa de paiacuteses laquoavanzadosraquo como EEUU o
Japoacuten Si bien estos modelos de evaluacioacuten auacuten acumulan
distintas acusaciones de rigidez o falta de contraste empiacuterico
los resultados obtenidos en sus evaluaciones resultan
consistentes con la sensacioacuten de constante laquoapagafuegosraquo que
suelen sufrir los profesionales del software Tambieacuten suelen
revelar la praacutectica despreocupacioacuten de los responsables de las
organizaciones de software por la mejora de la calidad de sus
procesos de trabajo o de sus productos bien sea por contar con
una situacioacuten interna de empresa poco propicia porque el
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
14
ambiente del mercado no fomenta la preocupacioacuten por estos
temas o bien por su poco intereacutes real en la buacutesqueda de la
calidad
III La actualidad
La gran mayoriacutea de los sistemas de software creados hoy en
diacutea son los llamados sistemas corporativos es decir son
orientados a formar una parte importante de los negocios de
las grandes empresas
Continuando en nuestro contexto se identifica un nuevo
enfoque del problema de desarrollo el apoyo en la
sincronizacioacuten de los procesos de negocio estructuras
complejas de informacioacuten manejada por el negocio todo esto
entrelazado por restricciones dadas por las reglas del negocio
La tecnologiacutea actual por otro lado ha alejado maacutes todaviacutea los
ingenieros de las maacutequinas sistemas operativos incluso de
las tareas de programacioacuten
El enfoque de la mayoriacutea de los equipos de desarrollo e
ingenieros participes en proyectos sigue siendo con un bajo
nivel de abstraccioacuten cerca de la codificacioacuten Se tiende a
pensar en la base de datos a utilizar establecer la navegacioacuten
de las paacuteginas programar los protocolos de comunicacioacuten etc
Esto lleva a utilizar las tareas de programacioacuten y de pruebas
para validar el entendimiento y cumplimiento de la
funcionalidad de los sistemas
Lo anteriormente expuesto muestra un problema
metodoloacutegico consecuencia de un desfase entre el enfoque
teoacuterico oacuteptimo (anaacutelisis de negocio) y el enfoque praacutectico real
(programacioacuten y pruebas) en los proyectos de hoy En otras
palabras la metodologiacutea actualmente usada estaacute atrasada con
respecto al avance tecnoloacutegico
Desarrollando maacutes esta idea se identifican algunos
problemas concretos de las metodologiacuteas
Ellas no obligan a sus ejecutores a respetar todas las
normas y los procedimientos establecidos especialmente
en las etapas tempranas del proyecto Es muy faacutecil y
tentador ―saltar una o maacutes de estas etapas uno o maacutes
documentos o modelos pasando directamente a
implementacioacuten produccioacuten y posterior correccioacuten de los
sistemas desarrollados
Control de calidad del producto final La codificacioacuten y
complejidad del programa es demasiada para ser revisada
y verificada fehacientemente Por otro lado los coacutedigos
fuentes y los ejecutables actualmente son los uacutenicos
entregables eficientemente verificables
Estos dos problemas al parecer forman una situacioacuten
contradictoria la metodologiacutea tradicional no permite validar
eficientemente la calidad de los sistemas antes de llegar al
coacutedigo fuente y por otro lado tampoco permite llegar
eficientemente a coacutedigos fuentes de calidad
IV Futuro
La salida de este ―ciacuterculo vicioso que se propone es
bastante natural analizar la situacioacuten actual de la ingenieriacutea
de software en la luz de sus tendencias histoacutericas
La primera de ellas relacionada con los problemas que
resuelven los sistemas obviamente presente y muy utilizada
en nuestra realidad los sistemas de hoy no soacutelo resuelven los
problemas del mundo real sino que estaacuten fuertemente influen-
ciando el desarrollo del mundo real
Fig2 Modela
El enfoque de los ingenieros desde hace unos antildeos no se ha
movido significativamente por el camino del aumento de
abstraccioacuten establecido histoacutericamente Se han hecho ciertos
avances en temas puntuales (como arquitecturas de
componentes patrones de disentildeo nuevos lenguajes de
programacioacuten etc) pero conceptualmente
metodoloacutegicamente la tarea de programacioacuten sigue siendo
ejecutada de la misma forma escribiendo coacutedigos fuentes en
forma de los programas textuales
Eacuteste es justamente el ―atraso metodoloacutegico que se
mencionoacute Para disminuir la brecha entre las tendencias
histoacutericas es necesario ajustar la metodologiacutea en teacuterminos de
aumentar la abstraccioacuten del enfoque de los ingenieros de
software y acercarlo a la abstraccioacuten del problema
El aumento de la abstraccioacuten del proceso de desarrollo del
software hace pensar que la proacutexima generacioacuten de meacutetodos
de desarrollo se perfila en un conceptualmente nuevo con-
] INGENIERIacuteA DE SOFTWARE
15
INGENIERIacuteA DE SISTEMAS
junto de herramientas que permitan aumentar en un mayor
grado al actual la abstraccioacuten escondiendo los detalles de maacutes
bajo nivel
Fig3 Probable modelo a futuro
Las nuevas herramientas permitiraacuten ―programar en nivel
de anaacutelisis generando coacutedigos en un lenguaje de
programacioacuten tradicional de forma automaacutetica tal como hoy
los compiladores generan el lenguaje maacutequina a partir del
coacutedigo fuente Nuevos ―lenguajes de programacioacuten
naturalmente seriacutean visuales y se pareceriacutean a las
especificaciones de software en uno de los lenguajes de
modelamiento por ejemplo UML
V Conclusioacuten
Es muy probable que estemos proacuteximos a ver un nuevo
paso evolutivo en la ingenieriacutea de software Tan grande como
el invento de lenguajes de alto nivel o anaacutelisis y disentildeo
orientado a objetos Una nueva generacioacuten que absorberaacute a la
actual automatizando la mayoriacutea de las buenas praacutecticas
usadas actualmente
Una pregunta natural es si una maacutequina puede llegar a
generar programas tan buenos como los hechos por un pro-
gramador experto En vez de ―romper la cabeza con esta
pregunta ahora quizaacutes seriacutea suficiente recordarse otra vez de
la historia Los primeros compiladores de ninguna generacioacuten
alcanzaban de inmediato lo deseable y oacuteptimo Sin embargo
con el paso del tiempo apoyados en la experiencia de los
ingenieros y en el avance tecnoloacutegico se mejoraban hasta el
nivel de superar significativamente las generaciones
anteriores
Es poco factible que hoy en diacutea alguien cuestione la calidad
de los compiladores de por ejemplo Java y la calidad del
coacutedigo de maacutequina generado por ellos
VI Referencias [6] Website [Online]
httpwwwenterpriseanalystnetdownloadmda_informaticap
df
[7] httpwwwslidesharenetamrrochafuturo-del-software-impacto-en-las-organizaciones-y-en-los-profesionales
[8] httpwwwdcubaareventseci2008conferenciasIngSoftHexacta
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
13
INGENIERIacuteA DE SISTEMAS
El futuro de la ingenieriacutea de software Luis E Aguirre
Ingenieriacutea de Sistemas
Universidad San Francisco de Asiacutes
20 de Octubre esq Belisario Salinas
La Paz - Bolivia leaguirreusfaedubo
Resumen El disentildeo de programas a partir de informacioacuten binaria
significoacute un paso sustantivo para la industria desarrolladora de
software Desde ese hallazgo ocurrido en la deacutecada de los
cincuenta hasta hoy el crecimiento de metodologiacuteas para su
desarrollo ha subido notablemente en complejidad Sin embargo
los ciacuterculos viciosos que acusa hoy la confeccioacuten de programas
informaacuteticos impiden conceptualizar el objeto a un nivel
superior de abstraccioacuten tal y como lo exige el avance tecnoloacutegico
y los procesos de negocios
Palabras clave mdash futuro software ingenieriacutea programador y
desarrollo
I Introduccioacuten
La calidad de los sistemas informaacuteticos satisfaccioacuten de sus
usuarios y clientes son temas ampliamente conocidos
recurrentes y de constante preocupacioacuten por parte de los
practicantes de la Ingenieriacutea de software
Esta joven y dinaacutemica ingenieriacutea siempre estaacute en busca de
mejoras en el desarrollo de sistemas aumento de
productividad del ingeniero de software mayor control del
proceso de desarrollo establecimiento de nuevos meacutetodos de
desarrollo
Fig 1 Primeros programas computacionales en formato de tarjeta perforada
Estos elementos combinados y aplicados de buena forma
logran un buen proceso de desarrollo y en definitiva un buen
producto
Identificar los pasos que ha recorrido esta ingenieriacutea analizar
su contexto actual y finalmente proyectar hacia doacutende se
dirige es el pilar de este artiacuteculo
II iquestSe aplica actualmente la ingenieriacutea del software
La investigacioacuten y el desarrollo de teacutecnicas y meacuteto
dos de ingenieriacutea del software son constantes y suelen suponer
interesantes avances en la resolucioacuten de problemas de
desarrollo de software Sin embargo es habitual que en la
praacutectica diaria profesional no se incluya praacutecticamente
ninguna de las recomendaciones maacutes elementales de la
ingenieriacutea del software En efecto es habitual que el
desarrollo de software se parezca maacutes al descontrol del cuento
de laquosi los programadores fueran albantildeilesraquo ([Novatica
1996]) que a una idiacutelica y bien organizada factoriacutea de
software (concepto de gran vigencia a finales de los ochenta
[Nunamaker et al 1988])
De hecho las evaluaciones de los procesos productivos de
software realizadas a raiacutez de los modelo de procesos de
software (por ejemplo con CMM [Paulk et al 1993])
confirman que el desarrollo de software suele estar
baacutesicamente en estado caoacutetico
Y no soacutelo en como uno podriacutea pensar pequentildeas
organizaciones de un paiacutes mediterraacuteneo como el nuestro sino
en tambieacuten en las empresas adjudicatarias de interesantes
contratos de defensa de paiacuteses laquoavanzadosraquo como EEUU o
Japoacuten Si bien estos modelos de evaluacioacuten auacuten acumulan
distintas acusaciones de rigidez o falta de contraste empiacuterico
los resultados obtenidos en sus evaluaciones resultan
consistentes con la sensacioacuten de constante laquoapagafuegosraquo que
suelen sufrir los profesionales del software Tambieacuten suelen
revelar la praacutectica despreocupacioacuten de los responsables de las
organizaciones de software por la mejora de la calidad de sus
procesos de trabajo o de sus productos bien sea por contar con
una situacioacuten interna de empresa poco propicia porque el
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
14
ambiente del mercado no fomenta la preocupacioacuten por estos
temas o bien por su poco intereacutes real en la buacutesqueda de la
calidad
III La actualidad
La gran mayoriacutea de los sistemas de software creados hoy en
diacutea son los llamados sistemas corporativos es decir son
orientados a formar una parte importante de los negocios de
las grandes empresas
Continuando en nuestro contexto se identifica un nuevo
enfoque del problema de desarrollo el apoyo en la
sincronizacioacuten de los procesos de negocio estructuras
complejas de informacioacuten manejada por el negocio todo esto
entrelazado por restricciones dadas por las reglas del negocio
La tecnologiacutea actual por otro lado ha alejado maacutes todaviacutea los
ingenieros de las maacutequinas sistemas operativos incluso de
las tareas de programacioacuten
El enfoque de la mayoriacutea de los equipos de desarrollo e
ingenieros participes en proyectos sigue siendo con un bajo
nivel de abstraccioacuten cerca de la codificacioacuten Se tiende a
pensar en la base de datos a utilizar establecer la navegacioacuten
de las paacuteginas programar los protocolos de comunicacioacuten etc
Esto lleva a utilizar las tareas de programacioacuten y de pruebas
para validar el entendimiento y cumplimiento de la
funcionalidad de los sistemas
Lo anteriormente expuesto muestra un problema
metodoloacutegico consecuencia de un desfase entre el enfoque
teoacuterico oacuteptimo (anaacutelisis de negocio) y el enfoque praacutectico real
(programacioacuten y pruebas) en los proyectos de hoy En otras
palabras la metodologiacutea actualmente usada estaacute atrasada con
respecto al avance tecnoloacutegico
Desarrollando maacutes esta idea se identifican algunos
problemas concretos de las metodologiacuteas
Ellas no obligan a sus ejecutores a respetar todas las
normas y los procedimientos establecidos especialmente
en las etapas tempranas del proyecto Es muy faacutecil y
tentador ―saltar una o maacutes de estas etapas uno o maacutes
documentos o modelos pasando directamente a
implementacioacuten produccioacuten y posterior correccioacuten de los
sistemas desarrollados
Control de calidad del producto final La codificacioacuten y
complejidad del programa es demasiada para ser revisada
y verificada fehacientemente Por otro lado los coacutedigos
fuentes y los ejecutables actualmente son los uacutenicos
entregables eficientemente verificables
Estos dos problemas al parecer forman una situacioacuten
contradictoria la metodologiacutea tradicional no permite validar
eficientemente la calidad de los sistemas antes de llegar al
coacutedigo fuente y por otro lado tampoco permite llegar
eficientemente a coacutedigos fuentes de calidad
IV Futuro
La salida de este ―ciacuterculo vicioso que se propone es
bastante natural analizar la situacioacuten actual de la ingenieriacutea
de software en la luz de sus tendencias histoacutericas
La primera de ellas relacionada con los problemas que
resuelven los sistemas obviamente presente y muy utilizada
en nuestra realidad los sistemas de hoy no soacutelo resuelven los
problemas del mundo real sino que estaacuten fuertemente influen-
ciando el desarrollo del mundo real
Fig2 Modela
El enfoque de los ingenieros desde hace unos antildeos no se ha
movido significativamente por el camino del aumento de
abstraccioacuten establecido histoacutericamente Se han hecho ciertos
avances en temas puntuales (como arquitecturas de
componentes patrones de disentildeo nuevos lenguajes de
programacioacuten etc) pero conceptualmente
metodoloacutegicamente la tarea de programacioacuten sigue siendo
ejecutada de la misma forma escribiendo coacutedigos fuentes en
forma de los programas textuales
Eacuteste es justamente el ―atraso metodoloacutegico que se
mencionoacute Para disminuir la brecha entre las tendencias
histoacutericas es necesario ajustar la metodologiacutea en teacuterminos de
aumentar la abstraccioacuten del enfoque de los ingenieros de
software y acercarlo a la abstraccioacuten del problema
El aumento de la abstraccioacuten del proceso de desarrollo del
software hace pensar que la proacutexima generacioacuten de meacutetodos
de desarrollo se perfila en un conceptualmente nuevo con-
] INGENIERIacuteA DE SOFTWARE
15
INGENIERIacuteA DE SISTEMAS
junto de herramientas que permitan aumentar en un mayor
grado al actual la abstraccioacuten escondiendo los detalles de maacutes
bajo nivel
Fig3 Probable modelo a futuro
Las nuevas herramientas permitiraacuten ―programar en nivel
de anaacutelisis generando coacutedigos en un lenguaje de
programacioacuten tradicional de forma automaacutetica tal como hoy
los compiladores generan el lenguaje maacutequina a partir del
coacutedigo fuente Nuevos ―lenguajes de programacioacuten
naturalmente seriacutean visuales y se pareceriacutean a las
especificaciones de software en uno de los lenguajes de
modelamiento por ejemplo UML
V Conclusioacuten
Es muy probable que estemos proacuteximos a ver un nuevo
paso evolutivo en la ingenieriacutea de software Tan grande como
el invento de lenguajes de alto nivel o anaacutelisis y disentildeo
orientado a objetos Una nueva generacioacuten que absorberaacute a la
actual automatizando la mayoriacutea de las buenas praacutecticas
usadas actualmente
Una pregunta natural es si una maacutequina puede llegar a
generar programas tan buenos como los hechos por un pro-
gramador experto En vez de ―romper la cabeza con esta
pregunta ahora quizaacutes seriacutea suficiente recordarse otra vez de
la historia Los primeros compiladores de ninguna generacioacuten
alcanzaban de inmediato lo deseable y oacuteptimo Sin embargo
con el paso del tiempo apoyados en la experiencia de los
ingenieros y en el avance tecnoloacutegico se mejoraban hasta el
nivel de superar significativamente las generaciones
anteriores
Es poco factible que hoy en diacutea alguien cuestione la calidad
de los compiladores de por ejemplo Java y la calidad del
coacutedigo de maacutequina generado por ellos
VI Referencias [6] Website [Online]
httpwwwenterpriseanalystnetdownloadmda_informaticap
df
[7] httpwwwslidesharenetamrrochafuturo-del-software-impacto-en-las-organizaciones-y-en-los-profesionales
[8] httpwwwdcubaareventseci2008conferenciasIngSoftHexacta
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
14
ambiente del mercado no fomenta la preocupacioacuten por estos
temas o bien por su poco intereacutes real en la buacutesqueda de la
calidad
III La actualidad
La gran mayoriacutea de los sistemas de software creados hoy en
diacutea son los llamados sistemas corporativos es decir son
orientados a formar una parte importante de los negocios de
las grandes empresas
Continuando en nuestro contexto se identifica un nuevo
enfoque del problema de desarrollo el apoyo en la
sincronizacioacuten de los procesos de negocio estructuras
complejas de informacioacuten manejada por el negocio todo esto
entrelazado por restricciones dadas por las reglas del negocio
La tecnologiacutea actual por otro lado ha alejado maacutes todaviacutea los
ingenieros de las maacutequinas sistemas operativos incluso de
las tareas de programacioacuten
El enfoque de la mayoriacutea de los equipos de desarrollo e
ingenieros participes en proyectos sigue siendo con un bajo
nivel de abstraccioacuten cerca de la codificacioacuten Se tiende a
pensar en la base de datos a utilizar establecer la navegacioacuten
de las paacuteginas programar los protocolos de comunicacioacuten etc
Esto lleva a utilizar las tareas de programacioacuten y de pruebas
para validar el entendimiento y cumplimiento de la
funcionalidad de los sistemas
Lo anteriormente expuesto muestra un problema
metodoloacutegico consecuencia de un desfase entre el enfoque
teoacuterico oacuteptimo (anaacutelisis de negocio) y el enfoque praacutectico real
(programacioacuten y pruebas) en los proyectos de hoy En otras
palabras la metodologiacutea actualmente usada estaacute atrasada con
respecto al avance tecnoloacutegico
Desarrollando maacutes esta idea se identifican algunos
problemas concretos de las metodologiacuteas
Ellas no obligan a sus ejecutores a respetar todas las
normas y los procedimientos establecidos especialmente
en las etapas tempranas del proyecto Es muy faacutecil y
tentador ―saltar una o maacutes de estas etapas uno o maacutes
documentos o modelos pasando directamente a
implementacioacuten produccioacuten y posterior correccioacuten de los
sistemas desarrollados
Control de calidad del producto final La codificacioacuten y
complejidad del programa es demasiada para ser revisada
y verificada fehacientemente Por otro lado los coacutedigos
fuentes y los ejecutables actualmente son los uacutenicos
entregables eficientemente verificables
Estos dos problemas al parecer forman una situacioacuten
contradictoria la metodologiacutea tradicional no permite validar
eficientemente la calidad de los sistemas antes de llegar al
coacutedigo fuente y por otro lado tampoco permite llegar
eficientemente a coacutedigos fuentes de calidad
IV Futuro
La salida de este ―ciacuterculo vicioso que se propone es
bastante natural analizar la situacioacuten actual de la ingenieriacutea
de software en la luz de sus tendencias histoacutericas
La primera de ellas relacionada con los problemas que
resuelven los sistemas obviamente presente y muy utilizada
en nuestra realidad los sistemas de hoy no soacutelo resuelven los
problemas del mundo real sino que estaacuten fuertemente influen-
ciando el desarrollo del mundo real
Fig2 Modela
El enfoque de los ingenieros desde hace unos antildeos no se ha
movido significativamente por el camino del aumento de
abstraccioacuten establecido histoacutericamente Se han hecho ciertos
avances en temas puntuales (como arquitecturas de
componentes patrones de disentildeo nuevos lenguajes de
programacioacuten etc) pero conceptualmente
metodoloacutegicamente la tarea de programacioacuten sigue siendo
ejecutada de la misma forma escribiendo coacutedigos fuentes en
forma de los programas textuales
Eacuteste es justamente el ―atraso metodoloacutegico que se
mencionoacute Para disminuir la brecha entre las tendencias
histoacutericas es necesario ajustar la metodologiacutea en teacuterminos de
aumentar la abstraccioacuten del enfoque de los ingenieros de
software y acercarlo a la abstraccioacuten del problema
El aumento de la abstraccioacuten del proceso de desarrollo del
software hace pensar que la proacutexima generacioacuten de meacutetodos
de desarrollo se perfila en un conceptualmente nuevo con-
] INGENIERIacuteA DE SOFTWARE
15
INGENIERIacuteA DE SISTEMAS
junto de herramientas que permitan aumentar en un mayor
grado al actual la abstraccioacuten escondiendo los detalles de maacutes
bajo nivel
Fig3 Probable modelo a futuro
Las nuevas herramientas permitiraacuten ―programar en nivel
de anaacutelisis generando coacutedigos en un lenguaje de
programacioacuten tradicional de forma automaacutetica tal como hoy
los compiladores generan el lenguaje maacutequina a partir del
coacutedigo fuente Nuevos ―lenguajes de programacioacuten
naturalmente seriacutean visuales y se pareceriacutean a las
especificaciones de software en uno de los lenguajes de
modelamiento por ejemplo UML
V Conclusioacuten
Es muy probable que estemos proacuteximos a ver un nuevo
paso evolutivo en la ingenieriacutea de software Tan grande como
el invento de lenguajes de alto nivel o anaacutelisis y disentildeo
orientado a objetos Una nueva generacioacuten que absorberaacute a la
actual automatizando la mayoriacutea de las buenas praacutecticas
usadas actualmente
Una pregunta natural es si una maacutequina puede llegar a
generar programas tan buenos como los hechos por un pro-
gramador experto En vez de ―romper la cabeza con esta
pregunta ahora quizaacutes seriacutea suficiente recordarse otra vez de
la historia Los primeros compiladores de ninguna generacioacuten
alcanzaban de inmediato lo deseable y oacuteptimo Sin embargo
con el paso del tiempo apoyados en la experiencia de los
ingenieros y en el avance tecnoloacutegico se mejoraban hasta el
nivel de superar significativamente las generaciones
anteriores
Es poco factible que hoy en diacutea alguien cuestione la calidad
de los compiladores de por ejemplo Java y la calidad del
coacutedigo de maacutequina generado por ellos
VI Referencias [6] Website [Online]
httpwwwenterpriseanalystnetdownloadmda_informaticap
df
[7] httpwwwslidesharenetamrrochafuturo-del-software-impacto-en-las-organizaciones-y-en-los-profesionales
[8] httpwwwdcubaareventseci2008conferenciasIngSoftHexacta
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
15
INGENIERIacuteA DE SISTEMAS
junto de herramientas que permitan aumentar en un mayor
grado al actual la abstraccioacuten escondiendo los detalles de maacutes
bajo nivel
Fig3 Probable modelo a futuro
Las nuevas herramientas permitiraacuten ―programar en nivel
de anaacutelisis generando coacutedigos en un lenguaje de
programacioacuten tradicional de forma automaacutetica tal como hoy
los compiladores generan el lenguaje maacutequina a partir del
coacutedigo fuente Nuevos ―lenguajes de programacioacuten
naturalmente seriacutean visuales y se pareceriacutean a las
especificaciones de software en uno de los lenguajes de
modelamiento por ejemplo UML
V Conclusioacuten
Es muy probable que estemos proacuteximos a ver un nuevo
paso evolutivo en la ingenieriacutea de software Tan grande como
el invento de lenguajes de alto nivel o anaacutelisis y disentildeo
orientado a objetos Una nueva generacioacuten que absorberaacute a la
actual automatizando la mayoriacutea de las buenas praacutecticas
usadas actualmente
Una pregunta natural es si una maacutequina puede llegar a
generar programas tan buenos como los hechos por un pro-
gramador experto En vez de ―romper la cabeza con esta
pregunta ahora quizaacutes seriacutea suficiente recordarse otra vez de
la historia Los primeros compiladores de ninguna generacioacuten
alcanzaban de inmediato lo deseable y oacuteptimo Sin embargo
con el paso del tiempo apoyados en la experiencia de los
ingenieros y en el avance tecnoloacutegico se mejoraban hasta el
nivel de superar significativamente las generaciones
anteriores
Es poco factible que hoy en diacutea alguien cuestione la calidad
de los compiladores de por ejemplo Java y la calidad del
coacutedigo de maacutequina generado por ellos
VI Referencias [6] Website [Online]
httpwwwenterpriseanalystnetdownloadmda_informaticap
df
[7] httpwwwslidesharenetamrrochafuturo-del-software-impacto-en-las-organizaciones-y-en-los-profesionales
[8] httpwwwdcubaareventseci2008conferenciasIngSoftHexacta
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
16
Ingenieriacutea de Software para
Desarrolladores de juegos Huascar Huanca Orozco
Ingenieria de Sistemas San francisco de Asis
Av20 de Octubre esq Belisario Salinas
hhuncausfaedubo
ResumenmdashEn este artiacuteculo veremos una lo que es ldquoIS para
Desarrolladores de juegosrdquo si crees que un juego es facil pues
te equivocas en este articulo mostramos el uso de la IS en la
cracion de juegos que metodos utilizan y la complejidad que
representa para el equipo de desarrollo
1) Palabras clave mdash UMLRequisitosjuegoequipo de trabajo motor del juego
IV INTRODUCCIOacuteN
En la ingenieriacutea de software (IS) el desarrollo
de videojuegos es uacutenico pero similares a los
esfuerzos de software Es la uacutenica que combina el
trabajo de los equipos que cubren muacuteltiples
disciplinas (arte muacutesica actuacioacuten
programacioacuten etc) y que el juego de
acoplamiento que se busca a traveacutes del uso de
prototipos e iteraciones Con ello el desarrollo
del juego se enfrenta a desafiacuteos que pueden ser
abordadas mediante las praacutecticas tradicionales de
SE La industria tiene que adoptar buenas
praacutecticas de SE para sus distintas necesidades
tales como la gestioacuten de activos multimedia y
encontrar el fundamento en el juego La industria
debe asumir los retos por la evolucioacuten de los
meacutetodos de SE para satisfacer sus necesidades
Este trabajo investiga estos desafiacuteos y praacutecticas
de ingenieriacutea destaca para mitigar estos
problemas
V ENTRA EN EL JUEGO
Lo que la IS para desarrolladores de juegos hace
es
Mezcla de ingenieriacutea y el arte El software como
una praacutectica como una preocupacioacuten profesional
Meacutetodos para aprender a disentildear y fabricar un
producto El desarrollo del personaje e ingenieriacutea
de software Estrategias para hacer el mejor uso
de la ingenieriacutea del conocimiento formalizado El
aprendizaje de las habilidades que se pueden
aplicar en cualquier lugar
VI REQUISITOS
Esta parte ofrece una visioacuten general de los
conceptos y herramientas necesarias para la
obtencioacuten de requisitos
IDENTIFICAR LO QUE SE CONSIDERA UN REQUISITO DE SOFTWARE
ESTABLECER LOS CRITERIOS PARA DAR SENTIDO A LOS REQUISITOS Y LA
ESCRITURA DETERMINAR LA MANERA DE REUNIR LOS REQUISITOS O DESCUBRIR
EXPLORAR COacuteMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y
ANALIZAR LAS NECESIDADES ENCONTRAR TEacuteCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTEacuteN
COMPLETOS
VERIFICAR LA EXACTITUD DE LOS REQUISITOS TRACE CAMBIOS EN LOS REQUISITOS
VII PROGRAMADOR DEL MOTOR DEL JUEGO
Fig 1 Juego RPG
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
17
INGENIERIacuteA DE SISTEMAS
Los programadores de juegos motores crear el
motor de base del juego incluyendo la fiacutesica de
simulacioacuten y disciplinas graacuteficas
A Fiacutesica del motor del programador
Programador de un juego de la fiacutesica se dedica
al desarrollo de las fiacutesica de un juego se emplean
Por lo general un juego de soacutelo simular algunos
aspectos de la fiacutesica del mundo real Por ejemplo
un juego de espacio puede necesitar simulada
gravedad pero no tendriacutea ninguna necesidad
para simular agua viscosidad
Para un juego de rol como World of Warcraft
soacutelo un programador de la fiacutesica puede ser
necesaria Para un juego de combate complejo
como Battlefield 1942 los equipos de
programadores de la fiacutesica pueden ser necesarias
B motor de graacuteficos del programador
A pesar de todos los programadores antildeadir
tanto los contenidos y la experiencia que ofrece
un juego un programador de juego se centra maacutes
en la estrategia de un juego la aplicacioacuten de la
mecaacutenica del juego y la loacutegica y la sensacioacuten
de un juego
Esto no suele ser una disciplina independiente
como lo que este programador es por lo general
se diferencia de un juego a otro y que
inevitablemente se veraacute involucrado con las aacutereas
maacutes especializadas de desarrollo del juego como
los graacuteficos o el sonido
VIII EQUIPO DE TRABAJO
Fig 2 Grupo de trabajo
Un equipo de desarrollo en una organizacioacuten de
ingenieriacutea de software se compone de un grupo
de personas que trabajan en funciones
especializadas para lograr un objetivo comuacuten El
objetivo es la realizacioacuten de un proyecto Un
proyecto se define como un esfuerzo temporal
emprendido para crear un producto uacutenico
servicio o resultado
Aquiacute una pequentildea lista incompleta de algunos de
los componentes de un equipo de trabajo para
Desarrollo de juegos
Analista de requerimientos recopilar y analizar
los requisitos para el software
Arquitecto de software determinar la mejor
arquitectura para el software Seleccionar
Los componentes del proveedor para su inclusioacuten
en el esfuerzo de desarrollo
Disentildeador de software acotar el software para
lograr un rendimiento y otros
Objetivos
Prueba de software probador del software para
garantizar que funcione de acuerdo a la
Requisitos
Programador senior desarrollar bajo nivel de
documentacioacuten de disentildeo sirven como una
tecno-
Ventaja teacutecnica para los demaacutes e implementar el
software de acuerdo
Para el disentildeo
Programador implementar el software de acuerdo
al disentildeo
Trabajos de mantenimiento en el programador de
software creado durante el desarrollo anterior
Los esfuerzos para agregar funcionalidad o
eliminar errores de trabajo con
Atencioacuten al cliente
IX LENGUAJE UNIFICADO DE MODELADO (UML)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
18
Tomando en cuenta que el UML es un estaacutendar
muy flexible Nos da razoacuten que podemos pensar
en el diagrama
como herramientas que permiten realizar
diferentes tipos de trabajo Para revisar un poco
Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propoacutesitos de disentildeo o pruebas
Use un diagrama de actividades para explorar los escenarios de casos de uso
Use un diagrama de clases para identificar las clases y ver coacutemo las
clases se relacionan entre siacute Use un diagrama de objetos para ver coacutemo un objeto se comunica con
otro
Use un diagrama de estado para explorar los atributos de cambio de objeto
Use un diagrama de secuencia para explorar a fondo un caso de uso
mediante el trazado de la orden en el que los objetos enviar mensajes a siacute mismos o entre siacute
Use un diagrama de colaboracioacuten para ver la loacutegica del sistema y la
forma en que los objetos envian mensajes entre siacute Use un diagrama de componentes para explorar y si existen los
subsistemas dentro de su juego
Use un diagrama de implementacioacuten para encontrar la manera de
configurar el paquete de instalacioacuten para su juego
X CONCLUSIONES
El desarrollo de los juegos se han vueltos mas
complejos con el pasar del tiempo y para el
desarrollo de un juego que este a la vanguardia
de la competencia se debe trabajar con la IS es
una forma eficaz de conseguir un juego de
calidad internacional
Referencias [9] Software Engineering for Game Developers by john P Flynt with Omar
Salem [10] httpieeexploreieeeorgxplloginjsptp=amparnumber=5070627ampurl=http
3A2F2Fieeexploreieeeorg2Fiel52F50705742F50705752F05
070627pdf3Farnumber
[11] httpgamedevstackexchangecomquestions19934abstract-game-engine-design
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
19
INGENIERIacuteA DE SISTEMAS
Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asiacutes Av 20 de Octubre La Paz Bolivia
maccc19hotmailcom
Resumen Una estrategia de software es un mecanismo que
proporciona una guiacutea o base pasa ver la forma como se debe
desarrollar la aplicacioacuten en cuanto a meacutetodos esfuerzo
tiempo y recursos que son necesarios para lograr un producto
exitoso
La frecuencia con las que realicen las pruebas es de gran
importancia ya que de estaacute manera se pueda la en encontrar
los errores antes de que se conviertan en errores para la
aplicacioacuten si no se lleva un orden de aplicacioacuten de las pruebas
se va a perder tiempo recurso y sobre todo esfuerzo
Durante las primeras etapas de las pruebas es importante
concentrar toda la atencioacuten en un pequentildeo grupo de
componentes o en un componente que se considere importante
para el desarrollo tanto en los datos como en la parte loacutegica de
la aplicacioacuten
El objetivo final de las estrategias de prueba es documentar la
forma en el que equipo ha hecho el desarrollo y el seguimiento
que se le ha hecho a cada una de las etapas durante las etapas
de desarrollo e implementacioacuten
Palabras clave Calidad Prueba Estrategias Sistema
I INTRODUCCIOacuteN
Durante este articulo es importante mencionar algunos
aspectos que determinan el eacutexito de la aplicacioacuten de las
estrategias de prueba como lo son el enfoque estrateacutegico
para la prueba de software aspectos estrateacutegicos
estrategias de prueba para software convencional
estrategias de prueba para software orientado a objeto
estrategia de prueba para webapps pruebas de validacioacuten y
por uacuteltimo las pruebas del sistema
IIESTRATEGIAS DE PRUEBA DEL SOFTWARE
Verificacioacuten Estamos construyendo el producto
correctamente
Validacioacuten Estamos construyendo el producto correcto
Integracioacuten descendente
La integracioacuten descendente es un planteamiento
incremental a la construccioacuten de la estructura de programas
Se integran los moacutedulos movieacutendose hacia abajo por la
jerarquiacutea de control comenzando por el moacutedulo de control
principal (programa principal) Los moacutedulos subordinados
(de cualquier modo subordinados) al moacutedulo de control
principal se van incorporando en la estructura bien de
forma primero-en-profundidad o bien de forma primero-en-
anchura Fig1
Integracioacuten ascendente
La prueba de la integracioacuten ascendente como su nombre
indica empieza la construccioacuten y la prueba con los
moacutedulos atoacutemicos (es decir moacutedulos de los niveles maacutes
bajos de la estructura del programa) Dado que los moacutedulos
se integran de abajo hacia arriba el proceso requerido de
los moacutedulos subordinados a un nivel dado siempre estaacuten
disponibles y se elimina la necesidad de resguardos Fig2
Fig 1 Integracioacuten descendente
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
20
Fig 3 Integracioacuten Ascendente
Aspectos Estrateacutegicos
Tom Gilb plantea que se deben abordar los
siguientes puntos si se desea implementar con
eacutexito una estrategia de prueba del software
Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
-Establecer los objetivos de la prueba de manera expliacutecita (teacuterminos
medibles)
-Comprender queacute usuarios va a tener el software y desarrollar un perfil
-Desarrollar un plan de prueba que haga hincapieacute en la prueba de ciclo
raacutepido
-Construir un software ―robusto disentildeado para probarse a siacute mismo
-Usar revisiones teacutecnicas formales efectivas como filtro antes de la
prueba
Llevar a cabo revisiones teacutecnicas formales para evaluar la
estrategia de prueba y los propios casos de prueba
Desarrollar un enfoque de mejora continua al proceso de
prueba Deberiacutea medirse la estrategia de prueba
Prueba de Unidad
La prueba de unidad centra el proceso de
verificacioacuten en la menor unidad del disentildeo del
software el moacutedulo La prueba de unidad siempre
esta orientada a caja blanca y este paso se suele
llevar a cabo en paralelo para muacuteltiples moacutedulos
Pruebas de Alfa y Beta
C u a n d o s e c o n s t r u y e s o f t w a r e a m e d i d a s e
l l e v a n a c a b o u n a s e r i e d e p r u e b a s d e
a c e p t a c i oacute n p a r a permitir que el cliente valide todos
los requisitos La prueba alfa se lleva a cabo en el
lugar del desarrollo pero por un cliente Se usa el
software en forma normal con el desarrollador como
observador del usuario y registrando los errores y
problemas de uso(entorno controlado)La prueba beta se
lleva a cabo por los usuarios finales en los lugares
de trabajo de los clientes El cliente registra los
problemas y los informa a intervalos regulare
Pruebas del sistema
La prueba del sistema estaacute constituida por una
serie de pruebas diferentes cuyo propoacutesito es
ejercitar profundamente el sistema
Prueba de recuperacioacuten
E s l a p r u e b a d e l s i s t e m a q u e f u e r z a a l
f a l l o d e l s o f t w a r e d e m u c h a s f o r m a s y
v e r i f i c a q u e l a recuperacioacuten se lleva a cabo
apropiadamente Recuperacioacuten automaacutetica o manual
Prueba de seguridad
Intenta verificar que los mecanismos de proteccioacuten
incorporados en el sistema lo protegeraacute de hecho de
accesos impropios
Pruebas de Resistencia
Estaacuten disentildeadas para enfrentar a los programas con
situaciones anormales Una variante de la prueba de
resistencia es una teacutecnica denominada prueba de
sensibilidad intenta descubrir combinaciones de datos
dentro de una clase de entrada valida que pueda producir
inestabilidad o un proceso incorrecto
El arte de la depuracioacuten
La depuracioacuten ocurre como consecuencia de una
prueba efectiva Cuando un caso de prueba
descubre u n e r r o r l a d e p u r a c i oacute n e s e l
p r o c e s o q u e p r o v o c a l a e l i m i n a c i oacute n d e l
e r r o r E l p r o c e s o m e n t a l q u e conecta un siacutentoma
con una causa es la depuracioacuten
El proceso de la depuracioacuten
E l p r o c e s o d e d e p u r a c i oacute n i n t e n t a h a c e r
c o r r e s p o n d e r e l s iacute n t o m a c o n u n a c a u s a
l l e v a n d o a s iacute a l a correccioacuten del error El proceso de
depuracioacuten siempre tiene uno de los dos resultados
siguientes
(1)se encuentra la causa se corrige y se elimina
o
(2)no se encuentra la causa En eacuteste uacuteltimo caso la persona
que realiza la depuracioacuten debe sospechar la causa disentildear
un caso de prueba que ayude a confirmar sus sospechas y el
trabajo vuelve hacia atraacutes a la correccioacuten del error de una
forma iterativa iquestPor queacute es tan difiacutecil la depuracioacuten
Varias caracteriacutesticas de los errores nos dan algunas
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
21
INGENIERIacuteA DE SISTEMAS
pistas1El siacutentoma y la causa pueden ser
geograacuteficamente remotos entre siacute2El siacutentoma
puede desaparecer (temporalmente) al corregir
otro error
3 E l s iacute n t o m a p u e d e r e a l m e n t e e s t a r
p r o d u c i d o p o r a l g o q u e n o e s u n e r r o r
( i n e x a c t i t u d d e l o s redondeos)
4El siacutentoma puede estar causado por un error
humano que no sea faacutecilmente detectado
5El siacutentoma puede ser el resultado de problemas
de temporizacioacuten en vez de problema s de proceso
6Puede ser difiacutecil reproducir exactamente las
condiciones de entrada
7 E l s iacute n t o m a p u e d e a p a r e c e r e n f o r m a
i n t e r m i t e n t e
8 E l s iacute n t o m a p u e d e s e r d e b i d o a c a u s a s q u e
s e d i s t r i b u y e n p o r u n a s e r i e d e t a r e a s
e j e c u t aacute n d o s e e n diferentes procesadores
IIICONCLUCIONES
Las estrategias de prueba del software es un mecanismo
que proporciona una guiacutea o base pasa ver la forma como se
debe desarrollar la aplicacioacuten en cuanto a meacutetodos para
logra un producto exitoso
IVREFERENCIAS
httpbuenastareascomensayosEstategias-de-prueba-de-
software3752643html
httpwwwestrategiascompruebaagil
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
22
Ingenieriacutea Inversa Juan Carlos Zenteno Sanga
1
Departamento de Ingenieriacutea de Sistemas Universidad San Francisco de Asiacutes
Direccioacuten Incluyendo el Paiacutes 1juanka_58hotmailcom
Resumenmdash La ingenieriacutea de Software es parte del modelo de
proceso de reingenieriacutea de software es el proceso de analizar
un programa con la finalidad de crear una representacioacuten del
programa en un grado mayor de abstraccioacuten del coacutedigo
fuente las herramientas de ingenieriacutea inversa obtienen
informacioacuten del disentildeo de datos arquitectoacutenico y de
procedimientos a partir de un programa existente
En el siguiente artiacuteculo se veraacuten los conceptos baacutesicos y se
denotara un ejemplo praacutectico para una mayor comprensioacuten
del tema
Palabras clave mdash Ingenieriacutea de Software Reingenieriacutea
Linux Ingenieriacutea Inversa
XI INTRODUCCIOacuteN
Inmersa en el aacuterea de conocimiento de la
ingenieriacutea de software se encuentra la ingenieriacutea
inversa como punto de apoyo para los procesos
de anaacutelisis y disentildeo propuestos en diferentes
meacutetodos de desarrollo
La ingenieriacutea inversa permite subsanar esta
deficiencia al documentar los productos de
software a partir del coacutedigo ejecutable con el fin
de obtener los artefactos de anaacutelisis y disentildeo
La ingenieriacutea inversa es ademaacutes una
herramienta uacutetil que ayuda en el proceso de
aseguramiento de la calidad del software
mediante la comparacioacuten de diagramas de fases
de anaacutelisis y desarrollo se apoya comuacutenmente en
la generacioacuten del diagrama de clases debido a la
importancia de este diagrama en la fase de disentildeo
y su facilidad de generacioacuten Existen tambieacuten
otros diagramas de intereacutes como el de
comunicacioacuten y el de secuencias que modelan
las caracteriacutesticas dinaacutemicas de un producto de
software
Hoy en diacutea los productos maacutes comuacutenmente
sometidos a la Ingenieriacutea Inversa son los
productos de Hardware y Software pero
cualquier producto puede ser sometido a este
proceso
Aplicar ingenieriacutea Inversa a algo supone
profundizar el estudio de su funcionamiento
En el caso concreto del Software se conoce
por ingenieriacutea de software a la actividad que se
ocupa de describir coacutemo funciona un programa
de cuyo coacutedigo no se dispone hasta el punto de
generar coacutedigo propio que cumpla con las
mismas funciones Un ejemplo claacutesico del uso de
esta teacutecnica es el software de pago donde las
empresas utilizan esta teacutecnica para proteger sus
productos contra posibles acceso no autorizados
o examinar el producto final para encontrar
posibles bugs inesperados en la ejecucioacuten de
dicho sistema
Existe una gran variedad de software
desensamblador y depurador para aplicar esta
teacutecnica
En resumen la idea general al aplicar
ingenieriacutea inversa es
Conocer a fondo la aplicacioacuten y generar un
mejor coacutedigo
Migrar la aplicacioacuten a un nuevo sistema operativo
Hacer o completar la documentacioacuten
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
23
INGENIERIacuteA DE SISTEMAS
Verificar que el coacutedigo en estudio cumple las
especificaciones del disentildeo estaacutendar
La informacioacuten extraiacuteda de la lectura del
coacutedigo fuente son las especificaciones de disentildeo
modelos de flujo de control diagramas de disentildeo
documentos de especificacioacuten de disentildeo
pudiendo tomarse estas especificaciones como
nuevo punto de partida para aplicar ingenieriacutea
inversa y obtener informacioacuten a mayor nivel de
abstraccioacuten
Dado que es una labor estrateacutegica es
conveniente conocer cuando conviene realizar la
tarea de Ingenieriacutea inversa para una aplicacioacuten y
cuaacutendo es maacutes rentable sustituirla e implementar
una nueva Las aplicaciones para el primer paso
son aquellas en la que se produce las siguientes
situaciones
bull Fallos frecuentes que son difiacuteciles de
localizar
bull Son poco eficientes pero realizan la funcioacuten
esperada
bull Dificultades en la integracioacuten con otros
sistemas
bull Calidad pobre del software final
bull Resistencia a introducir cambios
bull Pocas personas capacitadas para realizar
modificaciones
bull Dificultades para realizar pruebas
bull El mantenimiento consume muchos recursos
XII LAS BASES DE LA INGENIERIA INVERSA
Los ejemplos maacutes trascendentes sobre los
inicios de la ingenieriacutea inversa son claramente las
investigaciones realizadas sobre antiguos
artefactos creados por humanos ancestrales con
el fin de descubrir la manera en que funcionaban
Uno de los maacutes conocidos es el llamado
mecanismo de Antikythera (Fig 1) el cual se
piensa que fue disentildeado para fines astronoacutemicos
por los griegos siendo uno de los primeros
artefactos que funcionaban con ruedas de
engranes
Figura 1 Antikythera (mecanismo presuntamente creado para fines astronoacutemicos)
Podemos entonces implantar un paralelo en aquella
mitoloacutegica buacutesqueda de descubrimiento sobre el
funcionamiento de esos artefactos y la ingenieriacutea inversa
actual usada en ingenieriacutea de software estableciendo un
importante factor en comuacuten la falta de documentacioacuten En
este ambiente es muy comuacuten contar con una especie de caja
negra en donde sabemos lo que ingresamos y el resultado
que obtenemos pero desconocemos el procedimiento con la
precisioacuten que necesitariacuteamos para replicarlo
Esta falta de documentacioacuten es el impulso
principal de toda la ingenieriacutea inversa las
finalidades de la misma pueden variar pero este
factor inicial nunca lo haraacute
XIII INGENIERIA INVERSA COMO UN PROCESO DE
REINGENIERIA
La ingenieriacutea inversa tiene la misioacuten de
desentrantildear los misterios y secretos de los
sistemas en uso
Baacutesicamente recupera el disentildeo de la
aplicacioacuten a partir del coacutedigo esto se realiza
mediante herramientas que extraen la
informacioacuten de los datos procedimientos y
arquitecturas del sistema
Es aplicable a sistemas con las siguientes
caracteriacutesticas
Documentacioacuten inexistente o totalmente obsoleta
Programacioacuten en bloque de coacutedigos muy grandes
yo sin estructural
La aplicacioacuten cubre gran parte de los requisitos
y el rendimiento esperado
A Nivel de abstraccioacuten
El nivel de Abstraccioacuten de un proceso de
Ingenieriacutea Inversa y las herramientas que se
utilizan para realizarlo aluden la sofisticacioacuten de
la informacioacuten de disentildeo que se puede extraer del
coacutedigo fuente Este proceso deberiacutea ser capaz de
derivar
Sus representaciones de disentildeo de procedimiento
(con un bajo nivel de abstraccioacuten)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
24
La informacioacuten de las estructuras de datos de
procedimiento (con un nivel de abstraccioacuten
ligeramente maacutes elevado)
Modelos de flujo de datos de control (un nivel de
abstraccioacuten relativamente alto)
Modelos de entidades y de relaciones (un elevado
nivel de abstraccioacuten)
B Completitud
En la mayoriacutea de los casos la completitud
decrece a medida que aumenta el grado de
abstraccioacuten
La completitud mejora en proporcioacuten directa a
la cantidad de anaacutelisis efectuado por la persona
que estaacute efectuando la ingenieriacutea inversa
C Interactividad
La interactividad alude al grado con el cual el
ser humano se integra con las herramientas
automatizadas para crear un proceso de
ingenieriacutea inversa efectivo
D Proceso
El Proceso de ingenieriacutea inversa (Fig 2) es el encargado
de reestructurar el coacutedigo fuente para que solamente
contenga instrucciones de programacioacuten estructurada Lo
que hace que el coacutedigo sea maacutes faacutecil de leer y proporciona
la base para las subsiguientes actividades de ingenieriacutea
inversa
Figura 2 Diagrama de Proceso de la Ingenieriacutea Inversa
E Reestructuracioacuten
La reestructuracioacuten del software modifica el
coacutedigo fuente y los datos en un intento adecuado
a futuros cambios esta no modifica la
arquitectura global del programa Tiene a
centrarse en los detalles de disentildeo de moacutedulos
individuales y en estructuras de datos locales
definidas dentro de los moacutedulos
Estos son algunos de los beneficios que se
pueden lograr cuando se reestructura el software
Programas de mayor calidad
Reduce el esfuerzo requerido para llevar a cabo
las actividades de mantenimiento
Hace el software maacutes sencillo para comprobar y
depurar
F Re documentacioacuten
Es el proceso mediante el cual se produce
documentacioacuten retroactivamente desde un
sistema existente
Es considerada una forma de ingenieriacutea inversa
porque la documentacioacuten reconstruida es usada
para ayudar al conocimiento del programa
XIV UTILIZANDO EL METODO CIENTIFICO EN LA
INGENIERIA INVERSA
Ante cualquier dificultad tecnoloacutegica el
meacutetodo cientiacutefico siempre es y seraacute nuestra maacutes
preciada arma Partamos imaginando un pequentildeo
dilema relacionado con el tema de ingenieriacutea de
software especiacuteficamente con un sencillo
programa (Fig 3)
Figura 3 Pantalla de aplicacioacuten que nos serviraacute de ejemplo
Esta sencilla aplicacioacuten mostraraacute un mensaje con cierto
resultado y aun siendo un problema demasiado sencillo
para considerarlo como un reto el objetivo es soacutelo describir
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
25
INGENIERIacuteA DE SISTEMAS
las acciones usuales del proceso las cuales son aplicables
en escalas muy superiores
El resultado mostrado por el programa dentro del mensaje
emergente se basa en nuestra entrada pero nosotros
desconocemos en lo absoluto los procedimientos utilizados
sobre esta entrada para producir aquella respuesta
A La Observacioacuten es Trascendental
Primero es importante observar el problema su
comportamiento Es substancial tratar de lograr
un pensamiento inductivo en donde logremos
identificar el principio particular del problema
para poder llegar a extrapolarlo a una solucioacuten
general
El punto de quiebre se produce en este instante
Ya al haber observado la aplicacioacuten podriacuteamos
decidir procesar los datos que nos entrega y
lograr crear un coacutedigo equivalente o investigar el
funcionamiento interno
B Dentro de la aplicacioacuten
Luego de la formulacioacuten de una hipoacutetesis sobre
su funcionamiento necesitamos algunas
herramientas para comenzar con la investigacioacuten
En el caso de esta aplicacioacuten con un poco de
conocimientos del lenguaje ensamblador de
programacioacuten tradicional y un descompilador es
suficiente
Es importante emprender de buena forma
nuestro sondeo ser ordenados y metoacutedicos en la
tarea En este momento las capacidades analiacuteticas
y loacutegicas son muy importantes para alivianar
nuestra faena
Lo fundamental es conocer muy bien el
entorno en que nos desenvolveremos En este es
punto indispensable saber que una aplicacioacuten
para Windows necesita invocar internamente al
punto de entrada MessageBox o MessageBoxEx
de la libreriacutea de sistema user32dll para poder
desplegar un mensaje (Fig 4)
Figura 4 Resultado de la Aplicacioacuten
Ya con esa pista es sencillo encontrar el
fragmento de coacutedigo relacionado con las
operaciones relacionadas a nuestro nuacutemero de
entrada que tendriacutea una forma similar a la
mostrada a continuacioacuten en nuestro
descompilador (Fig 5)
Figura 5 Vista del Programa en Ensamblador
Cualquier programador intuiriacutea faacutecilmente lo
que hacen las liacuteneas superiores de esta aplicacioacuten
en especial sprintf es parte de la libreriacutea estaacutendar
de C++ Claramente vemos tambieacuten el tiacutetulo de la
ventana en el coacutedigo estos valores son
interpretados de forma inteligente por este
descompilador en especial y en particular nos
asiste de sobremanera a comprender el coacutedigo
Lo siguiente es sencillamente explorar paso a
paso las acciones superiores de caacutelculo del
resultado En esta instancia seraacute ideal realizar
numerosas pruebas para estar completamente
seguros de que logramos develar el secreto tras la
funcionalidad objetivo (Fig 6)
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
26
Figura 6 Inicio del coacutedigo al que aplicaremos ingenieriacutea inversa
Hay que detenerse algunos segundos a
individualizar algunos procedimientos del
anaacutelisis que a simple vista pueden parecer
inconcebibles con el fin de poder generar una
tesis concluyente
Cabe destacar que se omitiraacuten pasos
intermedios de asignaciones de memoria y otros
formalismos propios de ensamblador para
favorecer el entendimiento del lector
Inicialmente tenemos el valor de entrada
supuestamente ya leiacutedo desde el cuadro de
diaacutelogo del programa ahora nos enfocamos en la
primera accioacuten importante Asumiremos el valor
de entrada como una incoacutegnita
En el siguiente trozo de coacutedigo la liacutenea
destacada antildeadioacute siete a nuestra incoacutegnita (Fig 7)
Figura 7 Coacutedigo donde se denota la adicioacuten de 7 a nuestra ecuacioacuten
A continuacioacuten se multiplica ese valor
resultante de la suma por el mismo (Fig 8)
Figura 8 Coacutedigo donde se denota la multiplicacioacuten del valor por la suma
Nuevamente multiplicamos el resultado por el
anterior proporcionado tras la suma En esta
segunda vez ya podemos expresar la operacioacuten
simplemente elevando al cubo la suma anterior
(Fig 9)
Figura 9 Coacutedigo que denota una nueva multiplicacioacuten del resultante
Ahora le restamos diez al resultado
El procedimiento que viene a continuacioacuten
propone un mayor desafiacuteo intelectual Un nuacutemero
constante en este caso el cargado al registro
EAX (Fig 10)
Figura 10 ubicacioacuten del nuacutemero constante EAX
Generalmente la divisioacuten es algo maacutes costosa
en tiempo de procesador que otras operaciones
por lo que ciertos compiladores incluyen tablas
de constantes las cuales son llamadas ―nuacutemeros
maacutegicos para la divisioacuten entera
d Con signo Sin signo
m (hex) s m (hex) a s
-5 99999999 1
-3 55555555 1
-2k 7FFFFFFF k-
1
1 mdash mdash 0 1 0
2k 80000001 k-
1 232-k 0 0
3 55555556 0 AAAAAAAB 0 1
5 66666667 1 CCCCCCCD 0 2
6 2AAAAAAB 0 AAAAAAAB 0 2
7 92492493 2 24924925 1 3
9 38E38E39 1 38E38E39 0 1
10 66666667 2 CCCCCCCD 0 3
11 2E8BA2E9 1 BA2E8BA3 0 3
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
27
INGENIERIacuteA DE SISTEMAS
12 2AAAAAAB 1 AAAAAAAB 0 3
25 51EB851F 3 51EB851F 0 3
125 10624DD3 3 10624DD3 0 3
Tabla 1 Algunos nuacutemeros maacutegicos (32 bits)
Ahora bien conociendo la tabla 1 sabiendo
que el nuacutemero cargado en esta ocasioacuten
corresponde al once lo que hace el coacutedigo es
multiplicar el resultado de la salida temporal por
aquel nuacutemero (Fig 11)
Figura 11 Multiplicacioacuten del resultante por el numero 11
Naturalmente la multiplicacioacuten por un nuacutemero
tan grande produce una especie de
desbordamiento en el registro contenedor del
resultado al exceder el tamantildeo de palabra del
procesador (en este caso de 32 bits) Estos bits
sobrantes se almacenan naturalmente en el
registro EDX registro que es contiguo a ECX
dentro de la memoria de los registros del
procesador
Ahora desplazamos un bit del registro EDX
(equivalente a una divisioacuten entera por dos) para
obtener la solucioacuten de la divisioacuten por once
generando una sencilla ecuacioacuten
Figura 12 Desplazamiento del bit de registro EDX
El uacuteltimo paso luego de documentar estos
resultados seraacute crear una aplicacioacuten que recree
esta foacutermula soacutelo en caso de tener intenciones de
re-codificacioacuten del desarrollo Consumando este
punto es sencillo confeccionar un diagrama con
todo el proceso anteriormente visto
XV CONCLUSIONES
Queda claro que el tema de la ingenieriacutea
inversa es uno de los toacutepicos maacutes interesantes a
los que podriacutea afrontarse un profesional de la
tecnologiacutea y en general disfrutar el largo proceso
involucrado gracias al desafiacuteo poco predecible
que presenta
En general podemos darnos cuenta de que no
existen muchas metodologiacuteas y teoriacuteas estrictas
sobre coacutemo aplicar las teacutecnicas de ingenieriacutea
inversa Afortunadamente un ingeniero estaacute
preparado para afrentar desafiacuteos de este tipo
Adicionalmente podemos deducir tambieacuten el
aspecto bidireccional de la ingenieriacutea inversa
pues como ya lo comprobamos no solo es un
desafiacuteo aplicarla sino que tambieacuten lo es tener que
dificultar el proceso o incluso tratar de impedirlo
si la situacioacuten lo requiere
REFERENCIAS
[12] Roger Pressman Ingenieriacutea de Software ―Un Enfoque Moderno 6th ed
MC Graw Hill [13] httpeswikipediaorgwikiIngenieria_inversa
[14] httpwwwinfosecwritersconntext_resourcespdfsoftware_security_and_r
everse_engineeringpdf [15] httperwinriedclmodo=visorampelemento=239
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
28
METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO Univ Alejandro Meacutendez Escobar
Universidad San Francisco de Asiacutes
Ingenieriacutea de Sistemas
Ingenieriacutea de Software I
La Paz - Bolivia
amendezusfaedubo
Resumenmdash Al adquirir el software educativo dentro del campo de
desarrollo de software una gran importancia y siendo este
inspiracioacuten de propuestas de innumerables metodologiacuteas que buscan
la elaboracioacuten de un software de calidad
Tomaremos la metodologiacutea Aacutencora enfocada a la fase de
requerimientos y que ofrece elementos que indican las actividades
que deben realizarse los artefactos que se producen y la forma de
obtenerlos
Usando al desarrollo de software educativo como ejemplo de una
mejor comprensioacuten de dicha metodologiacutea analizando la aplicacioacuten
del Aacutencora en un trabajo propuesto para el Instituto Tecnoloacutegico de
Orizaba Meacutexico
Palabras clave mdash Aacutencora Metodologiacutea Desarrollo de Software
Educativo Requerimientos Calidad
XVI INTRODUCCIOacuteN
Hoy en diacutea la tecnologiacutea esta dentro de las
actividades que realizamos es asiacute que la educacioacuten no
queda exenta de ella por o cual es necesario adaptarse
al movimiento tecnoloacutegico que nos trae grandes
ventajas en la transmisioacuten de conocimientos de una
manera sencilla y dinaacutemica
De esta manera han surgido infinidad de
metodologiacuteas de desarrollo de software educativo el
cual tiene como objetivo ser el apoyo para docentes
alumnos y toda persona que este dentro del proceso de
aprendizaje
Tomando en cuenta este ramillete infinito de
metodologiacuteas surge en el ejemplo propuesto la
adaptacioacuten del Aacutencora en el desarrollo de software
educativo teniendo como objetivo principal la
comprensioacuten de los elementos y conceptos de la
metodologiacutea Aacutencora
Aacutencora es una metodologiacutea enfocada a la
adquisicioacuten de requerimientos para software que
ofrece guiacuteas y elementos de apoyo para la obtencioacuten de
estos requerimientos Al mismo tiempo permite pasar a
la fase de disentildeo de manera sencilla Aprovechando las
ventajas que presenta Aacutencora se le hicieron algunas
adaptaciones con el fin de cubrir algunas
caracteriacutesticas del disentildeo instruccional y enriquecer
Aacutencora habilitaacutendola para la adquisicioacuten de
requerimientos de software educativo
XVII APLICACIOacuteN DE LA METODOLOGIacuteA AacuteNCORA
Como es el objetivo principal la comprensioacuten de la
aplicacioacuten de la metodologiacutea Aacutencora dentro del
desarrollo de software educativo de calidad solo
describiremos los meacutetodos del meacutetodo y los resultados
obtenidos
Claro esta que para ahondar maacutes en tema del
software educativo en si el lector puede recurrir a los
siguientes autores Metodologiacutea de desarrollo de
sistemas multimedia (Vaughan 2006) Propuesta de
metodologiacutea para el disentildeo desarrollo y evaluacioacuten
de software educativo (Reyes 2009) Ingenieriacutea de
software educativo con modelaje orientado por objetos
(Goacutemez 1998) asi como tambieacuten los siguientes
modelos ADDIE (Anaacutelisis Disentildeo Desarrollo
Implantacioacuten y Evaluacioacuten) de (McGriff 2000) y el
disentildeo instruccional aplicado al desarrollo de software
educativo EISE (Especificacioacuten Instruccional de
Software Educativo) de (Hernaacutendez 2005)
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
29
INGENIERIacuteA DE SISTEMAS
Quienes tienen el mismo objetivo de crear software
educativo de calidad podemos sintetizar de ellos los
siguientes puntos
Anaacutelisis del puacuteblico al que se dirigiraacute el software
Problema oacute necesidad educativa a atender
Anaacutelisis de contenido (Tema a tratar actividades
para alcanzar el objetivo de ensentildeanza y forma de
evaluarlo)
Actividades oacute forma actual de llevar a cabo la
ensentildeanza del tema en cuestioacuten
Elaboracioacuten de guiones metaacuteforas escenarios
Creacioacuten de prototipo oacute Storyboard
Disentildeo de interfaz
Mapas de navegacioacuten
Modelos de datos
Elaboracioacuten de diagramas de contexto diagramas
de flujo o diagramas de casos de uso
Ahora enfocaacutendonos en el aacutencora se establece la
propuesta de seleccionar las actividades de Aacutencora que
permitan obtener los requerimientos de un software
educativo
La Tabla 1 presenta las actividades y artefactos
producidos en las fases de Aacutencora para la elaboracioacuten
de software educativo
TABLA 1 ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGIacuteA AacuteNCORA PARA EL
DESARROLLO DE SOFTWARE EDUCATIVO
Metodologiacutea Aacutencora
Fases Actividades y artefactos
Anaacutelisis de
Requerimientos
A traveacutes de entrevistas con los clientes
(maestros y pedagogos) y de la lectura
del respectivo material proporcionado
por ellos se definiraacute la asignatura a la
que se enfocaraacute el software el tema a
tratar y la forma en que se abordaraacute y
evaluaraacute Tambieacuten se estableceraacute el
objetivo general de aprendizaje la
metaacutefora que se emplearaacute y se
determinaraacute el puacuteblico al que se
dirigiraacute el software
Artefactos
Documento que define la asignatura
contenido objetivo general de
aprendizaje metaacutefora y puacuteblico al que
se dirigiraacute el software Guion de la
situacioacuten actual
Recoleccioacuten y
clasificacioacuten de
requerimientos
El guion de la propuesta
computacional reflejaraacute la metaacutefora
que se sigue el ambiente de cada
escena
La bitaacutecora de desarrollo permitiraacute ver
coacutemo el sistema responderaacute a las
diversas acciones que realice el
usuario
En lugar del prototipo raacutepido se
elaboraraacute un Storyboard para presentar
graacuteficamente la estructura de sistema
propuesto
Artefactos
Guion de propuesta computacional
bitaacutecora de desarrollo Storyboard
Resolucioacuten de
conflictos
jerarquizacioacuten y
validacioacuten de
requerimientos
Modificaciones al guion de la
propuesta computacional de acuerdo a
los cambios propuestos por los
maestros y pedagogos
Artefactos
Guion de propuesta computacional e
Storyboard con adecuaciones sentildealas
Cierre
Trasladar los guiones a casos de uso
Artefactos
Casos de uso
Se agregaron algunas caracteriacutesticas a ciertos
artefactos de Aacutencora para poder cubrir los
requerimientos de software educativo Uno de estos
elementos es el guion de la propuesta computacional
al que se propone agregar lo siguiente
Conocimientos previos del usuario Se refiere a los
conocimientos baacutesicos o miacutenimos que debe tener el
alumno para poder interactuar con el moacutedulo
Objetivo de aprendizaje Es el aprendizaje que
debe obtener el alumno despueacutes de haber interactuado
con el moacutedulo
La Figura 1 se presenta la estructura sugerida para el
guion de la propuesta computacional En la bitaacutecora de
desarrollo se propone antildeadir una fila al final de cada
pista donde se describan las situaciones favorables y
no favorables para el cumplimiento del objetivo de
aprendizaje para esa pista en particular Por otra parte
en lugar del prototipo se sugiere utilizar el Storyboard
ya que permite mostrar de manera maacutes completa la
estructura del guion de la propuesta computacional La
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
30
Figura 2 muestra el formato para la elaboracioacuten del
Storyboard
Figura 1 Estructura del guion para la propuesta computacional
Figura 2 Formato para la elaboracioacuten del Storyboard
XVIII RESULTADOS
Aplicando Aacutencora en un ejemplo para la parte de
requerimientos se obtuvo la siguiente informacioacuten
Asignatura Matemaacuteticas
Contenido Estaacute articulado con base en seis ejes
con sus respectivos temas y subtemas que variacutean de
acuerdo al grado escolar Considerando lo anterior se
tiene lo siguiente
a) Grado escolar De segundo hasta quinto grado de
primaria
b) Temas Nuacutemeros naturales capacidad peso
tiempo y ubicacioacuten espacial planteamiento y
resolucioacuten de problemas sencillos en los que se
requiera recolectar y registrar informacioacuten
perioacutedicamente representacioacuten de informacioacuten en
tablas de frecuencia y graacuteficas de barras registros de
los resultados de experimentos aleatorios
representacioacuten de los resultados de un experimento
aleatorio en tablas y graacuteficas
c) Subtemas Planteamiento y resolucioacuten de
problemas que impliquen dos o maacutes operaciones con
nuacutemeros naturales
d) Ejes Introduccioacuten del kiloacutemetro como la unidad
que permite medir grandes distancias y recorridos
largos capacidad peso y tiempo uso del reloj y el
calendario los nuacutemeros sus relaciones y sus
operaciones medicioacuten la prediccioacuten y el azar
tratamiento de la informacioacuten
Objetivo general de aprendizaje Ejercitar las
operaciones aritmeacuteticas baacutesicas interpretar la
informacioacuten y los resultados de la informacioacuten dada
aplicada en situaciones de la vida cotidiana
Con las actividades hasta ahora realizadas se ha
observado que los artefactos de Aacutencora son flexibles y
pueden por lo tanto adaptarse de acuerdo a las
necesidades que implican la adquisicioacuten de
requerimientos de un software educativo Tambieacuten se
aprecian las ventajas de algunos artefactos como la
bitaacutecora de desarrollo que permite determinar las
respuestas del sistema ante las acciones del usuario y
estimar tambieacuten el tiempo que llevaraacute implementar
cada quinteta
La estimacioacuten del tiempo ayuda a tener un valor
aproximado del tiempo de desarrollo de software
Agregar el objetivo de aprendizaje a la bitaacutecora de
desarrollo puede parecer repetitivo despueacutes de
incluirlo en el Storyboard pero esto nos permite ver las
situaciones u obstaacuteculos que pueden impedir que el
objetivo de aprendizaje se alcance y por tanto tenerlos
presente durante el disentildeo A pesar de las ventajas de
la bitaacutecora de desarrollo un inconveniente hasta ahora
encontrado es lo tedioso al manejar muchas quintetas
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
31
INGENIERIacuteA DE SISTEMAS
cuando por la naturaleza del guion se tienen varios
avisos y mensajes para el usuario Por otra parte los
guiones han ayudado a realizar de manera sencilla el
modelo de casos de uso
En lo referente a la presentacioacuten con los clientes el
guion es un artefacto que pude dar un panorama
general del software que se va a elaborar y queda
reforzada a traveacutes de los Storyboard Cuando se
requieren cambios solicitados por los clientes las
modificaciones a estos artefactos no han sido muy
complicadas dado que por su estructura es faacutecil de
ubicar las secciones y respectivos elementos
XIX CONCLUSIONES
Con los resultados hasta ahora obtenidos se puede
decir que la propuesta permite a los desarrolladores
con poca experiencia en desarrollo de software
educativo obtener los requerimientos de una manera
sencilla
Permite realizar un mejor relevamiento de informacioacuten
de los requerimientos del cliente enfocaacutendonos mas en
este
Es tambieacuten importante mencionar los avances que
tiene y seguiraacute teniendo el software educativo aplicado
no solo a nivel escolar sino tambieacuten al superior
Habiendo revisado el concepto y la aplicacioacuten de la
metodologiacutea Aacutencora en el desarrollo de software
educativo se llegoacute a una comprensioacuten mas extensa de
dicho meacutetodo el cual es de gran importancia dentro de
la ingenieriacutea de Software ya que nos
REFERENCIAS
httpwwwuvmxmisproductividaddocumentsCarmenChay_CIIM2010pdf
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
32
Redes Bayesianas en la
Ingenieriacutea del Software Luis Miguel Ticona
1
Universidad San Francisco de Asiacutes Av 20 de Octubre esq Belisario Salinas (Plaza Avaroa)
La Paz - Bolivia 1lticonacopyusfaedubo
Resumen - Recientemente modelos graacuteficos que combinan la
probabilidad y la teoriacutea de grafos estaacuten siendo aplicados a
problemas de la ingenieriacutea del software donde la incertidumbre
estaacute presente En el presente artiacuteculo veremos de manera general
sobre las redes bayesianas sus fundamentos en la teoriacutea de la
probabilidad y ademaacutes se describiraacute diferentes extensiones de las
redes bayesianas asiacute como su aplicacioacuten a la ingenieriacutea del
software y teacutecnicas de mineriacutea de datos
Palabras clave- redes bayesianas graacuteficos aciacuteclicos nodos
grafo probabilidades inferencia discretizacioacuten dominio
I Introduccioacuten
Las redes bayesianas son graacuteficos aciacuteclicos dirigidos que
los nodos representan variables y los arcos que los unen
codifican dependencias condicionales entre las variables
Los nodos pueden representar cualquier tipo de variable ya
sea un paraacutemetro medible (o medido) una variable latente
o una hipoacutetesis Existen algoritmos que realizan inferencias
y aprendizaje basados en redes bayesianas
A modo de ejemplo la red Bayesiana de la Figura 1
representa un modelo simplificado de estimacioacuten de errores
en la ingenieriacutea del software Cada nodo del grafo
representa una variable del dominio defectos insertados
detectados y residuales (nuacutemero de defectos que
permanecen en el coacutedigo una vez entregado al
cliente)Cada arco del grafo representa una relacioacuten causal
entre variables los defectos insertados influyen en el
nuacutemero de defectos detectados durante el testeo y el
nuacutemero de defectos residuales a su vez el nuacutemero defectos
influye en el nuacutemero de defectos residuales En este caso
cada variable puede tomar solamente dos valores bajo o
alto Las relaciones entre variables son caracterizadas por
medio de las tablas de probabilidad tambieacuten mostradas en
la Figura 1
Fig 1 Red Bayesiana simplificada para la estimacioacuten de defectos
Una vez que se tienen evidencias el estado de ciertas
variables es decir cuando tenemos conocimiento o
podemos observar su estado se actualizan las tablas de
probabilidad propagando las nuevas probabilidades
Fig 2 Modo de ejecucioacuten sin evidencias introducidas
En general los programas para manipular redes Bayesianas
tienen dos modos de operar un modo de edicioacuten que
permite la creacioacuten de redes y la especificacioacuten de tablas de
probabilidad como muestra la figura 1 Y un modo de
consulta (ver Figuras 2 y 3) donde se introducen las
evidencias y se propagan las nuevas probabilidades En el
caso de la Figura 2 muestra las probabilidades de cada
variable sin evidencias introducidas En este caso las
probabilidades estaacuten distribuidas uniformente y no se
puede decir mucho del estado del dominio
Fig 3 Modo de ejecucioacuten con evidencias introducidas
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
33
INGENIERIacuteA DE SISTEMAS
Sin embargo si tenemos la certeza (100 de probabilidad) de
que el nuacutemero de defectos insertados es bajo y de que un alto
nuacutemero de defectos fueron detectados durante el testeo la red
Bayesiana propaga las probabilidades estimando que el
nuacutemero de defectos residuales seraacute bajo con una probabilidad
de 08 y alto con una probabilidad de 02 La figura 3 muestra
dicho escenario las barras que marcan un 100 indican
variables con estado conocido el resto muestran las nuevas
probabilidades despueacutes de propagar las evidencias Noacutetese que
la salida es una distribucioacuten de probabilidades en vez de un
uacutenico valor Naturalmente consideraremos el valor con mayor
probabilidad como valor estimado
II Fundamentos de las redes Bayesianas
Formalmente una red Bayesiana es un grafo dirigido
aciacuteclico Los nodos representan variables aleatorias del
dominio X1 X2hellip Xn y los arcos representan relaciones de
dependencia entre variables Las redes Bayesianas asumen
que un nodo depende solamente de sus padres y que cada
nodo estaacute asociado a una tabla de probabilidades
condicionales que definen la probabilidad de cada estado
en los que puede estar una variable dados los posibles
estados de sus padres Una red Bayesiana se muestra la
probabilidad de distribucioacuten conjunta para un conjunto de
X1 X2hellip Xn tal que
P(x1 x2 hellipxn ) = prod i=1hellipn P (xi | padres (X))
Donde xi representa el valor que toma la variable X y
padres (X) denota los valores que tienen el conjunto de los
padres en la red Bayesiana del nodo X Por tanto cada
estado de una variable puede ser calculado multiplicando
un nuacutemero reducido de valores en las tablas de
probabilidad
III Tipos de Evidencia
Hay dos tipos de evidencia
- Evidencia firme o especiacutefica (instanciacioacuten)se da cuando
se asigna un valor concreto a una variable
- Evidencia parcial o virtual de un nodo permite actualizar
las probabilidades a priori de los estados que puede tomar
la variable
IV Variables Continuas
Las redes Bayesianas permiten usar variables continuas sin
embargo al haber un nuacutemero infinito de estados el
problema reside en la especificacioacuten de las tablas de
probabilidad condicional Hay dos formas de contrarrestar
estos problemas
La discretizacioacuten consiste en dividir el rango de las
variables continuas en un nuacutemero finito en un dominio a
modelar puede tomar cualquier valor entre 0 y 100 es
posible dividir el rango en un nuacutemero finito de intervalos
(0 - 20) (20 - 40) y (40 ndash 100) Naturalmente al discretizar
se pierde informacioacuten que depende del dominio y el
nuacutemero de intervalos Es el meacutetodo maacutes comuacuten ya que la
mayoriacutea de las herramientas y algoritmos se basan en
nodos discretos
El segundo meacutetodo consiste en usar modelos parameacutetricos
como la distribucioacuten Gausiana que es representada por dos
paraacutemetros la media y la varianza
V Inferencia en Redes Bayesianas
Proporciona un sistema de inferencia donde una vez
encontradas nuevas evidencias sobre el estado de ciertos
nodos se modifican sus tablas de probabilidad y a su vez
las nuevas probabilidades son propagadas al resto de los
nodos a esto se lo denomina inferencia probabiliacutestica es
decir que algunas variables pueden ser calculadas dadas la
evidencias de otras variables
Los algoritmos de propagacioacuten exactos maacutes simples
incluyen Inferencia mediante Enumeracioacuten y Eliminacioacuten
de variables (Russel y Norvihg 2003) Los algoritmos de
propagacioacuten exacta funcionan bien con redes de hasta
aproximadamente 30 nodos sin embargo no son
apropiados para redes con maacutes nodos o altamente conexas
Para estos casos se han desarrollado algoritmos
aproximados
Los meacutetodos aproximados se clasifican en meacutetodos de
simulacioacuten estocaacutestica y los meacutetodos de buacutesqueda
determiniacutestica
VI Mineriacutea de Datos
Sin embargo a menudo se tienen base de datos del dominio
(en la ingenieriacutea del software por ejemplo histoacutericos de
proyectos) para automatizar en cierta medida la creacioacuten
de redes Bayesianas siguiendo los pasos tiacutepicos de la
mineriacutea de datos que son los siguientes
Preparacioacuten de los datos Los son formateados de forma
que las herramientas puedan manipularlos juntar diferentes
bases de datos etc
Seleccioacuten y limpieza de los datos Este paso consiste en la
seleccioacuten de variables discretizar los datos decidir sobre
valores anoacutemalos ruido etc
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
34
Mineriacutea de datos En este paso se produce la extraccioacuten del
conocimiento donde se aplican los algoritmos El proceso
de mineriacutea de datos estaacute compuesto de dos tareas
principales
- Introduccioacuten del mejor modelo cualitativo partiendo de los
datos yo conocimiento previo de los expertos del dominio
- Estimacioacuten de las tablas de probabilidades se definen las
tablas de probabilidad siendo el meacutetodo maacutes sencillo
Interpretacioacuten de los resultados en el caso de las redes
bayesianas consistiraacute en realizar inferencias basaacutendose en
las evidencias obtenidas
Asimilacioacuten y explotacioacuten de los resultados
En la figura 4 muestra los pasos indicando que el experto
de dominio necesita complementar los algoritmos de
mineriacutea de datos
Fig 4 Pasos tiacutepicos en la construccioacuten de redes Bayesianas partiendo de
base de datos
Como ejemplo de la creacioacuten de redes Bayesianas en la
ingenieriacutea del software imaginemos que una compantildeiacutea con
una base de datos de proyectos con los atributos definidos
en la Tabla 1 y un sub conjunto de los datos podriacutea ser
como los que se muestra Tabla 1 Ejemplo de atributos de una base de datos de proyectos
Vari
able
Descripcioacuten Tipo
Com
pleji
dad
Tipo de
proyecto(orgaacute
nico mediano
y complejo)
Discreta
Tam
antildeo
No de liacuteneas
de coacutedigo(en
miles)
Continu
a
Esfu
erzo
Horas Continu
a
Dura
cioacuten
No de meses Continu
a
Pers
onal
No de
personas a
tiempo
completo
requeridas
para llevar a
cabo el
proyecto
Continu
a
Dise
ntildeo
Calidad Discreta
Def
Intro
No de defectos
introducidos
durante el
desarrollo
Continu
a
EsfT
est
Calidad
experiencia el
equipo de
testeo
Discreta
defR
es
No de defectos
encontrados
posteriores a la
entrega
continua
Tabla 2 En cursiva y negrita se destacan posibles errores en los datos
Tabla 3 Muestra parcialmente como los atributos continuos pueden ser
discretizados
En la figura 5 se muestra la pantalla de la herramienta Hugi
(2006) para refinar la red obtenida por el algoritmo de
mineriacutea de aprendizaje de la red Fi
g
5
Pa
ntal
la
de
H
ugi
n
par
a
reso
lv
er in
certidumbres de la estructura de red Por ejemplo la Figura 6 muestra que si el Tamantildeo
(Tamano_d es la variable dis-cretizada) estaacute entre las 335
y 445 miles de liacuteneas de coacutedigo la probabilidad de
que la duracioacuten sea menor de 1235 (etiquetado como
lt1235lsquo) es de 096 la pro-babilidad de que esteacute entre
1235 y 1625 es de 1962 la probabilidad de que esteacute
entre 1915 y 2145 es de 096 y de que sea mayor de 2145
es solamente 096 Na-turalmente la prediccioacuten es que la
duracioacuten estimada estaraacute dentro el intervalo con mayor
probabilidad Para obtener valores concretos podriacutea usarse
la esperanza ma-temaacutetica E[X]=sumixip(xi) donde xi podriacutea
ser el valor medio del intervalo
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
35
INGENIERIacuteA DE SISTEMAS
Fig 6 Ejemplo de inferencia utilizando Hugin
VII Redes Bayesianas Orientadas a Objetos
Las Redes Bayesianas Orientadas a Objetos (OOBN en sus
siglas en ingleacutes) facilitan la representacioacuten de redes con un
gran nuacutemero de nodos de una manera modular (Koller y
Pfeffer 1997) Por tanto es posible reutilizar subredes ya
construidas dentro del sistema en las que cada subred tiene
su propia identidad ahorrando tiempo y esfuerzo a los
ingenieros del conocimiento encargados de modelar el
sistema
Hasta la fecha muy pocas herramientas implementan redes
orientadas a objetos una de ellas es Hugin (2006) en la
que se incluyen nodos llamados instancias que representan
subredes Las instancias o moacutedulos contienen nodos de
interfaz que pueden ser de entrada o de salida La Figura 7
(a) muestra un ejemplo de subred y su equivalente de forma
abstracta (Figura 7 (b)) Las subredes se comportan como
redes Bayesianas normales de manera que tambieacuten
pueden ser usadas para el razonamiento Para realizar la
inferencia en las redes Bayesianas orientadas a objetos lo
normal es transformarlas en redes normales y entonces
realizar las inferencias Fig 7 (a) OOBN extendida (b) OOBN representada de modo abstracto
En
ingenieriacutea del software Neil et al (2000) han aplicado
las redes Bayesianas orientadas a objetos y han
propuesto una metodologiacutea basada en una serie de
modismos para ayudar a los expertos del dominio a crear
redes complejas con un gran nuacutemero de nodos en un
proyecto llamado SERENE (SafEty and Risk
Evaluation using Bayesian Networks)
VIII Diagrama de Influencia
Los diagramas de influencia extienden las redes
Bayesianas con dos nuevos nodos llamados utilidad (o
valor) y decisioacuten para modelar expliacutecitamente la toma de
decisiones
Fig 8 Tipos de nodos en un diagrama de influencias
Por ejemplo imagiacutenese un escenario en la ingenieriacutea del
software donde el gestor de proyectos necesita decidir si
lleva a cabo inspecciones (reuniones formales don-de se
evaluacutea el disentildeo o coacutedigo) o no Es de sobra conocido que
las inspecciones de coacutedigo reducen el nuacutemero de defectos
y que corregir un error en un sistema ya en produccioacuten es
mucho maacutes caro que lo que seriacutea durante el testeo sin
embargo las inspecciones son costosas debido al nuacutemero
de horas invertidas por el personal Por tanto puede ser
beneficioso recabar informacioacuten adicional antes de
decidirse por la realizacioacuten de inspecciones La Tabla 4
muestra la funcioacuten de utilidad combinando el coste de
realizar inspecciones junto con el hecho de que si
entregamos al cliente un producto con alto nuacutemero de
errores se perderiacutea dinero en el proyecto A menor nuacutemero
de errores mayor beneficio proporcionaraacute el proyecto Tabla 4 Funcioacuten de utilidad
Un posible escenario se muestra en el diagrama de
influencia de la Figura 9 con el nodo de decisioacuten
Inspeccionar y el nodo valor Coste asociado con el nodo
Residual
Fig
9
Diag
ra
m
a
de
infl
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
INGENIERIacuteA DE SOFTWARE
INGENIERIacuteA DE SISTEMAS
36
uencia con bajo nuacutemero de errores introducidos
Por otro lado si sabemos que el nuacutemero de defectos
introducidos durante el desarrollo es bajo el proyecto
generaraacute beneficios se hagan o no inspecciones pero
generaraacute mayor beneficio si no se llevan a cabo las
inspecciones (la Figura 10 muestra este escenario)
Fig 10 Diagrama de influencia con un alto nuacutemero de errores
introducidos
IX Aplicaciones de las redes Bayesianas a la Ingenieriacutea del
Software
Las redes bayesianas son un tipo de modelos de mineriacutea de
datos que pueden ser utilizados en cualquiera de las
siguientes actividades de negocio
Prevencioacuten del fraude
Prevencioacuten del abandono de clientes
Marketing personalizado
Mantenimiento2
Scoring de clientes
Clasificacioacuten de datos estelares
X Propiedades y limitaciones de las redes Bayesianas
Las redes Bayesianas tienen un nuacutemero de caracteriacutesticas
que hacen que sean apropiadas para la ingenieriacutea del
software
- Representacioacuten graacutefica
- Modelado cualitativo y cuantitativo
- Inferencia bidireccional
- Anaacutelisis de sensibilidad
- Incertidumbre
- Valores de confianza
A pesar de sus ventajas tienen las siguientes limitaciones o
dificultades a la hora de crearlas
- Estructura
- Variables ocultas
- Probabilidades inconsistentes
XI Conclusiones
Las redes Bayesianas modelos que combinan la teoriacutea de
grafos y de probabilidad son aplicadas a la toma de
decisiones en dominios donde la incertidumbre representa
un papel importante como es el caso de la ingenieriacutea del
software Aunque este tipo de modelos han sido conocidos
desde hace mucho tiempo solamente han podido ser
aplicados desde finales de los antildeos 80 gracias al desarrollo
de nuevos algo-ritmos que permiten la creacioacuten y
propagacioacuten de probabilidades en redes suficientemente
complejas como para representar problemas reales En este
capiacutetulo se han introducido sus extensiones y uso en la
ingenieriacutea del software donde han sido aplicadas Se ha
proporcionado una visioacuten general de la metodologiacutea para su
construccioacuten asiacute como algunos algoritmos que podriacutean
considerarse como parte de la mine-riacutea de datos Ademaacutes
se han comparado con otras teacutecnicas maacutes tradicionales
dentro de la ingenieriacutea del software y se han descrito sus
ventajas e inconvenientes
Reconocimientos
Fenton (1999) ha descrito ―La clave de un uso maacutes
eficiente de meacutetricas del software no se encuentra en
meacutetricas maacutes potentes sino en la combinacioacuten
inteligente de diferentes meacutetricas Una vez dominada
dicha combinacioacuten se pueden estudiar meacutetodos
estadiacutesticos avanzados para obtener buenas predicciones
Las redes Bayesianas son uno de los meacutetodos con un futuro
prometedor
Referencias [1] Fenton N E Neil M (1999) A Critique of Software Defect Prediction
Models IEEE Trans-actions on Software Engineering 25 (5) pp 675-689
[2] Hugin (2006) Hugin httpwwwhugincom [3]Fenton N E Neil M (2000) Software Metrics A Roadmap en
Finkelstein A (Ed) The Fu-ture of Software Engineering ACM Press
[4] Redes Bayesianas Wikipeid httpwwwwikipediaorg
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS
] INGENIERIacuteA DE SOFTWARE
37
INGENIERIacuteA DE SISTEMAS