Revista de Ingenieria de Software by Elisipaty

2012 ]

INGENIERÍA DE SOFTWARE

Universidad San Francisco de Asís Ingeniería de Sistemas

Revista Conceptual Ing. de Software Este segundo número nos entrega información de Ingeniería de Software. 1 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE

EDITORIAL El emprendimiento para realizar la revista, es hacer nacer el interés a los alumnos en el ámbito de la investigación, dándoles parámetros para que ellos en su futuro, proyecten sus propias investigación de temas de interés personal con referencia a la carrera , incentivando al resto del alumnado para la creación de nuevos números 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 brindará a futuro, estudiantes con una visión más amplia en la parte de la investigación que es lo que debemos fomentar.

Se felicita y conmina a los autores de los artículos a seguir por este camino que les llevará a grandes logros en su vida profesional. Tomen en cuenta siempre “EL SABER ES PODER”.

MSc. Elizabeth Pommier Gallo

2 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE

INDICE Tom DeMarco Ingenieria de Software y Control de Proyectos……………………………………………………………………..4 Adictos al ……………………………………………………………....6 Skinput: Una pantalla táctil en tu piel…………………………………………..11 Mini computadoras………………………………………………………………...14 Estudio de redes GNOP…………………………………………………………………………… 7 La súper cámara que lo ve todo……….………………………………………………..………………20 Desimpresión ……………………………………………………………………… ………………………..….23 Cloud Computing……………………………………………………………………… ……………………….26 Nano- celular solares…………………………………………………………………………… ……………29 Memorias USB en módulos………………………………………………………………………… …....32 Teléfonos móviles de ultima generación……………………………………………………………34 My coach…………………………………….……………………………………… ………………………….….37 Factores del Cableado en el Centro de Cómputo………………………………………………40

3 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE

Tom DeMarco, Ingeniería de Software y Control de Proyectos Joe Luis Aramayo Blanco Ingeniería de Sistemas, Universidad San Francisco de Asís 20 de Octubre Esq. Belisario Salinas La Paz - Bolivia jlaramayo@usfa.edu.boResumen.- En este artículo haremos algunas observaciones sobre un artículo que escribió hace un tiempo atrás Tom DeMarco sobre métricas, control de proyectos e ingeniería de software, donde en general podemos encontrar frases que claramente contradicen su postura de hace unas décadas. Palabras clave.- Ingeniería de Software, Control de Proyectos, Métricas, No puedes controlar lo que no puedes medir, Desarrollo de Software.

Esto nos lleva a la desagradable conclusión que el control estricto es algo que importa mucho en proyectos relativamente inútiles y mucho menos en proyectos útiles. ¿Estoy diciendo que está bien ejecutar proyecto sin control o con un control relativamente menor? Casi. Estoy sugiriendo que deberíamos seleccionar primero a los proyectos cuyo control preciso no importe demasiado.

I. INTRODUCCIÓN Todos comprendemos que las métricas de software cuestan dinero y tiempo, y que deben ser usadas con moderación.

En los últimos 40 años nos hemos torturado por nuestra ineptitud en acabar proyectos a tiempo y con el presupuesto previsto. Pero como sugerí antes, no debería haber sido el objetivo supremo.

El desarrollo de software es inherentemente diferente de las ciencias naturales tales como la física, por lo que sus métricas son mucho menos precisas para capturar lo que deben describir.

El objetivo más importante es la transformación, crear software que cambie el mundo, o que transforme una empresa, o la forma en que hace negocios.

La frase ―No puedes controlar lo que no puedes medir‖ lleva implícita que el control es un aspecto importante, quizás el más importante, de cualquier proyecto de software. Pero no lo es.

El desarrollo de software es y será siempre algo experimental. La construcción real de software no es necesariamente experimental, pero sí lo es su concepción. Allí deberíamos enfocar nuestros esfuerzos. Allí es donde deberíamos haberlo hecho siempre. Está claro que es mucho más fácil criticar un artículo que hacer uno nuevo pero dada la trascendencia que está teniendo este escrito en particular voy a expresar mi opinión. Creo que DeMarco sabe venderse. Creo que cuando era más joven se supo posicionar como gurú de la Ingeniería de Software y el control de proyectos y creo que ahora está en la edad en que puede decir que parte de lo que dijo está mal e igual quedar bien porque su posición coincide con la de muchos gurúes actuales. Sin embargo, me parece que el artículo está lleno de frases impactantes pero que no salen de un análisis profundo. Me voy a explayar.

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.

4 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE

Fig. 3 Referencia a las Métricas cuestan dinero

Que las métricas cuestan dinero, en cierto sentido, es cierto. También es cierto que ahora es mucho más fácil llevar algunas métricas que hace unos años, dado que ahora utilizamos herramientas que las generan de manera automática. Podríamos decir que en el presente es mucho menos costoso tener la misma información que hace unas décadas DeMarco consideraba importante. Fig. 3 Referencia de WIKIPEDIA

Que el desarrollo de software es inherentemente diferente de las ciencias naturales como la física también es verdad. Lo que no se termina de entender es por qué nos comparamos con las Físicas y no con las Ingenierías. El diseño de una planta de gas en situaciones extremas también es único y con resultados impredecibles, la construcción de una torre en Dubai, algún nuevo prototipo de avión, un nuevo celular, etc. también son inherentemente diferentes de las ciencias naturales y sin embargo cuentan con presupuestos, métricas de avance, de defectos, etc. O sea, es una verdad, pero que no aplica a la conclusión a la que llega. Donde puedo estar más de acuerdo es cuando hablamos del control de proyectos de software aunque más adelante voy a definir mi posición. En este caso, en mi opinión también escribe algo cierto: ―El control no es lo más 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 desviación de 500% en costos.

Al menos, en mi entorno, la mayoría de los proyectos son internos o externos (para un cliente). Los proyectos externos tienen presupuestos o se crean luego de llamados a licitación. Es decir, costo fijo, tiempo fijo, alcance fijo más menos alguna que otra variación. Es claro que si no contamos con un mínimo de control en estos proyectos, la empresa no sabe si está siendo rentable o no. Tampoco sabe si el producto que es desarrollado le puede traer problemas a futuro por alguna cuestión de calidad. No poner un mínimo énfasis en el control de estos proyectos puede llevar a la empresa a la quiebra sin que esta sea consciente salvo por los números 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 último, cuando dice: el desarrollo de software es y siempre será algo experimental vuelve a caer en las afirmaciones de las que en 40 años (en caso de estar vivo, claro) podría volver a arrepentirse. Es cierto que todavía estamos en una etapa inicial de la que llamamos ingeniería de software. Es cierto que no es fácil gestionar proyectos de software por sus características intrínsecas (intangibilidad, maleabilidad, etc.) pero cada ingeniería tiene sus problemas particulares y cada una supo evolucionar a lo que son ahora. Seguramente la ingeniería de Software con el tiempo encontrará su camino.

Fig. 1 Referencia de Google Earth

Ahora bien, aparte de criticar un poco a DeMarco (que era lo más fácil), vamos a retomar la frase:

Ambos proyectos (Wikipedia, que surge de NuPedia) y GoogleEarth fueron proyectos en los que hubo inversores poniendo su dinero durante años sin ver resultados. Se puede buscar en Internet acerca de la historia de NuPedia, antecesora de Wikipedia y a Jimi Wales explicando que después de haber gastado 250.000 dólares solo había logrado 16 artículos en su nueva Enciclopedia. Lo mismo pasó con GoogleEarth, anteriormente en manos de KeyHole con inversores como Sony y otros Fondos de Capital. En este tipo de proyectos, se pueden asumir pérdidas durante años hasta lograr un producto que puede romper con el mercado o también se puede perder todo lo invertido. Se trata de proyectos de inversión de alto riesgo y determinan proyectos de desarrollo que claramente son poco comunes.

―No puedes controlar lo que no puedes medir‖ lleva implícita que el control es un aspecto importante, quizás el más importante, de cualquier proyecto de software. Pero no lo es. En cierta medida, explicaba arriba, estoy de acuerdo con esta afirmación. 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 más complejo haciendo que ningún 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 estándar. Este tipo de gente piensa las cosas de manera diferente, tiene la calidad incorporada como método de trabajo y la capacidad de

5 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE generar soluciones a las distintas situaciones hace que el esfuerzo estimado pueda acortarse en órdenes de magnitud. Estuve dentro equipos de este estilo y lo que se puede lograr en un ambiente hiperproductivo difícilmente se logre en una empresa de desarrollo común y corriente. El problema es que la gente que tiene estas cualidades escasea y el mercado está lleno de trabajadores ―estándar‖ que requieren definiciones, procesos, un área de calidad que verifique sus entregables, y un PM que le indique qué es lo que tiene que hacer. De a poco, estimo yo, la industria irá decantando por rendimiento aquellos profesionales que hacen la diferencia y los estándares de productividad, calidad, base teórica requerida para un puesto irán aumentando. Fue pasando durante estas décadas y seguirá pasando en el futuro. II. CONCLUSIONES En síntesis y para terminar con este artículo, medir y controlar importa, importa más en las empresas con gente estándar, importa más en las empresas con proyectos estándar y, siempre que estemos dentro de una empresa, algo vamos a tener que medir, pero el control no es condición 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 solución que el cliente necesita. Por eso cuando veo gente que se preocupa por aumentar el control o aumentar los procesos, creo que está perdiendo el foco, cuando lo que debería buscar es cómo hacer para encontrar y hacer rendir a los verdaderos profesionales del software. III. REFERENCIAS [1] [2]

