Tendencias de la Ingeniería de Software - Impacto en las TIC

8/18/2019 Tendencias de la Ingeniería de Software - Impacto en las TIC

1/98

Tendencias de laIngeniería de Software

Impacto en las Tecnologías de Información y Comunicación

Jezreel Mejia Miranda Mirna A. Muñoz Mata Alma Y. Quiñonez Carrillo Hugo A. Mitre Hernández José A. Mora Soto


2/98

Tendencias en la Ingeniería de Software

Impacto en las Tecnologías de Información y Comunicación

Editado por:

Publicado por:

Jezreel Mejia Miranda Mirna A. Muñoz Mata Alma Y. Quiñonez Carrillo Hugo A. Mitre Hernández José A. Mora Soto


3/98

Tendencias en la Ingenieria del Software.

Impacto en las Tecnologias de Información y Comunicación

D.R. © Primera edición, 2016

D.R. © Centro de Investigación en Matemáticas, A.C.

Jalisco s/n, Valenciana

C.P. 36240, Guanajuato, Gto., MéxicoApdo. Postal 402http://www.cimat.mx

El cuidado de la edición estuvo a cargo de Jezreel Mejia Miranda, Mirna A. Muñoz Mata, Alma Y. Quiñonez Carrillo,Hugo A. Mitre Hernández y José A. Mora Soto.

ISBN: 978-607-96212-6-1

Este libro no puede ser reproducido total ni parcialmente, por ningún medio electrónico o de otro tipo, sin autorizaciónescrita del editor.

This book may not be reproduced, whole or in part, by any means, whitout written permission from the publisher.

Impreso y hecho en México.

Printed and Made in Mexico.

.

http://www.cimat.mx/http://www.cimat.mx/http://www.cimat.mx/


4/98

Agradecemos su apoyo para la realización del presente libro.


5/98

Prólogo de la serie

Este libro está dedicado a la publicación de los trabajos de investigación con aplicaciones reales y de actualidad,los cuales están relacionados a las tendencias en la Ingenieria del Software aplicados a las Tecnologias de

Información y Comunicación.


6/98

Prólogo:

La Ingeniería de Software (IS) permite el establecimiento y uso de principios de ingeniería robustos, orientadosa obtener productos y servicios de software de alta calidad, económico, fiable, eficiente y que satisfaga las

necesidades del usuario. Por lo tanto, la IS se ha convertido sin duda una área indispensable para el desarrollode productos y servicios orientados en las Tecnologias de Informacion y Comunicación (TICs) ya que éstas sehan convertido en un motor que mueve a la sociedad en todos sus sectores.

En este contexto, los trabajos publicados en este libro abordan temas relacionados a: la definición y validaciónde requerimientos de sistemas basada en herramientas y bajo el esquema de patrones; Aspectos euristicos parael mejoramiento de herramientas desarrolladas bajo componentes; Método de validación de software con baseen el modelo CMMI; Desarrollo de software para un entorno universitario y de la utilización de nuevoscomponentes como la Graph API de Facebook para la difusión de información. Asimismo, se presenta unmodelo para la integración de las MiPymes, Sociedad y Gobierno a través del uso de las TICs. Además, en elcontexto de la educación se presenta un sistema de detección de emociones para la recomendación de recursoseducativos y un modelo para implementar un sistema de gestión del conocimiento en la educación Dual. En elárea de seguridad de las TICs se presenta una propuesta de contenido y controles de seguridad para un sitio web de un CSIRT. Para el sector Salud se presenta una solución alternativa para el uso de TICs

específicamente en la endoscopia y finalmente, se presenta una trabajo en progreso acerca del establecimientodel estado del arte sobre marcos de trabajo, métodos y metodologías para evaluar la implementación demetodologías agules en Pymes.

Los trabajos publicados en este libro abordan nuevos enfoques o áreas de interés mencionados anteriormente,presentando investigaciones que abarcan tanto el entorno académico como el industrial, y que permitendimensionar los retos a los cuales la IS se enfrenta actualmente.

Editores:

Jezreel Mejia

Mirna MuñozAlma Y. Quiñonez Carrillo

Hugo A. Mitre Hernández

José A. Mora Soto


7/98

Comité Científico

Adriana Peña Perez-Negron Universidad de Guadalajara México

Alejandro Rodríguez Gonzalez Universidad Politecnica de Madrid España

Alma Maria Gómez Rodriguéz Universidad de Vigo España

Alvaro Rocha Universidade de Coimbra PortugalAngel Jordan Carnegie Mellon University Estados Unidos

Antoni Lluis Mesquida Calafat Universidad de las Islas Baleares España

Antonia Mas Pichaco Universidad de las Islas Baleares España

Antonio Pereira Instituto Politécnico de Leiria Portugal

Antonio de Amescua Seco Universidad Carlos III de Madrid España

Arturo Méndez Penín Universidad de Vigo España

Carla Pacheco Universidad Tecnológica de la Mixteca, Oaxaca México

Carlos Lara López CIMAT Unidad Zacatecas México

Diego Martín de Andrés Universidad Carlos III de Madrid España

Edrisi Muñoz Mata CIMAT Unidad Zacatecas, México México

Edwin León Cardenal CIMAT Unidad Zacatecas México

Elisabet Cápon Swiss Federal Institute of Technology, Zürich(ETHZ)

Suiza

Enrique Barreiro Alonso Universidad de Vigo España

Fernando Moreina Universidade Portucalense Portugal

Francisco Ortín Soler Universidad de Oviedo España

Giner Alor Hernandez Instituto Tecnológico de Orizaba México

Gloria P. Gasca Hurtado Universidad de Medellin Colombia

Gonzalo Cuevas Agustín Universidad Politécnica de Madrid España

Gonzalo R. Luzardo Morocho Escuela Superior Politécnica del Litoral Ecuador

Gustavo Illescas Universidad Nacional del Centro de la Provincia deBuenos Aires

Argentina

Henrique Mamede Universidade Aberta de Lisboa Portugal

Hugo Arnoldo Mitre CIMAT Unidad Zacatecas, México México

Ivan A. Garcia Pacheco Universidad Tecnológica de la Mixteca, Oaxaca México

Jaime A. Guzmán Luna Universidad Nacional de Colombia Colombia

Javier García Guzman Universidad Carlos III de Madrid EspañaJoao Barroso Universidad Tras-os-Montes e Alto Douro Portugal

Jörg Thomaschewski Universidad de Vigo -Hochschule Emden-Leer España

Jose A. Calvo Manzano Villalon Universidad Politécnica de Madrid España

Jose A. Mora Soto CIMAT Unidad Zacatecas México

Jose Antonio Cerrada Somolinos Universidad Nacional de Educación a Distancia España

Jose Baltasar García Perez-

Schofield Universidad de Vigo España

Juan Carlos Gonzáles Moreno Universidad de Vigo España

Juan Manuel Cueva Lovelle Universidad de Vigo España

Leandro Rodríguez Linares Universidad de Vigo España

Leandro Rodríguez Linares Universidad de Vigo España

Luis Casillas CUCEI de la Universidad de Guadalajara México

Luis Fernández Sanz Universidad de Alcalá España

Luis Borges Goveia Universidad Fernando Pessoa Portugal

Luis J. Dominguez Pérez CIMAT Unidad Zacatecas México

Magdalena Arcilla Cobián Universidad Nacional de Educación a Distancia España

Manuel Pérez Cota Universidad de Vigo España

María José Lado Touriño Universidad de Vigo España

María Y. Hernández Pérez Instituto de Investigaciones Eléctricas México

Marion Lepmets Regulated Software Research Centre, DundalkInstitute of Technology, Ireland

Estonia

Omar S. Gómez Escuela Superior Politécnica de Chimborazo Ecuador

Paul Clarke Dundalk Institute of Technology Irlanda

Perla Velasco-Elizondo Universidad Autonoma de Zacatecas (UAZ) México

Rafael Valencia García Universidad de Murcia España


8/98

Ramiro Goncalves Universidad Tras-os Montes Portugal

Raúl Aguilar Vera Universidad Autónoma de Yucatán México

Ricardo Colomo Palacios Østfold University College Noruega

Rory O´Connor Dublin City University Irlanda

Santiago Mataloaga Universidad ORT Uruguay Uruguay

Sodel Vázquez Reyes Universidad Autonoma de Zacatecas (UAZ) México

Sulema Torres Ramos CUCEI de la Universidad de Guadalajara México

Tomas San Feliu Gilabert Universidad Politécnica de Madrid España

Ulises Juárez Martínez Instituto Tecnológico de Orizaba México

Ulrik brandes Universidad de Konstanz, Alemania

Valentine Casey Dundalk Institute of Technology Irlanda

Vianca Vega Universidad Católica del Norte Chile

Victor Saquicela Uiversidad de Cuenca Ecuador

Vítor Filipe Universidad Tras-os-Montes e Alto Douro Portugal

Yadira Quiñonez Universidad Autonoma de Sinaloa México

Yilmaz Murat Çankaya University Turquia


9/98

Índice general

Herramienta para administración y validación de requerimientos de sistemas 7

Definición de Requerimientos de Software a Través de Escenarios utilizando Patrones 15

Proceso basado en patrones de proceso para desarrollar aplicaciones Web 22

Evaluación Heurística de Herramientas de Composición de Componentes Centrada en elUsuario Final

32

Metamodelo para validación de software basado en el CMMI 41

Presupuesto-CUC y SIRU, dos Experiencias de Desarrollo De Software A La MedidaPara Fortalecer La Gestión De La Universidad De La Costa: Presentación DeResultados, Impactos, Dificultades y Recomendaciones. 49

