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-2642Nuevas 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-2642Modelo 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-2642También puede leer