Software Engenieering: an idea whose time has come and gone?, por Tom DeMarco. CyS Ingenieria de Software. El blog del área de Ingeniería de Software de CyS Informática S.A.

6 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE

EXTREME PROGRAMMING PARA DESARROLLO DE SOFTWARE Erwin Adán Choque Ulloa Ingeniería de Sistemas Universidad San Francisco de Asís Plaza Avaroa esq. Belisario Salinas La paz – Bolivia adan_eking@hotmail.com continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, Resumen simplicidad en las soluciones implementadas y facilidad para enfrentar los cambios. XP se define como En este articulo se describirá algunas de las metodologías especialmente adecuada para proyectos con requisitos agiles de desarrollo de software puesto que para asegurar el éxito durante el desarrollo de un software es importante imprecisos y muy cambiantes, y donde existe un alto saber la metodología de desarrollo la cual nos provee una riesgo técnico. Ahora se describirá las características guía para la correcta aplicación y desarrollo de Software. esenciales del Extreme Programming. La metodología Extreme Programming XP que es una de las metodologías ágiles más extendidas y populares, además es considerada como una metodología posmoderna donde grandes capacidades se generan a través de procesos emergentes. Palabras claves: Extreme Programming, metodología, software, usuario.

INTRODUCCION El esquema tradicional para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamaño respecto a tiempo y recursos. Sin embargo, este enfoque no resulta ser el más adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Ante este problema, las metodologías ágiles son una posible respuesta para llenar ese vacío metodológico. Orientadas para proyectos pequeños, las metodologías ágiles constituyen una solución. A continuación se describirá cada metodologías de desarrollo de software.

una

las

EXTREME PROGRAMMING XP La metodología de desarrollo de software XP es la primera metodología ágil y la que le dio conciencia al movimiento actual de metodologías ágiles. Kent Beck el padre de la metodología XP, se basa en realimentación

2.1. LAS HISTORIAS DEL USUARIO La red Las historias del usuario es la técnica utilizada para especificar los requisitos de software, son tarjetas de papel donde el cliente especifica de manera simplificada las características que el sistema debe poseer ya sean requisitos funcionales o requisitos no funcionales. Se caracteriza por ser dinámica y flexible cada historia de usuario debe ser comprensible y delimitada para que los programadores puedan implementarla en pocas semanas. 2.2. ROLES XP Según Kent Beck los roles son:  Programador. El programador se encarga de escribir las pruebas unitarias y también está encargado de producir el código 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 además de ejecutar las pruebas constantemente, encargado de de las

7 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE

   

herramientas de soporte de pruebas como también difundir los resultados de dicha prueba. Encargado de seguimiento. Es el encargado de la realimentación al equipo y realiza el seguimiento del proceso de cada iteración Entrenador. Es el encargado de prever guías al equipo basadas en XP y de seguir el proceso correctamente. Consultor. Es el que posee un conocimiento especifico en algún tema necesario para el proyecto, para solucionar problemas. Gestor. Es la interacción entre clientes y programadores ayudando a trabajar de forma adecuada y de esta manera coordinar de forma correcta.



 2.3. 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 implementación.  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 más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos. El ciclo de vida ideal de XP consiste de seis fases:  Exploración  Planificación de la Entrega (Release)  Iteraciones  Producción  Mantenimiento y Muerte del Proyecto.



 

2.4. PRACTICAS XP Las siguientes prácticas ayudan al desarrollo de software: 



El juego de la planificación. Hay una comunicación frecuente el cliente y los programadores. El equipo

técnico realiza una estimación del esfuerzo requerido para la implementación de las historias de usuario y los clientes deciden sobre el ámbito y el tiempo de entregas y de cada iteración. Entregas pequeñas. Producir rápidamente versiones del sistema que sean operativas aunque no cuenten con toda la funcionalidad del sistema. Esta versión ya constituye un resultado de valor para el negocio. Una entrega no debería tardar más de tres meses. Metáfora. El sistema es definido mediante un conjunto de metáforas compartidas por el cliente y el equipo de desarrollo. Una metáfora es una historia compartida que describe como debería funcionar el sistema. Diseño simple. Se diseña la solución más simple que pueda funcionar y ser implementada en un determinado momento del proyecto. Pruebas. La producción de código está dirigida para las pruebas unitarias. Estas son establecidas por el cliente antes de escribirse el código y son ejecutadas continuamente ante cada modificación del sistema. Pruebas. Es una actividad constante de reestructuración del código con el objetivo de remover duplicación de código, mejorar su legibilidad, simplificarlo y hacerlo más flexible para facilitar los cambios. Se mejora la estructura interna del código sin alterar su comportamiento externo. Programación en parejas. Toda la producción del código debe realizarse con trabajo en parejas de programadores. Para tener ventajas como menor tasa de errores, mejor diseño, etc. Propiedad colectiva del código. Cualquier programador puede cambiar cualquier parte del código en cualquier instante. Integración continua. Cada pieza del código es integrada en el sistema una vez que este lista.asi el sistema puede ser integrado y construido varias veces en un mismo día. 40 horas por semana. Se debe trabajar un máximo de 40 horas por semana, no se trabajan horas extras en dos semanas seguidas. Si esto ocurre está 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 éxito para el proyecto XP. Y así guiar y disipar cualquier duda de los programadores donde la comunicación es más efectiva que la escrita. Estándares de programación. XP enfatiza que la comunicación de los programadores es a través del código por lo que es importante que se sigan estándares de programación para mantener el código legible. CONCLUCIONES

8 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE

Las metodologías ágiles ofrecen una solución casi a medida para una gran cantidad de proyectos. La metodología XP es una de las metodologías ágiles más extendidas y populares, además es considerada como una metodología posmoderna cuyas grandes capacidades se generan a través de procesos emergentes. REFERENCIAS http//www.metodologiasSoft.com/desarrollo/agil http//www.wikipedia.com/metodologia/XP .

9 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE

Desarrollo de Scrum Sergio J. Guzmán L. Ingeniería de Sistemas Universidad San Francisco de Asís 20 Octubre Esq. Belisario Salinas La Paz - Bolivia

sjguzman@usfa.edu.bo Resumen— Scrum es una metodología ágil de desarrollo de proyectos que toma su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80. En 1996 se definió por primera vez un patrón para aplicar esos principios de desarrollo en “campos de scrum” al software. Palabras clave — scrum, metodología, patrón, software, sprint, rol,

I. Que es Scrum? Scrum es una metodología ágil de desarrollo de proyectos que toma su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80. En 1996 se definió por primera vez un patrón para aplicar esos principios de desarrollo en ―campos de scrum‖ al software. Esta fue la primera definición de un patrón Scrum aplicado al software, diseñada por Jeff Sutherland y Ken Schwaber y presentada en Object-Oriented Programming, Systems, Languages & Applications OOPSLA en 1996 II. ¿Cómo incorporarla?



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

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 metodologías para la gestión y desarrollo de software basadas en un proceso iterativo e incremental. Su estructura está 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 rápidos y la productividad es lo más importante. En los proyectos basados en Scrum se consideran tres roles: 

Dueño del producto: Es quien determina las propiedades de los entregables.

arquitecto de software. Sin embargo, como comenta Charlie Alfred, ―la arquitectura es al aceite y el filtro que lubrica adecuadamente a Scrum‖.



Maestro de Scrum: Administra y facilita la ejecución del proceso.

Fig. 2 El flujo de Scrum.

10 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE

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 abstracción, proveen posibles soluciones, mejoran la comunicación con los miembros del equipo de construcción a través de modelos, visualizan las generalidades del problema, definen los roles y las interacciones entre los componentes de construcción, entre otras tareas. Al igual que es imposible pensar que un rascacielos puede ser construido sin una arquitectura sólida, es imposible pensar que productos de software empresariales puedan ser implementados sin una arquitectura bien pensada. Según Bass, Clements y Kasman, ―La arquitectura de software de un programa o sistema informático, 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 definición 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. Además, la arquitectura es clave en la reutilización de artefactos de software en sistemas de línea de productos de software. Viendo la importancia de la arquitectura en el desarrollo del software, en éste artículo se presenta una propuesta para gestionar la arquitectura de Software en Scrum. En el primer capítulo se trata el tema de la localización de la arquitectura de software en el ciclo de desarrollo de Scrum; en el segundo capítulo 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 0″ al inicio del ciclo de desarrollo. El objetivo principal del arquitecto en el Sprint 0 es analizar y diseñar 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 más ágiles en el desarrollo de productos específicos.