Propuesta de un modelo para la Implementación de un Sistema de Gestión delConocimiento en la Educación Dual 55

Propuesta de un modelo para la integración de las MiPyMES, Sociedad y Gobierno através del uso de las TIC de la Zona Metropolitana del Valle de Orizaba, Veracruz 62

Sistema de detección de emociones para la recomendación de recursos educativos 68

Propuesta de contenido y controles de seguridad para un sitio web de un CSIRT 75

Forming an alternate solution for endoscopy 83

Establishing the state of art of frameworks, methods and methodologies to assess the

implementation and use of agile methodologies in SMEs: A systematic review 90


10/98

Jezreel Mejia Miranda - Mirna A. Muñoz Mata - Alma Y. Quiñonez Carrillo - Hugo A. Mitre Hernández - José A. Mora Soto

7

Herramienta para administración y validación de requerimientos de

sistemas

Oscar Carlos Medina, Marcelo Martín Marciszack, Mario Alberto Groppo

GIDTSI, Grupo de Investigación, Desarrollo y Transferencia de Sistemas de InformaciónUniversidad Tecnológica Nacional, Facultad Regional Córdoba

Maestro López esq. Av. Cruz Roja Argentina, Ciudad Universitaria – (5016) Có[email protected], marciszack @gmail.com, [email protected]

Abstract. El presente trabajo describe una aplicación web denominada SIAR (Sistema Integral deAdministración de Requerimientos) que gestiona los requerimientos de un sistema de informaciónmediante Casos de Uso, según los lineamientos de UML (Lenguaje Unificado de Modelado). LosCasos de Uso son útiles para la generación y análisis de requisitos de sistemas. La finalidad principalde SIAR es la administración de Casos de Uso con una herramienta informática que agilice suregistración, normalice su contenido y posibilite implementar validaciones funcionales, como porejemplo un método automatizado de análisis de consistencia de Casos de Uso, para lo cual el sistema

genera un grafo con la transición de estados de cada Caso de Uso, expresado en el protocolo XPDL(Lenguaje de Definición de Flujo de Trabajo), que es analizado en un simulador de autómata finitodeterminista para verificar la cohesión de los escenarios en él definidos.

Palabras Clave: Caso de Uso, Requerimientos, UML, XPDL, Autómata finito determinista.

1 Introducción

SIAR (Sistema Integral de Administración de Requerimientos) es la denominación que se le dio a unaaplicación web que gestiona los requerimientos funcionales de un sistema de información según loslineamientos de UML (Lenguaje Unificado de Modelado).

Esta aplicación se originó dentro del proyecto de investigación ―Validación de Requerimientos a través

de Modelos Conceptuales‖ del GIDTSI (Grupo de Investigación, Desarrollo y Transferencia de Sistemasde Información), dependiente del Departamento Ingeniería en Sistemas de Información de la UniversidadTecnológica Nacional, Facultad Regional Córdoba que ―busca dar solución a uno de los principales

problemas de la Ingeniería de Requisitos relacionado a la elicitación y especificación de requerimientos,que vincula las distintas etapas del proceso de desarrollo de software manteniendo la trazabilidad de losmismos hasta su validación e implementación‖.

Como el modelo de requerimientos tiene por objetivo la registración y estandarización derequerimientos funcionales, la construcción de SIAR tiene por fin administrar en forma integral losrequerimientos funcionales de un proyecto de software según la metodología UML. SIAR es unaaplicación web que permitió registrar en forma normalizada los casos de uso y cuya primera versióncomprende el siguiente alcance:

• Administración de los atributos de un proyecto de software y su versionado.• Diseño y validación del Modelo Conceptual.• Gestión de los alcances de cada versión del proyecto y los casos de uso asignados.• Administración de los atributos de un caso de uso, incluyendo actores, pre-condiciones, post-

condiciones, cursos de acción, normal y alternativos, y su versionado.• Clasificación, priorización y trazabilidad de los casos de uso.• Visualización de consultas y generación de reportes en distintos formatos, inclusive XPDL, para

comunicarse con otras aplicaciones.• Gestión de atributos de procesos de negocio, de actividades de negocio que los componen y los

casos de uso asociados a estas actividades.• Registración y consulta de un glosario por proyecto, con entradas y sinónimos, siguiendo las

recomendaciones de LEL (Léxico Extendido del Lenguaje), que es una estrategia de modelado derequisitos basada en lenguaje natural.


11/98


8

2 Construcción de una herramienta para la administración integral de Casos de

Uso

La herramienta ha sido diseñada con un criterio de lógica que permite describir la siguiente relación decascada:

Fig. 1. Relaciones de SIAR.

SIAR permite trabajar con diferentes Sistemas, cada uno con sus propias Versiones, cada Versióncubre un número limitado de Alcances, cada Alcance gestiona un grupo de Casos de Uso, cada Caso deUso está compuesto por una secuencia ordenada de Pasos, finalmente un paso puede o no tenerAlternativas.

Los Pasos de un Caso de Uso permiten efectuar tareas que son descriptos con el soporte del sistemaque se ha desarrollado.

Desde el punto de vista conceptual un Caso de Uso es la descripción de una secuencia de interaccionesentre el sistema y uno o más Actores. Las personas o entidades que participarán en un caso de uso sedenominan Actores.

Cada caso de uso tiene pre-condiciones que se deben cumplir para que el flujo de eventos se puedanllevar a cabo. Dichas pre-condiciones son las reglas o condiciones que se deben cumplir antes de que seainiciado el caso de uso.

También posee post-condiciones que reflejan el estado en que se queda el Sistema una vez ejecutadoel caso de uso.

Puede clasificarse con diferentes niveles de Complejidad según el criterio de cada Analista funcionalen Muy Alta, Media y Baja.

A su vez, un Caso de Uso puede ser del tipo Concreto o Abstracto. Un caso de uso es Abstracto si no puede ser realizado por sí mismo, o si no es Concreto ya que puede ser iniciado por un actor y realizado por sí mismo.

Los pasos son las actividades que deberán realizarse para llevar a cabo algún proceso (Rumbaugh,Jacobson, Booch, 1999).

Cada paso posee alternativas que a su vez puede tener pasos y estos volver a tener alternativas.Cada caso de uso está codificado con 5 dígitos que conforman el Identificador del Caso de Uso:1. Id del Sistema.2. Id de la Versión del Sistema.3. Id del Alcance de la Versión.4. Id del Caso de Uso.5. Id de la Versión del Caso Uso.

3 Alcance de SIAR versión 1.0

El aplicativo busca cubrir las siguientes necesidades:


12/98


9

3.1 Administración de requerimientos

Se planteó la necesidad de generar un sistema que no solo administre los casos de usos por separado, sinotambién gestione en forma integral todo el proyecto que lo contiene. Es decir, sistema con sus versiones,

por cada versión del sistema sus alcances y por cada alcance sus casos de usos con sus versiones.

Fig. 2. Consulta de Casos de Uso de un Sistema.

Para cumplir con esta funcionalidad se incluyó también el concepto de sistema, versiones y alcances deversiones. A su vez cada caso de uso incluye pasos y alternativas. También se propone hacer unatrazabilidad de los cambios.

3.2 Configuración del entorno de desarrollo

Para su implementación se utilizó una plataforma de desarrollo ―case‖, generando en lenguaje de programación C# y almacenando la información en una base de datos MYSQL.

3.3 Interfaz de usuario

El desarrollo del sistema es web porque solo se precisa Internet para acceder a la aplicación desde unacomputadora personal. No se escogió un desarrollo de escritorio porque sería necesario contar con unentorno de configuración local en el equipo que se desee acceder al sistema.

3.4 Administración de proyectos de sistemas

Como se mencionó anteriormente, el trabajo tiene por objetivo principal administrar las descripciones ymantenimiento de casos de uso en forma integral.

3.5 Administración de Casos de Uso

Durante la descripción de un Caso de Uso, pueden administrarse las pre-condiciones, post-condiciones, pasos y alternativas como así también los datos básicos de un Caso de Uso. Del mismo modo, en ladescripción de un nivel o paso, una vez definido el mismo puede modificarse o darse de baja, esto se vereflejado en las versiones del CU. Lo mismo con cada alternativa de un nivel o paso.


13/98


10

3.6 Versionado de Casos de Uso

La aplicación permite versionar sistemas y versionar Casos de Uso. Se ofrecen distintas herramientas para llevar a cargo esta tarea, por ejemplo el listado de comparación de versiones de un caso de uso,detalla los cambios entre dos versiones seleccionadas. Puede ocurrir que el usuario que consulta elversionado del Caso de Uso no sea el mismo que lo generó, de esta manera puede ver reflejada en el

listado la evolución del CU desde el principio hasta la última modificación.

Fig. 3. Versionado de un Caso de Uso.

3.7 Exportación a archivos XML

Esta es una funcionalidad que proporciona el sistema para poder intercambiar datos con otrasaplicaciones por ejemplo un autómata finito. El archivo XML representa en este protocolo de intercambiode datos el grafo de estados del Caso de Uso que surge de la equivalencia con sus pasos y alternativas.

3.8 Consultas

Es posible obtener las siguientes salidas del sistema:

a) Sistemas b) Versionado de Sistemasc) Alcances por Versión de Sistemad) Casos de Uso por Alcancee) Versionado de Casos de Usof) Comparación entre dos Versiones de un Caso de Usog) Reportes de Casos de Uso

