REVISTA LATINOAMERICANA DE INGENIERIA DE SOFTWARE
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
REVISTA LATINOAMERICANA DE INGENIERIA DE SOFTWARE JUNIO 2013 VOLUMEN 1 NUMERO 3 ISSN 2314-2642 PUBLICADO POR EL GISI-UNLa EN COOPERACIÓN POR LOS MIEMBROS DE LA RED DE INGENIERÍA DE SOFTWARE DE LATINOAMÉRICA ARTÍCULOS TÉCNICOS La Esencia de la Ingeniería de Software: El Núcleo de Semat 71-78 Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence y Svante Lidman Traducción de: Carlos Mario Zapata Jaramillo Modelo de Proceso de Conceptualización de Requisitos 79-101 Alejandro Hossian Procedimiento de Explotación de Información para la Identificación de Campos anómalos 102-106 en Base de Datos alfanuméricas Horacio Kuna, German Pautsch, Alice Rambo, Martin Rey, J. Cortes, S. Rolón Un Modelo de Ciclo de Vida y Mapa de Actividades para Proyectos de Explotación de 107-124 Información Hernán Arboleya
REVISTA LATINAMERICANA DE INGENIERIA DE SOFTWARE La Revista Latinoamericana de Ingenieria del Software es una publicación tecnica auspiciada por la Red de Ingeniería de Software de Latinoamérica (RedISLA). Busca: [a] difundir artículos técnicos, empíricos y teóricos, que resulten críticos en la actualización y fortalecimiento de la Ingeniería de Software Latinoamericana como disciplina y profesión; [b] dar a conocer de manera amplia y rápida los desarrollos científico-tecnológicos en la disciplina de la región latinoamericana; y [c] contribuir a la promoción de la cooperación institucional entre universidades y empresas de la Industria del Software. La línea editorial, sin ser excluyente, pone énfasis en sistemas no convencionales, entre los que se prevén: sistemas móviles, sistemas, plataformas virtuales de trabajo colaborativo, sistemas de explotación de información (minería de datos), sistemas basados en conocimiento, entre otros; a través del intercambio de información científico y tecnológica, conocimientos, experiencias y soluciones que contribuyan a mejorar la cadena de valor del desarrollo en la industria del software. Comité Editorial RAUL AGUILAR VERA (México) BELL MANRIQUE LOSADA (Colombia) JOSÉ ANTONIO POW-SANG (Perú) Cuerpo Academico de Ingenieria de Software Programa de Ingeniería de Sistemas Maestría en Informática Facultad de Matemáticas Facultad de Ingeniería Pontifica Universidad Católica del Perú Universidad Autonoma de Yucatán Universidad de Medellín DIEGO VALLESPIR (Uruguay) PAOLA BRITOS (Argentina) CLAUDIO MENESES VILLEGAS (Chile) Instituto de Computación Grupo de Ingeniería de Explotación de Información Departamento de Ingeniería de Sistemas y Computación Universidad de la Republica Laboratorio de Informática Aplicada Facultad de Ingeniería y Ciencias Geológicas Universidad Nacional de Río Negro Universidad Católica del Norte CARLOS MARIO ZAPATA JARAMILLO (Colombia) Departamento de Ciencias de la Computación y de la RAMON GARCÍA-MARTINEZ (Argentina) JONÁS MONTILVA C. (Venezuela) Decisión Grupo de Investigación en Sistemas de Información Facultad de Ingeniería Facultad de Minas Licenciatura en Sistemas Escuela de Ingeniería de Sistemas Universidad Nacional de Colombia Departamento de Desarrollo Productivo y Tecnológico Universidad de Los Andes Universidad Nacional de Lanús MARÍA FLORENCIA POLLO-CATTANEO (Argentina) ALEJANDRO HOSSIAN (Argentina) Grupo de Estudio en Metodologías de Ingeniería de Grupo de Investigación de Sistemas Inteligentes en Software Ingeniería Facultad Regional Buenos Aires Facultad Regional del Neuquén Universidad Tecnológica Nacional Universidad Tecnológica Nacional Contacto Dirigir correspondencia electrónica a: Dirigir correspondencia postal a: Editor de la Revista Latinoamericana de Ïngenieria de Software Editor de la Revista Latinoamericana de Ïngenieria de Software RAMON GARCIA-MARTINEZ RAMON GARCIA-MARTINEZ e-mail: rgarcia@unla.edu.ar Licenciatura en Sistemas. Departamento de Desarrollo Productivo y Tecnológico e-mail alternativo: rgm1960@yahoo.com Universidad Nacional de Lanus Página Web de la Revista: http://www.unla.edu.ar/sistemas/redisla/ReLAIS/index.htm Calle 29 de Septiembre No 3901. (1826) Remedios de Escalada, Lanús. Página Web Institucional: http://www.unla.edu.ar Provincia de Buenos Aires. ARGENTINA. Normas para Autores Cesión de Derechos de Autor No retiene los derechos de reproducción o copia (copyright), por lo que los autores podrán Los autores toman conocimiento y aceptan que al enviar una contribución a la Revista disponer de las versiones finales de publicación, para difundirlas en repositorios institucionales, Latinoamericana de Ingenieria del Software, ceden los derechos de autor para su publicación blogs personales o cualquier otro medio electrónico, con la sola condición de hacer mención a la electrónica y difusión via web por la Revista. Los demas derechos quedan en posesión de los fuente original de publicación, en este caso Revista Latinoamericana de Ingeniería de Software. Autores. Lista de Comprobación de Preparación de Envíos Políticas de revisión, evaluación y formato del envío de manuscritos Como parte del proceso de envío, se les requiere a los autores que indiquen que su envío cumpla con La Revista Latinoamericana de Ingenieria del Software recibe artículos inéditos, producto del trabajo todos los siguientes elementos, y que acepten que envíos que no cumplan con estas indicaciones de investigación y reflexión de investigadores en Ingenieria de Software. Los artículos deben pueden ser devueltos al autor: presentarse redactados en el castellano en el formato editorial de la Revista. El incumplimiento del 1. La contribución respeta el formato editorial de la Revista Latinoamericana de Ingenieria del formato editorial en la presentación de un artículo es motivo de retiro del mismo del proceso de Software (ver plantilla). evaluación. Dado que es una publicación electrónica no se imponen limites sobre la cantidad de 2. Actualidad/Tipo de referencias: El 45% de las referencias debe hacerse a trabajos de publicados paginas de las contribuciones enviadas. También se pueden enviar comunicaciones cortas que den en los últimos 5 años, así como a trabajos empíricos, para cualquier tipo de artículo (empírico o cuenta de resultados parciales de investigaciones en progreso. teórico). Las contribuciones recibidas están sujetas a la evaluación de pares. Los pares que evaluaran cada 3. Características artículos empíricos (análisis cuantitativo de datos): Se privilegian artículos contribución son seleccionados por el Comité Editorial. El autor que envíe la contribución al contacto empíricos con metodologías experimentales y cuasi experimentales, con pruebas estadísticas de la Revista será considerado como el autor remitente y es con quien la revista manejará toda la robustas y explicitación del cumplimiento de los supuestos de las pruebas estadísticas usadas. correspondencia relativa al proceso de evaluación y posterior comunicación. 4. Características artículos empíricos (análisis cualitativo de datos): Se privilegian artículos Del proceso de evaluación, el articulo enviado puede resultar ser: [a] aceptado, en cuyo caso será empíricos con estrategias de triangulación teórica-empírica, definición explícita de categorías publicado en el siguiente numero de la revista, [b] aceptado con recomendaciones, en cuyo caso se orientadoras, modelo teórico de análisis, y análisis de datos asistido por computadora. enviará al autor remitente la lista de recomendaciones a ser atendidas en la nueva versión del 5. Características artículos de revisión: Para el caso de artículos de revisión, se evaluará que los articulo y su plazo de envio; ó [c] rechazado, en cuyo caso será devuelto al autor remitente mismos hayan sido desarrollados bajo el formato de meta análisis, la cantidad de referencias fundando el motivo del rechazo. deben superar las 50, y deben explicitarse los criterios de búsqueda, bases consultadas y pertinencia disciplinar del artículo. Temática de los artículos 6. El artículo (en formato word y pdf) se enviará adjunto a un correo electrónico dirigido al contacto La Revista Latinoamericana de Ingeniería del Software busca artículos empíricos y teóricos que de la Revista en el que deberá constar la siguiente información: dirección postal del autor, resulten críticos en la actualización y fortalecimiento de la Ingeniería de Software Latinoamericana dirección de correo electrónico para contacto editorial, número de teléfono y fax, declaración de como disciplina y profesión. que el artículo es original, no ha sido previamente publicado ni está siendo evaluado por otra La línea editorial pone énfasis en sistemas no convencionales, entre los que se prevén: sistemas revista o publicación. También se debe informar de la existencia de otras publicaciones similares móviles, sistemas multimediales vinculados a la televisión digital, plataformas virtuales de trabajo escritas por el autor y mencionar la versión de la aplicación de los archivos remitidos (versión del colaborativo, sistemas de explotación de información (minería de datos), sistemas basados en editor de texto y del conversor a archivo pdf) para la publicación digital del artículo. conocimiento, entre otros. Se privilegiarán artículos que contribuyan a mejorar la cadena de valor 7. Loa Autores aceptan que el no cumplimiento de los puntos anteriores es causal de No Evaluación del desarrollo en la industria del software. del articulo enviado. Política de Acceso Abierto Compromiso de los Autores de Artículos Aceptados La Revista Latinoamericana de Ingeniería de Software: La Revista Latinoamericana de Ingeniería del Software busca ser una revista técnica de calidad, en Sostiene su compromiso con las políticas de Acceso Abierto a la información científica, al cuyo desarrollo estén involucrados los investigadores y profesionales latinoamericanos de la considerar que tanto las publicaciones científicas como las investigaciones financiadas con disciplina. En este contexto, los Autores de artículos aceptados asumen ante la Revista y la fondos públicos deben circular en Internet en forma libre, gratuita y sin restricciones. Comunidad Latinoamericana de Ingeniería del Software el compromiso de desempeñarse como pares Ratifica el modelo de Acceso Abierto en el que los contenidos de las publicaciones científicas se evaluadores de nuevas contribuciones. encuentran disponibles a texto completo libre y gratuito en Internet, sin embargos temporales, y cuyos costos de producción editorial no son transferidos a los autores.
La Esencia de la Ingeniería de Software: El Núcleo de Semat Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Traducción de: Carlos Mario Zapata Jaramillo Spence y Svante Lidman Facultad de Minas Integrantes de la iniciativa Semat (Método y Teoría de la Universidad Nacional de Colombia Ingeniería de Software) Medellín, Colombia cmzapata@unal.edu.co Artículo publicado originalmente en Communications of the ACM, vol. 55, no. 12, december 2012, pp. 42-49. El traductor declara tener autorización de los autores para difundir la versión en español en la Revista Latinoamericana de Ingeniería de Software, sin que ello presente incompatibilidades o vulnere los derechos de Communications of the ACM. Resumen— Esta es una traducción del artículo que se publicó que la gente trabaja con métodos de desarrollo de software [3, en Communications of the ACM en Diciembre de 2012 bajo el 4, 8]. Ellos escribieron una declaración del llamado a la acción, título “The Essence of Software Engineering: The SEMAT que en pocas líneas identifica una cantidad de problemas Kernel” y se realiza debido a la importancia que adquiere el tema críticos, explica por qué se necesita actuar y sugiere qué se para la audiencia de hispanoparlantes, de forma que se pueda generar un acceso a lo que constituye uno de los últimos necesita para hacerlo. El llamado a la acción es: adelantos en Ingeniería de Software. Algunas áreas de la ingeniería de software hoy en día sufren prácticas inmaduras. Los problemas específicos Palabras clave— Núcleo, alfa, espacio de actividad, estado, incluyen: Semat • La prevalencia de bogas más típicas en la industria de la moda que en una disciplina ingenieril. I. INTRODUCCIÓN • La carencia de una base teórica sonora y ampliamente aceptada. • La gran cantidad de métodos y variantes de métodos, con Todo aquel que desarrolla software sabe que es un negocio diferencias que poco se entienden y que se magnifican complejo y riesgoso y que sus participantes siempre buscan artificialmente. nuevas ideas que los conduzcan a desarrollar mejor software. • La carencia de evaluación y validación experimentales y Por fortuna, la ingeniería de software es aún una profesión creíbles. joven y creciente que mira las innovaciones y mejoras en las • La separación entre la práctica industrial y la investigación mejores prácticas cada año. Por ejemplo, basta mirar las académica. mejoras y beneficios que el pensamiento lean y ágil tuvo sobre los equipos de desarrollo de software. La afirmación del llamado a la acción de Semat de que la industria de software es propensa a bogas y modas hace que la Los equipos exitosos de desarrollo de software necesitan gente asuma que Semat se opone a las nuevas ideas. Esto no establecer un balance entre las entregas rápidas de sistemas de podría estar más lejos de la verdad. Como usted podrá ver en software que trabajen bien, la satisfacción de sus interesados, el este artículo y en el libro que pronto se publicará, llamado “La tratamiento de sus riesgos y la mejora de sus formas de trabajo. esencia de la ingeniería de software: aplicando el núcleo de Para eso, ellos necesitan un marco de pensamiento efectivo que Semat” [6], los partidarios de Semat son muy entusiastas con cierre la brecha entre su actual forma de trabajo y cualquier las nuevas ideas. Ellos están en contra del comportamiento idea nueva que quieran adoptar. Este artículo presenta ese contrario a lo lean y a lo ágil. Este comportamiento proviene de marco de pensamiento en forma de un núcleo accionable, que gente que adopta soluciones inapropiadas porque creen que podría beneficiar cualquier equipo que desee balancear sus esas soluciones están de moda o porque los presionan sus pares riesgos y mejorar su forma de trabajo. o la corrección política. El trabajo en el núcleo, la esencia de la ingeniería de Semat apoya un proceso para redefinir la ingeniería de software, se inspiró y es una respuesta directa al llamado a la software, basado en una teoría sólida, principios probados y acción de los Métodos y Teoría de la Ingeniería de Software mejores prácticas que: (Semat, por sus iniciales en inglés; nota del traductor: si bien el origen de la palabra Semat lo constituyen las iniciales de las • Incluyan un núcleo de elementos ampliamente aceptados y palabras que conforman la sigla, acogiendo el espíritu de la que se pueda extender a usos específicos. iniciativa, se prefiere colocarlo con mayúscula inicial, pues se • Traten asuntos tecnológicos y humanos. pretende que, más que un acrónimo, se convierta en un • Los apoyen la industria, la academia, los investigadores y sustantivo), el cual es, a su modo, un pequeño paso hacia la los usuarios. redefinición de la ingeniería de software. • Apoyen la extensión ante los requisitos cambiantes y la Ivar Jacobson, Bertrand Meyer y Richard Soley fundaron tecnología. Semat en septiembre de 2009, cuando sintieron que había El llamado a la acción de Semat recibió un amplio apoyo, llegado el momento de cambiar fundamentalmente la forma en incluyendo una lista creciente de signatarios y partidarios Carlos Mario Zapata Jaramillo (Traductor), Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, Svante Lidman. 2013. La Esencia de la 71 Ingeniería de Software: El Núcleo de Semat. Revista Latinoamericana de Ingeniería de Software, 1(3): 71-78, ISSN 2314-2642
(http://www.semat.org). En febrero de 2010, los fundadores de • Un marco de pensamiento para que los equipos razonen Semat desarrollaron el llamado a la acción por medio de una sobre el progreso que están haciendo y la salud de sus declaración de visión [5]. De acuerdo con esta visión, Semat se esfuerzos. enfoca en dos objetivos principales: encontrar un núcleo de • Un terreno común para la discusión, mejoramiento, elementos ampliamente aceptados y la definición de una base comparación e intercambio de métodos y prácticas de teórica sólida. ingeniería de software. En gran medida, esas dos tareas son independientes una de • Un marco para que los equipos ensamblen y mejoren otra. Encontrar el núcleo y sus elementos es un ejercicio continuamente su forma de trabajo, mediante la pragmático que requiere desarrolladores experimentados de composición de prácticas definidas por separado y de software con conocimiento de muchos de los métodos diverso origen. existentes. Definir la base teórica es una investigación • Un fundamento para la definición de medidas que no académica y podría tomar muchos años para conseguir un dependan de las prácticas, para evaluar la calidad del resultado exitoso. software producido y los métodos que se usan para II. EL PODER DE UN TERRENO COMÚN producirlo. • Más importante aún, una forma de ayudarle a los equipos a El primer paso de Semat era identificar un terreno común comprender dónde están, qué deberían hacer luego y para la ingeniería de software. Este terreno común se dónde necesitan mejorar. manifestaba como un núcleo de elementos esenciales que son universales a todos los esfuerzos de desarrollo de software y un III. LA IDEA GENERAL lenguaje sencillo para describir métodos y prácticas. El núcleo se publicó inicialmente en la entrega [2, 9] que hizo Semat al ¿Qué hace del núcleo algo más que sólo un modelo OMG (Grupo de Gestión de Objetos, por sus siglas en inglés). conceptual de la ingeniería de software? ¿Qué es lo realmente Como se muestra en las figuras 1 y 2, el núcleo contiene un nuevo acá? Esto se puede resumir en sus principios pequeño número de “cosas con las que siempre trabajamos” y fundamentales (véase la Figura 3), que realmente suministran “cosas que siempre hacemos” cuando se desarrollan sistemas tres características únicas del núcleo: es accionable, es de software. También se está adelantando trabajo para definir extensible y es práctico. las “habilidades que siempre necesitamos tener”, pero esto tendrá que esperar hasta futuras versiones del núcleo. Más que un modelo conceptual, el núcleo provee: Fig. 1. Cosas con las que siempre trabajamos. 72 Carlos Mario Zapata Jaramillo (Traductor), Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, Svante Lidman. 2013. La Esencia de la Ingeniería de Software: El Núcleo de Semat. Revista Latinoamericana de Ingeniería de Software, 1(3): 71-78, ISSN 2314-2642
Fig. 2. Cosas que siempre hacemos. El núcleo no presenta el desarrollo de software como un proceso lineal, sino como una red de elementos que colaboran y que se deben balancear y mantener, de modo que los equipos puedan hacer progresos efectivos y eficientes, eliminar desperdicios y desarrollar muy buen software. Los alfas en el núcleo proveen un marco general para dirigir y hacer progresar los esfuerzos de desarrollo de software, sin importar las prácticas que se apliquen o la filosofía que se siga. A medida que se agregan prácticas al núcleo, se agregarán nuevos alfas para representar las cosas que dirijan o inhiban el progreso de los alfas del núcleo. Por ejemplo, el alfa “requisitos” no se tratará en conjunto, sino que avanzará ítem por ítem. El progreso de los ítems individuales de requisitos conducirá o inhibirá el progreso y salud del alfa “requisitos”. Los ítems de requisitos pueden ser de diferentes tipos, por ejemplo, características, historias de usuario o porciones de Fig. 3. Principios fundamentales que apoyan el núcleo. casos de uso. Cada tipo se puede representar como un alfa y tener unos estados a seguir. El beneficio de relacionar esos El núcleo es accionable. Una característica única del ítems pequeños con el núcleo de granularidad más gruesa núcleo es la forma en que maneja las “cosas con qué trabajar”. radica en que permite seguir la salud del esfuerzo en conjunto. Ellas se capturan como alfas en lugar de productos de trabajo Esto proporciona un balance necesario al seguimiento de bajo (tales como documentos). Un alfa es un elemento esencial del nivel de los ítems individuales, permitiendo a los equipos esfuerzo de ingeniería de software, el cual es relevante para entender y optimizar sus formas de trabajo. una evaluación de su progreso y salud. Como se muestra en la El núcleo es extensible. Otra característica única del Figura 1, Semat identificó siete alfas: oportunidad, interesados, núcleo es la manera en que se puede extender para apoyar requisitos, sistema de software, trabajo, forma de trabajo y diferentes proyectos (por ejemplo, nuevos desarrollos, mejoras equipo. a sistemas legados, desarrollos internos, desarrollos externos, Los alfas se caracterizan por un simple conjunto de estados líneas de productos de software, etc.). El núcleo le ayuda a que representan su progreso y salud. Por ejemplo, el sistema de agregar prácticas, tales como historias de usuario, casos de uso, software se mueve entre los estados “con arquitectura desarrollo basado en componentes, arquitectura, programación seleccionada”, “demostrable”, “usable”, “listo”, “operacional” por pares, reuniones diarias de pie, equipos auto organizados y y “retirado”. Cada estado tiene una lista de chequeo que otras. Se buscan prácticas para construir los métodos que usted especifica los criterios necesarios para alcanzar un estado. Esos necesita. Por ejemplo, diferentes métodos se podrían ensamblar estados hacen que el núcleo sea accionable y lo habilitan para para desarrollo interno y subcontratado o para el desarrollo de guiar el comportamiento de los equipos de desarrollo de sistemas embebidos de seguridad crítica y sistemas de reporte software. de asistencia administrativa. Carlos Mario Zapata Jaramillo (Traductor), Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, Svante Lidman. 2013. La Esencia de la 73 Ingeniería de Software: El Núcleo de Semat. Revista Latinoamericana de Ingeniería de Software, 1(3): 71-78, ISSN 2314-2642
La separación de prácticas es la idea clave aquí. Ya que el • Correr el desarrollo completo, desde la idea hasta el término “práctica” se usó ampliamente en la industria por producto. muchos años, el núcleo tiene un enfoque específico en el • Escalar hacia grandes organizaciones y esfuerzos manejo e intercambio de prácticas. Las prácticas se representan complejos de desarrollo de software. como unidades modulares separadas y distintas, que un equipo La primera aplicación, la planeación de una iteración, se puede escoger usar o no. Esto contrasta con los enfoques usa acá como un ejemplo de lo que un equipo puede hacer con tradicionales que tratan el desarrollo de software como una el núcleo. Las otras se cubren completamente en La Esencia de sopa de prácticas que no se diferencian y conduce a los equipos la Ingeniería de Software: aplicando el núcleo de Semat. a deshacerse de lo bueno y lo malo cuando se mueven de un método a otro. El ejemplo que se presenta acá asume que una compañía El núcleo es práctico. Quizá la característica más tiene muy poco en cuanto a procesos formales. En el pasado, se importante del núcleo es la manera en que se usa en la práctica. creía en tener individuos creativos y habilidosos en los equipos Los enfoques tradicionales de los métodos de desarrollo de experimentados, pero la compañía no crecía ni tenía muchas software tienden a enfocarse en apoyar a los ingenieros de nuevas contrataciones. Esos nuevos empleados, la mayoría procesos o los ingenieros de calidad. El núcleo, en contraste, es recién salidos de la universidad, tienen buenas habilidades un marco de pensamiento tangible y práctico que apoya a los técnicas (por ejemplo en lenguajes de programación), pero no profesionales de software a medida que realizan su trabajo. son tan habilidosos en otros aspectos del desarrollo de Por ejemplo, el núcleo se puede “tocar” y usar [7, 10] software, como el trabajo con los interesados para lograr empleando tarjetas (véase la figura 4). Las tarjetas acuerdos en los requisitos. proporcionan recordatorios concisos y señales para los Esta compañía tiene un equipo de desarrollo que es miembros del equipo, a medida que realizan sus tareas diarias. responsable por hacer una aplicación móvil para redes sociales Al proporcionar listas de chequeo y sugerencias prácticas, en que permita a los usuarios compartir ideas, fotos y comentarios lugar de discusiones conceptuales, el núcleo se convierte en y navegar por ellos. El equipo comenzó con sólo dos algo que el equipo usa diariamente. Esta es una diferencia desarrolladores, Smith (el líder del equipo) y Tom, los cuales fundamental con los enfoques tradicionales, que tienden a tenían familiaridad con el núcleo. Luego, se les unieron otros exagerar el énfasis en las descripciones de los métodos, en dos desarrolladores, Dick y Harriet, que eran nuevos en el lugar del uso de los métodos y, por ello, sólo los suele trabajo y no tenían experiencia previa en el núcleo. Para Smith, consultar gente nueva del equipo. el líder del equipo, el éxito significaba más que funcionalidad, Las tarjetas proporcionan una descripción concisa que sirve cronograma y calidad. Este equipo corría el desarrollo de forma como recordatorios para los miembros del equipo. Ellos iterativa. Usted puede pensar en planear una iteración de la pueden mantener el núcleo como un pequeño mazo de tarjetas manera siguiente: en sus bolsillos, que fácilmente pueden extraer para discutir el 1. Determine dónde está: resuelva el estado actual del estado actual del desarrollo, la asignación de trabajo y la esfuerzo colaboración entre los miembros del equipo. Los equipos 2. Determine a dónde ir: decida en qué enfocarse luego y también pueden discutir áreas de mejoramiento refiriéndose a cuáles serán los objetivos de la próxima iteración. las tarjetas. Así, el núcleo no es sólo una descripción pesada de lo que un equipo necesita hacer. En su lugar, forma una parte esencial de lo que hacen cada día. 3. Determine cómo llegar allá: póngase de acuerdo en las tareas que el equipo necesita para lograr los objetivos. El núcleo en acción. El núcleo tiene muchas aplicaciones en las vidas diarias de los profesionales de software. Algunas de ellas son: • Correr una iteración o un sprint. Fig. 4. Las tarjetas hacen tangible el núcleo. 74 Carlos Mario Zapata Jaramillo (Traductor), Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, Svante Lidman. 2013. La Esencia de la Ingeniería de Software: El Núcleo de Semat. Revista Latinoamericana de Ingeniería de Software, 1(3): 71-78, ISSN 2314-2642
IV. DETERMINE DÓNDE ESTÁ EL EQUIPO UTILIZANDO EL El nombre del estado del alfa suministra una pista para NÚCLEO comprender lo que se necesita lograr para alcanzar un estado. Los miembros del equipo pueden encontrar más al leer y Supongamos que Smith y su equipo llevan seis semanas en comprender las listas de chequeo de los estados de los alfas. Al el desarrollo. Ellos proporcionaron una demostración temprana recorrer los estados de cada alfa uno a uno, un equipo se puede del sistema a sus interesados, quienes se sintieron satisfechos y familiarizar rápidamente con lo que se requiere para lograr proporcionaron una valiosa retroalimentación. Sin embargo, el cada estado. De esta manera, el equipo aprende sobre los alfas sistema aún no lo pueden correr los usuarios finales. Usted del núcleo al mismo tiempo que determina el estado actual de puede usar el núcleo para hacer esto de varias formas. Si usted su desarrollo y sus estados objetivo siguientes. está empleando tarjetas de estado de los alfas, entonces usted Determine cómo llegar allá con el núcleo. Smith y su puede hacer un tutorial como sigue: equipo buscan los próximos estados objetivo y se ponen de 1. Coloque las tarjetas de cada alfa en una fila de una tabla acuerdo en lo que necesitan para establecer algunas con el primer estado a la izquierda y el último estado a la prioridades. Primero, ellos necesitan determinar su forma de derecha. trabajo: trabajando bien, luego su sistema de software: usable 2. Deténgase en cada estado y pregunte a su equipo si se y, finalmente, sus requisitos: tratados. La razón es simple: si no logró ese estado. se tiene la forma de trabajo trabajando bien, se impedirían sus 3. Si se logró el estado, mueva la tarjeta hacia la izquierda. intentos de tener el sistema de software usable. Además, ellos Continúe con la siguiente tarjeta hasta que logre el estado se pusieron de acuerdo en la prioridad para los ítems de que su equipo aún no logra. requisitos perdidos necesarios para lograr el estado requisitos: 4. Mueva esta tarjeta de estado y el resto de las tarjetas tratados. pendientes de estado hacia la derecha. Smith y su equipo luego discutieron lo que necesitaban La Figura 5 muestra los estados que el equipo de Smith hacer para lograr esos estados, como se muestra en la Tabla 1. logró a la izquierda y aquellos que aún no logró a la derecha. Al recorrer los estados objetivo de los alfas, Smith es capaz de Por simplicidad, la Figura 5 muestra sólo tres de los alfas del determinar un conjunto de objetivos y tareas para la próxima núcleo. iteración. Determine a dónde ir con el núcleo. Una vez el equipo se Cómo el núcleo ayuda a planear iteraciones. Un buen plan pone de acuerdo en los estados de los alfas, los miembros debe ser inclusivo, lo que significa que debe incluir todos los discuten los próximos estados “objetivo” deseados, que guían ítems esenciales y cubrir el equipo como un todo. También, su planeación. El equipo se pone de acuerdo para usar los debe ser concreto, de modo que el equipo lo pueda accionar. El inmediatamente próximos estados de los alfas para ayudar a equipo debería, también, tener una manera de monitorear su establecer los objetivos de la próxima iteración, como se progreso contra el plan. muestra en la Figura 6. Fig. 5. El equipo usa los alfas para determinar los estados actuales. Carlos Mario Zapata Jaramillo (Traductor), Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, Svante Lidman. 2013. La Esencia de la 75 Ingeniería de Software: El Núcleo de Semat. Revista Latinoamericana de Ingeniería de Software, 1(3): 71-78, ISSN 2314-2642
Estado objetivo Cómo el equipo planea alcanzarlo Tanto Dick como Harriet estuvieron de acuerdo en que tenían dificultades para aplicar las pruebas automáticas. Ellos necesitaban ayuda para progresar. Tom estuvo de acuerdo en que él tenía que invertir tiempo enseñándoles. Se agregó una tarea a la lista de pendientes de la iteración para que Tom condujera un entrenamiento en pruebas automáticas para Dick y Harriet. • Tarea 1. Conducir entrenamiento en pruebas automáticas. Este estado nos recuerda que el sistema de software debe mostrar que es de la calidad y funcionalidad suficientes para ser útil para los usuarios. Hasta acá, el equipo de Smith estuvo haciendo pruebas dentro de su entorno de desarrollo. Ahora, se deberían conducir pruebas dentro de un entorno de aceptación de pruebas, que debían preparar. Esto generó las siguientes tareas: • Tarea 2: Preparar el entorno de pruebas de aceptación. El equipo de Smith tenía que lograr que todos los ítems de requisitos fueran actualmente demostrables en el sistema para completarlos. Esto significaba que cada ítem de requisitos se debía probar completamente dentro del entorno de aceptación de pruebas. • Tarea 3: Completar el ítem de requisitos A: “Navegar en línea y fuera de línea. • Tarea 4: Completar el ítem de requisitos B: “Publicar comentarios (en línea y fuera de línea). • Tarea 5: Completar el ítem de requisitos C: “Navegar álbumes”. Este estado nos recuerda la necesidad de trabajar con los interesados para asegurar que ellos están felices con el sistema producido. En nuestra historia, Smith tenía que trabajar con Angela, la representante del cliente, para determinar cuáles ítems de requisitos adicionales se necesitaba implementar. Esto generó la siguiente tarea adicional: • Tarea 6: Hablar con Angela y acordar con ella los ítems de requisitos, dentro de la iteración, que harán que el sistema sea digno de considerarse operativo. Fig. 6. Los próximos pasos seleccionados y la manera como los alcanzará el equipo. El núcleo le ayuda a lograr esto de la manera siguiente: casos, ellos usan el núcleo y las prácticas que se desarrollaron en Ivar Jacobson International [1, 10]. Entre los primeros en Inclusivo. Los alfas del núcleo sirven como recordatorios adoptar la idea del núcleo se cuentan: de las diferentes dimensiones del desarrollo de software, • MunichRe, la compañía líder en seguros del mundo, donde ayudando a crear un plan que trate todas las dimensiones de una familia de “modelos de colaboración” se ensambló manera balanceada. para cubrir el espectro completo del software y el trabajo Concreto. Las listas de chequeo para cada estado de alfa de aplicación. Cuatro modelos de colaboración suministran pistas sobre lo que se necesita hacer en la iteración. (exploratorio, estándar, mantenimiento y soporte) se Las listas de chequeo mismas ayudan a determinar su progreso, construyeron en el núcleo mismo desde el mismo conjunto haciendo claro lo que usted tiene que hacer y comparando esto de doce prácticas. con lo que se supone que usted hace. • Fujitsu Services, donde el paquete Apt se construyó sobre una versión previa del núcleo de la ingeniería de software, V. EL NÚCLEO EN EL MUNDO REAL incluyendo formas de trabajo ágiles y en cascada [1]. Si bien las ideas que aquí se presentan serán nuevas para • Una de las mayores compañías japonesas de electrónica de muchos de ustedes, la academia y la industria las vienen consumo, donde los procesos de software se definieron aplicando de forma exitosa en el mundo real. En todos los sobre una versión previa del núcleo, ayudando a los 76 Carlos Mario Zapata Jaramillo (Traductor), Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, Svante Lidman. 2013. La Esencia de la Ingeniería de Software: El Núcleo de Semat. Revista Latinoamericana de Ingeniería de Software, 1(3): 71-78, ISSN 2314-2642
equipos a aplicar nuevas prácticas y a gestionar un Cómo se relaciona el núcleo con lo ágil y otros proveedor de desarrollo externo. paradigmas. El núcleo se puede usar con todas las prácticas • KPN, donde un proceso basado en el núcleo se adaptó para técnicas y administrativas populares, incluyendo Scrum, más de 300 proyectos a lo largo de trece programas como Kanban, iteraciones basadas en riesgos, cascada, desarrollo parte de un movimiento hacia el desarrollo iterativo. El dirigido por casos de uso, desarrollo dirigido por pruebas de núcleo también suministró la base para un nuevo proceso aceptación, integración continua y desarrollo dirigido por de aseguramiento de la calidad enfocado en los resultados, pruebas. Esto ayudará a los grupos a embarcarse en el que se podría aplicar a todos los proyectos sin importar el desarrollo de productos de software nuevos e innovadores, y método o las prácticas que se empleen. aquellos involucrados en mejorar y mantener productos de • El mayor departamento de gobierno del Reino Unido, software establecidos. Esto ayudará, también, a equipos de donde un paquete ágil basado en el núcleo se introdujo todos los tamaños, desde equipos individuales hasta programas para habilitar la agilidad disciplinada y el seguimiento del fuertes de ingeniería de software de más de 1000 personas. progreso y salud de los proyectos de forma independiente Por ejemplo, el núcleo apoya los valores del Manifiesto a las prácticas. Ágil. Con su enfoque en listas de chequeo y resultados y su El núcleo ya se usa en cursos de ingeniería de software de inherente independencia de las prácticas, el núcleo valora los primero y segundo año en el Instituto Real de Tecnología KTH individuos y las interacciones por encima de los procesos y las en Suecia. Después de que los estudiantes de los cursos de herramientas. Con su enfoque en las necesidades de los primer año dirigieron sus proyectos, se adentraron en los alfas equipos profesionales de desarrollo de software, el núcleo de Semat y compararon los resultados de sus proyectos, bajo la valora la forma de trabajo y privilegia las responsabilidades del dirección de Anders Sjögren. Los estudiantes tuvieron la equipo por encima de los métodos. oportunidad de familiarizarse con los alfas y evaluarlos para El núcleo no compite de ninguna manera con los métodos obtener una visión del progreso y salud de los proyectos. En los existentes, sean ellos ágiles o de otro tipo. Por el contrario, el cursos de segundo año que condujo Mira Kajko-Mattsson, a los núcleo es agnóstico para el método que elija el equipo. Aún si estudiantes se les preguntó el uso del núcleo de Semat cuando su equipo está usando un método particular, el núcleo aún corrían sus proyectos sin importar el método que siguieran. puede ayudar. Sin importar el método que se use, como Robert Como se muestra en la Figura 3, Kajko-Mattsson creó un Martin señala en su prefacio a La esencia de la ingeniería de escenario de desarrollo de software y lo evaluó para cada alfa, software, los proyectos, aún los ágiles, se pueden desordenar y, sus estados y los ítems de la lista de chequeo de estados. A los cuando lo hacen, los equipos necesitan saber más. Ahí es estudiantes se les pidió, luego, hacer lo mismo cuando dirigían donde yace el verdadero valor del núcleo, pues puede guiar un y evaluaban sus proyectos. equipo a las acciones que necesitan realizar para regresar a la Las experiencias de esos cursos proporcionaron lecciones senda, para extender su método o para tratar un vacío crítico en muy valiosas. Por ejemplo, el núcleo asegura que todos los su forma de trabajo. Se enfoca en las necesidades del aspectos esenciales de la ingeniería de software se consideran profesional de software y los valores del “uso de los métodos” en un proyecto. Al emparejar los resultados contra los alfas del por encima de “la descripción de las definiciones de los núcleo, los estudiantes pudieron identificar fácilmente los lados métodos” (como era normal en el pasado). bueno y malo de sus métodos de desarrollo. El núcleo también El núcleo no sólo apoya las mejores prácticas modernas, preparó a los estudiantes para los futuros esfuerzos de sino que también reconoce que una gran cantidad de software desarrollo de software con un mínimo de esfuerzo en ya se desarrolló y necesita que lo mantengan. Este software enseñanza. Siguiendo los alfas del núcleo, los estudiantes vivirá por décadas y lo tendrán que mantener de manera pudieron aprender el alcance total del esfuerzo en ingeniería de eficiente. Esto significa que la forma como trabaje este software y, así, vieron lo que se requería de ellos en su futuro software tendrá que evolucionar a lo largo del software mismo. como profesionales (véase la Figura 7). Fig. 7. Visualización del enfoque pedagógico cuando se enseña con el núcleo de Semat. Carlos Mario Zapata Jaramillo (Traductor), Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, Svante Lidman. 2013. La Esencia de la 77 Ingeniería de Software: El Núcleo de Semat. Revista Latinoamericana de Ingeniería de Software, 1(3): 71-78, ISSN 2314-2642
Nuevas prácticas se tendrán que introducir de manera que [4] Jacobson, I., Meyer, B. and Soley, R. Call for action: The complementen las que ya están en uso. El núcleo proporciona SEMAT initiative. Dr. Dobb’s Journal, (2009). los mecanismos para migrar los métodos legados desde los [5] Jacobson, I., Meyer, B. and Soley, R. The SEMAT vision monolíticos enfoques en cascada hasta los más modernos statement, (2009). métodos ágiles y más allá, de forma evolucionaria. Esto le [6] Jacobson, I., Pan-Wei Ng, McMahon, P., Spence, I. and Lidman permite cambiar sus métodos legados práctica a práctica, S. The Essence of Software Engineering—Applying the mientras mantiene y mejora la habilidad del equipo para hacer SEMAT Kernel. Addison-Wesley. (Forthcoming in Jan. 2013 entregas. but available in a prepublication version on safaribooksonline.com.) Cómo le ayuda el núcleo. El uso del núcleo tiene muchos [7] Jacobson, I., Pan-Wei Ng and Spence, I. Enough of process— beneficios para los profesionales de software, ya sean let’s do practices. Journal of Object Technology 6, 6 (2007), 41- experimentados o novatos, y para los equipos en que trabajan. 67. Por ejemplo, el núcleo ayuda a evaluar el progreso y salud de [8] Jacobson, I. and Spence, I. Why we need a theory for software los esfuerzos de desarrollo de software, evaluar las prácticas engineering. Dr. Dobb’s Journal, (2009). actuales y mejorar la forma de trabajo. También, ayuda a [9] Object Management Group (OMG). RFP: A foundation for the mejorar la comunicación, a moverse más fácilmente entre Agile creation and enactment of software engineering methods, equipos y a adoptar nuevas ideas. El núcleo ayudará a la (2012). industria en conjunto, al mejorar la interoperabilidad entre los [10] Pan-Wei Ng and Magee, M. Lightweight application lifecycle equipos, los proveedores y las organizaciones de desarrollo. management using state cards. Agile Journal (Oct. 2010) Al proporcionar un fundamento independiente de las prácticas para la definición de los métodos de software, el Ivar Jacobson, el presidente de Ivar Jacobson International, es uno de los padres de los componentes y de la núcleo tiene también el poder de transformar completamente la artuite3ctura de componentes, los casos de uso, el lenguaje forma en que se definen los métodos y se intercambian las unificado de modelado y el proceso unificado racional. Ha prácticas. Por ejemplo, al permitir a los equipos mezclar y contribuido al modelado de negocios moderno y al emparejar prácticas de diferentes fuentes para construir y desarrollo de software orientado a aspectos. mejorar la forma de trabajo, el núcleo trata dos de los Pan-Wei Ng entrena el desarrollo de sistemas a gran escala problemas metodológicos clave que enfrenta la industria: que involucran muchos millones de líneas de código y cientos de personas por cada versión, ayudándoles a la • Los equipos no se encuentran ya atrapados en sus transición hacia una forma de trabajo lean y ágil, sin olvidar métodos. Ellos pueden mejorar continuamente su forma de el mejoramiento de su código y arquitectura y las pruebas trabajo al agregar o remover prácticas cuando la situación por medio de casos de uso y aspectos. Es coautor, con Ivar lo exija. Jacobson, del libro “Desarrollo de software orientado a aspectos con casos de uso”. • Los metodólogos no necesitan más gastar tiempo en describir los métodos completos. Ellos pueden fácilmente Paul McMahon es un consultor independiente que se enfoca en el entrenamiento de gerentes de proyectos, líderes describir sus nuevas ideas de manera concisa y de proyectos y profesionales de software en el uso práctico reutilizable. de las técnicas lean y ágiles en entornos restringidos. Ha sido líder de la iniciativa Semat desde sus inicios. Finalmente, el núcleo beneficia la academia. El núcleo proporciona la base para la creación de cursos fundamentales Ian Spence es oficial de tecnología en jefe en Ivar Jacobson de la ingeniería de software, que se pueden luego International y el líder del equipo para el desarrollo del complementar con cursos adicionales sobre prácticas núcleo de Semat. Introdujo cientos de proyectos a las prácticas iterativas y ágiles y también lideró numerosos específicas (ya sea parte del currículum educativo inicial o proyectos exitosos de transformación a gran escala después durante el desarrollo profesional de los estudiantes). trabajando con organizaciones de más de 5000 personas. Igualmente importante es la habilidad del núcleo para actuar como un modelo de referencia compartido y habilitar la Svante Lidman tiene una amplia experiencia en la construcción de equipos de desarrollo de software en investigación y experimentación adicional. empresas de alto rendimiento. Ha ocupado cargos en Hansoft AB, Ivar Jacobson International, Microsoft, Rational REFERENCIAS Software y Objectory, entre otras. Desde mediados de 2010, [1] Azoff, M. Apt Methods and Tools, Fujitsu. Ovum Technology Lidman es el agente de cambio que lidera la más grande Report. Reference Code O100032-002 (Jan. 2011). transición lean/ágil de todos los tiempos en Escandinavia. [2] Fujitsu, Ivar Jacobson Internat ional AB, Model Driven Carlos Mario Zapata se desempeña actualmente como Solutions. Essence—kernel and language for software Profesor Asociado del Departamento de Ciencias de la engineering. Initial submission, 2012, version 1.0. Computación y de la Decisión de la Universidad Nacional de [3] Jacobson, I. and Meyer, B. Methods need theory. Dr. Dobb’s Colombia, Sede Medellín. Es, además, presidente del Comité Ejecutivo del Capítulo Latinoamericano de Semat y también Journal, (2009). es uno de los traductores oficiales del libro “La Esencia de la Ingeniería de Software: aplicando el núcleo de Semat”. 78 Carlos Mario Zapata Jaramillo (Traductor), Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, Svante Lidman. 2013. La Esencia de la Ingeniería de Software: El Núcleo de Semat. Revista Latinoamericana de Ingeniería de Software, 1(3): 71-78, ISSN 2314-2642
Modelo de Proceso de Conceptualización de Requisitos Alejandro Hossian Grupo de de Investigación en Sistemas Inteligentes Aplicados a Ingeniería Facultad Regional Neuquén Universidad Tecnológica Nacional Neuquén, Argentina alejandrohossian@yahoo.com.ar Resumen — El proceso de captura de requisitos constituye un utilizarse para este análisis de problemas son los objetos, las proceso con connotaciones sociales relacionadas con diferentes funciones y los estados, pudiendo éstos describirse en múltiples personas (stakeholders), una circunstancia que hace que se niveles de detalle. Dado que hay tantas relaciones que pueden presenten ciertos problemas cuando se lleva adelante la existir entre todos los elementos, se hace necesario disponer de conceptualización de requisitos. En este trabajo se propone un una estructura de conocimiento (colección estructurada de Proceso de Conceptualización de Requisitos que se estructura en conceptos y sus interrelaciones) que permita la captura estas dos fases: (a) Análisis Orientado a al Problema: cuyo objetivo es relaciones. comprender el problema dado por el usuario en el dominio en el A partir de la partición, es posible capturar la relación que este se lleva a cabo, y (b) Análisis de Orientado al Producto: estructural “agregación/parte de” entre objetos, funciones o cuyo objetivo es obtener las funcionalidades que el usuario espera estados en el dominio del problema. A partir de la abstracción, es posible capturar las relaciones estructurales del producto de software a desarrollar, teniendo en cuenta la “general/específico” o “ejemplo de” entre objetos, funciones o relación de estas con la realidad expresada por el usuario en su estados en el dominio del problema. A partir de la proyección, discurso. Se proponen seis técnicas que articulan cada una de las es posible capturar la relación estructural “visión de” entre tareas que componen las fases de proceso propuesto. objetos, funciones o estados en el dominio del problema. Si bien estos principios ofrecen su aporte a los efectos de Palabras Clave — Proceso de captura de requisitos, precisar un mejor entendimiento de sus requisitos, son de conceptualización de requisitos, proceso de conceptualización de carácter muy general y de poco nivel de detalle. requisitos, análisis orientado a al problema, análisis de orientado De igual manera y en lo que respecta a la gestión del al producto, técnicas de modelado. conocimiento dentro del campo de los sistemas basados en conocimientos (SBC), se puede citar una técnica de I. INTRODUCCION representación intermedia como el “Análisis de Protocolos” En estadios tempranos de la Ingeniería de Requerimientos, [6]. Este método es de gran utilidad a los fines de obtener Alford [1], Yeh y Zave [2] y Davis [3] identificaron la heurísticas que el experto utiliza en la solución de problemas, necesidad de obtener una representación intermedia de la pero que le resulta difícil explicar [7]. información obtenida – conceptualización de los requisitos –, En síntesis, esta técnica consiste en grabar en un protocolo facilitando de esta manera una captura adecuada del problema el comportamiento del experto mientras este trabaja en la a resolver por parte del profesional de ingeniería de software solución del problema. Luego ese protocolo se transcribe y se antes de pasar a la construcción de los modelos conceptuales, analiza para, finalmente, interpretarlo y convertirlo en un habida cuenta de que una correcta construcción de estos conjunto de razonamientos que convergen a la solución del modelos es fundamental para el éxito en el desarrollo del problema. La reconstrucción de esta solución permite modelar proyecto software, mientras que su incorrección puede los conocimientos del experto. perjudicar seriamente a las organizaciones implicadas [4]. La forma más clásica de representar este conocimiento Asimismo cabe señalar, que la escasa existencia de trabajos consiste en codificar el mismo en la forma de reglas de referidos a la elaboración de representaciones intermedias de producción, las cuáles presentan una parte izquierda [PI] y una los caudales de información obtenidos a lo largo de la actividad parte derecha [PD] (Si..[PI].. Entonces..[PD]..). de educción, tendientes a una búsqueda de reducción de la Cabe destacar, que si bien esta técnica permite poner en complejidad de la realidad y su problemática expresada por el evidencia carencias y fallos en el documento de educción de cliente y/o usuario en su discurso, agravan aún más este conocimientos, también es cierto que determinados procesos problema. no son reportados por el experto y que no todos los En este sentido y en lo que se refiere a la gestión de conocimientos son fáciles de representar en forma de reglas requisitos en el campo de los sistemas de información, se [8]. pueden citar algunos principios fundamentales de Se ha propuesto como objetivo de este trabajo definir un estructuración de la información – “Partición, Abstracción y marco metodológico que incorpore una actividad de Proyección” –, los cuáles proporcionan una estructura de conceptualización tendiente a mejorar la comprensión y conocimiento a fin de contribuir a una visión simplificada de la captura de requisitos de usuario en la fase de análisis de la realidad y su problemática [5]. Los elementos que suelen Ingeniería de Requerimientos del Software. Esta actividad de conceptualización buscará plasmar en un esquema de Alejandro Hossian. 2013. Modelo de Proceso de Conceptualización de Requisitos. 79 Revista Latinoamericana de Ingeniería de Software, 1(3): 79-101, ISSN 2314-2642
También puede leer