todos los requisitos claros para comenzar la fase de diseño arquitectónico. Para determinar los conductores arquitectónicos, se debe identificar los objetivos del negocio de más 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 tendrán un mayor impacto sobre la arquitectura. El diseño arquitectónico puede comenzar una vez que se encuentran definidos los conductores arquitectónicos. El proceso de análisis de requisitos será entonces influenciado por las preguntas generadas durante el diseño arquitectónico. El resultado del Srpint 0 es un documento inicial que explica la arquitectura. El documento puede basarse en los pasos definidos por el método ADD (Attrbute Driver Design). Este método ha sido probado exitosamente en proyectos anteriores. Con ADD se puede definir una arquitectura de software mediante un proceso de descomposición 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 evaluación, se propone el método ATAM (Architecture Tradeoff Analysis Method). El ATAM revela cuán bien una arquitectura satisface los objetivos particulares de calidad y provee una aproximación de cómo los objetivos de calidad interactúan. Si la evaluación de la arquitectura se encuentra que se deben realizar cambios a la misma, entonces ésta se debe refinar hasta llegar a tener como resultado del Sprint 0 el documento público de la arquitectura junto con el sistema esqueleto. Finalmente, la arquitectura creada en el Sprint 0 beneficiará 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 está en el Sprint 0, o en

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 análisis preliminar de los conductores arquitectónicos (requisitos funcionales, de calidad y del negocio), y de un estudio de factibilidad del proyecto. No se necesita tener

11 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE sprints subsecuentes. Fig. 3 La Comunicación.

Sprint 0. En sistemas complejos, una persona difícilmente puede cubrir con amplitud técnica las decisiones arquitectónicas y dar credibilidad a la arquitectura de software. Esto quiere decir que la participación del equipo es de vital importancia para la creación y el mantenimiento de la arquitectura. Un equipo de arquitectos de software que se aísle 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 evaluación de la arquitectura. Específicamente, en el método ATAM se requiere la participación mutua de tres equipos que trabajan en conjunto con los arquitectos de software: el de evaluación, el de tomadores de decisiones del proyecto, y el de los involucrados en la arquitectura.



Junto con el maestro de Scrum, coordina a los miembros del equipo para adaptarse a la arquitectura previa.



El arquitecto junto con el dueño del producto y los miembros del equipo preparan el Product Backlog. V. Conclusión. En el presente artículo ofrecimos una propuesta para incluir la arquitectura de software en Scrum. En el Sprint 0 se realizan las actividades concernientes al análisis y diseño de la arquitectura de software, y el sistema esqueleto. En los siguientes sprints el arquitecto de software se asegura de que la implementación cumpla con la arquitectura. REFERENCIAS

[3] http://www.safecreative.org/work. [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 Nonaka:"No soy un gurú porque me falta carisma".

Sprints subsecuentes. El arquitecto de software asegura que el equipo de Scrum entienda el enfoque y los retos arquitectónicos más importantes en casa sprint. Los equipos de Scrum realizan construcciones cortas, guiados por las estrategias de la arquitectura. A continuación se nombran algunas de las responsabilidades del arquitecto de software desde el Sprint 1 en adelante: 

El dueño del producto y el maestro del Scrum trabajan con el arquitecto para priorizar los requisitos a implementar en cada iteración.



El arquitecto comunica las decisiones y facilita las conversaciones arquitectónicas 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 orientación arquitectónica cuando sea necesario.

12 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE

El futuro de la ingeniería de software Luis E. Aguirre Ingeniería de Sistemas Universidad San Francisco de Asís 20 de Octubre esq. Belisario Salinas

La Paz - Bolivia leaguirre@usfa.edu.bo Resumen El diseño de programas a partir de información binaria significó un paso sustantivo para la industria desarrolladora de software. Desde ese hallazgo, ocurrido en la década de los cincuenta, hasta hoy, el crecimiento de metodologías para su desarrollo ha subido notablemente en complejidad. Sin embargo, los círculos viciosos que acusa hoy la confección de programas informáticos, impiden conceptualizar el objeto a un nivel superior de abstracción, tal y como lo exige el avance tecnológico y los procesos de negocios. Palabras clave — futuro, software, ingeniería, programador y desarrollo.

I. Introducción La calidad de los sistemas informáticos, satisfacción de sus usuarios y clientes, son temas ampliamente conocidos, recurrentes y de constante preocupación por parte de los practicantes de la Ingeniería de software. Esta joven y dinámica ingeniería siempre está 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 métodos 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 ingeniería, analizar su contexto actual y, finalmente, proyectar hacia dónde se dirige, es el pilar de este artículo. II. ¿Se aplica actualmente la ingeniería del software? La investigación y el desarrollo de técnicas y méto dos de ingeniería del software son constantes y suelen suponer interesantes avances en la resolución de problemas de desarrollo de software. Sin embargo, es habitual que en la práctica diaria profesional no se incluya prácticamente ninguna de las recomendaciones más elementales de la ingeniería del software. En efecto, es habitual que el desarrollo de software se parezca más al descontrol del cuento de «si los programadores fueran albañiles...» ([Novatica, 1996]) que a una idílica y bien organizada factoría 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 raíz de los modelo de procesos de software (por ejemplo, con CMM [Paulk et al., 1993]) confirman que el desarrollo de software suele estar básicamente en estado caótico. Y no sólo en, como uno podría pensar, pequeñas organizaciones de un país mediterráneo como el nuestro sino en también en las empresas adjudicatarias de interesantes contratos de defensa de países «avanzados» como EE.UU. o Japón. Si bien estos modelos de evaluación aún acumulan distintas acusaciones de rigidez o falta de contraste empírico, los resultados obtenidos en sus evaluaciones resultan consistentes con la sensación de constante «apagafuegos» que suelen sufrir los profesionales del software. También suelen revelar la práctica despreocupación 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 situación interna de empresa poco propicia, porque el

13 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE ambiente del mercado no fomenta la preocupación por estos temas o bien por su poco interés real en la búsqueda de la calidad. III. La actualidad La gran mayoría de los sistemas de software creados hoy en día 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 sincronización de los procesos de negocio, estructuras complejas de información manejada por el negocio, todo esto entrelazado por restricciones dadas por las reglas del negocio. La tecnología actual, por otro lado, ha alejado más todavía los ingenieros de las máquinas, sistemas operativos, incluso de las tareas de programación. El enfoque de la mayoría de los equipos de desarrollo e ingenieros, participes en proyectos, sigue siendo con un bajo nivel de abstracción, cerca de la codificación. Se tiende a pensar en la base de datos a utilizar, establecer la navegación de las páginas, programar los protocolos de comunicación, etc. Esto lleva a utilizar las tareas de programación y de pruebas para validar el entendimiento y cumplimiento de la funcionalidad de los sistemas. Lo anteriormente expuesto muestra un problema metodológico, consecuencia de un desfase entre el enfoque teórico óptimo (análisis de negocio) y el enfoque práctico real (programación y pruebas) en los proyectos de hoy. En otras palabras, la metodología actualmente usada está atrasada con respecto al avance tecnológico. Desarrollando más esta idea, se identifican algunos problemas concretos de las metodologías:  Ellas no obligan a sus ejecutores a respetar todas las normas y los procedimientos establecidos, especialmente en las etapas tempranas del proyecto. Es muy fácil y tentador ―saltar‖ una o más de estas etapas, uno o más documentos o modelos, pasando directamente a implementación, producción y posterior corrección de los sistemas desarrollados.  Control de calidad del producto final. La codificación y complejidad del programa, es demasiada para ser revisada y verificada fehacientemente. Por otro lado, los códigos fuentes y los ejecutables actualmente son los únicos entregables eficientemente verificables.

Estos dos problemas al parecer forman una situación contradictoria: la metodología tradicional no permite validar eficientemente la calidad de los sistemas antes de llegar al código fuente y, por otro lado, tampoco permite llegar eficientemente a códigos fuentes de calidad. IV. Futuro La salida de este ―círculo vicioso‖ que se propone es bastante natural: analizar la situación actual de la ingeniería de software en la luz de sus tendencias históricas. 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 sólo resuelven los problemas del mundo real, sino que están fuertemente influen-

ciando el desarrollo del mundo real. Fig.2 Modela

El enfoque de los ingenieros, desde hace unos años, no se ha movido significativamente por el camino del aumento de abstracción establecido históricamente. Se han hecho ciertos avances en temas puntuales (como arquitecturas de componentes, patrones de diseño, nuevos lenguajes de programación, etc.), pero conceptualmente, metodológicamente, la tarea de programación sigue siendo ejecutada de la misma forma: escribiendo códigos fuentes en forma de los programas textuales. Éste es, justamente, el ―atraso‖ metodológico que se mencionó. Para disminuir la brecha entre las tendencias históricas, es necesario ajustar la metodología, en términos de aumentar la abstracción del enfoque de los ingenieros de software y acercarlo a la abstracción del problema. El aumento de la abstracción del proceso de desarrollo del software hace pensar que la próxima generación de métodos de desarrollo se perfila en un conceptualmente nuevo con-

14 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE

junto de herramientas, que permitan aumentar en un mayor grado al actual la abstracción, escondiendo los detalles de más bajo nivel.