Para la versión vigente de un Caso de Uso se pueden imprimir los siguientes reportes:• Conversión a archivo XML para ingresar a Autómata Finito Determinista. • Gráfico de estructura del Caso de Uso en forma de árbol. • Reporte PDF del Caso de Uso. • Tabla de Estados del Caso de Uso.

h) Información de Usuarios

4 Validación de consistencia de Casos de Uso con simuladores de autómatas finitos

En la actualidad UML es reconocido como el estándar para el modelado de proyectos de softwareorientado a objetos.

Los componentes principales de esta metodología son los Casos de Uso ya que especifican elcomportamiento deseado del sistema. Por definición el caso de uso ―especifica una secuencia de acciones,incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor paraun particular actor‖.

Una vez generado un caso de uso, es necesario comprobar y asegurar su validez. La verificación deconsistencia de la secuencia de acciones descripta en el caso de uso es una de las tareas que permiten su

validación.Es deseable que esta verificación pueda realizarse de manera automatizada para lo cual se podríatrabajar con autómatas finitos deterministas, ya que un autómata finito es un conjunto de estados y un


14/98


11

determinado. El desafío es transformar el caso de uso en un autómata finito determinista para validar sucohesión secuencial.

Partiendo de estas premisas, el aporte del presente análisis a la validación de requerimientos que se propone lograr el proyecto de investigación, consiste en dar respuesta a la siguiente pregunta:

¿Es factible determinar un método, basado en simuladores de autómatas finitos deterministas, queverifique la consistencia de la secuencia de acciones, incluyendo variantes, definidas en un caso de uso?.

La funcionalidad de SIAR que se detalla a continuación propone una alternativa viable para estanecesidad, que se realiza en 3 pasos:4.1 Registración normalizada del requerimiento.4.2 Transformación del Caso de Uso en una máquina de estados.4.3 Validación de la consistencia secuencial de los cursos de acción del Caso de Uso.

4.1 Registración normalizada del requerimiento

Como el modelo de requerimientos tiene por objetivo la captura de requerimientos funcionales (Jacobsony otros, 1992), la primera tarea que se emprendió, fue la construcción de SIAR, una herramienta cuyo fines administrar en forma integral los requerimientos funcionales de un proyecto de software según elestándar UML y permite registrar en forma normalizada los casos de uso.

4.2 Transformación del Caso de Uso en una máquina de estados

En segunda instancia se definió un conjunto de reglas de conversión del caso de uso en un grafo deestados para que sea la entrada a un simulador de autómata finito determinista.Una vez completa la versión de un caso de uso, se genera un grafo de estados a partir de las siguientesdefiniciones:

• Todo caso de uso tiene al menos un curso de acción normal.• Un caso de uso puede no tener ningún, o tener uno o tener varios cursos de acción alternativos. • Cada paso de un curso de acción de un caso de uso responde a un estado y es un nodo de la

máquina de estados.• Todo caso de uso tiene un paso inicial, y es el primer paso de todos los cursos de acción. Este

paso es el estado/nodo inicial.• Todo caso de uso tiene un paso final por aceptación, y es el último paso del curso de acciónnormal. También puede ser el último paso de algún curso alternativo. Este paso es el estado/nodofinal por aceptación.• Un caso de uso puede no tener ningún, tener uno o tener varios finales por error, y son el último

paso de un curso alternativo. Estos pasos son estados/nodos finales por error.• Todo caso de uso pasa de un estado/nodo a otro por medio de una función de transición. • Partiendo de un estado/nodo origen se puede continuar en un único estado/nodo destino, o en

dos nodos/estados destino alternativos dependiendo de una condición de bifurcación.• El grafo de estados asociado al caso de uso tiene un alfabeto de tres símbolos para indicar qué

evento lo cambia de un estado/nodo a otro:

o A = Por medio de una Acción determinada.

o S = Cuando Si se cumple una condición que bifurca los cursos de acción.o N = Cuando No se cumple una condición que bifurca los cursos de acción.

Fig. 4. Bifurcación en la especificación de trazo fino de un Caso de Uso.


15/98


12

Partiendo de un estado/nodo origen, en la función de transición puede estar asociado solamente uno de lossímbolos: A, N o S. Con esto se cumple la condición necesaria de un autómata finito determinista. De estamanera, si la transición entre dos estados/nodos se da dentro de un mismo camino, se asocia el símbolo A.Si en cambio interviene una bifurcación, la función de transición hacia el estado/nodo destino porcumplimiento de la condición de bifurcación, se asocia el símbolo S. Por el otro camino de la bifurcación,se asocia el símbolo N.

Fig. 5. Tabla de estados de un Caso de Uso. Transformación automática por SIAR.

Una vez generado el grafo de estados se expresa en protocolo XPDL, por ser el más adecuado paraintercambiar modelos de procesos entre distintas herramientas. Este lenguaje ―da soporte a la definición ya la importación/exportación de procesos, con el objetivo de que, aunque se modele un proceso en unaaplicación, este modelo pueda ser usado por otras aplicaciones de modelado y/o por otras aplicacionesque trabajen en el entorno de ejecución‖ (Pérez, 2007).

Fig. 6. Fragmento de archivo XPDL generado por SIAR.

4.3 Validación de la consistencia secuencial de los cursos de acción del Caso de Uso

Finalmente se ingresa el archivo XPDL, que representa al caso de uso como grafo de estados, al programa―Autómata Finito‖ que forma parte del conjunto de ―Herramientas Prácticas para el Aprendizaje de

Informática Teórica‖. Esta aplicación java ―permite definir autómatas y gramáticas para la enseñanza y

ejercitación de los alumnos de la asignatura Sintaxis y Semántica del Lenguaje que se dicta en la carrerade Ingeniería en Sistemas de Información de la Universidad Tecnológica Nacional Facultad RegionalCórdoba‖ (U.T.N. F.R.C., 2009).


16/98


13

Fig. 7. Fragmento del grafo de estados en el simulador de autómatas finitos.

El simulador posibilita probar el grafo de estados y comprobar si es aceptado o rechazado. En el segundocaso se puede visualizar el detalle para detectar la inconsistencia, la cual puede ser corregida en unanueva versión del caso de uso, generando un nuevo grafo de estados automáticamente. De esta manera selogra control y trazabilidad de los cambios en los cursos de acción de los requerimientos funcionales.

Vale recordar a F. P. Brook s cuando dijo: ―la tarea más importante que el ingeniero de software hace parael cliente es la extracción iterativa y el refinamiento de los requerimientos del producto‖.

4.4 Limitaciones

El software limita su alcance con las siguientes restricciones:• En cada paso abarca alternativas hasta un nivel, sin embargo cada alternativa puede incluir másde un paso.• Los Casos de Usos no registran relaciones de inclusión y extensión..

4.5 Resultados

Se pone a consideración este método automatizado, implementado en el aplicativo SIAR que registra,normaliza y transforma un caso de uso a formato XPDL y un simulador de autómatas finitos, que permiteverificar la consistencia secuencial de los distintos caminos del caso de uso.El aporte que realiza SIAR al proyecto en el que fue concebido, ―Validación de Requerimientos a travésde Modelos Conceptuales‖, es el de constituirse como plataforma de software integradora de las

aplicaciones que se utilizan en cada una de las líneas de investigación.El presente desarrollo está fundamentado en una ―Propuesta Metodológica para validación deRequerimientos Funcionales a través de Modelos Conceptuales‖ registrada en la República Argentina con

Derecho de autor de producciones tecnológicas (rubro ―Modelo de organizac ión y/o gestión, Ciencia ycultura-Ciencia y tecnología‖) según Expediente No.5229942. Esta metodología expone cómo se llega aidentificar la necesidad de construir SIAR y la especificación de requerimientos funcionales de susalcances, módulos y funcionalidades.

También ―S.I.A.R. – Sistema Integral de Administración de Requerimientos‖ está registrado en laRepública Argentina con Derecho de autor de producciones tecnológicas (rubro ―Máquina, equipo,instrumento y/o herramienta o su/s componente/s. Informática-software. Ciencia y cultura-Ciencia ytecnología‖) según Expediente No.5229955. En lo que respecta a la funcionalidad de análisis de consistencia, SIAR ofrece un método automatizado

para validar la cohesión de un caso de uso desde el punto de vista de la transición de estados definidosintrínsecamente en los pasos de su especificación funcional. Permitiendo también enlazar este proyectocon un trabajo académico de la carrera Ingeniería en Sistemas de Información, el del Grupo deHerramientas Didácticas de Informática Teórica que contribuyó con el simulador de autómatas finitos.Finalmente se tiene previsto en el año 2015 hacer una transferencia del software a una empresaespecializada en desarrollos de seguridad informática de la región en el marco de un programagubernamental de generación y transferencia de conocimientos.

5 Conclusión


17/98


14

información según los lineamientos de UML. Haciendo posible también enlazar este proyecto con untrabajo académico de la carrera Ingeniería en Sistemas de Información, el del Grupo de HerramientasDidácticas de Informática Teórica que contribuyó con el simulador de autómatas finitos, que permitióimplementar un método automatizado para validar la cohesión de un caso de uso desde el punto de vistade la transición de estados definidos intrínsecamente en los pasos de su especificación funcional.

Como lo señalaron Taurant y Marciszack: ―Actualmente existen en el mercado una gran variedad de

herramientas y metodologías que permiten la gestión de requerimientos de software a lo largo del ciclo devida de desarrollo. Independientemente de la herramienta o metodología utilizada, la creación ymantención de un gran número de modelos y artefactos es realizada por el analista en forma manual,generando con gran frecuencia inconsistencias entre los modelos generados, impactando en latr azabilidad de los requerimientos.‖