[7] [8]

http://www.slideshare.net/amrrocha/futuro-del-software-impacto-enlas-organizaciones-y-en-los-profesionales http://www.dc.uba.ar/events/eci/2008/conferencias/IngSoftHexacta

Fig.3 Probable modelo a futuro.

Las nuevas herramientas permitirán ―programar‖ en nivel de análisis, generando códigos en un lenguaje de programación tradicional de forma automática, tal como hoy los compiladores generan el lenguaje máquina a partir del código fuente. Nuevos ―lenguajes de programación‖ naturalmente serían visuales y se parecerían a las especificaciones de software en uno de los lenguajes de modelamiento, por ejemplo UML. V. Conclusión Es muy probable que estemos próximos a ver un nuevo paso evolutivo en la ingeniería de software. Tan grande como el invento de lenguajes de alto nivel o análisis y diseño orientado a objetos. Una nueva generación que absorberá a la actual, automatizando la mayoría de las buenas prácticas usadas actualmente.

Una pregunta natural es si una máquina puede llegar a generar programas tan buenos como los hechos por un programador experto. En vez de ―romper la cabeza‖ con esta pregunta ahora, quizás sería suficiente recordarse otra vez de la historia. Los primeros compiladores de ninguna generación alcanzaban de inmediato lo deseable y óptimo. Sin embargo, con el paso del tiempo, apoyados en la experiencia de los ingenieros y en el avance tecnológico, se mejoraban hasta el nivel de superar significativamente las generaciones anteriores. Es poco factible que hoy en día alguien cuestione la calidad de los compiladores de, por ejemplo, Java y la calidad del código de máquina generado por ellos. VI. Referencias [6]

Website.

[Online].

http://www.enterpriseanalyst.net/download/mda_informatica.p df

15 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE

Ingeniería de Software para Desarrolladores de juegos Huascar Huanca Orozco #

Ingenieria de Sistemas, San francisco de Asis Av.20 de Octubre esq. Belisario Salinas hhunca@usfa.edu.bo

Resumen—En este artículo veremos una lo que es “IS para Desarrolladores de juegos” 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 — UML,Requisitos,juego,equipo de trabajo, motor del juego

una práctica, como una preocupación profesional, Métodos para aprender a diseñar y fabricar un producto, El desarrollo del personaje e ingeniería de software, Estrategias para hacer el mejor uso de la ingeniería del conocimiento formalizado, El aprendizaje de las habilidades que se pueden aplicar en cualquier lugar

IV. INTRODUCCIÓN

En la ingeniería de software (IS), el desarrollo de videojuegos es único, pero similares a los esfuerzos de software. Es la única que combina el trabajo de los equipos que cubren múltiples disciplinas (arte, música, actuación, programación, etc), y que el juego de acoplamiento que se busca a través del uso de prototipos e iteraciones. Con ello, el desarrollo del juego se enfrenta a desafíos que pueden ser abordadas mediante las prácticas tradicionales de SE. La industria tiene que adoptar buenas prácticas de SE para sus distintas necesidades, tales como la gestión de activos multimedia y encontrar el fundamento en el juego. La industria debe asumir los retos por la evolución de los métodos de SE para satisfacer sus necesidades. Este trabajo investiga estos desafíos y prácticas de ingeniería destaca para mitigar estos problemas.

VI. REQUISITOS

Esta parte ofrece una visión general de los conceptos y herramientas necesarias para la obtención 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 CÓMO EMPLEAR CASOS DE USO PARA PERFECCIONAR Y ANALIZAR LAS NECESIDADES. ■ ENCONTRAR TÉCNICAS PARA CONFIRMAR QUE LOS REQUISITOS ESTÉN COMPLETOS. ■ VERIFICAR LA EXACTITUD DE LOS REQUISITOS. ■ TRACE CAMBIOS EN LOS REQUISITOS.

VII. PROGRAMADOR DEL MOTOR DEL JUEGO

V. ENTRA EN EL JUEGO

Lo que la IS para desarrolladores de juegos hace es: Mezcla de ingeniería y el arte, El software como

Fig. 1 Juego RPG

16 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE Fig. 2 Grupo de trabajo

Los programadores de juegos motores crear el motor de base del juego, incluyendo la física de simulación y disciplinas gráficas

Un equipo de desarrollo en una organización de ingeniería de software se compone de un grupo de personas que trabajan en funciones especializadas para lograr un objetivo común. El objetivo es la realización de un proyecto. Un proyecto se define como "un esfuerzo temporal emprendido para crear un producto único, servicio o resultado.

A. Física del motor del programador

Programador de un juego de la física se dedica al desarrollo de las física de un juego se emplean. Por lo general, un juego de sólo simular algunos aspectos de la física del mundo real. Por ejemplo, un juego de espacio puede necesitar simulada gravedad , pero no tendría ninguna necesidad para simular agua viscosidad Para un juego de rol como World of Warcraft , sólo un programador de la física puede ser necesaria. Para un juego de combate complejo, como Battlefield 1942 , los equipos de programadores de la física pueden ser necesarias.

  

B. motor de gráficos del programador

A pesar de todos los programadores añadir tanto los contenidos y la experiencia que ofrece un juego, un programador de juego se centra más en la estrategia de un juego, la aplicación de la mecánica del juego y la lógica, y la "sensación" 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 verá involucrado con las áreas más especializadas de desarrollo del juego como los gráficos o el sonido.

       

VIII. EQUIPO DE TRABAJO

  

Aquí una pequeña 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 inclusión en el esfuerzo de desarrollo. Diseñador 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 documentación de diseño, sirven como una tecnoVentaja técnica para los demás, e implementar el software de acuerdo Para el diseño. Programador implementar el software de acuerdo al diseño. Trabajos de mantenimiento en el programador de software creado durante el desarrollo anterior Los esfuerzos para agregar funcionalidad o eliminar errores de trabajo con Atención al cliente. IX. LENGUAJE UNIFICADO DE MODELADO (UML)

17 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE Tomando en cuenta que el UML es un estándar muy flexible. Nos da razón que podemos pensar en el diagrama como herramientas que permiten realizar diferentes tipos de trabajo. Para revisar un poco:

[11] http://gamedev.stackexchange.com/questions/19934/abstract-game-enginedesign

■ Use un diagrama de casos de uso para reunir y estudiar los requisitos para los propósitos de diseño 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 cómo las clases se relacionan entre sí. ■ Use un diagrama de objetos para ver cómo 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 sí mismos o entre sí. ■ Use un diagrama de colaboración para ver la lógica del sistema y la forma en que los objetos envian mensajes entre sí. ■ Use un diagrama de componentes para explorar y si existen los subsistemas dentro de su juego ■ Use un diagrama de implementación para encontrar la manera de configurar el paquete de instalación 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] http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5070627&url=http% 3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F5070574%2F5070575%2F05 070627.pdf%3Farnumber%

18 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE

Estrategias de Prueba del Software Miguel Angel Callisaya Quispe Universidad San Francisco de Asís Av. 20 de Octubre ,La Paz Bolivia maccc19@hotmail.com

Resumen Una estrategia de software es un mecanismo que proporciona una guía o base pasa ver la forma como se debe desarrollar la aplicación en cuanto a métodos, 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 está manera se pueda la en encontrar los errores antes de que se conviertan en errores para la aplicación, si no se lleva un orden de aplicación 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 atención en un pequeño grupo de componentes o en un componente que se considere importante para el desarrollo tanto en los datos como en la parte lógica de la aplicación. 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 implementación.

jerarquía de control, comenzando por el módulo de control principal (programa principal). Los módulos subordinados (de cualquier modo subordinados) al módulo de control principal se van incorporando en la estructura, bien de forma primero-en-profundidad o bien de forma primero-enanchura. Fig1 Integración ascendente La prueba de la integración ascendente, como su nombre indica, empieza la construcción y la prueba con los módulos atómicos (es decir, módulos de los niveles más bajos de la estructura del programa). Dado que los módulos se integran de abajo hacia arriba, el proceso requerido de los módulos subordinados a un nivel dado siempre están disponibles y se elimina la necesidad de resguardos. Fig2

Palabras clave: Calidad, Prueba, Estrategias, Sistema

INTRODUCCIÓN Durante este articulo es importante mencionar algunos aspectos que determinan el éxito de la aplicación de las estrategias de prueba como lo son: el enfoque estratégico para la prueba de software, aspectos estratégicos, estrategias de prueba para software convencional, estrategias de prueba para software orientado a objeto, estrategia de prueba para webapps, pruebas de validación y por último las pruebas del sistema. II.ESTRATEGIAS DE PRUEBA DEL SOFTWARE Fig. 1 Integración descendente

Verificación: Estamos correctamente.

construyendo

producto

Validación: Estamos construyendo el producto correcto. Integración descendente La integración descendente es un planteamiento incremental a la construcción de la estructura de programas. Se integran los módulos moviéndose hacia abajo por la