Es por esto que se propuso con SIAR, el desarrollo de una herramienta que permita al analistagestionar los requerimientos en forma asistida y parcialmente automatizada, por medio de la generaciónde modelos conceptuales como representaciones de máquinas abstractas, considerando que se alcanzaronestos objetivos parcialmente.

Una alternativa factible para continuar trabajando con SIAR es ampliar la trazabilidad de los modelosde requerimientos de manera tal que permita medir el impacto de los cambios desde el ModeloConceptual hasta el Modelo de Sistema de Información agregando técnicas de validación yfuncionalidades de gestión de proyectos de software. Hasta el momento la metodología propuesta y el

modelo de datos de la herramienta que la soporta, posibilitan la trazabilidad desde el modelo derequerimientos del sistema con su origen en el modelo de datos, pero aún no se alcanza a medir elimpacto en el cambio de dichos modelos. Se está indagando la incorporación de ―Patrones‖, según el

concepto de la Ingeniería de Software, en la validación de Modelos Conceptuales como el próximo paso aseguir para ampliar el alcance de esta herramienta.

Además se hace necesario validar dentro del Modelo Conceptual también los Requerimientos nofuncionales desde el punto de vista del usuario, entendiendo que usabilidad es el atributo de calidad quemide la facilidad de las interfaces de un sistema.

Referencias

Rumbaugh, J., Jacobson,I., Booch,G. (1999). The Unified Modelling Language Reference. Addisson Wesley.

Chakraborty, Samarjit (2003). Formal Languages and Automata Theory-Regular Expressions and Finite Automata-.Computer Engineering and Networks Laboratory Swiss Federal Institute of Technology (ETH) Zurich.

Marciszack, Marcelo, Pérez,Ramiro, Castro, Claudia Castro (2013). Validación de Requerimientos a través deModelos Conceptuales – Modelos y Transformaciones. WICC 2013.

Jacobson, Ivar y otros (1992). Object Oriented Software Engineering. A Use Case Driven Approach. AddisonWesley.

Pérez, J. D. (2007). Notaciones y lenguajes de procesos. Una visión global. Tesis de Doctorado Universidad deSevilla.

U.T.N. F.R.C. (2009). Proyecto Construcción de Herramientas Didácticas para la enseñanza y ejercitación prácticaen laboratorio de Informática Teórica en las Carreras con Informática. Manual de Usuario – Grupo deHerramientas Didácticas.

Bibliografía adicional

Sommerville, I. (2005). Software Enginnering, Computing Departament, Lancaster University, John Willey&SonsLtd.

Davis, A. (1993). Software requeriments. Object, functions and states. Pretince Hall international Inc.

Brooks, Frederik P. (1987). No Silver Bullet. Essence and Accidents in Software Engineering. IEEE Computer.

Leonardi, C., Leite, J.C.S., Rossi, Gustavo (2001). Una estrategia de Modelado Conceptual de Objetos, basada enModelos de requisitos en lenguaje natural. Tesis de Maestría Universidad Nacional de la Plata.


18/98


Definición de Requerimientos de Software a Través de Escenarios

utilizando Patrones

Carlos Alberto Cortés Bravo1, María A. Abud Figueroa1, Celia Romero Torres,

Ulises Juárez Martínez1, Gustavo Pelaez Camarena1

,1 Instituto Tecnológico de Orizaba, División de Estudios de Posgrado e Investigación,

Av. Oriente 9 No. 852, Orizaba, Veracruz, México [email protected], {mabud, cromero, ujuarez

gpelaez}@ito-depi.edu.mx

Abstract. La definición de los requerimientos de software consiste en la especificación y validaciónde las funcionalidades que el sistema a desarrollar debe proporcionar, al igual que las restriccionesque el sistema debe cumplir. Para el análisis de los requerimientos existen varias técnicas, siendo losescenarios una técnica que permite describir el comportamiento esperado del software en un lenguajereconocido por los involucrados con lo que se logra una buena comunicación con el cliente. Por otra

parte, los patrones permiten reutilizar elementos previamente comprobados funcionando como unregistro de experiencias que ayudan a agilizar y mejorar los procesos. En este artículo se presenta una propuesta para la definición de patrones de escenario que servirán para tener una descripción másclara de los que se espera del software a desarrollar y que serán la base para un catálogo de patrones para un dominio especifico.

Keywords: patrones, escenarios, requerimientos de software

1 Introducción

Un punto prioritario en el desarrollo de software es la definición de lo que se quiere producir, ya que eldesarrollo del software inicia hasta el momento en el que se tienen establecidas a detalle las

características del software que se va a desarrollar, situación que es más crítica cuando se trata desistemas complejos.La ingeniería de requisitos es el área de investigación que atiende este punto fundamental en el proceso

de producción, proponiendo métodos, técnicas y herramientas que facilitan el trabajo de definición de loque se quiere de un producto de software. Su objetivo es aumentar el conocimiento del dominio del

problema para así representar las necesidades de un cliente en función de una aplicación de software deuna manera adecuada y entendible tanto para los usuarios finales como para el equipo de desarrollo.

Es de suma importancia asegurar una buena comunicación con los clientes y/o usuarios, ya que de ellodepende un futuro éxito o fracaso, porque es en esta parte en donde se recopila todo lo que el futurosistema tendrá implementado.

Existen diversas técnicas para documentar los requisitos, como son casos de uso, prototipos, puntos devista, escenarios, entre otras. De éstas se reporta como una de las más exitosas los escenarios, ya queéstos permiten mantener mucha información en una forma que los involucrados reconocen (Ridao, et al

2001). Son muchas las definiciones de la palabra escenario (Ridao, et al. 2001; Sutcliffe, 2003; Hadad, etal. 1996), una de las cuales es: ―un escenario es una descripción parcial y concreta del comportamiento deun sistema en una determinada situación‖ (Ridao, 2000).

Por otra parte, los patrones permiten, en diferentes áreas del conocimiento, utilizar soluciones previas aun problema en nuevas situaciones, ofreciendo un mecanismo de reutilización de experiencia. En estetrabajo, se propone el uso de patrones en la definición de escenarios con el fin de aprovechar lassituaciones recurrentes en la definición de requerimientos, para lo cual se establece un formato para sudefinición. En la sección 2 de este artículo se muestra una revisión de diferentes propuestas para larepresentación de requerimientos a través de escenarios, posteriormente en la sección 3 se presenta una

propuesta para la definición patrones de escenarios en la definición de requerimientos, finalmente se presentan las conclusiones.

2 Trabajos Relacionados sobre Definición de Requerimientos

L i i t ifi é l l i t d b h (f i ) i d d


19/98


16

proporcionar una visión amplia sobre lo que se pretende resolver con el desarrollo de una aplicación desoftware.

En la fase de definición de requerimientos, el ingeniero de requerimientos se enfrenta a distintasdificultades (Hadad et al 1996). La elección de una buena técnica para recopilar requerimientos como eluso de un lenguaje común, tanto para los desarrolladores como para los clientes y usuarios, es vital paragarantizar un buen proceso de definición y validación de requerimientos. De igual manera es muy

importante comprender el dominio del problema, con lo cual se necesita que el ingeniero derequerimientos se vuelva experto en el dominio para así comprender de la manera más amplia lasnecesidades del cliente, ya que de no ser así es muy probable que se recopilen requerimientos incompletosy erróneos.

2.1 Lenguaje para Definición de Requerimientos

Capturar el dominio del problema es una de las formas mediante las cuales se garantiza una mejorcompresión en la descripción de un escenario, tanto por clientes como por el equipo de desarrollo. Elvocabulario del UdeD (Universo de Discurso) es el que refleja las palabras peculiares y más usadas en elmismo (Ridao, et al. 2001). Para la recopilación del conocimiento del UdeD es necesario revisar ladocumentación, realizar entrevistas o aplicar otras técnicas. Son diversos los casos donde la construcción

de escenarios se basa en el UdeD como en (Ridao, et al. 2001; Ridao, 2000; Doorn, 2002), con el propósito de mantener una buena comunicación con el cliente, ya que se logra que el ingeniero derequerimientos maneje un vocabulario entendible tanto por los integrantes del equipo de desarrollo asícomo por los clientes y/o usuarios. Uno de los métodos que permite mantener un leguaje homogéneo paraambos es el LEL (Léxico Extendido del Lenguaje), el cual es una representación de los símbolos en ellenguaje del dominio del problema (do Prado Leite. et al. 1997). Combinar el uso de escenarios y el LELfacilita la compresión por parte de las personas no especializadas en el desarrollo del software (Hadad,2010).

Los objetivos del LEL son conocer el vocabulario del usuario y contar con un instrumento simple detrazabilidad (Hadad, et al. 1996). Los elementos para la descripción de un símbolo LEL son: nombre,noción e impacto; el nombre identifica el símbolo del LEL, la noción indica qué es el símbolo y elimpacto cómo repercute en el sistema. En la Tabla 1 se presenta un ejemplo de un símbolo del LEL quese construye para un caso de estudio de una biblioteca, en la cual se observa que el nombre que se le da

está formado por dos palabras siendo estas sinónimos mediante las cuales se identifica el símbolo(Kaplan, et al. 2000).

Tabla 1. Ejemplo simbología del LEL.