19 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE de trabajo de los clientes. El cliente registra los problemas y los informa a intervalos regulare. Pruebas del sistema La prueba del sistema está constituida por una serie de pruebas difere ntes cuyo propósito es ejercitar profundamente el sistema. Prueba de recuperación Es la prueba del sistema que fuerza al fallo del software de muchas formas y v e r i f i c a q u e l a recuperación se lleva a cabo apropiadamente. Recuperación automática o manual. Prueba de seguridad Intenta verificar que los mecanismos de protección incorporados en el sistema lo protegerá, de hecho, de accesos impropios.

Fig. 3 Integración Ascendente

Aspectos Estratégicos Tom Gilb plantea que se deben abordar los siguientes puntos si se desea implementar con éxito 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 explícita (términos medibles) -Comprender qué usuarios va a tener el software y desarrollar un perfil. -Desarrollar un plan de prueba que haga hincapié en la prueba de ciclo rápido. -Construir un software ―robusto‖ diseñado para probarse a sí mismo. -Usar revisiones técnicas formales efectivas como filtro antes de la prueba. Llevar a cabo revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba. Desarrollar un enfoque de mejora continua al proceso de prueba. Debería medirse la estrategia de prueba

Pruebas de Resistencia Están diseñadas para enfrentar a los programas con situaciones anormales. Una variante de la prueba de resistencia es una técnica 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 depuración La depuración 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 ó n e s e l proceso que provoca la eliminación del 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 síntoma con una causa es la depuración.

Prueba de Unidad La prueba de unidad centra el proceso de verificación en la menor unidad del diseño del software: el módulo .La prueba de unidad siempre esta orientada a caja blanca y este paso se suele llevar a cabo en paralelo para múltiples módulos. Pruebas de Alfa y Beta Cuando se construye software a medida, se llevan a cabo una serie de pruebas de a c e p t a c i ó 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

 

El proceso de la depuración El proceso de depuración intenta hacer corresponder el síntoma con una causa, l l e v a n d o a s í a l a corrección del error .El proceso de depuración 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 éste último caso, la persona que realiza la depuración debe sospechar la causa, diseñar un caso de prueba que ayude a confirmar sus sospechas y el trabajo vuelve hacia atrás a la corrección del error de una forma iterativa. ¿Por qué es tan difícil la depuración? Varias características de los errores nos dan algunas

20 INGENIERÍA DE SISTEMAS

]

     

INGENIERÍA DE SOFTWARE

pistas:1.El síntoma y la causa pueden ser geográficamente remotos entre sí.2.El síntoma puede desaparecer (temporalmente) al corregir otro error. 3.El síntoma puede realmente estar producido por algo que no es un error ( i n e x a c t i t u d d e l o s redondeos) 4.El síntoma puede estar causado por un error humano que no sea fácilmente detectado. 5.El síntoma puede ser el resultado de problemas de temporización en vez de problema s de proceso 6.Puede ser difícil reproducir exactamente las condiciones de entrada. 7.El síntoma puede aparecer en forma intermitente. 8.El síntoma puede ser debido a causas que se distribuyen por una serie de tareas e j e c u t á n d o s e e n diferentes procesadores. III.CONCLUCIONES Las estrategias de prueba del software es un mecanismo que proporciona una guía o base pasa ver la forma como se debe desarrollar la aplicación en cuanto a métodos para logra un producto exitoso. IV.REFERENCIAS http://.buenastareas.com/ensayos/Estategias-de-prueba-desoftware/3752643.html http//www.estrategias.com/prueba/agil

21 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE

Ingeniería Inversa Juan Carlos Zenteno Sanga #1 #

Departamento de Ingeniería de Sistemas, Universidad San Francisco de Asís Dirección Incluyendo el País 1

juanka_58@hotmail.com

Resumen— La ingeniería de Software es parte del modelo de proceso de reingeniería de software, es el proceso de analizar un programa con la finalidad de crear una representación del programa en un grado mayor de abstracción del código fuente, las herramientas de ingeniería inversa obtienen información del diseño de datos, arquitectónico y de procedimientos a partir de un programa existente. En el siguiente artículo se verán los conceptos básicos y se denotara un ejemplo práctico, para una mayor comprensión del tema.

productos de Hardware y Software, pero cualquier producto puede ser sometido a este proceso.

Palabras clave — Ingeniería de Software, Reingeniería, Linux, Ingeniería Inversa.

XI. INTRODUCCIÓN

Inmersa en el área de conocimiento de la ingeniería de software, se encuentra la ingeniería inversa como punto de apoyo para los procesos de análisis y diseño propuestos en diferentes métodos de desarrollo. La ingeniería inversa permite subsanar esta deficiencia, al documentar los productos de software a partir del código ejecutable, con el fin de obtener los artefactos de análisis y diseño. La ingeniería inversa es además una herramienta útil que ayuda en el proceso de aseguramiento de la calidad del software, mediante la comparación de diagramas de fases de análisis y desarrollo, se apoya comúnmente en la generación del diagrama de clases, debido a la importancia de este diagrama en la fase de diseño y su facilidad de generación. Existen también otros diagramas de interés como el de comunicación y el de secuencias, que modelan las características dinámicas de un producto de software. Hoy en día, los productos más comúnmente sometidos a la Ingeniería Inversa son los

 

Aplicar ingeniería Inversa a algo supone profundizar el estudio de su funcionamiento. En el caso concreto del Software, se conoce por ingeniería de software a la actividad que se ocupa de describir cómo funciona un programa, de cuyo código no se dispone, hasta el punto de generar código propio que cumpla con las mismas funciones. Un ejemplo clásico del uso de esta técnica es el software de pago, donde las empresas utilizan esta técnica para proteger sus productos contra posibles acceso no autorizados o examinar el producto final, para encontrar posibles bugs inesperados en la ejecución de dicho sistema. Existe una gran variedad de software desensamblador y depurador para aplicar esta técnica. En resumen, la idea general al aplicar ingeniería inversa es: Conocer a fondo la aplicación y generar un mejor código. Migrar la aplicación a un nuevo sistema operativo. Hacer o completar la documentación.

22 INGENIERÍA DE SISTEMAS

] 

INGENIERÍA DE SOFTWARE

Verificar que el código en estudio cumple las especificaciones del diseño estándar. La información extraída de la lectura del código fuente son las especificaciones de diseño: modelos de flujo de control, diagramas de diseño, documentos de especificación de diseño, pudiendo tomarse estas especificaciones como nuevo punto de partida para aplicar ingeniería inversa y obtener información a mayor nivel de abstracción. Dado que es una labor estratégica, es conveniente conocer cuando conviene realizar la tarea de Ingeniería inversa para una aplicación y cuándo es más rentable sustituirla e implementar una nueva. Las aplicaciones para el primer paso, son aquellas en la que se produce las siguientes situaciones: • Fallos frecuentes, que son difíciles de localizar • Son poco eficientes, pero realizan la función esperada • Dificultades en la integración con otros sistemas • Calidad pobre del software final • Resistencia a introducir cambios • Pocas personas capacitadas para realizar modificaciones • Dificultades para realizar pruebas • El mantenimiento consume muchos recursos

Figura 1 Antikythera (mecanismo presuntamente creado para fines astronómicos).

Podemos entonces implantar un paralelo en aquella mitológica búsqueda de descubrimiento sobre el funcionamiento de esos artefactos y la ingeniería inversa actual usada en ingeniería de software, estableciendo un importante factor en común: la falta de documentación. En este ambiente es muy común contar con una especie de caja negra, en donde sabemos lo que ingresamos y el resultado que obtenemos pero desconocemos el procedimiento con la precisión que necesitaríamos para replicarlo.

Esta falta de documentación es el impulso principal de toda la ingeniería inversa, las finalidades de la misma pueden variar, pero este factor inicial nunca lo hará. XIII. INGENIERIA INVERSA COMO UN PROCESO DE REINGENIERIA.

  

XII. LAS BASES DE LA INGENIERIA INVERSA.

Los ejemplos más trascendentes sobre los inicios de la ingeniería 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 más conocidos es el llamado mecanismo de Antikythera (Fig. 1) el cual se piensa que fue diseñado para fines astronómicos por los griegos, siendo uno de los primeros artefactos que funcionaban con ruedas de engranes.

La ingeniería inversa tiene la misión de desentrañar los misterios y secretos de los sistemas en uso. Básicamente recupera el diseño de la aplicación a partir del código, esto se realiza mediante herramientas que extraen la información de los datos, procedimientos y arquitecturas del sistema. Es aplicable a sistemas con las siguientes características: Documentación inexistente o totalmente obsoleta. Programación en bloque de códigos muy grandes y/o sin estructural.  La aplicación cubre gran parte de los requisitos y el rendimiento esperado.

A. Nivel de abstracción.



El nivel de Abstracción de un proceso de Ingeniería Inversa y las herramientas que se utilizan para realizarlo aluden la sofisticación de la información de diseño que se puede extraer del código fuente. Este proceso debería ser capaz de derivar: Sus representaciones de diseño de procedimiento (con un bajo nivel de abstracción).

23 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE 

 

La información de las estructuras de datos de procedimiento (con un nivel de abstracción ligeramente más elevado). Modelos de flujo de datos de control (un nivel de abstracción relativamente alto). Modelos de entidades y de relaciones (un elevado nivel de abstracción).