Las heurísticas que son utilizadas para la construcción del LEL son: identificar fuentes de información,identificar símbolos, clasificar símbolos, describir los símbolos, verificar el LEL y validarlo. Una vez quese obtiene el LEL es necesario actualizarlo para obtener la mejor compresión del UdeD. Así como estatécnica mejora la comprensión del dominio del problema, también es posible que tenga defectos loscuales surgen cuando no se construye un LEL de manera correcta. Los principales defectos que puedencontener el LEL son: de descripción, de clasificación, de identificación y de referencia los cuales estándescritos en (Kaplan, et al. 2000).

2.2 Representación de un Escenario

En Ryser (1999) define un procedimiento para la recopilación de los requerimientos y su documentación


20/98


17

• Encontrar todos los eventos relevantes al sistema.• Determinar entradas, resultados y salidas del sistema.• Determinar límites del sistema.• Crear descripciones de escenarios amplias.• Priorizar los escenarios de acuerdo a la importancia, asegurar que los escenarios cubran

la funcionalidad del sistema.

• Crear una descripción paso a paso de eventos y acciones para cada escenario• Crear un gráfico general y un diagrama de dependencia.• Tener opinión y comentarios de los usuarios sobre los diagramas y escenarios.• Extender escenario al refinar su descripción, dividir las tareas en pasos de trabajo

individuales.• Flujo de acciones del modelo alternativo, especificar excepciones y cómo reaccionar a

las excepciones.• Factorizar escenarios abstractos (secuencias de interacciones que aparecen en más de un

escenario).• Incluir requerimientos no funcionales y cualidades en escenarios.• Revisar el diagrama de información general y diagrama de dependencia.• Pedir a los usuarios comprobar y validar los escenarios (revisiones formales).

Para la construcción de un escenario es preciso considerar los elementos por los que este escenarioestará formado. En (Hadad, G et al 1996) se muestran algunos ejemplos de escenarios, en los cuales seobservan los siguientes elementos como parte de un escenario: nombre, objetivo, contexto, recursos,actores, conjunto de episodios y casos alternativos. En (Hadad, G et al 1997) se propone otrarepresentación de un escenario que se ilustra como un diagrama E-R y se observa en la Figura 1.

Fig. 1. Diagrama Entidad-Relación para la construcción de un escenario

Las propuestas revisadas son muy similares, básicamente tienen los mismos elementos para representarun escenario. En la Tabla 2 se presenta un ejemplo de un escenario de un caso de estudio ―Sistema

Nacional para la Emisión de Pasaportes (Hadad, et al. 1998).


21/98


18

Tabla 2. Ejemplo Escenario para ―Sistema Nacional de Emisión de Pasaportes‖

Tomando en cuenta los modelos revisados, se propone incluir en la representación de un escenario loselementos: título, objetivo, acción, recursos, actores, episodios y excepciones, mismos que se representanen un diagrama de clases UML como se muestra en la Figura 2.

Fig. 2. Elementos Escenario

3 Patrones de Escenario

El uso de patrones en la construcción de escenarios permite ahorrar tiempo para la construcción de losmismos, ofreciendo una visión más estructural de las situaciones, y con esto determinar el tipo deescenario que corresponda a cada situación. En este sentido existen algunas propuestas como la de(Ridao 2001), sin embargo ofrecen situaciones muy abstractas y difíciles de utilizar.

En este trabajo se propone el uso de patrones para la representación de escenarios basados en lanotación LEL, compuesto por la siguiente notación:

+ significa composición,{x} significa cero o más ocurrencias de x,( ) es usado para agrupamiento,


22/98


19

El patrón se forma con los siguientes elementos:

Títuloo El título identificará de forma única un escenario para una acción específica del sistema.o Sintaxis: Frase

Objetivoo El objetivo describirá de forma breve que se logra con implementación de este

escenario.o Sintaxis: [Actor | Recurso] + Verbo + Predicado

Actoreso Se mencionarán los involucrados que participan en este escenario en particular.o Sintaxis: Nombre

Accióno Describirá la actividad que se ejemplifica este escenario.o Sintaxis: [Sujeto | Actor | Recuso] + Verbo + Predicado + {Restricción}

Restriccióno Describirá la situación solo en la que este escenario tendrá lugar (opcional)o Sintaxis: [Actor | Recurso] + Verbo + Predicado

Secuenciao Contendrá los pasos que describen de forma clara los pasos que sigue este escenario,

para llegar a un fin.o Sintaxis:

::= | |

::= ::= IF THEN ::= [ ]donde es descrita como:(([Actor | Recurso] + Verbo + Predicado) | ([Actor | Recurso] + [Verbo] +Título)) + {Restricción}

Secuencia Alternao En caso de que durante el proceso de esta actividad no se logre completar

satisfactoriamente en este apartado se describirá lo que sucederé en esos casos.o Sintaxis:

Causa [(Solución)]donde Causa es:

Frase | ([Sujeto | Actor | Recurso] + Verbo + Predicado)donde Solución es:

Título

Con base en esta propuesta, en la Tabla 3 se muestra un ejemplo del patrón de escenario Ingreso,mismo que detalla los pasos a seguir cuando un usuario realiza una acción de acceso al sistema.

Tabla 3. Patrón de Escenario Ingreso Título Ingreso Objetivo Un actor ingresa datos de identificación para acceder al sistemaActores Sólo un actorAcción El Usuario inicia sesión en el SistemaRestricción Por lo menos unaSecuencia Por lo menos uno como el siguiente:

El Actor ingresa datos de identificación para acceder al sistema Se verifica que los datos son correctos

DEBEN ESTAR EN SECUENCIA INTERACCIÓN ACTOR YSISTEMA

Secuencia Alterna Circunstancia que obstaculiza el acceso al sistema

La Tabla 4 muestra el caso específico de uso de este patrón para un ingreso donde se solicita a un


23/98


20

Tabla 4. Uso del Patrón de Escenario Ingreso Título Ingreso Objetivo Un actor ingresa datos de identificación para acceder al sistemaActores UsuarioAcción El Usuario inicia sesión en el Sistema

Restricción El Usuario debe ser un Usuario RegistradoSecuencia El Usuario ingresa id y contraseña y selecciona la opción Ingresar

SI id existe ENTONCES verifica contraseña SI contraseña es correcta ENTONCES el sistema verifica

privilegios e inicia sesiónSecuencia Alterna Id no existe [mensaje de error]

Contraseña errónea [mensaje de error]

4 Conclusiones

Los escenarios son una técnica que permite mantener una descripción clara y concisa de los

requerimientos, por lo que combinándola con el uso de LEL como la técnica para la construcción deescenarios, permite tener un proceso más ágil de definición/validación de requerimientos con losclientes/usuarios y de esta manera evitar la propagación de requerimientos y descripciones incompletasque pueden llegar a ser interpretadas de múltiples maneras y llevar a errores en la implementación de lasfuncionalidades de un software.

Una de las ventajas que tienen los escenarios es que la posibilidad de construirlos a partir de patrones,de tal manera que es posible reutilizar las soluciones a situaciones similares que se presentan en diversos

proyectos de software. El contar con una representación formal para un escenario facilitará la creación deun catálogo de patrones que ayude a agilizar y hacer más segura la definición de requerimientos.

En comparación con los trabajos revisados, esta propuesta está enfocada en describir escenarios que puedan ser útiles para tener una descripción más precisa en cuanto a lo que se espera del software adesarrollar, cuyas situaciones son recurrentes en casi cualquier sistema de software, en el trabajo de Ridao(2001) su propuesta describe situaciones muy abstractas y difíciles de reconocer en primera instancia.

Como trabajo futuro se propone el desarrollo de un catálogo de patrones de escenarios para un dominioespecífico y realizar las pruebas de campo que permitan exponer las ventajas que trae consigo el uso deun catálogo de patrones para la construcción de escenarios.

Agradecimientos.

El autor corresponsal agradece al Consejo Nacional de Ciencia y Tecnología CONACYT por el apoyo brindado para la realización de los estudios de postgrado.

Referencias

1. Do Prado Leite, J. C. S., Rossi, G., Balaguer, F., Maiorana, V., Kaplan, G., Hadad, G., & Oliveros, A.Enhancing a requirements baseline with scenarios. Requirements Engineering, 2(4), 184--198 (1997)

2. Doorn, J. H., Hadad, G. D., & Kaplan, G. N. Comprendiendo el Universo de Discurso Futuro conEscenarios. In WER, 117--131 (2002).

3. Hadad, Graciela DS., Doorn, Jorge., Kaplan, Gladys. Enfoque middle-out en la Construcción e Integraciónde Escenarios, (1998)

4. Hadad, G., Kaplan, G., Oliveros, A., & Sampaio do Prado Leite, J. C. Integración de Escenarios con elLéxico Extendido del Lenguaje en la elicitación de requerimientos*: Aplicación a un caso real, (1996)

5. Hadad, G.; Kaplan, G.; Oliveros, A.; Leite, J.C.S.P. Construcción del Léxico Extendido del Lenguaje yderivación de Escenarios para la elicitación de requerimientos, (1997)

6. Hadad, G. D. S. Uso de Escenarios en la Derivación de Software. In XII Workshop de Investigadores enCiencias de la Computación, (2010)

7 Kaplan G N Hadad G D Doorn J H & do Prado Leite J C S Inspección Del Lexico Extendido Del


24/98


21

8. Potts, C., Takahashi, K., & Antón, A. Inquiry-based requirements analysis. IEEE software, 11(2). 21--32(1994)

9. Ridao, Marcela. Uso de Patrones en el Proceso de Construccion de Escenarios. Workshop de Engenharia deRequisitos. 140--157 (2000)

10. Ryser, J., & Glinz, M. A scenario-based approach to validating and testing software systems usingstatecharts. In Proc. 12th International Conference on Software and Systems Engineering and their