B. Completitud.

En la mayoría de los casos la completitud decrece a medida que aumenta el grado de abstracción. La completitud mejora en proporción directa a la cantidad de análisis efectuado por la persona que está efectuando la ingeniería 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 ingeniería inversa efectivo. D.



Proceso.

El Proceso de ingeniería inversa (Fig. 2) es el encargado de reestructurar el código fuente, para que solamente contenga instrucciones de programación estructurada. Lo que hace que el código sea más fácil de leer y proporciona la base para las subsiguientes actividades de ingeniería inversa.

Figura 2 Diagrama de Proceso de la Ingeniería Inversa.



arquitectura global del programa. Tiene a centrarse en los detalles de diseño de módulos individuales y en estructuras de datos locales definidas dentro de los módulos. 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 más sencillo para comprobar y depurar.

F. Re documentación.

Es el proceso mediante el cual se produce documentación retroactivamente desde un sistema existente. Es considerada una forma de ingeniería inversa porque la documentación reconstruida es usada para ayudar al conocimiento del programa. XIV. UTILIZANDO EL METODO CIENTIFICO EN LA INGENIERIA INVERSA

Ante cualquier dificultad tecnológica, el método científico siempre es y será nuestra más preciada arma. Partamos imaginando un pequeño dilema relacionado con el tema de ingeniería de software, específicamente con un sencillo programa (Fig. 3):

Figura 3 Pantalla de aplicación que nos servirá de ejemplo

E. Reestructuración.

La reestructuración del software modifica el código fuente y los datos en un intento adecuado a futuros cambios; esta no modifica la

Esta sencilla aplicación mostrará un mensaje con cierto resultado y aun siendo un problema demasiado sencillo para considerarlo como un reto, el objetivo es sólo describir

24 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE

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 Observación 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 solución general. El punto de quiebre se produce en este instante. Ya al haber observado la aplicación podríamos decidir procesar los datos que nos entrega y lograr crear un código equivalente o investigar el funcionamiento interno.

Figura 4 Resultado de la Aplicación.

Ya con esa pista es sencillo encontrar el fragmento de código relacionado con las operaciones relacionadas a nuestro número de entrada que tendría una forma similar a la mostrada a continuación en nuestro descompilador (Fig. 5).:

B. Dentro de la aplicación.

Luego de la formulación de una hipótesis sobre su funcionamiento necesitamos algunas herramientas para comenzar con la investigación. En el caso de esta aplicación con un poco de conocimientos del lenguaje ensamblador, de programación tradicional y un descompilador es suficiente. Figura 5 Vista del Programa en Ensamblador.

Es importante emprender de buena forma nuestro sondeo, ser ordenados y metódicos en la tarea. En este momento las capacidades analíticas y lógicas 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 aplicación para Windows necesita invocar internamente al punto de entrada MessageBox o MessageBoxEx de la librería de sistema user32.dll para poder desplegar un mensaje (Fig. 4).

Cualquier programador intuiría fácilmente lo que hacen las líneas superiores de esta aplicación, en especial sprintf es parte de la librería estándar de C++. Claramente vemos también el título de la ventana en el código, estos valores son interpretados de forma inteligente por este descompilador en especial y en particular, nos asiste de sobremanera a comprender el código. Lo siguiente es sencillamente explorar paso a paso las acciones superiores de cálculo del resultado. En esta instancia será ideal realizar numerosas pruebas para estar completamente seguros de que logramos develar el secreto tras la funcionalidad objetivo: (Fig. 6)

25 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE

Nuevamente multiplicamos el resultado por el anterior, proporcionado tras la suma. En esta segunda vez ya podemos expresar la operación simplemente elevando al cubo la suma anterior (Fig. 9):

Figura 9 Código que denota una nueva multiplicación del resultante.

Ahora le restamos diez al resultado:

Figura 6 Inicio del código al que aplicaremos ingeniería inversa

El procedimiento que viene a continuación propone un mayor desafío intelectual. Un número constante, en este caso el cargado al registro EAX (Fig. 10):

Hay que detenerse algunos segundos a individualizar algunos procedimientos del análisis que a simple vista pueden parecer inconcebibles, con el fin de poder generar una tesis concluyente. Cabe destacar que se omitirán 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 leído desde el cuadro de diálogo del programa, ahora nos enfocamos en la primera acción importante. Asumiremos el valor de entrada como una incógnita.

En el siguiente trozo de código, la línea destacada añadió siete a nuestra incógnita (Fig. 7):

Figura 7 Código donde se denota la adición de 7 a nuestra ecuación

A continuación, se multiplica ese valor resultante de la suma, por el mismo (Fig. 8):

Figura 10 ubicación del número constante EAX.

Generalmente la división es algo más costosa en tiempo de procesador que otras operaciones, por lo que ciertos compiladores incluyen tablas de constantes las cuales son llamadas ―números mágicos‖ para la división entera.

-5

Con signo m (hex) 99999999

-3

55555555

-2k

7FFFFFFF

—

80000001

3 5 6

Sin signo s 1

m (hex)

232-k

55555556

1 k1 — k1 0

AAAAAAAB

66666667

CCCCCCCD

2AAAAAAB

AAAAAAAB

92492493

24924925

38E38E39

66666667

CCCCCCCD

2E8BA2E9

BA2E8BA3

Figura 8 Código donde se denota la multiplicación del valor por la suma

26 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE

2AAAAAAB

AAAAAAAB

51EB851F

10624DD3

Tabla 1 Algunos números mágicos (32 bits)

Ahora bien, conociendo la tabla 1, sabiendo que el número cargado en esta ocasión corresponde al once, lo que hace el código es multiplicar el resultado de la salida temporal por aquel número (Fig. 11):

Figura 11 Multiplicación del resultante por el numero 11

Naturalmente la multiplicación por un número tan grande produce una especie de desbordamiento en el registro contenedor del resultado al exceder el tamaño 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 división entera por dos) para obtener la solución de la división por once, generando una sencilla ecuación:

Figura 12 Desplazamiento del bit de registro EDX.

El último paso, luego de documentar estos resultados, será crear una aplicación que recree esta fórmula sólo en caso de tener intenciones de re-codificación 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 ingeniería inversa es uno de los tópicos más interesantes a los que podría afrontarse un profesional de la tecnología y en general, disfrutar el largo proceso involucrado gracias al desafío poco predecible que presenta. En general podemos darnos cuenta de que no existen muchas metodologías y teorías estrictas sobre cómo aplicar las técnicas de ingeniería inversa. Afortunadamente un ingeniero está preparado para afrentar desafíos de este tipo. Adicionalmente podemos deducir también el aspecto bidireccional de la ingeniería inversa, pues como ya lo comprobamos, no solo es un desafío aplicarla, sino que también lo es tener que dificultar el proceso, o incluso tratar de impedirlo si la situación lo requiere. REFERENCIAS [12] Roger Pressman. Ingeniería de Software ―Un Enfoque Moderno‖ 6th ed., MC Graw Hill. [13] http://es.wikipedia.org/wiki/Ingenieria_inversa [14] http://www.infosecwriters.conn/text_resources/pdf/software_security_and_r everse_engineering.pdf [15] http://erwin.ried.cl/?modo=visor&elemento=239

27 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE

METODOLOGÍA ÁNCORA PARA EL DESARROLLO DE SOFTWARE EDUCATIVO Univ. Alejandro Méndez Escobar Universidad San Francisco de Asís Ingeniería de Sistemas Ingeniería de Software I La Paz - Bolivia amendez@usfa.edu.bo

Resumen— Al adquirir el software educativo dentro del campo de desarrollo de software una gran importancia y siendo este inspiración de propuestas de innumerables metodologías que buscan la elaboración de un software de calidad. Tomaremos la metodología Áncora, 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 comprensión de dicha metodología, analizando la aplicación del Áncora en un trabajo propuesto para el Instituto Tecnológico de Orizaba, México.

Áncora es una metodología enfocada a la adquisición de requerimientos para software, que ofrece guías y elementos de apoyo para la obtención de estos requerimientos. Al mismo tiempo permite pasar a la fase de diseño de manera sencilla. Aprovechando las ventajas que presenta Áncora, se le hicieron algunas adaptaciones, con el fin de cubrir algunas características del diseño instruccional y enriquecer Áncora, habilitándola para la adquisición de requerimientos de software educativo.

Palabras clave — Áncora, Metodología, Desarrollo de Software, Educativo, Requerimientos, Calidad.

XVII. XVI.

INTRODUCCIÓN

Hoy en día la tecnología esta dentro de las actividades que realizamos, es así que la educación no queda exenta de ella, por o cual es necesario adaptarse al movimiento tecnológico, que nos trae grandes ventajas en la transmisión de conocimientos de una manera sencilla y dinámica. De esta manera han surgido infinidad de metodologías 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 metodologías surge en el ejemplo propuesto, la adaptación del Áncora en el desarrollo de software educativo, teniendo como objetivo principal la comprensión de los elementos y conceptos de la metodología Áncora.