Applications, (1999)

11. Ridao, Marcela. Uso de Patrones en el Proceso de Construcción de Escenarios. Tesis Doctoral. Facultad deInformática, (2001)

12. Ridao, Marcela and Jorge Doorn., and Julio Cesar Sampaio (2001). Incorporación de Patrones al Proceso deConstruccion de Escenarios. Workshop em Engenharia de Requisitos, Buenos Aires, Argentina, s.f. 107--123 (2001)

13. Sutcliffe, A. Scenario-based requirements engineering. In Requirements engineering conference,.Proceedings. 11th IEEE international 320--329 (2003)

14. Toro, A. D., & Jiménez, B. B. Metodología para la Elicitación de Requisitos de Sistemas Software. InformeTécnico LSI-2000-10. Facultad de Informática y Estadística Universidad de Sevilla. (2000)


25/98


26/98


23

Fig. 1 Proceso de software orientado a objetos

2 Trabajos relacionados

En (Xiang-xi Meng, 2007) se menciona que a pesar de que existe gran variedad de casos exitosos en eluso de métodos ágiles, dado que cada proyecto de software es único es difícil definir una serie de

procesos universales y repetibles para todos los proyectos ágiles. Por ello, se propuso un lenguaje que se basa en patrones de proceso para métodos de desarrollo ágil. PPL ( Process Pattern Language, Lenguajede Patrones de Proceso) se basa en dos metodologías ágiles, XP (eXtreme Programming , ProgramaciónExtrema) y SCRUM, combinando el proceso de desarrollo de ambas metodologías para generar unmodelo de proceso ágil apropiado para diferentes proyectos en diferentes organizaciones.

En (Mohsen Asadi, 2009.) se menciona la poca flexibilidad que proporcionan las metodologías dedesarrollo tradicionales ya que no proveen el soporte necesario para el desarrollo de proyectos de sistemasmodernos, lo cual conlleva a cambiar de metodología entre un proyecto y otro. Por ello propusieron el

proceso de ingeniería de métodos situacional (SMEP) como marco de trabajo que se basa en patrones de proceso para generar procesos SME (Situational Method Engineering , Ingeniería de Métodos Situacional)

a la medida.En (Tran, 2007) se mencionó que aplicar patrones de proceso tiene como principales objetivos dar a

conocer las mejores prácticas de los procesos y reducir el tiempo de modelado de éstos. La problemáticaque se abordó es que aunque existen diversos intentos para formalizar a los patrones de proceso, ningunocumple totalmente con todos los requerimientos que se mencionan anteriormente, es por esta razón que

presenta un meta-modelo de procesos que se basa en UML y permite una representación explícita de patrones de proceso en los modelos de procesos. Lo novedoso de la propuesta es que permite laaplicación de diferentes tipos de procesos no solo para construir sino también para mejorar los modelosde procesos.

La principal aportación de los patrones de procesos es reducir tiempo y esfuerzo en el desarrollo desoftware mediante la reutilización de procesos de desarrollo ya existentes. Como se observa este tipo de

patrones tienen diferentes usos. Sin embargo no existen trabajos que reporten un proceso basado en estos patrones que sirva para el desarrollo de aplicaciones Web.

3 Proceso

En esta sección se presenta el proceso propuesto basado en patrones de proceso para desarrollaraplicaciones Web. Se tomó como base los patrones propuestos por Scott Ambler (Tabla 1), eligiendo lasactividades más adecuadas para el caso de las aplicaciones Web, complementado la definición con los

patrones de diseño de Gamma para la parte de diseño.

3.1 Elementos del proceso

La idea central del proceso se basa en tres elementos básicos: rol, producto de trabajo y tarea (Figura 2).

Las tareas representan el esfuerzo a hacer, los roles representan quién lo hace y los productos de trabajorepresentan las entradas que se utilizan en las tareas y las salidas que se producen. La idea centralsubyacente consiste básicamente, en decir quién (rol) realiza qué (tarea) para, a partir de unas


27/98


24

Fig.2 Idea básica de proceso SPEM 2.0

Tabla 1. Patrones de proceso propuestos por Scott Ambler.

3.2 Roles

A continuación se definen los roles técnicos y el perteneciente a la parte del cliente. Es importamencionar que roles como ingeniero de requisitos, administrador del proyecto, programador, diseñador,ingeniero de pruebas y técnico de soporte, tendrán la tarea de realizar los documentos que sean necesarios

de acuerdo a los productos de trabajo que se definieron.

Jefe del proyecto. Se encarga de dirigir el proyecto, asegurándose que cada actividad, tarea y producto detrabajo se realice de manera correcta. Las tareas que desempeña este rol se muestran en la Figura3.

Fig.3 Jefe de proyecto

Patrón de proceso

propuesto por Scott AmblerDescripción

Initiate El objetivo principal de este patrón es poner las bases para un proyecto exitoso. Se compone de ladefinición y validación de los requerimientos, la

administración de documentos, la justificación ydefinición de la infraestructura del proyecto.Construct Este patrón se concentra en la construcción de la

aplicación de manera que sea fácil de mantener y demejorar. Incluye tareas de modelado, programación,

pruebas unitarias y reutilización. Deliver Se enfoca en proporcionar al cliente una

aplicación que se haya desarrollado con un trabajode alta calidad y que se encuentre bien documentada.Se basa en realizar pruebas, mejorar los defectos, yen la liberación del sistema poniéndola a disposiciónde los usuarios y capacitándolos.

Maintenance and Support Su objetivo es mantener la aplicación en

funcionamiento y lo más actualizada posible. Esdecir, que se atienden las necesidades de los usuarios proporcionando capacitación, dando respuesta a susdudas y reparando cualquier problema que se

presente.


28/98


25

Ingeniero de requisitos. Recolecta toda la información necesaria que el cliente proporciona para eldesarrollo de la aplicación. Las tareas que desempeña este rol se muestran en la Figura 4.

Fig.4 Ingeniero de requisites

Administrador del proyecto. Es el encargado de elaborar todos los documentos administrativos del proyecto. Las tareas que desempeña este rol se muestran en la Figura 5.

Fig.5 Administrador del proyecto

Programador. Es el encargado de construir la aplicación de acuerdo con las especificaciones dadas enlos requisitos que el cliente proporcionó. También realiza las mejoras de los defectos que la aplicaciónnecesite. Las tareas que desempeña este rol se muestran en la Figura 6.

Fig.6 Programador

Diseñador. Analiza los requisitos y en base a ellos elabora los modelos que permitirán observar con másdetalla cómo estará constituida y estructurada la aplicación. Las tareas que desempeña este rol semuestran en la Figura 7.

Fig.7 Diseñador

Ingeniero de pruebas. Realiza las pruebas que son necesarias para verificar la correcta funcionalidad dela aplicación y documenta todo a través de reportes. Las tareas que desempeña este rol se muestran en laFigura 8.

Fig.8 Ingeniero de pruebas

Técnico de soporte. Es el encargado de recibir, analizar y proporcionar una solución a las solicitudes desoporte que el cliente requiere. Las tareas que desempeña este rol se muestran en la Figura 9.


29/98


26

Fig.9 Técnico de soporte

Usuario final. Es el cliente que se encarga de aportar la información necesaria sobre qué es lo que esperay cómo quiere interactuar con la aplicación Web. Las tareas que desempeña este rol se muestran en laFigura 10.

Fig.10 Usuario Final

3.3 Fases del proceso

En esta sección se explicarán a detalle las fases que conforman el proceso de desarrollo de aplicacionesWeb, cada una de las cuales se conforman de actividades que a su vez contienen tareas y productos detrabajo. El proceso consta de cuatro fases principales: inicio, construcción, y mantenimiento-soporte, delas cuales las fases de construcción y entrega son iterativas (Figura 11).

Fig.11 Fases del proceso

3.3.1 Fase de Inicio

La fase de inicio tiene como objetivo obtener información proveniente del cliente para detectar losrequerimientos para la construcción de la aplicación, así como preparar los documentos que permitan unamayor organización para lograr el éxito del proyecto. Las actividades propuestas en esta fase seseleccionaron del patrón de proceso Initiate (Inicio) propuesto por Scott Ambler (Figura 12) y se detallana continuación:

Fig.12 Fase de inicio

Definir y validar requerimientos. Determina exactamente las características del software que seentregará al usuario final, para ello se realizan una serie de actividades con el fin de recolectar, definir yvalidar los requisitos que indiquen qué características tendrá la aplicación a desarrollar. Las tareas arealizar son:

Definición de requerimientos. El jefe del proyecto y el ingeniero de requisitos se citan con el

cliente para realizar una serie de entrevistas que permitan obtener la mayor cantidad de

información para determinar los requerimientos de la aplicación que se quiere desarrollar.

Documentación de requerimientos. El ingeniero de requisitos realiza un documento de

requerimientos donde especifica cada uno de los requerimientos del sistema.

Validación de requerimientos. El ingeniero de requisitos, el jefe del proyecto y el cliente se

reúnen en varias ocasiones según se requiera con el fin de realizar un análisis para verificar los

requerimientos que se tienen, para evitar se olvide algún requisito o que no se haya comprendido

con claridad.El producto de trabajo generado es: Documento de requerimientos. Especificación a detalle de los requerimientos acordados con el


30/98


27

Definir documentos de administración. En esta etapa se crean documentos importantes que permiten laadministración adecuada del proyecto. Las tareas a realizar son:

Elaboración del plan del proyecto. El jefe del proyecto y el documentador realizan un

documento formal y aprobado el cual se usará para guiar, controlar y ejecutar el proyecto.

Elaboración del plan de evaluación de riesgos. El jefe del proyecto y el documentador evalúan

e identifican los posibles riesgos que surgirán durante el desarrollo del proyecto y plantean

medidas de solución. El objetivo es identificar los riesgos para que tengan un impacto mínimo enel proyecto y así evitar pérdidas de tiempo y dinero.

Elaboración del plan de aseguramiento de la calidad . El jefe del proyecto y el documentador

identifican las técnicas y procedimientos que se emplearán en las actividades de prueba y

aseguramiento de la calidadLos productos de trabajo generados son: Plan del proyecto. Documento que permite organizar todos los componentes que conforman un

proyecto. Plan de evaluación de riesgos. Documento en donde se definen los posibles riesgos del

proyecto, su prioridad y la tasa de impacto que tendrá, así como posibles alternativas desolución.

Plan de aseguramiento de la calidad. Documento que describe las políticas y procedimientosde prueba que serán empleadas.

Justificación. Se conforma de un estudio de factibilidad y por la identificación de posibles riesgos que puedan surgir durante el desarrollo del proyecto. Las tareas a realizar son:

Realización del estudio de factibilidad. El administrador del proyecto es el encargado de

realizarlo, con el fin de comparar diversas alternativas de implementación basándose en la

factibilidad técnica, económica y operacional que se tenga. De acuerdo con los resultados que se

obtengan se selecciona la alternativa que mejor convenga.

Identificación de riesgos. El administrador del proyecto identifica y define los riesgos posibles

que fueron encontrados durante el estudio de factibilidad técnica y operacional del proyecto, los

cuales se agregan al documento de riesgos.El producto de trabajo generado es: Documento de estudio de factibilidad. Describe los resultados del estudio de factibilidad. Documento de riesgos. Describe los posibles riesgos y sus soluciones.

Definir infraestructura. Se define la infraestructura necesaria para el desarrollo de la aplicación: lasherramientas de desarrollo, el equipo de trabajo, entre otras. Las tareas a realizar son:

Definición del equipo del proyecto. El administrador del proyecto/ingeniero de infraestructura

selecciona a las personas que formarán parte del equipo de desarrollo de acuerdo a sus

habilidades, asignando a cada una su rol y las responsabilidades que tendrá dentro del desarrollo

del proyecto.

Adaptación del proceso de software. Se seleccionan y definen los procedimientos y

metodologías que se deberán seguir para que los miembros del equipo de desarrollo sepan qué es

lo que harán y cómo se realizará, con el fin de aumentar la eficacia del equipo del proyecto.

También se seleccionan y definen los estándares y directrices que se aplicarán en el proyecto

para asegurar consistencia y mantenibilidad.

Definición de herramientas. Antes de comenzar la fase de construcción se necesita seleccionar

la herramienta que se utilizará para el modelado, la documentación, la administración del

proyecto, entornos de programación, de soporte y de prueba.El producto de trabajo generado es: Documento de infraestructura. Tiene una descripción de las personas involucradas en el

proyecto, cuáles serán los roles y qué responsabilidades tendrán, así como las herramientas deapoyo para el desarrollo

3.3.2 Fase de Construcción

La fase de construcción se compone de tres etapas, así como una serie de iteraciones para el desarrollo decada parte de la aplicación Web y al final se define un hito que permite verificar si los objetivos se

cumplieron. Se basa en el patrón de proceso Construct (Construcción) propuesto por Scott Ambler(Figura 13) y consta de las siguientes actividades:


31/98


28

Fig.13 Fase de construcción

Modelado. Se crean diversos modelos con base en los requerimientos que permiten al desarrollador unamejor compresión de lo que realmente se desea construir. Las tareas a realizar son:

Diseño del modelo de requerimientos. El diseñador con base en los requisitos identifica los

actores que participarán en el uso de la aplicación Web así como las funciones a las que tendrá

acceso cada uno.

Diseño del modelo conceptual. Consiste en el diagrama de clases que representa los datos del

dominio que se usan en la aplicación.

Diseño del modelo de presentación. El diseñador define cómo se verá estructurada la

aplicación Web, es decir, crea las interfaces de usuario que se mostrarán. Se sugiere utilizar los

patrones de diseño de interfaz de usuario, los cuales permiten un buen diseño de interfaz.

Diseño del modelo de navegación. El diseñador define la forma en cómo el usuario navegará a

través de la aplicación Web. Definición de la tecnología a utilizar. Determinar qué tecnología se utilizará para el desarrollo

de la aplicación Web.

Los productos de trabajo generados son: Modelo de requerimientos. Permite representar los elementos que formarán parte de la

aplicación Web, así como la relación que existirá entre ellos.

Modelo conceptual. Permite representar las clases con los elementos que formarán parte de la

aplicación.

Modelo de presentación. Permite representar la forma en que se presentará la información al

usuario, así se tiene una mejor comprensión y se especifica cómo los actores interactuarán con la

aplicación.

Modelo de navegación. Permite representar la navegación a páginas relacionadas a través de

asociaciones o enlaces hipertextuales. Tecnología. Engloba el lenguaje de programación, servidor de base de datos, y cualquier

tecnología a utilizar para el desarrollo de la aplicación Web.

Programación. Se genera el código fuente para el desarrollo de la aplicación Web y su respectivadocumentación. Aquí se desarrolla la tarea:

Codificación y documentación. El programador con base en los requisitos, y los modelos que

se diseñaron anteriormente, construye la aplicación Web haciendo uso de la tecnología de

programación que se seleccionó, así como también se genera la documentación necesaria para el

usuario. En esta etapa se sugiere utilizar patrones de diseño propuestos por Gamma.

El producto de trabajo es: Código Fuente Documentado. Es un conjunto de instrucciones que engloban la funcionalidad

de la aplicación incluyendo información detallada. Pruebas unitarias. Se enfoca en la verificación, validación y prueba de documentos, modelos y

código fuente que se generó durante cada iteración. Las tareas a realizar son: Realización de pruebas. El ingeniero de pruebas realiza una serie de pruebas necesarias para

verificar que los artefactos desarrollados funcionen bien de acuerdo a lo que el usuario necesita,

y documenta lo que salió mal, sugiriendo su solución.

Realización de correcciones. El programador, con base al reporte de pruebas, corrige los

errores que se presentaron y se verifica nuevamente que todo funcione de manera correcta.

El producto de trabajo generado es: Reporte de pruebas unitarias. Documenta todos los detalles de las pruebas que se realizan a la

aplicación Web.

3.3.3 Fase de Entrega

La fase de entrega permite ajustar los últimos detalles del producto para asegurar que al ser implementadofuncionará de manera adecuada para satisfacer las necesidades del cliente. Consta de un conjunto de


32/98


29

visualizar que los objetivos de la iteración se cumplieron, así como de las siguientes actividades, lascuales fueron seleccionadas del patrón de proceso Deliver (Entrega) propuesto por Scott Ambler (Figura14).

Fig.14 Fase de entrega

Pruebas de integración. Se junta lo que se desarrolló durante la iteración con lo que ya funciona de laliberación anterior, para después realizar una serie de pruebas para verificar que funciona correctamente.Las tareas a realizar son:

Integración de módulos. El programador integra el módulo que se desarrolló durante la

iteración con lo que ya se tiene de liberaciones anteriores.

Realización de pruebas del sistema. El ingeniero de pruebas realiza una serie de pruebas a la

aplicación Web para determinar las capacidades de la aplicación y resolver los problemas antes

de pasar a las pruebas de usuario. Realización de pruebas de usuario. El usuario realiza un proceso de pruebas con el fin de

verificar que la aplicación satisface sus necesidades.

El producto de trabajo generado es: Reporte de pruebas de integración. Documenta todos los detalles de las pruebas que se

realizan a la aplicación Web.

Mejora. Se reparan defectos críticos que se detectaron en la etapa de pruebas de integración.Consta de las siguientes tareas:

Priorización de defectos. El ingeniero de pruebas analiza los defectos que se encontraron

durante la etapa de pruebas de integración y los enlista de acuerdo a la prioridad que requieren

para ser resueltos, de manera que se reparen a tiempo antes de que generen un gasto mayor

después.

Reparación de defectos. El programador se encargará de dar solución a los defectos según su prioridad. Antes de realizar estos cambios, se realizará un análisis de impacto, para determinar

las posibles afectaciones al hacer el cambio. Con base a los resultados de este análisis, se

realizarán las modificaciones que necesite la aplicación, en dónde se actualizarán los modelos,

código fuente, documentación y se realizará otra vez pruebas unitarias. El producto de trabajo generado es: Reporte de mejora defectos. Enlista los defectos que se encontraron con base a su prioridad y la

descripción detallada de cada uno.

Liberación. Se entrega la liberación de una iteración hasta llegar a la entrega final de la aplicación Web,la documentación correspondiente y dar la capacitación necesaria al usuario. Las tareas a realizar son:

Preparación de la liberación. El administrador y jefe del proyecto se aseguran y preparan todo lo

necesario (documentos, aplicación, etc.) para realizar la entrega al cliente.

Liberación a la comunidad de usuarios. El jefe del proyecto se encarga de realizar la entrega

formal de la aplicación al cliente para su implantación.

Los productos de trabajo generados son: Aplicación Web. Producto funcionalmente terminado que cuenta con las características que el

cliente solicitó.

Manual del usuario. Documento dirigido al usuario final que explica el funcionamiento de la