APLICACIÓN DE LA METODOLOGÍA ÁNCORA

Como es el objetivo principal la comprensión de la aplicación de la metodología Áncora dentro del desarrollo de software educativo de calidad solo describiremos los métodos del método y los resultados obtenidos. Claro esta que para ahondar más en tema del software educativo en si el lector puede recurrir a los siguientes autores: Metodología de desarrollo de sistemas multimedia (Vaughan, 2006), Propuesta de metodología para el diseño, desarrollo y evaluación de software educativo (Reyes, 2009), Ingeniería de software educativo con modelaje orientado por objetos (Gómez, 1998), asi como también los siguientes modelos: ADDIE (Análisis, Diseño, Desarrollo, Implantación y Evaluación) de (McGriff, 2000) y el diseño instruccional aplicado al desarrollo de software educativo EISE (Especificación Instruccional de Software Educativo) de (Hernández, 2005).

28 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE

Quienes tienen el mismo objetivo, de crear software educativo de calidad, podemos sintetizar de ellos los siguientes puntos: * Análisis del público al que se dirigirá el software. * Problema ó necesidad educativa a atender. * Análisis de contenido (Tema a tratar, actividades para alcanzar el objetivo de enseñanza y forma de evaluarlo). * Actividades ó forma actual de llevar a cabo la enseñanza del tema en cuestión. * Elaboración de guiones, metáforas, escenarios. * Creación de prototipo ó Storyboard. * Diseño de interfaz. * Mapas de navegación. * Modelos de datos. * Elaboración de diagramas de contexto, diagramas de flujo o diagramas de casos de uso. Ahora enfocándonos en el áncora, se establece la propuesta de seleccionar las actividades de Áncora que permitan obtener los requerimientos de un software educativo. La Tabla 1 presenta las actividades y artefactos producidos en las fases de Áncora para la elaboración de software educativo.

TABLA 1. ACTIVIDADES Y ARTEFACTOS DE LA METODOLOGÍA ÁNCORA PARA EL DESARROLLO DE SOFTWARE EDUCATIVO.

Fases

Análisis de Requerimientos

Metodología Áncora Actividades y artefactos A través de entrevistas con los clientes (maestros y pedagogos) y de la lectura del respectivo material proporcionado por ellos, se definirá la asignatura a la que se enfocará el software, el tema a tratar y la forma en que se abordará y evaluará. También se establecerá el objetivo general de aprendizaje, la metáfora que se empleará y, se determinará el público al que se dirigirá el software. Artefactos: Documento que define la asignatura,

Recolección y clasificación de requerimientos

Resolución de conflictos, jerarquización y validación de requerimientos

Cierre

contenido, objetivo general de aprendizaje, metáfora y público al que se dirigirá el software. Guion de la situación actual. El guion de la propuesta computacional reflejará la metáfora que se sigue, el ambiente de cada escena. La bitácora de desarrollo permitirá ver cómo el sistema responderá a las diversas acciones que realice el usuario. En lugar del prototipo rápido se elaborará un Storyboard para presentar gráficamente la estructura de sistema propuesto. Artefactos Guion de propuesta computacional, bitácora de desarrollo, Storyboard. 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 señalas. Trasladar los guiones a casos de uso. Artefactos Casos de uso.

Se agregaron algunas características a ciertos artefactos de Áncora 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 básicos o mínimos que debe tener el alumno para poder interactuar con el módulo. * Objetivo de aprendizaje: Es el aprendizaje que debe obtener el alumno después de haber interactuado con el módulo. La Figura 1 se presenta la estructura sugerida para el guion de la propuesta computacional. En la bitácora de desarrollo se propone añadir 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 más completa la estructura del guion de la propuesta computacional. La

29 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE Figura 2 muestra el formato para la elaboración del Storyboard.

Figura 1. Estructura del guion para la propuesta computacional

b) Temas: Números naturales, capacidad, peso, tiempo y ubicación espacial; planteamiento y resolución de problemas sencillos en los que se requiera recolectar y registrar información periódicamente; representación de información en tablas de frecuencia y gráficas de barras; registros de los resultados de experimentos aleatorios; representación de los resultados de un experimento aleatorio en tablas y gráficas. c) Subtemas: Planteamiento y resolución de problemas que impliquen dos o más operaciones con números naturales. d) Ejes: Introducción del kilómetro como la unidad que permite medir grandes distancias y recorridos largos; capacidad, peso y tiempo; uso del reloj y el calendario, los números sus relaciones y sus operaciones; medición; la predicción y el azar; tratamiento de la información. * Objetivo general de aprendizaje: Ejercitar las operaciones aritméticas básicas, interpretar la información y los resultados de la información dada, aplicada en situaciones de la vida cotidiana.

Con las actividades hasta ahora realizadas, se ha observado que los artefactos de Áncora son flexibles y pueden, por lo tanto, adaptarse de acuerdo a las necesidades que implican la adquisición de requerimientos de un software educativo. También se Figura 2. Formato para la elaboración del Storyboard. aprecian las ventajas de algunos artefactos, como la bitácora de desarrollo, que permite determinar las respuestas del sistema ante las acciones del usuario y XVIII. RESULTADOS estimar también el tiempo que llevará implementar cada quinteta. La estimación del tiempo ayuda a tener un valor Aplicando Áncora en un ejemplo para la parte de aproximado del tiempo de desarrollo de software. requerimientos se obtuvo la siguiente información: Agregar el objetivo de aprendizaje a la bitácora de * Asignatura: Matemáticas desarrollo puede parecer repetitivo después de * Contenido. Está articulado con base en seis ejes, con sus respectivos temas y subtemas que varían de incluirlo en el Storyboard pero esto nos permite ver las acuerdo al grado escolar. Considerando lo anterior se situaciones u obstáculos que pueden impedir que el objetivo de aprendizaje se alcance y por tanto, tenerlos tiene lo siguiente: a) Grado escolar: De segundo hasta quinto grado de presente durante el diseño. A pesar de las ventajas de la bitácora de desarrollo, un inconveniente hasta ahora primaria. encontrado, es lo tedioso al manejar muchas quintetas,

30 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE

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 presentación con los clientes, el guion es un artefacto que pude dar un panorama XIX.

general del software que se va a elaborar y queda reforzada a través 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 fácil de ubicar las secciones y respectivos elementos.

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 información de los requerimientos del cliente enfocándonos mas en este. Es también importante mencionar los avances que tiene y seguirá teniendo el software educativo aplicado no solo a nivel escolar sino también al superior. Habiendo revisado el concepto y la aplicación de la metodología Áncora en el desarrollo de software educativo, se llegó a una comprensión mas extensa de dicho método el cual es de gran importancia dentro de la ingeniería de Software ya que nos REFERENCIAS http://www.uv.mx/mis/productividad/documents/CarmenChay_CIIM2010.pdf.

31 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE

Redes Bayesianas en la Ingeniería del Software Luis Miguel Ticona#1 Universidad San Francisco de Asís Av. 20 de Octubre esq. Belisario Salinas (Plaza Avaroa) La Paz - Bolivia 1

lticona©usfa.edu.bo Resumen - Recientemente modelos gráficos que combinan la Una vez que se tienen evidencias el estado de ciertas probabilidad y la teoría de grafos, están siendo aplicados a variables, es decir cuando tenemos conocimiento o problemas de la ingeniería del software donde la incertidumbre podemos observar su estado, se actualizan las tablas de está presente. En el presente artículo veremos de manera general probabilidad propagando las nuevas probabilidades. sobre las redes bayesianas, sus fundamentos en la teoría de la probabilidad y además se describirá diferentes extensiones de las redes bayesianas así como su aplicación a la ingeniería del software y técnicas de minería de datos. Palabras clave.- redes bayesianas, gráficos acíclicos, nodos, grafo, probabilidades, inferencia, discretización, dominio.

Introducción

Las redes bayesianas son gráficos acíclicos 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 parámetro medible (o medido), una variable latente o una hipótesis. 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 estimación de errores en la ingeniería del software. Cada nodo del grafo representa una variable del dominio: defectos insertados, detectados y residuales (número de defectos que permanecen en el código una vez entregado al cliente).Cada arco del grafo representa una relación causal entre variables; los defectos insertados influyen en el número de defectos detectados durante el testeo y el número de defectos residuales, a su vez, el número defectos influye en el número 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, también mostradas en la Figura 1.

Fig. 1 Red Bayesiana simplificada para la estimación de defectos

Fig. 2 Modo de ejecución sin evidencias introducidas

En general los programas para manipular redes Bayesianas tienen dos modos de operar: un modo de edición que permite la creación de redes y la especificación 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 están distribuidas uniformente y no se puede decir mucho del estado del dominio.

Fig. 3 Modo de ejecución con evidencias introducidas

32 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE

Sin embargo, si tenemos la certeza (100% de probabilidad) de que el número de defectos insertados es bajo, y de que un alto número de defectos fueron detectados durante el testeo, la red Bayesiana propaga las probabilidades estimando que el número de defectos residuales será bajo con una probabilidad de 0,8 y alto con una probabilidad de 0,2. La figura 3 muestra dicho escenario, las barras que marcan un 100%, indican variables con estado conocido; el resto muestran las nuevas probabilidades después de propagar las evidencias. Nótese que la salida es una distribución de probabilidades en vez de un único valor. Naturalmente, consideraremos el valor con mayor probabilidad como valor estimado. II. Fundamentos de las redes Bayesianas



Los algoritmos de propagación exactos más simples incluyen Inferencia mediante Enumeración y Eliminación de variables (Russel y Norvihg 2003). Los algoritmos de propagación exacta funcionan bien con redes de hasta aproximadamente 30 nodos, sin embargo no son apropiados para redes con más nodos o altamente conexas. Para estos casos se han desarrollado algoritmos aproximados. Los métodos aproximados se clasifican en métodos de simulación estocástica y los métodos de búsqueda determinística. VI. Minería de Datos

Hay dos tipos de evidencia: Evidencia firme o específica (instanciación).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 número infinito de estados, el problema reside en la especificación de las tablas de probabilidad condicional. Hay dos formas de contrarrestar estos problemas: La discretización consiste en dividir el rango de las variables continuas en un número finito en un dominio a modelar puede tomar cualquier valor entre 0 y 100, es posible dividir el rango en un número finito de intervalos: (0 - 20), (20 - 40) y (40 – 100). Naturalmente al discretizar

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 probabilística es decir que algunas variables pueden ser calculadas dadas la evidencias de otras variables.

Formalmente una red Bayesiana es un grafo dirigido acíclico. Los nodos representan variables aleatorias del dominio X1, X2,…, 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 está 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 distribución conjunta para un conjunto de X1, X2,…, Xn tal que: P(x1, x2 …,xn ) = ∏ i=1…n 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 número reducido de valores en las tablas de probabilidad. III. Tipos de Evidencia

se pierde información que depende del dominio y el número de intervalos. Es el método más común ya que la mayoría de las herramientas y algoritmos se basan en nodos discretos. El segundo método consiste en usar modelos paramétricos como la distribución Gausiana, que es representada por dos parámetros, la media y la varianza.



Sin embargo a menudo se tienen base de datos del dominio (en la ingeniería del software por ejemplo, históricos de proyectos), para automatizar en cierta medida la creación de redes Bayesianas siguiendo los pasos típicos de la minería de datos que son los siguientes: Preparación de los datos. Los son formateados de forma que las herramientas puedan manipularlos, juntar diferentes bases de datos, etc. Selección y limpieza de los datos. Este paso consiste en la selección de variables, discretizar los datos, decidir sobre valores anómalos, ruido, etc.

33 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE 



Minería de datos. En este paso se produce la extracción del conocimiento, donde se aplican los algoritmos. El proceso de minería de datos está compuesto de dos tareas principales: Introducción del mejor modelo cualitativo partiendo de los datos y/o conocimiento previo de los expertos del dominio. Estimación de las tablas de probabilidades, se definen las tablas de probabilidad, siendo el método más sencillo. Interpretación de los resultados, en el caso de las redes bayesianas consistirá en realizar inferencias basándose en las evidencias obtenidas. Asimilación y explotación de los resultados. En la figura 4 muestra los pasos, indicando que el experto de dominio necesita complementar los algoritmos de minería de datos.

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.

Fig. 4 Pasos típicos en la construcción de redes Bayesianas partiendo de base de datos.

Como ejemplo de la creación de redes Bayesianas en la ingeniería del software, imaginemos que una compañía con una base de datos de proyectos con los atributos definidos en la Tabla 1 y un sub conjunto de los datos podría ser como los que se muestra:

En la figura 5 se muestra la pantalla de la herramienta Hugi (2006) para refinar la red obtenida por el algoritmo de minería de aprendizaje de la red. Fi g. 5 P a nt al la d e H u gi n p ar a re so lv er in

Tabla 1 Ejemplo de atributos de una base de datos de proyectos

Vari able Com pleji dad Tam año Esfu erzo Dura ción Pers onal

Dise ño Def Intro

EsfT est

Descripción

Tipo

Tipo de proyecto(orgá nico, mediano y complejo) No de líneas de código(en miles) Horas

Discreta

No de meses No de personas a tiempo completo requeridas para llevar a cabo el proyecto Calidad No de defectos introducidos durante el desarrollo Calidad experiencia el equipo de testeo

Continu a Continu a Continu a Continu a certidumbres de la estructura de red.

Discreta Continu a

Discreta

Por ejemplo, la Figura 6 muestra que si el Tamaño (Tamano_d, es la variable dis-cretizada) está entre las 33.5 y 44.5 miles de líneas de código, la probabilidad de que la duración sea menor de 12.35 (etiquetado como ‗<12.35‘) es de 0.96, la pro-babilidad de que esté entre 12.35 y 16.25 es de 19.62, la probabilidad de que esté entre 19.15 y 21.45 es de 0.96 y de que sea mayor de 21.45 es solamente 0.96. Na-turalmente, la predicción es que la duración estimada estará dentro el intervalo con mayor probabilidad. Para obtener valores concretos podría usarse la esperanza ma-temática: E[X]=∑ixip(xi), donde xi podría ser el valor medio del intervalo.

34 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE ingeniería del software, Neil et al (2000) han aplicado las redes Bayesianas orientadas a objetos y han propuesto una metodología basada en una serie de modismos para ayudar a los expertos del dominio a crear redes complejas con un gran número 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 decisión para modelar explícitamente la toma de decisiones.

Fig. 8 Tipos de nodos en un diagrama de influencias.

Fig. 6 Ejemplo de inferencia utilizando Hugin

VII.

Redes Bayesianas Orientadas a Objetos

Las Redes Bayesianas Orientadas a Objetos (OOBN, en sus siglas en inglés) facilitan la representación de redes con un gran número 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 módulos 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 también 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.

Por ejemplo, imagínese un escenario en la ingeniería del software donde el gestor de proyectos necesita decidir si lleva a cabo inspecciones (reuniones formales don-de se evalúa el diseño o código) o no. Es de sobra conocido que las inspecciones de código reducen el número de defectos, y que corregir un error en un sistema ya en producción es mucho más caro que lo que sería durante el testeo; sin embargo, las inspecciones son costosas debido al número de horas invertidas por el personal. Por tanto, puede ser beneficioso recabar información adicional antes de decidirse por la realización de inspecciones. La Tabla 4 muestra la función de utilidad combinando el coste de realizar inspecciones junto con el hecho de que si entregamos al cliente un producto con alto número de errores, se perdería dinero en el proyecto. A menor número de errores, mayor beneficio proporcionará el proyecto. Tabla 4 Función de utilidad

Un posible escenario se muestra en el diagrama de influencia de la Figura 9, con el nodo de decisión Inspeccionar y el nodo valor Coste asociado con el nodo Residual. Fi g. 9 Di ag ra m a de in fl

35 INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE uencia con bajo número de errores introducidos

Por otro lado, si sabemos que el número de defectos introducidos durante el desarrollo es bajo, el proyecto generará beneficios se hagan o no inspecciones, pero generará mayor beneficio si no se llevan a cabo las inspecciones (la Figura 10 muestra este escenario).

Fig. 10 Diagrama de influencia con un alto número de errores introducidos

IX.

Aplicaciones de las redes Bayesianas a la Ingeniería del Software Las redes bayesianas son un tipo de modelos de minería de datos que pueden ser utilizados en cualquiera de las siguientes actividades de negocio: Prevención del fraude Prevención del abandono de clientes Marketing personalizado Mantenimiento2 Scoring de clientes Clasificación de datos estelares

      X.

Propiedades y limitaciones de las redes Bayesianas Las redes Bayesianas tienen un número de características que hacen que sean apropiadas para la ingeniería del software:

Representación gráfica. Modelado cualitativo y cuantitativo Inferencia bidireccional Análisis 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 teoría 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 ingeniería del software. Aunque este tipo de modelos han sido conocidos desde hace mucho tiempo, solamente han podido ser aplicados desde finales de los años 80, gracias al desarrollo de nuevos algo-ritmos que permiten la creación y propagación de probabilidades en redes suficientemente complejas como para representar problemas reales. En este capítulo se han introducido sus extensiones y uso en la ingeniería del software donde han sido aplicadas. Se ha proporcionado una visión general de la metodología para su construcción así como algunos algoritmos que podrían considerarse como parte de la mine-ría de datos. Además, se han comparado con otras técnicas más tradicionales dentro de la ingeniería del software y se han descrito sus ventajas e inconvenientes. Reconocimientos Fenton (1999) ha descrito: ―La clave de un uso más eficiente de métricas del software, no se encuentra en métricas más potentes, sino en la combinación inteligente de diferentes métricas . Una vez dominada dicha combinación, se pueden estudiar métodos estadísticos avanzados para obtener buenas predicciones. Las redes Bayesianas son uno de los métodos 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. http://www.hugin.com/. [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 http://www.wikipedia.org/

36 INGENIERÍA DE SISTEMAS

]

INGENIERÍA DE SOFTWARE

37 INGENIERÍA DE SISTEMAS