aplicación, desde su instalación hasta cómo se utiliza en general.

3.3.4 Fase de Mantenimiento-soporte

La fase de mantenimiento-soporte es la fase final del proceso e involucra la identificación de defectos y la

corrección de los mismos una vez que el producto está implementado, de manera que se mejore yoptimice la aplicación. Consta de las siguientes actividades, las cuales fueron seleccionadas del patrón de proceso Maintenance and Support (Mantenimiento-soporte) propuesto por Scott Ambler (Figura 15).


33/98


30

Fig.15 Fase de mantenimiento-soporte

Soporte. Se da respuesta a las solicitudes entrantes provenientes de los usuarios, para identificar una

solución a la solicitud y después supervisar la implementación a esa solución. Las tareas a realizar son: Respuesta a una solicitud. El técnico de soporte recibe una solicitud de un usuario el cual

necesita que le brinden soporte para resolver un problema a la brevedad posible.

Determinación de la resolución. El técnico de soporte trabajará en conjunto con el usuario

solicitante con el fin de determinar una solución para el problema.

Resolución del problema. Una vez que se tiene una estrategia de solución, el técnico en soporte

guiará al usuario para implementar la solución con el objetivo de resolver el problema actual.

Los productos de trabajo generados son: Solución. Es la respuesta que se le da a un problema para que funcione adecuadamente el

elemento que lo presenta.

Solicitud de cambio de software (SCR). Descripción de una mejora al software. Las solicitudes

se envían a la etapa de identificar defectos y mejores para que se traten esos cambios.

Identificar defectos y mejoras. Se analizan las solicitudes de cambio de software que se definieron en laetapa de soporte de modo que esos cambios se identifican y se asignan a los elementos de configuraciónapropiados. Las tareas a realizar son:

Análisis de peticiones de cambio de software. Se analizan las solicitudes que se tienen y se

identifica si se trata de un defecto o de una mejora. Para ello se tienen cuatro categorías para

mantenimiento de cambios: preventivo y correctivo que se usan para defectos, y adaptativo -

perfectivo para mejoras.

Priorización de mantenimiento. Después de que se ya se identificó si se dará mantenimiento a

la aplicación por defecto o por mejora, se les asigna prioridad. Existen tres maneras de priorizar:

emergencia, urgente y regular.

Asignación de cambios de mantenimiento a los elementos de configuración. Se realizan los

cambios de acuerdo a su prioridad.

El producto de trabajo que se genera es: Reporte de mantenimiento-soporte. Documento que engloba una descripción de los problemas

de software que se identificaron y de los cambios que se realizarán.

4. Conclusiones

El uso de patrones de proceso en el desarrollo de software proporciona un beneficio ya que permitenreutilizar actividades que fueron probadas y tuvieron resultados de éxito en situaciones similares, lo quetiene como ventaja un desarrollo rápido, disminuyendo el riesgo de fracaso en los proyectos.

En la actualidad no se reporta un proceso basado en patrones de proceso para desarrollar aplicacionesWeb, por ello el presente documento presentó la definición de un proceso el cuál se basa en el conjuntode patrones de proceso propuesto por Scott Ambler. Consta de cuatro fases principales, así como susetapas, tareas y productos de productos de trabajo respectivos que se definieron como parte del proceso dedesarrollo para aplicaciones Web, el cual fue creado con base al meta-modelo SPEM 2.0 y de acuerdo a laselección de un conjunto de patrones de proceso que se consideraron importantes para el ciclo de vida dedesarrollo de aplicaciones Web. También se especifica cada uno de los roles que participan en este

proceso y sus responsabilidades.

5. Trabajo a futuro

Se trabaja en un caso de estudio para validar el proceso de desarrollo propuesto. Se desarrolla unaaplicación Web que automatice el proceso de residencias profesionales que se llevan a cabo en eldepartamento académico de sistemas y computación del Instituto Tecnológico de Orizaba. Actualmente

se está trabajando en la etapa de modelado de la fase de construcción, refinando detalles del modeloconceptual, de navegación y presentación.Como trabajo futuro se seguirá trabajando en las siguientes fases y etapas de desarrollo del caso de


34/98


31

6. Referencias

Alexander, C. (1979). The Timeless Way of Building. Oxford University Press, New York.

Ambler, S. W. (1999). More process patterns: building large-scale systems using object technology. CambridgeUniversityPress.

Ambler, S. W. (1998). Process patterns: building large-scale systems using object technology. Cambridge UniversityPress.

Gamma Erich et al (2009). Patrones de diseño. Pearson Addison Wesley,

Mohsen Asadi, R. R. (2009.). "Method engineering process patterns.". Proceedings of the 2nd India softwareengineering conference.New York, USA: ACM. , 143-144.

Ruiz Francisco, J. V. (2008). ―Guía de Uso de SPEM 2 con EPF Composer‖.

Tran, H. C. (2007). "Modeling Process Patterns and Their Application.". Software Engineering Advances, ICSEA. ,25-31.

Xiang-xi Meng, Y.-s. W.-J. (2007). "A Process Pattern Language for Agile Methods.". Software EngineeringConference, APSEC. , 374 - 381.


35/98


Evaluación Heurística de Herramientas de Composición de

Componentes Centrada en el Usuario Final

Yadira Jarvio Hernández1

, Perla Velasco-Elizondo2

y

Edgard Benítez-Guerrero1

1 Universidad Veracruzana, Facultad de Estadística e Informática, Xalapa, VER, 91020, México.

2 Universidad Autónoma de Zacatecas, Unidad Académica de Ingeniería, Ciudad Universitaria Siglo XXI,Zacatecas, ZAC, 98000, México.

[email protected], [email protected], [email protected]

Resumen. Cada vez más personas realizan diversas tareas apoyándose de sistemas de software queson construidos a partir de la composición de componentes. A pesar de la popularidad del desarrollocentrado en composición y las herramientas existentes para soportarlo hay evidencia sobre que el usode éstas sigue siendo complicado. Sin embargo, existe poca evidencia que permita comprender esta problemática en un contexto de usuarios finales. En este trabajo se realiza una evaluación heurísticade herramientas de composición de componentes centrada en el usuario final. Una contribuciónimportante de esta evaluación es que considerando un conjunto de aspectos intrínsecos al desarrollocentrado en composición y a los usuarios finales, se identifican un conjunto de heurísticas relevantes para detectar problemas generales de usabilidad. Las heurísticas y los problemas identificados proveen una base de conocimiento que puede ser extendida en dominios específicos de aplicación para mejorar el diseño de herramientas de composición.

Keywords: evaluación heurística, composición de componentes, usuarios finales.

1 Introducción

Muchas personas realizan diversas tareas apoyándose de sistemas de software que son construidos a partirde la composición de componentes. En términos generales, un componente es un elemento de software

pre-existente que implementa alguna funcionalidad, la cual puede ser accedida a través de interfaces biendefinidas (Sommerville, 2006). Los COTS (Commercial Off-The-Shelf) (Morisio, Seaman, Basili, Parra,Kraft, & Condon, 2002), los Servicios Web (Cauldwell, Chawla, & Chopra, 2002), los Mashlets(Abiteboul, Greenshpan, & Milo, 2008) o las (Web) APIs son ejemplos de componentes en estossistemas.

Enfoques de desarrollo como el Desarrollo Basado en Componentes (Sommerville, 2006), las Líneasde Productos de Software (Clements & Northrop, 2001), la Arquitectura Orientada a Servicios (Erl, 2005)o más recientemente las arquitecturas de micro servicios (Fowler, 2014) han adquirido popularidad puestoque soportan el desarrollo de sistemas de software usando un enfoque centrado en la composición.Actualmente existen diversas herramientas y (repositorios de) componentes en dominios específicos quefacilitan el desarrollo de sistemas bajo este enfoque.

La disponibilidad de herramientas y (repositorios de) componentes ha contribuido a que nuevascomunidades de usuarios incursionen en el desarrollo de este tipo de sistemas. Un ejemplo es la

comunidad de usuarios finales (Mehandjiev, Namoune, Wajid, Macaulay, & Sutcliffe, 2010), (Garlan,Dwivedi, Ruchkin, & Schmerl, 2012), (Roy Chowdhury, 2012). En términos generales este tipo deusuarios y los sistemas que construyen presentan las siguientes características:a. Son inexpertos en materia de desarrollo de sistemas y, generalmente, expertos en algún dominio

profesional. b. Soportan sus tareas diarias mediante sistemas de software que ellos mismos construyen a partir de la

composición de componentes de software que son provistos por terceras partes.c. Los sistemas que construyen tienen una arquitectura ―data -flow‖ (Taylor, Medvidovic, & Dashofy,

2009).Ejemplos de estos usuarios incluyen a sociólogos realizando análisis de influencia en redes sociales

(Knoke & Yang, 2008) con scripts que usan las APIs de Twitter (Twitter, 2015) e igraph para R (Team,2015) o biólogos realizando análisis de cadenas de proteínas con workflows creados con la herramientade composición Taverna (School of Computer Science, 2010) y servicios Web en BioCatlogue (Bhagat,

et al., 2010).A pesar de la popularidad del desarrollo centrado en composición y las herramientas existentes para

soportarlo hay evidencia sobre que el uso de éstas sigue siendo complicado Sin embargo existe muy


36/98


33

detectar problemas generales de usabilidad relevantes al contexto de un usuario final. En contraste contrabajos relacionados, una contribución importa

Tendencias de la Ingeniería de Software - Impacto en las TIC

Documents

Transcript of Tendencias de la Ingeniería de Software - Impacto en las TIC