Embed Size (px)
Citation preview
MODELO CONCEPTUAL PARA EL ASEGURAMIENTO DE LA CALIDAD DE
LOS REQUERIMIENTOS EN PROYECTOS DE SOFTWARE
LUIS DAVID LEDESMA MARIÑO
UNIVERSIDAD CATÓLICA DE PEREIRA
FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA
INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
Pereira
2018
MODELO CONCEPTUAL PARA EL ASEGURAMIENTO DE LA CALIDAD DE
LOS REQUERIMIENTOS EN PROYECTOS DE SOFTWARE
LUIS DAVID LEDESMA MARIÑO
Informe Final
Investigadores:
LUIS EDUARDO PELÁEZ VALENCIA
ALONSO TORO LAZO
UNIVERSIDAD CATÓLICA DE PEREIRA
FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA
INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
Pereira
2018
TABLA DE CONTENIDO
RESUMEN ..................................................................................................................................... 6
ABSTRACT .................................................................................................................................... 6
INTRODUCCIÓN .......................................................................................................................... 8
1. SITUACIÓN PROBLEMÁTICA ............................................................................................ 9
2. OBJETIVOS .......................................................................................................................... 10
2.1. Objetivo general ........................................................................................................... 10
2.2. Objetivos específicos .................................................................................................... 10
3. APORTE TEÓRICO Y PRÁCTICO ..................................................................................... 11
4. METODOLOGÍA .................................................................................................................. 12
5. DESARROLLO DEL PROYECTO ...................................................................................... 14
5.1. Exploración del estado del arte (Fase 1)..................................................................... 14
5.2. Herramientas para la Gestión de Requerimientos (Fase 2) ..................................... 19
5.3. Análisis comparativo de las herramientas (Fase 3) ................................................... 27
5.4. Entradas para el modelo conceptual .......................................................................... 30
6. ELICITACIÓN Y ESPECIFICACIÓN DE REQUISITOS (Fase 4) ............................. 32
6.1. Elicitación de requisitos ............................................................................................... 32
6.2. Análisis de requisitos .................................................................................................... 35
6.3. Especificación de requisitos ......................................................................................... 38
6.4. Aplicación del procedimiento ...................................................................................... 43
7. ANÁLISIS Y DISCUSIÓN DE RESULTADOS ................................................................. 48
8. CONCLUSIONES ................................................................................................................. 49
9. REFERENCIAS BIBLIOGRÁFICAS .................................................................................. 50
LISTA DE ILUSTRACIONES
Ilustración 1: Estructura de la ingeniería de requisitos [10] ......................................................... 16
Ilustración 2: Proceso iterativo de desarrollo de requisitos [10]................................................... 16
Ilustración 3. Datos de entrada solicitados para un requerimiento ............................................... 25
Ilustración 4. Datos solicitados por la herramienta ....................................................................... 25
Ilustración 5. Datos solicitados por Jama Software ...................................................................... 26
Ilustración 6. Datos solicitados por Visual Paradigm ................................................................... 27
Ilustración 7. Datos solicitados por REM ..................................................................................... 27
Ilustración 8: Herramientas para la gestión de requerimientos [33] ............................................. 29
Ilustración 9: Herramientas para la gestión de requerimientos [33] ............................................. 29
Ilustración 10: Herramientas para la gestión de requerimientos. [33] .......................................... 30
Ilustración 11: Elementos de entrada de un requerimiento ........................................................... 31
Ilustración 12. Proceso iterativo de desarrollo de requisitos [34, p. 45] ....................................... 32
Ilustración 13:REQNF000 ............................................................................................................ 36
Ilustración 14:REQF000 ............................................................................................................... 37
Ilustración 15. Información general sobre PEVReS [36] ............................................................. 38
Ilustración 16: Procedimiento para especificar requisitos de software en mipymes desarrolladoras
de software de la ciudad de Pereira............................................................................................... 39
Ilustración 17: Especificación de requisitos ................................................................................. 40
Ilustración 18: Especificación de Requisitos ................................................................................ 41
Ilustración 19: Especificación requisitos del sistema ................................................................... 42
Ilustración 20. Técnicas seleccionadas del procedimiento PEVReS para la especificación de
requisitos ....................................................................................................................................... 43
Ilustración 21: Diagrama de actividades ....................................................................................... 44
Ilustración 22: Prototipo REQF000-REQF007 ............................................................................. 45
Ilustración 23: Plantilla para especificar requisitos en lenguaje natural estructurado [36] .......... 46
LISTA DE TABLAS
Tabla 1. Herramientas CASE para gestión de requisitos .............................................................. 19
Tabla 2 Tabla comparativa entre herramientas para la gestión de requerimientos ....................... 28
Tabla 3: Requisitos identificados .................................................................................................. 33
Tabla 4: Origen requisitos ............................................................................................................. 34
6
RESUMEN
Dado que en un proyecto se identifica un conjunto de requisitos lo que también llevaría a
evidenciar inconvenientes al momento de gestionarlos si no se hace uso de algún software
especializado que agilice y facilite el trabajo con los mismos. El no hacerlo, con frecuencia genera
consecuencias negativas en el proyecto tales como retrasos en las entregas por una inadecuada
priorización de los requisitos, aumento de los costos asociados a reprocesos en la ejecución de los
mismos y difícil trazabilidad debido a que el proceso se lleva a cabo de forma manual, haciendo
del trabajo con los requisitos algo complejo y difícil de controlar.
Lo anterior, permite comprender la importancia de las herramientas para la gestión de
requisitos en el desarrollo de proyectos software y su aporte en el aseguramiento de la calidad. Sin
embargo, considerando que cada herramienta tiene diversas capacidades y grados de madurez para
ser implementadas en proyectos de software de diferentes tamaños y complejidades, se hace
importante estudiar sus características para identificar aquellas herramientas que proporcionen un
mayor control en el mantenimiento de los requisitos y permitan reducir los posibles errores que se
presenten durante el desarrollo, lo que a su vez redunde en una reducción significativa de los costos
del proyecto.
El objetivo de este documento es dar a conocer una revisión sistemática de herramientas
empleadas para la gestión de requisitos que permita establecer las principales características de un
modelo automatizado para el RQA. Finalmente, se presentan los resultados y principales
conclusiones obtenidas.
De igual manera, proponer diagramas de una plataforma para las pymes de la ciudad de
Pereira en la que puedan realizar el proceso de elicitación de requisitos de la mejor manera y de
calidad. Examinando una serie de herramientas que ya existen para la gestión de requisitos, con el
fin, de a futuro, desarrollar una herramienta con mejores características para la región.
Palabras claves: RQA, software, trazabilidad, herramienta CASE.
ABSTRACT
Since a project identifies a set of requirements that can also cause an inconvenience when
managing it, if you can not use software that can speed up and facilitate work with them. Failure
to do so often generates negative consequences in the project, such as delays in deliveries due to
inadequate prioritization of requirements, increase in costs associated with reprocessing in the
execution of the same, and difficult traceability due to the fact that the process is carried out Cape
out manually, doing work with the requirements of something complex and difficult to control.
The above, allows to understand the importance of the tools for the management of
requirements in the development of software projects and their contribution in the assurance of
quality. However, considering that each tool has several capacities and degrees of maturity to be
implemented in software projects of different sizes and complexities, it is necessary to make a
selection of its tools to identify itself. reduce the possible errors that arise during the development,
which in turn was reduced in a significant reduction of the project costs.
7
The objective of this document is to present a systematic review of tools used for the
management of requirements that allow establishing the main characteristics of an automated
model for the RQA. Finally, the results and main conclusions are presented
Similarly, proposing diagrams of a platform for SMEs in the city of Pereira where the
process of elicitation of requirements in the best way and quality can be performed. Examining a
series of tools that already exist for the management of requirements, with the aim, of a future, to
develop a tool with better characteristics for the region.
Key words: RQA, software, traceability, CASE tool.
8
INTRODUCCIÓN
Como proceso fundamental aplicado a los proyectos de desarrollo de software, la ingeniería
de software cumple un papel fundamental en el ciclo del desarrollo de los proyectos, implica
asegurar la calidad del producto mismo adoptando métodos y metodologías, que si bien son
aplicadas lograr concluir la consecución de la calidad de los proyectos de software.
En su aplicación y desarrollo, la ingeniería de software propone dimensionar desde el
aspecto de la calidad, logar satisfacer a completitud las necesidades previas que se identifican en
relación al usuario solicitante, de esta manera y relacionando la investigación, se consideran
hipótesis que han permitido concluir el déficit de las pymes de la región por conseguir y asegurar
la calidad de sus productos software, identificando en primera instancia que se está evadiendo la
etapa de elicitación de requerimientos, lo que ha permitido generar una brecha que indica no se
está realizando la gestión necesaria sobre la etapa de requerimientos, generando en primera
medida que la cobertura del requerimiento no ha sido suficiente, razón por la cual ha llevado a que
gran porcentaje de los proyectos de software fracasen por esta situación-
Con lo anterior, se plantea levantar los requerimientos de una plataforma para el
aseguramiento de la calidad del software y su efecto con el aseguramiento de la calidad de los
requerimientos respectivamente, funcionando por fases (diseño, desarrollo y mantenimiento) para
así facilitar y guiar al sector del software, lo que les permitirá en gran medida garantizar la calidad
de sus productos.
Con este proyecto se pretende realizar una previa identificación de los elementos de entrada
necesarios para un sistema de información, investigar sobre errores comunes que cometen las
pymes, esto a nivel regional, nacional e internacional para así tener unas fuertes bases y guiar a las
pymes de la región de la mejor manera posible. También se identificarán plataformas que faciliten
la gestión y desarrollo de los requisitos.
Se plantearán unos posibles requerimientos del modelo conceptual haciendo uso de
instrumentos de sistematización que faciliten la elicitación de los requerimientos.
9
1. SITUACIÓN PROBLEMÁTICA
Actualmente en la región las empresas desarrolladoras de software no vienen haciendo su
trabajo de la mejor manera, pues, se enfocan en terminar el proyecto de una manera rápida,
evadiendo metodologías y métodos necesarios y requeridos para que un software sea de calidad.
Las pymes no están haciendo uso de las mejores prácticas a la hora de desarrollar software, en este
caso, evadiendo la elicitación y gestión de los requisitos, por lo tanto, se obtiene software de baja
o mala calidad, llevando esto a tener malos resultados y por ende no satisfacer las necesidades del
cliente.
Tomando la definición de la IEEE un requerimiento es: “Una condición o capacidad que el
usuario necesita para resolver un problema o alcanzar un objetivo” [1]. Teniendo un poco más
claro la definición de requerimiento, se puede especular que en la región del eje cafetero en
especial la industria del software tiene un índice alto de desarrollo de software fracasados debido
al mal comienzo en la etapa inicial del desarrollo (elicitación de requerimientos); en algunos casos
sucede por desconocimiento, no tener claro lo importante que es la ingeniería de software, también
por no tener un dominio sobre el tema.
Es evidente que la ingeniería de software esta menos presente que el desarrollo a la hora de
realizar un proyecto, teniendo claro que es mucho más importante la ingeniería de software.
Por estas razones se cree que en la región del eje cafetero no se está realizando software de
calidad, desperdiciando el gran talento y potencial humano que hay en esta región, llegando así a
no ser competencia con las grandes industrias.
10
2. OBJETIVOS
2.1.Objetivo general
Elaborar los diagramas que soporten un modelo conceptual de un sistema de aseguramiento
de calidad de requerimientos.
2.2.Objetivos específicos
Realizar una revisión de antecedentes relacionados con sistemas de gestión de
requerimientos.
Identificar los elementos de entrada que se requiere en un modelo conceptual.
Elaborar los instrumentos de sistematización de información de entrada.
Definir los requerimientos de un modelo conceptual mediante instrumentos de
sistematización de información de entrada.
Elaborar los diagramas que respondan a dichos requerimientos.
11
3. APORTE TEÓRICO Y PRÁCTICO
El proyecto contribuirá al mejoramiento del proceso de desarrollo de requerimientos en las
empresas desarrolladoras de software de la región del eje cafetero, permitiéndoles obtener en sus
productos software de calidad, además una herramienta que facilitará todo el proceso de
modelación, análisis y diseño.
El proyecto será de gran ayuda, tendrá muchos beneficios para las empresas que desarrollan
software de baja calidad, con éste la industria de la región cafetera desarrolladora de software
tendrá una iniciativa de poder competir en calidad.
El modelo conceptual será imprescindible a la hora de realizar la ingeniería del software de la
plataforma automatizada ya que éste nos guiará de manera muy ilustrativa y ayudará a identificar
cual es el verdadero problema a tratar con sus posibles soluciones, dicho modelo podrá ser
interpretado por cualquier persona interesada en el proyecto de manera oportuna.
12
4. METODOLOGÍA
La metodología utilizada está compuesta por cinco fases, a través de las cuales se guía el
desarrollo del modelo conceptual para el desarrollo de un sistema de información que posibilite el
aseguramiento de la calidad de los requisitos de software. Las mismas, se describen a continuación:
Fase 1: Exploración del estado del arte
Para el presente proyecto, esta fase consiste en realizar un levantamiento de información
en diferentes fuentes físicas y electrónicas, relacionado principalmente con las teorías sobre
ingeniería del software e ingeniería de requisitos en las que se enmarca el proyecto, así como sobre
las herramientas de gestión de requisitos que acompañan el desarrollo de un proyecto de software,
identificadas desde los ámbitos regional, nacional e internacional. Lo anterior, con la intensión de
contextualizar la situación problemática y justificación del proyecto de investigación al cual
pertenece este trabajo.
Fase 2: Caracterización de las herramientas
En este apartado se clasifican y describen las herramientas más usadas a nivel mundial por
las compañías desarrolladoras de software a la hora de desarrollar y gestionar los requerimientos,
considerando que existen herramientas de pago y libres. Así mismo, se determinan sus principales
características, funcionalidades y limitaciones, de tal manera que se puedan identificar las
principales entradas de información que requieren para su funcionamiento. Esto, ya que el proyecto
pretende, a manera de trabajo futuro, aportar en la formulación de un modelo automatizado para
el aseguramiento de la calidad de los requerimientos.
Posteriormente, se realizan algunas pruebas sobre varias de las herramientas identificadas
para estudiar su funcionamiento, necesidades de información y restricciones, con el ánimo de
determinar, entre otras cosas, los elementos de entrada de un requerimiento solicitados por las
mismas.
Fase 3: Análisis comparativo de las herramientas
Se realiza una comparación de las características de las herramientas utilizadas en la fase
anterior para identificar las ventajas y desventajas de cada una de ellas. Dado que la mayoría de
las herramientas permiten ejecutar otras funciones relacionadas con la ingeniería de software, se
hace énfasis en la gestión de requerimientos, por ser el objetivo principal de la presente
investigación. Esta fase pretende, además, entregar a la sociedad elementos diferenciadores de las
múltiples herramientas, de tal manera que las personas y empresas que requieran hacer uso de este
tipo de herramientas CASE, puedan tomar decisiones con facilidad a la hora de elegir una de ellas.
Fase 4: Elicitación de requerimientos
Se realiza la elicitación de requerimientos teniendo un origen como base del mismo, ya sea
por análisis del grupo de investigación, estado del arte, trabajos previos o el instrumento mediante
se consultó a las empresas desarrolladoras de software de la ciudad de Pereira.
Fase 5: Conclusiones y trabajo futuro
13
En esta fase del proyecto, se plantean las conclusiones iniciales de acuerdo a los hallazgos y
resultados del trabajo realizado con las herramientas, de tal manera que las mismas puedan
contribuir a las etapas subsecuentes del proyecto de investigación, relacionadas con el diseño
conceptual de un modelo para el aseguramiento de la calidad de los requerimientos y el desarrollo
de un sistema automatizado para la gestión de los mismos.
14
5. DESARROLLO DEL PROYECTO
5.1. Exploración del estado del arte (Fase 1)
Este apartado pretende dar cuenta de una exploración conceptual sobre los requisitos de
software como base de la investigación, así como de las herramientas usadas actualmente para
gestionarlos. Por tanto, se presentan a continuación algunos referentes teóricos que permiten
introducir al lector en el contexto de desarrollo del proyecto.
Frecuentemente, la Ingeniería de Requisitos es tratada como una disciplina [2] y tiene como
propósito “desarrollar una especificación de requisitos completa, consistente y no ambigua, la
cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se
describen las funciones que realizará el sistema". Por consiguiente, cualquier proyecto de
desarrollo de software debe buscar satisfacer las características antes mencionadas, alineándose
con el propósito de la Ingeniería de Requisitos, según lo expuesto por el autor.
Para [3] “el proceso de descubrir, analizar, documentar y verificar estos servicios y
restricciones se denomina ingeniería de requisitos (RE)”. También menciona que “la Ingeniería
de Requisitos es el proceso de desarrollar una especificación de software. Las especificaciones
pretenden comunicar las necesidades del sistema del cliente a los desarrolladores del sistema”.
[3]. Es evidente entonces la relevancia que tiene el desarrollo y gestión de los requisitos dentro de
la Ingeniería de requisitos, pues permite que el desarrollador entienda y de solución a las
necesidades expresadas por el cliente.
Por su parte, [4], indica que la Ingeniería de Requisitos:
“Ayuda a los ingenieros de software a entender mejor el problema en cuya solución
trabajarán. Incluye el conjunto de tareas que conducen a comprender cuál será el impacto
del software sobre el negocio, qué es lo que el cliente quiere y cómo interactuarán los
usuarios finales con el software.”
En la misma línea [5] citados en [6] definen que:
“La ingeniería de requisitos proporciona el mecanismo apropiado para entender lo que
desea el cliente, analizar las necesidades, evaluar la factibilidad, negociar una solución
razonable, especificar la solución sin ambigüedades, validar la especificación y administrar
los requisitos a medida que se transforman en un sistema funcional.”.
Esta preocupación que expresan los autores por entender lo que el cliente realmente necesita y
determinar en qué medida el software desarrollado puede contribuir al cumplimiento de los
objetivos del negocio, deberían ser aspectos a tener en cuenta en el desarrollo de todo proyecto
software y, por ende, en el documento de definición de requisitos.
De igual forma, [7] indican que la Ingeniería de requisitos es un enfoque sistémico para
recolectar, organizar y documentar los requisitos del sistema; es también el proceso que establece
y mantiene acuerdos sobre los cambios de requisitos, entre los clientes y el equipo del proyecto.
15
De la misma manera, [5] mencionan que “la Ingeniería de Requisitos es la ciencia y disciplina a
la cual le concierne el establecer y documentar los requisitos”.
También [2], menciona una disciplina denominada ingeniería de requisitos para desarrollar una
especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos
comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el
sistema. Así mismo, autores como [1] consideran que todo lo concerniente a requisitos hace parte
de un dominio entero definido Ingeniería de Requisitos, que a la vez es dividida tanto en Desarrollo
como en Gestión de Requisitos. Como disciplina, establece el proceso de definición de requisitos
en una sucesión de actividades mediante las cuales lo que debe hacerse se elicita, se modela y se
analiza, citado en [8]
Por otro lado, la guía al cuerpo de conocimientos para la ingeniería del software SWEBOK®
(Software Engineering Body of Knowledge) propuesto por la IEEE1, en su versión 2014 trata el
tema como la primera de sus áreas del conocimiento (KA por sus siglas en inglés Knowledge
Areas), en la que se refiere a la captura, el análisis, la especificación y la validación de los requisitos
del software y contempla una serie de aspectos y conceptos que llevan al software a ser objeto de
aplicación de la ingeniería. Como producto de salida al proceso correspondiente de aplicar los
conocimientos del área se logra un documento que permita sistematizar, revisar, evaluar y aprobar
todo lo relacionado con los requisitos del software [9].
De igual forma, el SEI2 a través del Modelo de Madurez de Capacidad Integrado CMMI®
(Capability Maturity Model Integration) el cual contiene un conjunto de buenas prácticas de la
industria para el desarrollo, mantenimiento, adquisición y operación de productos y servicios;
contempla el trabajo con los requisitos donde se incluye tanto el desarrollo como la gestión de los
mismos. Para ello se cuenta con las áreas de proceso "Gestión de Requisitos” o Requirements
Management (REQM) por sus siglas en inglés y “Desarrollo de Requisitos” o Requirements
Development (RD) ubicadas en los niveles 2 y 3 en la representación por etapas, estando ubicadas
en la categoría de Proceso de Ingeniería para la representación continua y escalonada. Tienen como
propósito producir, analizar y administrar los requisitos del cliente, del usuario, del producto y de
los componentes del producto. Las prácticas definidas en esta área de proceso permiten determinar
todos los requisitos del proyecto, ya sea para el desarrollo o mantenimiento. Parte de los requisitos
del cliente que son derivados en requisitos del producto hasta refinarlos al nivel de requisitos de
los componentes del producto, todo esto durante el ciclo de vida del producto.
Si bien se puede considerar que la especificación de requisitos puede hacer parte de la
documentación de un proyecto de software, es importante resaltar, como lo indican los autores,
que dicho documento no solo permitirá plasmar las necesidades del cliente respecto al sistema a
desarrollar, sino que también posibilitará llevar a cabo una adecuada gestión de los mismos.
Algunos autores como [10], [11] proponen que la Ingeniería de Requisitos puede estructurarse
como se ilustra a continuación:
1 Institute of Electrical and Electronics Engineers (IEEE) 2 Software Engineering Institute (SEI) | Carnegie Mellon University
16
Ilustración 1: Estructura de la ingeniería de requisitos [10]
Teniendo en cuenta que el desarrollo de requisitos como se muestra en la Ilustración 2
comprende diferentes fases, el autor propone abordar todo el desarrollo de requisitos como un
proceso iterativo con el objetivo de adquirir una mayor comprensión y expresión de los requisitos.
En la siguiente ilustración se da cuenta de ello:
Ilustración 2: Proceso iterativo de desarrollo de requisitos [10]
Cada una de estas fases de la ingeniería de requisitos, si se toma como referencia lo
propuesto por el [11] con respecto al desarrollo de requisitos, se explican con mayor detalle a
continuación:
“Elicitación”: La elicitación o captura de requisitos hace referencia a los orígenes de los requisitos
y como el ingeniero de software puede recogerlos. Es la primera etapa en la construcción de una
comprensión del problema que el software requerido va a resolver. Es fundamentalmente una
actividad humana y es donde los interesados se identifican y se establecen las relaciones entre el
equipo de desarrollo y el cliente. Se denomina diversamente "Captura de Requisitos",
"Descubrimiento Requisitos" y "Adquisición de Requisitos" (Idem, pág. 36).
Por su parte [10] afirman que la elicitación de requisitos es “el proceso de identificación de las
necesidades y limitaciones de los interesados para un sistema de software. “Elicitación” no es lo
mismo que ‘el levamiento de requisitos.’ Tampoco es una simple cuestión de transcribir
exactamente lo que dicen los usuarios. La “elicitación” es un proceso colaborativo y analítico que
incluye actividades para recolectar, descubrir, extraer y definir los requisitos”.
Análisis: Según [11], el análisis se refiere al proceso de analizar requisitos para:
Detectar y resolver los conflictos entre los requisitos.
Descubrir los límites del software y cómo debe obrar recíprocamente con su ambiente.
Elaborar los requisitos del sistema para derivar requisitos software
Comprende las siguientes actividades:
Ingeniería de
Requisitos
Desarrollo
Recolección
AnálisisEspecifica
ciónValidación
Administración
17
Clasificación de los requisitos
Modelamiento conceptual.
Diseño de arquitectura y asignación de requisitos.
Negociación de Requisitos.
Análisis formal.
Desde el punto de vista de [4] en el análisis los requisitos se agrupan por categorías y se
organizan en subconjuntos, se estudia cada requisito en relación con el resto, se examinan los
requisitos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades
de los clientes/usuarios.
La información obtenida se debe analizar de manera muy detallada, con el fin de clasificar todos
los requerimientos recolectados. Los requerimientos del negocio, aportarán información
importante y darán paso a los requerimientos del sistema y posteriormente a los de software [10].
En esta fase se toman los requerimientos de alto nivel y se descomponen con un apropiado nivel
de detalle. Esto permite completar los requerimientos del sistema, se detallan y clasifican los
requerimientos de software, ya con estos, siguen los funcionales, no funcionales y los demás
requerimientos sin clasificar. [1] [10]
Una vez clasificados los requerimientos se les asigna una prioridad teniendo en cuenta los
factores ambientales que puedan afectar al proyecto [1]. Luego, se llega al modelado. La idea es
plasmar el problema en diagramas para así comprender mejor la situación actual, se pueden usar
diagramas de casos de uso, modelos de estado, modelos basados en objetivos, modelo de objetos
y modelo de datos, entre otros. [1]
Especificación: según la [1],
“Para la mayoría de las carreras de ingeniería, el término ‘especificación’ se refiere a la
asignación numérica de valores o límites a los objetivos de diseño de un producto. La
“Especificación de requisitos de Software se refiere típicamente a la producción de un documento,
o a su equivalente electrónico, que puede estar sistemáticamente repasado, evaluado, y aprobado”.
Es notorio que la especificación, según el proceso iterativo propuesto por [10] comienza cuando
se ha realizado un trabajo en las etapas de “elicitación” y análisis. Es por ello que la especificación
consolida los resultados de las etapas anteriores donde se hace fundamental que dicha
consolidación sea lo suficientemente clara para convertir las necesidades del cliente en una
solución software que las satisfaga.
La especificación permite que estén establecidos los requerimientos que realmente tienen valor
tanto para el cliente como para el negocio. Esto, implica representar y almacenar los
requerimientos recolectados de una manera organizada. Básicamente es traducir las necesidades
de los usuarios a un lenguaje más técnico para una mejor comprensión y revisión. [10]. Así, estos
requerimientos podrán ser evaluados y aprobados por parte de los desarrolladores y del cliente.
Existen según [1] tres tipos de documentos:
Documento de definición del sistema.
18
Especificación de requerimientos del sistema.
Especificación de requerimientos de software (SRS)
Cuando los productos software son “simples”, sólo es necesario el documento SRS. [12]
Validación: [1] considera la validación como posterior ejercicio a la especificación de requisitos
donde el documento de requisitos de software resultante de una especificación debería ser sujeto
de procedimientos de validación y verificación. Los requisitos deberían ser validados para
asegurar de que el ingeniero software ha entendido los requisitos, es también importante verificar
que un documento de requisitos se ajusta a las normas de la empresa y que es comprensible,
coherente y completo. En casos donde la documentación de los estándares de la compañía o
terminología no es compatible con los estándares ampliamente aceptados se debería realizar un
mapeo o una correspondencia que será acordada y anexada al documento de requisitos.
Desde la mirada de [10], los requisitos pueden ser sometidos a procesos tanto de verificación
como de validación. El término “verificación” determina si se han escrito los requisitos bien, es
decir, que cada requisito cumple con las características de un buen requisito. La “validación”
evalúa si se han escrito los requisitos adecuados: están alineados a los objetivos de negocio. Estos
dos conceptos están estrechamente entrelazados.
La validación de requisitos permite a los equipos construir una solución correcta que cumpla
con los objetivos de negocio establecidos.
Gestión de requisitos: La gestión de requerimientos abarca todo lo relacionado con la planeación
del progreso y gestión de cambios durante el ciclo de vida del requerimiento, su principio es que
un requerimiento de un proyecto software puede variar en cualquier momento. Según [12], existen
muchos tipos de proyectos, la gestión es algo común en todos, sin embargo, dependiendo del
proyecto se podría generar mejores resultados si se efectúa de una u otra forma.
La planeación varía su gestión de acuerdo a los resultados obtenidos en etapas anteriores. Estos
resultados, deberían ser aprobados antes de realizar cualquier actividad acorde por el experto del
negocio, con el fin de establecer si las soluciones realmente satisfacen las necesidades de los
usuarios. En desarrollos de software, esta aprobación es cuando aceptan el documento SRS. [13]
La gestión de cambios usa como principal herramienta el versionamiento de los diferentes
documentos y artefactos generados durante cada actividad [12]. Un error en el manejo de
versiones, podría afectar el tiempo, costo, cronograma, errores de diseño, o en el peor de los casos
la cancelación del proyecto [13]
De acuerdo a todo lo anterior, las herramientas para la gestión de requerimientos son
fundamentales para el éxito del proyecto, pues además de facilitar el desarrollo de los requisitos,
de organizar y gestionar las versiones del proyecto. Por tanto, se considera importante estudiar las
herramientas que de este tipo se encuentran comúnmente en el mercado, un breve resumen de las
mismas se presenta en el apartado siguiente.
19
5.2.Herramientas para la Gestión de Requerimientos (Fase 2)
Una de las etapas más importantes en el desarrollo de un producto software es el desarrollo de
los requerimientos, dado que allí se conoce a profundidad el problema a resolver y por defecto se
precisa el parámetro bajo el cual se cumplirán o no las expectativas del cliente. Una buena práctica
para garantizar que esta etapa tan fundamental se realice de manera adecuada es usar herramientas
que faciliten la gestión de los requerimientos y las tareas propias del desarrollo de software. Estas
son denominadas herramientas CASE (Ingeniería de software asistida por computador), y sirven
de apoyo para los desarrolladores desde el principio hasta el final del proceso [14]. Existen diversas
herramientas, tanto de pago3 como gratuitas (software libre4), que persiguen este objetivo.
Pese a lo anterior, se vislumbra como hipótesis que ninguna de estas herramientas satisface al
cien por ciento las necesidades de las MiPymes desarrolladoras de software del eje cafetero, pues
cada una presenta características, funcionalidades y limitaciones diferentes que no permiten lograr
un cubrimiento completo de las necesidades del proyecto y de la empresa. Así por ejemplo, algunas
herramientas son de uso libre, pero ofrecen capacidad limitada; otras, son de pago, pero el costo
de la licencia es muy elevado para las características de las empresas desarrolladoras pues, según
[15] no todas las empresas de la industria del software están en la capacidad financiera y operativa
para implementar algunos procesos y/o modelos que les permitan asegurar la calidad tanto de sus
procesos como de sus productos, pues en su mayoría, son pequeñas y medianas empresas
(PYMES) que poseen ciertas características específicas. Algunas de ellas, como lo mencionan [16]
son las siguientes:
El equipo de trabajo es poco calificado, suelen ser grupos menores a diez personas y sus
proyectos no son de más de medio año.
Cuentan con escasos recursos.
El proceso de desarrollo y gestión del proyecto (planeación, organización, monitoreo) se
basa en técnicas informales.
No se encuentra una estructura organizacional clara y no se definen roles dentro de la
organización.
Algunos ejemplos de herramientas que permiten la gestión de requerimientos, tanto de pago
como de uso libre, analizadas en el presente proyecto, son las presentadas en la Tabla 1, aclarando
que no todas se presentan en este documento:
Tabla 1. Herramientas CASE para gestión de requisitos
DE PAGO GRATUITAS
Case complete REM
Enterprise Architect Rmtoo
Jama software Let’s req
Visual paradigm REMAS
Caliber RETO
Rational IBM DRES
3 “Se pagó por el programa y se puede instalar en una o varias computadoras, dependiendo de una licencia. El usuario tiene garantía de que
el programa funcionará y, normalmente, el derecho a tener asistencia técnica si no es así. Está prohibido copiar el programa y distribuirlo
(pidiendo o no dinero a cambio)” Fuente especificada no válida.. 4 “Es el software que respeta la libertad de los usuarios y la comunidad. A grandes rasgos, significa que los usuarios tienen la libertad de
ejecutar, copiar, distribuir, estudiar, modificar y mejorar el software”Fuente especificada no válida..
20
Visure Requirements Gatherspace
Case Spec TopTeam Analyst
Las herramientas de pago contienen mejores funcionalidades y son mucho más robustas, sin
embargo, como se mencionó anteriormente el alto costo de sus licencias hace que sea difícil su
adquisición por las MiPymes. Otro aspecto desfavorable identificado es que generalmente éstas
solo funcionan en plataformas Windows, limitando en gran medida su utilización.
A continuación, se nombran herramientas para la gestión de requisitos como resultado de la
investigación, pero, por motivos de licencia no se logró instalar satisfactoriamente el software:
Rational Requisite Pro from IBM
Gestione el desarrollo de requerimientos basados en documentos (ej: Especificación
de casos de uso) en paralelo con IBM Rational RequisitePro
“IBM Rational RequisitePro fue diseñado para dar soporte a un enfoque serializado
de la ingeniería de requerimientos. Debido a los ciclos de vida y a los enfoques de múltiples
equipos, existe una demanda de trabajo sobre requerimientos en paralelo.” [17]
InsCo Requisite
“InSCo Requisite es una herramienta basada en web para la gestión de requisitos en
proyectos de desarrollo de software híbrido.” [18]
Caliber
“Caliber® (anteriormente, Borland Caliber) es una solución de requisitos completa
que garantiza la conformidad normativa y la coherencia del desarrollo con sus necesidades
empresariales. Calibre facilita la colaboración de las partes interesadas, unas funciones de
visualización completas, una sólida gestión y el seguimiento de los requisitos en los planes
de entrega de Agile. Distribuya el software con una gran precisión, sin necesidad de repetir
el trabajo, con ciclos de lanzamiento más cortos y con la garantía del cumplimiento de las
normativas internas y externas, todo ello para conseguir mejorar la satisfacción de los
clientes.” [19]
IBM Rational Doors
Es un software propio de IBM que gestiona los requerimientos y requisitos, permite
capturar, rastreas, analizar, y gestionar cambios a la información. [20]
Este software está diseñado como una aplicación de base de datos cliente/servidor.
Enterprise Architec
Este software no solo ayuda a gestionar los requerimientos si no que permite hacer
diseño de software, arquitectura de empresas, gestión de requisitos, testing, etc.
Está basado en estándares abiertos como lo son UML, BPMN.
Puede gestionar los requisitos, modelos estratégicos y modelos de análisis.
21
Realiza debug al software lo que permite inspeccionar la ejecución del software. [21]
Quality center Enterprise (QC)
Permite observar todo el desarrollo del ciclo de vida del software al igual que la
actividad de los desarrolladores, desde la gestión de los requisitos hasta las pruebas y
resolución de los defectos.
En este software existen 2 tipos de pruebas manuales o automatizadas, se pueden combinar
y así dar una flexibilidad y capacidad de respuestas óptimas en las pruebas. [21]
Se presentaron varios inconvenientes con esta herramienta en su versión de prueba
(TRIAL).
1. Solo funciona con el navegador internet explorer 11.
2. La ventana siempre presenta que existe un error.
Visure Requirements
Es un software muy flexible a la hora de hablar ingeniería de requerimientos. Capaz
de racionalizar y gestionar los procesos de gestión de requerimientos por ende es posible
alcanzar una excelente calidad.
Al igual que otro software permite gestionar (requisitos, pruebas, solicitudes de
cambio, etc) y está diseñado para un fácil uso con excelentes resultados.
Inicialmente se debe realizar un registro en su página web, al terminar este registro ellos
enviarán un nuevo correo informando los pasos a seguir para realizar una instalación
correcta. Se debe contar con correo empresarial o institucional.
Por lo general tardan para enviar la licencia y correos necesarios para poder iniciar
con la versión trial. La versión trial genera un gran inconveniente es que no todas las
funciones están activadas, es muy mínimo lo que permite realizar. Solo permite observar 2
ejemplos existentes.
Case spec
Permite especificar, gestionar y realizar seguimiento a los requisitos, casos de uso,
casos de prueba y todo en un entorno de trabajo unificado. Además de la gestión de
requisitos permite trazar relaciones entre los requisitos.
Admite personalizar los metadatos con vistas para que se adapten al proceso. [22]
Con Case spec, aunque dan la opción de probar la herramienta a la hora de intentar
descargarla no permite sin antes comprar mínimo una licencia.
Case complete
“Es una herramienta para la gestión de los requisitos de manera muy ágil para
reducir el esfuerzo de capturar los casos de uso y generar su documentación de forma
automática.” [23]
22
Esta herramienta es muy completa, con gran usabilidad y contiene todo lo
relacionado a requerimientos y casos de uso, para gestionarlos y observar su trazabilidad.
Para esta herramienta, el requisito tiene una serie de entradas las cuales son
obligatorias para crearse, esta herramienta, tiene un menú principal, una pestaña
suplementaria, la trazabilidad del requisito que es muy importante y la prueba del mismo.
Raquest
Es una herramienta sobre la gestión de requerimientos para el modelado UML. Se
puede realizar un seguimiento a los requisitos con una serie de características.
Las características principales de este software son:
o Definir y gestionar elementos de requisitos.
o Crear paquetes para gestionar artículos de requisito.
o Generar documentos para una parte o todo el proyecto en los siguientes formatos
(HTML, CSV, Word, Excel, RTF) [19]
En su última actualización, Raquest de Sparx Systems se volvió una herramienta de
Enterprise architec.
No solo se encuentra software de pago, también existen herramientas gratuitas y de
código libre que se pueden reemplazar siempre y cuando satisfagan las necesidades, esto
ayudaría a la empresa a reducir costos ya que no se tendría que comprar licencias costosas.
Algunas de esas herramientas son:
DRES (Requirements Engineering Support)
“Es un software libre (WEB) de código abierto que permite la gestión de requisitos
de un proyecto” [24]
Let’s req
Es una aplicación WEB que permite gestionar proyectos y requisitos de sistemas de
software de manera gratuita.
Open Source Requirement Mangement Source
“Herramienta de gestión de requisitos de código libre, diseñado para lograr una
trazabilidad completa SDLC para las características, requisitos, diseño, implementación y
pruebas.” [25]
Rmtoo
“Software para la gestión de requerimientos, es de código libre y abierto. Es una
herramienta sin interfaz de usuario todo es a base de comandos.” [26]
Una herramienta poco amigable con el usuario, muy difícil de usar ya que todo se basa en
comandos.
23
REM (Requirements Management)
“Es una herramienta gratuita para la gestión de los requisitos de software, su última
actualización fue en el año 2004.” [27]
A pesar de ser una herramienta gratuita, tiene muchos factores positivos para la gestión de
los requisitos.
Esta herramienta no solo se centra en los requisitos si no con todo lo relacionado a la
ingeniería del software.
REMAS (RElease MAnagement System)
Es un sistema para la gestión de requerimientos del lado de la web. Es de código
abierto y libre. [28]
Esta herramienta es de una mala interfaz con el usuario, poco amigable y su
ejecución es algo compleja.
Reqtify
Es una aplicación interactiva de fácil uso para la gestión de requisitos, trazabilidad
y análisis de impacto entre diferentes sistemas, programas y niveles de proyectos en todo
el ciclo de vida de desarrollo del software y el hardware.
Reqtify ofrece una completa lista de interfaces con varias herramientas de
ingeniería de sistemas. Reqtify puede capturar datos desde cualquier fuente (archivos,
bases de datos) de cualquier proveedor en una amplia variedad de formatos de datos y
archivos. Es una plataforma abierta y ampliable que cuenta con interfaces de más de 60
herramientas habituales de ingeniería de sistemas. Reqtify también permite a las
organizaciones gestionar eficazmente sus procesos de ingeniería de requisitos y garantizar
el cumplimiento de normas como ISO61508, ISO26262, Spice, DO178C, DO254, FDA,
GAMP, CMMI y muchas más.
Principales ventajas y beneficios:
o Captura de requisitos a cualquier nivel
o Captura de requisitos intuitiva, rápida y sencilla desde documentos de Word o PDF
o Análisis de cobertura y trazabilidad
o Gestión de cambios de requisitos e información de ciclo de vida
o Análisis de impacto ascendente y descendente para la gestión del riesgo de
regresión. [29]
Jama Software:
“Jama es una moderna solución de gestión de requisitos para el desarrollo de
sistemas complejos.” [30]
Con Jama se pueden gestionar proyectos de toda magnitud, desde pequeños hasta de gran
escala. Permite realizar trazabilidad, asignar responsable, hasta añadir descripción acerca
del requisito.
24
Accept 360:
“Con Accept360 Requirements Management ™ puede cubrir los requerimientos de
fugitivos y crear un plan de producto coherente y priorizado con la colaboración de todas
las partes interesadas. Desplaza las necesidades de fuentes dispersas e inaccesibles y las
coloca en un único repositorio empresarial. Todos sus interesados - ingenieros,
desarrolladores, probadores, así como gerentes de productos y ejecutivos de productos -
ahora tienen acceso fácil y basado en roles a la información que necesitan para crear
productos ganadores.” [31]
No se puede extraer mucho de esta herramienta ya que en su página principal es muy
limitada y no brinda mucha información acerca de cómo poder probar o descargar la
herramienta. Para poder obtener la herramienta es necesario contactarlos por llamada
telefónica y están ubicados en Texas, USA
Gather Space:
Es una herramienta WEB poco intuitiva y de difícil manejo, tiene poca coherencia y poco
entendimiento a la hora de crear un proyecto y realizar seguimiento a los requerimientos.
Es muy poco amigable con el usuario y la documentación que tiene es extensa y compleja
de entender.
5.2.1. Pruebas a las herramientas
Las pruebas realizadas a las herramientas consistieron principalmente en implementar una
especificación de requisitos de software a través de las diferentes plataformas, identificando
principalmente los elementos de entrada requeridos por la misma, las restricciones, detalles del
proceso a seguir, atributos que permite definir, ventajas y desventajas, entre otros. A continuación,
se muestran a manera de ejemplo, algunas de las evidencias del proceso con algunas de las
herramientas.
Case Complete
“Es una herramienta para la gestión de los requisitos de manera muy ágil para reducir el
esfuerzo de capturar los casos de uso y generar su documentación de forma automática.” [23]
Desarrollada por SERLIO SOFTWARE, esta herramienta presenta diversas funcionalidades, es
intuitiva y está enfocada en el desarrollo de los requerimientos y casos de uso.
Inicialmente, la herramienta solicita ingresar algunos detalles del requerimiento a especificar,
tales como nombre, prioridad, descripción, tipo, responsable, estado, documentos relacionados y
notas, entre otros atributos.
25
Ilustración 3. Datos de entrada solicitados para un requerimiento
De igual forma, se presenta una trazabilidad del requerimiento que es muy importante para
gestionar el control de versiones, los requerimientos asociados a este y las consecuencias de su
modificación en cualquier momento.
Enterprise Architec
Desarrollado por Sparxsystems, este software no solo ayuda a gestionar los requerimientos si
no que permite hacer diseño de software, plantear la arquitectura, gestionar los requisitos, realizar
testing, entre otras. Está basado en estándares abiertos UML, BPMN y puede gestionar los
requisitos, modelos estratégicos y modelos de análisis.
Ilustración 4. Datos solicitados por la herramienta
Esta herramienta presenta una gran variedad de atributos a la hora de crear los requerimientos.
Entre ellos se pueden destacar el tipo, estado, alias, palabras clave, autor, dificultad del
requerimiento, prioridad, versión, fase. De igual forma, presenta una funcionalidad para una mejor
26
especificación del requerimiento relacionada con las reglas, restricciones y su relación con otros
requerimientos.
Jama Software
Jama es una moderna solución de gestión de requisitos para el desarrollo de sistemas complejos
[30]. Con Jama se pueden gestionar proyectos de toda magnitud, desde pequeños hasta de gran
escala. Permite realizar trazabilidad, asignar responsables, añadir descripciones de los requisitos,
entre otras.
Ilustración 5. Datos solicitados por Jama Software
Esta herramienta es muy concreta a la hora de documentar los atributos de los requerimientos.
Algunos de estos son el id, nombre, descripción, responsable, estado, prioridad y lanzamiento.
Además, Jama Software permite compartir información entre los interesados del proyecto para que
todos tomen decisiones y realicen un seguimiento “trazabilidad” a los requerimientos.
Visual Paradigm
Visual Paradigm tiene un conjunto de ayudas para el desarrollo de programas informáticos,
desde la planificación, pasando por el análisis y el diseño, hasta la generación del código fuente
de los programas y la documentación. Visual Paradigm ha sido concebida para soportar el ciclo de
vida completo del proceso de desarrollo del software a través de la representación de todo tipo de
diagramas. Una de sus principales ventajas es que funciona en tanto en plataforma Windows como
en Linux y tiene una amplia gama de versiones (Enterprise, Community Edition, Professional,
entre otras).
27
Ilustración 6. Datos solicitados por Visual Paradigm
Esta herramienta es una de las más completas y más enfocadas a la gestión de requerimientos,
permite generar documentación sobre estos, trazabilidad a los requerimientos, realizar gráficas y
diagramas de requerimientos, vincular a los miembros del equipo para agilizar, compartir y realizar
seguimiento a los requerimientos. De igual forma, la herramienta tiene unos atributos clave a la
hora de crear los requerimientos. Algunos de ellos son id, nombre, tipo, riesgo, descripción.
REM
Es una herramienta gratuita para la gestión de los requisitos de software presentada por [32]
como parte de una tesis doctoral. Su última actualización fue en el año 2004 y a pesar de ser una
herramienta gratuita, tiene muchos factores positivos para la gestión de los requisitos.
Ilustración 7. Datos solicitados por REM
La herramienta tiene como factor desfavorable, que su última actualización fue en el año 2004,
quedando con algunos errores que afectan su funcionamiento. Sin embargo, cuenta con una
característica que permite generar documentación sobre requerimientos en HTML.
De igual forma, REM es una herramienta muy limitada por los pocos tipos de requerimientos
que pueden ser creados, alguno de sus atributos puede ser id, nombre, versión, fecha de creación,
responsable y autor. Así pues, pese a ser gratuita cuenta con funciones importantes que permiten
profundizar a la hora de crear los requerimientos como son la descripción, prioridad, trazabilidad,
historia y comentarios.
5.3.Análisis comparativo de las herramientas (Fase 3)
28
Una vez estudiadas las herramientas para la gestión de requerimientos identificadas, se realiza
una tabla comparativa en la que se pretende determinar las principales diferencias entre cada una
de las herramientas, considerando además los aspectos que mayor relevancia tiene cada una, sus
principales ventajas y falencias. Algunas de ellas, se presentan a continuación:
Tabla 2 Tabla comparativa entre herramientas para la gestión de requerimientos
De igual forma, [33] presentan un análisis de otras herramientas que también son objeto de
estudio de esta investigación. Las mismas se muestran a continuación:
Herramienta De pago /
Libre Plataforma Ventajas Desventajas
Enterprise Architec De Pago Windows
Modelado completo para el ciclo de vida. Repositorio escalable para el trabajo en equipo.
Veloz, estable y efectivo. Genera documentación. Generación e ingeniería a la
inversa del código fuente.
Solo funciona en plataforma Windows.
Visure Paradigm De Pago
Windows,
Linux, MAC OS
Genera modelos VP-UML instantáneamente a partir
de código binario .Net. Generación de documentación en formatos HTML y
PDF.
Generación de documentación: brinda la posibilidad de documentar todo el trabajo sin necesidad de
utilizar herramientas externas.
Las imágenes y reportes generados, no
son de muy buena calidad.
Case Complete De Pago Windows Interfaz amigable. Permite trazabilidad entre los
requerimientos. Rápido y de fácil manejo Solo funciona en plataforma Windows.
Jama Software De Pago Windows
Disponer de requisitos de calidad en un entorno compartido.
Implicar a todos los interesados en el proyecto y
fomentar la revisión y validación. Optimización de la gestión de requisitos óptima.
Gestión de Pruebas.
Interfaz con una experiencia de usuario excelente.
Adaptación a cualquier tipología y ciclo de vida de
requisitos.
Generación de todo tipo de vistas y reportes.
Solo funciona en plataforma Windows.
REM Libre Windows Permite exportar el documento HTML.
Difícil manejo
Última actualización fue en el 2004
Siempre presenta un error pero no afecta su funcionalidad
Interfaz poco amigable
29
Ilustración 8: Herramientas para la gestión de requerimientos [33]
Ilustración 9: Herramientas para la gestión de requerimientos [33]
30
Ilustración 10: Herramientas para la gestión de requerimientos. [33]
En el anterior análisis, es evidente que las herramientas de pago son mucho más robustas y
permiten implementar mayor número de funciones. Sin embargo, esto representa costos elevados
que hacen más difícil su adquisición por parte de pequeñas y medianas empresas. De igual forma,
se puede apreciar, con base en el estudio realizado, que el cien por ciento de estas herramientas de
pago solo pueden ser usadas en plataforma Windows.
Por otro lado, las herramientas libres tienen funciones y características importantes a la hora de
crear requerimientos, las mismas pueden ser elegidas por personas o empresas que no cuenten con
capital suficiente para este tema o recién comiencen en el ámbito laboral, pues con sus capacidades
pueden satisfacer ampliamente las necesidades de pequeñas empresas desarrolladoras de software
al momento de gestionar sus requerimientos.
El ejercicio permite también determinar los datos de entrada que con comunes entre las
herramientas, así como aquellos que son de obligatorio diligenciamiento o son más importantes.
Esto contribuirá significativamente al análisis de las necesidades principales para el modelo
automatizado que permita asegurar la calidad de los requerimientos, planteado como trabajo
futuro.
Otros aspectos como la trazabilidad, integración con otras plataformas, documentación
relacionada requerida y validación de la especificación obtenida son vitales para la investigación,
pue permiten dar una idea de la completitud con la que un sistema de gestión de requerimientos
debe operar.
Finalmente, el análisis realizado entrega información relevante para la siguiente etapa del
proyecto, relacionada con el diseño conceptual del modelo antes mencionado.
5.4.Entradas para el modelo conceptual
Las entradas son los elementos que necesita un requerimiento para poder ser creado. En este
apartado, se presentan las entradas que deberán ser tenidas en cuenta para el desarrollo de un
modelo automatizado para el aseguramiento de la calidad de los requisitos, identificadas a partir
de la consulta de las herramientas de desarrollo y gestión de requisitos estudiadas en el capítulo
anterior, así como en los resultados de la aplicación de un instrumento que indagó a las empresas
desarrolladoras de software de la región cafetera “Caracterización del aseguramiento de la calidad
de los requerimientos en la industria del software” sobre la forma en la que llevan a cabo el proceso
31
con los requisitos. Esto, busca determinar un instrumento que reúna las principales características
a considerar en el desarrollo de una herramienta para la elicitación, especificación y validación de
los requisitos que logre asegurar la calidad de los mismos.
De acuerdo a lo anterior, se presentan en la ilustración 22 los atributos principales a tener en
cuenta para el desarrollo de la herramienta propuesta:
Ilustración 11: Elementos de entrada de un requerimiento
ID
Versión
Fecha Creado Aprobado Modificado
Aceptado Diseñado Desarrollado Implantado Eliminado En espera Fecha
Funcional No funcional Usuario Sistema
Descripción Describir de manera detallada el requerimiento
Palabras clave
Suposiciones y dependencias Descripción de aquellos factores que si cambian, pueden afectar la realización de los req.
Pre-Condición Qué se debe cumplir antes de invocar el req.
Post-Condición Qué altera el sistema de manera posterior al ser realizado el req.
Alcance Describe en detalle los límites del proyecto, mencione las acciones que realizará el sistema
Restricciones Restricciones del sistema como tal, lenguajes de programación, hardware, software, entre otros.
Título del proyecto
Propósito Mencione los objetivos a los cuales debe dar solución el sistema
Fecha liberado
Nombre del requerimiento
Autor
Responsable
Muy alto
Muy alto
Estado
Tipo
Dificultad Bajo Medio Alto
Prioridad Bajo Medio Alto
32
6. ELICITACIÓN Y ESPECIFICACIÓN DE REQUISITOS (Fase 4)
Para el desarrollo de esta fase de la metodología, se realizaron actividades tendientes a dar
cumplimiento a las fases del ciclo de vida de los requisitos propuesto por [34, p. 45], expresadas
en la siguiente figura:
Ilustración 12. Proceso iterativo de desarrollo de requisitos [34, p. 45]
6.1.Elicitación de requisitos
Para la identificación de los requisitos para la plataforma automatizada que permita asegurar la
calidad de los requisitos se establecieron por los investigadores del proyecto los siguientes 4
escenarios, de los cuales se obtuvieron 32 requisitos funcionales y 3 requisitos no funcionales:
Estado de la técnica: Es la recopilación de todo el trabajo realizado sobre el análisis de las
herramientas. Observar cuáles entradas se solicitaban para la creación del requerimiento y
las funciones relevantes que puede brindar una herramienta CASE para la gestión de
requerimientos.
Trabajos previos: Información recopilada de trabajos anteriores, en los cuales se utilizó
información necesaria para la creación del requerimiento, tal que este, tenga una estructura
adecuada y concisa para así, asegurar la calidad del mismo.
Encuesta: Información recolectada sobre el instrumento diligenciado por las empresas
desarrolladoras de software de la ciudad de Pereira, donde plasman lo necesario para el
aseguramiento de la calidad de los requerimientos software.
Análisis del grupo de trabajo: Requerimientos resultantes en las reuniones del grupo de
trabajo.
A continuación, en la Tabla 3 (Ver Anexo D – Requisitos herramienta) se listan los requisitos
identificados para la herramienta:
33
Tabla 3: Requisitos identificados
Identificador Descripción
REQF000 El sistema debe permitir al administrador crear un usuario
REQF001 El sistema debe permitir al administrador consultar un usuario
REQF002 El sistema debe permitir al administrador modificar un usuario
REQF003 El sistema debe permitir al administrador eliminar un usuario
REQF004 El sistema debe permitir al administrador crear un proyecto
REQF005 El sistema debe permitir al administrador eliminar un proyecto
REQF006 El sistema debe permitir a los usuarios modificar un proyecto al que pertenezca
REQF007 El sistema debe permitir a los usuarios consultar un proyecto
REQF008 El sistema debe permitir a los usuarios crear un requisito
REQF009 El sistema debe permitir a los usuarios modificar un requisito
REQF010 El sistema debe permitir a los usuarios eliminar un requisito
REQF011 El sistema debe permitir a los usuarios consultar un requisito
REQF012 El sistema debe permitir a los usuarios describir un requisito
REQF013 Al crear un requisito el sistema debe asignar fecha al requerimiento según la hora del sistema
operativo o servidor
REQF014 Al modificar un requisito el sistema debe asignar una nueva fecha al requerimiento según la
fecha del sistema operativo o servidor
REQF015 El sistema debe permitir a los usuarios priorizar un requisito
REQF016 Al crear un requerimiento el sistema debe versionar el requisito
REQF017 El sistema debe permitir a los usuarios observar el historial del requisito
REQF018 El sistema debe permitir a los usuarios agrupar los requisito
REQF019 El sistema debe permitir a los usuarios asignar un requisito
REQF020 El sistema debe permitir a los usuarios clasificar un requisito
REQF021 El sistema debe permitir a los usuarios escalar un requisito
REQF022 El sistema debe permitir a los usuarios consultar un reporte de los requisitos por: Estado, fecha,
versión, tipo.
REQF023 El sistema debe permitir a los usuarios recuperar su contraseña
REQF024 Al validar las credenciales el sistema debe permitir a los usuarios ingresar al sistema
REQF025 El sistema debe permitir al administrador agregar participantes a un proyecto
REQF026 El sistema debe permitir a los usuarios enviar mensajes a otros miembros del proyecto
REQF027 El sistema debe permitir a los usuarios ver quien está conectado en el proyecto
REQF028 El sistema debe permitir a los usuarios ver cómo redactar los requerimientos
REQF029 Cuando se crea un requerimiento el sistema debe permitir a los usuarios administrar diagramas
REQF030 Cuando se crea un proyecto el sistema debe permitir a los clientes comentar el proyecto
REQF031 Cuando se crea un proyecto el sistema debe permitir a los usuarios generar la documentación de
los requerimientos
REQNF000 Si un usuario malicioso intenta acceder a funciones para las cuales no tiene autorización, el
sistema debe denegar el acceso a las funciones del sistema y el 100% de las acciones son
registradas
REQNF001 El sistema debe ejecutar todas las funciones para las cuales está diseñado en los siguientes
navegadores: IE, Chome y Firefox.
34
REQNF002 Si ocurre una falla que produce que el sistema se detenga el sistema debe reiniciar el servicio en
un tiempo no mayor a 5 minutos
Los requisitos anteriores fueron producto de reuniones del grupo de investigación, trabajos previos
realizados, respuestas del instrumento o resultado de la investigación
A continuación, se presenta en la Tabla 4 una clasificación de los requisitos identificados de
acuerdo al escenario del cual fueron obtenidos:
Tabla 4: Origen requisitos
ORIGEN
Identificador
Estado de la
técnica Trabajos previos Encuesta
Análisis del grupo
de trabajo
REQF000 X
REQF001 X
REQF002 X
REQF003 X
REQF004 X
REQF005 X
REQF006 X
REQF007 X
REQF008 X
REQF009 X
REQF010 X
REQF011 X
REQF012 X
REQF013 X
REQF014 X
REQF015 X
REQF016 X
REQF017 X
REQF018 X
REQF019 X
REQF020 X
REQF021 X
REQF022 X
REQF023 X
REQF024 X
REQF025 X
REQF026 X
REQF027 X
REQF028 X X
REQF029 X
REQF030 X
REQF031 X
REQNF000 X
REQNF001 X
REQNF002 X
35
6.2.Análisis de requisitos
Con el fin de dar cumplimiento a la fase de análisis del ciclo de vida de los requisitos, se
usó el Formato para el levantamiento de requerimientos (Ver Anexo A - Formato para el
levantamiento de requerimientos) elaborado por [35], el cual permite asegurar una correcta
identificación de los atributos que debe contener cada uno de los requerimientos identificados.
A continuación se muestra un ejemplo de un requisito funcional y uno no funcional
detallados en el formato.
36
Ilustración 13:REQNF000
37
Ilustración 14:REQF000
38
6.3.Especificación de requisitos
La especificación de requisitos se realizó siguiendo el procedimiento “PEVReS”
(Procedimiento para la Especificación y Validación de Requisitos de Software), elaborado por
[36]
Ilustración 15. Información general sobre PEVReS [36]
El procedimiento establece la aplicación de técnicas y buenas prácticas de Ingeniería de
Requisitos como las siguientes, para asegurar la calidad de los requisitos especificados:
Especificación de requisitos en lenguaje natural
Esquema de clasificación de requisitos
Perspectivas sobre requisitos
Diagramas de Casos de uso
Diagrama Entidad-Relación
Diagrama de Clases
Diagrama de Actividades
Diagramas de Flujo de Datos
Diagrama de Estados
Prototipos
Revisiones guiadas (Walkthroughs)
Inspecciones
Listas de comprobación (Checklist)
En la primera parte del procedimiento se encuentran el título, la descripción, el responsable, las
precondiciones y las entradas, como se ilustra a continuación.
39
Ilustración 16: Procedimiento para especificar requisitos de software en mipymes desarrolladoras de software de la ciudad de Pereira
Posteriormente, el procedimiento presenta tres actividades y para cada una de ellas las técnicas que permiten llevar a cabo la actividad,
así como el cubrimiento de la técnica (requerida, recomendada, opcional), su responsable, los pasos para ejecutar la técnica y finalmente,
los formatos, guías y herramientas que le sirven de apoyo. La primera actividad, relacionada con el entendimiento del negocio, se muestra
a continuación.
40
Ilustración 17: Especificación de requisitos
41
La segunda actividad relacionada con la Especificación de requisitos de usuario se presenta a continuación.
Ilustración 18: Especificación de Requisitos
42
La tercera actividad hace referencia a Especificación de requisitos del sistema y al final se muestran las salidas del procedimiento en
las que se destaca el Documento de especificación de requisitos (SRS).
Ilustración 19: Especificación requisitos del sistema
43
6.4.Aplicación del procedimiento
Para la aplicación del procedimiento se seleccionaron las siguientes técnicas, de acuerdo a la
clasificación de los requisitos presentada en [11, p. 34], aclarando que para PEVReS los requisitos
de software (funcionales y no funcionales) se derivan de los requisitos del sistema, entendiendo
que el sistema tiene componentes de software.
Ilustración 20. Técnicas seleccionadas del procedimiento PEVReS para la especificación de requisitos
Para determinar los requisitos a nivel del Negocio, en el cual se encuentran aquellos requisitos
que representan objetivos de alto nivel para la organización o el cliente que requiere el producto y
constituyen finalmente la necesidad principal para la elaboración de la plataforma de
aseguramiento de la calidad de los requisitos, se aplicó la técnica relacionada con la elaboración
de un Diagrama de actividades, en el cual explica el funcionamiento básico del aplicativo web.
Diagrama de actividades
Prototipos
Lenguaje natural
44
Ilustración 21: Diagrama de actividades
Así mismo, con la intención de establecer los requisitos a nivel del Usuario, los cuales describen
tareas que los usuarios deben estar en capacidad de cumplir con el producto de software que se
está describiendo y buscando satisfacer las expectativas acerca de lo que el sistema debe proveer
al usuario y las restricciones sobre las cuales debe operar, se elaboraron los siguientes Prototipos
como técnica también orientada a facilitar la validación de los requisitos identificados, analizados
y especificados.
El siguiente prototipo hace referencia a los requerimientos funcionales (REQF000, REQF001,
REQF002, REQF003, REQF004, REQF005, REQF006, REQF007). (Ver anexo B – Prototipos)
45
Ilustración 22: Prototipo REQF000-REQF007
De igual forma, se realizaron los prototipos para todos los requerimientos funcionales del sistema.
Finalmente, para especificar los requisitos del sistema los cuales hacen referencia a la
funcionalidad que debe ser construida para permitir al producto realizar sus tareas, en términos de
las necesidades del sistema, se empleó la técnica de especificación en Lenguaje natural
estructurado (Ver Anexo C – Plantilla lenguaje natural estructurado), la cual entrega una
forma de redactar los requisitos del sistema donde la libertad del redactor de los requisitos está
limitada y donde todos los requisitos se redactan de una forma estándar [37, p. 26]. Para limitar la
terminología al redactar los requisitos, se empleó una plantilla que facilita las notaciones del
lenguaje estructurado. La misma se presenta a continuación:
46
Ilustración 23: Plantilla para especificar requisitos en lenguaje natural estructurado [36]
Una vez aplicada la técnica a los requisitos identificados, se obtuvo el siguiente resultado.
Requisitos
Identificador Nombre
REQF000 Crear usuario
REQF001 Consultar usuario
REQF002 Modificar usuario
REQF003 Eliminar usuario
REQF004 Crear proyecto
REQF005 Eliminar proyecto
REQF006 Modificar proyecto
REQF007 Consultar proyecto
REQF008 Crear requisito
REQF009 Modificar requisito
REQF010 Eliminar requisito
REQF011 Consultar requisito
REQF012 Describir requisito
REQF013 Crear fecha requisito
REQF014 Asignar fecha requisito
REQF015 Priorizar requisito
REQF016 Versionar requisito
REQF017 Trazabilidad requisito
REQF018 Agrupar requisito
REQF019 Asignar requisito
REQF020 Clasificar requisito
REQF021 Escalar requisito
REQF022 Consultar reporte requisito
REQF023 Recuperar contraseña
REQF024 Ingresar a la aplicación
REQF025 Agregar participantes
REQF026 Enviar mensajes
REQF027 Ver qué persona del equipo está conectado
REQF028 Cómo redactar requisito
REQF029
Administrar diagramas
47
REQF030 Comentar proyecto
REQF031 Generar documentación requisito
REQNF000 Seguridad
REQNF001 Portabilidad
REQNF002 Disponibilidad
48
7. ANÁLISIS Y DISCUSIÓN DE RESULTADOS
Una vez estudiadas las herramientas para la gestión de requerimientos identificadas, se realiza
una tabla comparativa en la que se pretende determinar las principales diferencias entre cada una
de las herramientas, considerando además los aspectos que mayor relevancia tiene cada una, sus
principales ventajas y falencias (Tabla 1).
Se encontró que las herramientas de pago contienen mejores funcionalidades y son mucho más
robustas, sin embargo, como se mencionó anteriormente el alto costo de sus licencias hace que sea
difícil su adquisición por las MiPymes. Otro aspecto desfavorable identificado es que
generalmente éstas solo funcionan en plataformas Windows, limitando en gran medida su
utilización.
En el anterior análisis, es evidente que las herramientas de pago son mucho más robustas y
permiten implementar mayor número de funciones. Sin embargo, esto representa costos elevados
que hacen más difícil su adquisición por parte de pequeñas y medianas empresas. De igual forma,
se puede apreciar, con base en el estudio realizado, que el cien por ciento de estas herramientas de
pago solo pueden ser usadas en plataforma Windows.
Por otro lado, las herramientas libres tienen funciones y características importantes a la hora
de crear requerimientos, las mismas pueden ser elegidas por personas o empresas que no cuenten
con capital suficiente para este tema o recién comiencen en el ámbito laboral, pues con sus
capacidades pueden satisfacer ampliamente las necesidades de pequeñas empresas desarrolladoras
de software al momento de gestionar sus requerimientos.
El ejercicio permite también determinar los datos de entrada que con comunes entre las
herramientas, así como aquellos que son de obligatorio diligenciamiento o son más importantes.
Esto contribuirá significativamente al análisis de las necesidades principales para el modelo
automatizado que permita asegurar la calidad de los requerimientos, planteado como trabajo
futuro.
Otros aspectos como la trazabilidad, integración con otras plataformas, documentación
relacionada requerida y validación de la especificación obtenida son vitales para la investigación,
pue permiten dar una idea de la completitud con la que un sistema de gestión de requerimientos
debe operar.
Finalmente, el análisis realizado entrega información relevante para la siguiente etapa del
proyecto, relacionada con el diseño conceptual del modelo antes mencionado.
49
8. CONCLUSIONES
La Ingeniería de requisitos y, como parte de ella la gestión de los requerimientos, no es la
solución definitiva al problema de producir software de baja calidad, pero ayuda en gran medida
al descubrimiento y solución de falencias en etapas tempranas del desarrollo de proyectos de
software, reduciendo costos y tiempo en el ciclo de vida.
Por lo tanto, las herramientas CASE agilizan y facilitan la gestión de requerimientos software,
ofreciendo apoyo permanente al equipo de trabajo encargado del desarrollo del proyecto. En el
mercado se pueden encontrar herramientas gratuitas y de pago, brindando un abanico de
posibilidades a las empresas y/o personas que las requieren.
Sin embargo, la mayoría de herramientas de pago que se encuentran en el mercado presentan
altos costos en el licenciamiento, lo que representa difíciles para muchas de las pequeñas y
medianas empresas desarrolladoras de software, razón por la cual, en su gran mayoría, utilizan
herramientas gratuitas o no utilizan ninguna de ellas.
Con lo anterior, la gestión de requerimientos es una tarea que aún tiene mucho por explorar,
pues aún requiere optimizar y definir elementos de entradas fundamentales y concisos para cumplir
con las expectativas del cliente y satisfacer las necesidades del proyecto.
50
9. REFERENCIAS BIBLIOGRÁFICAS
[1] IEEE, SWEBOK, Piscataway: IEEE, 2004.
[2] B. Boehm, Software Engineering Economics, New Jersey: Prentice Hall, 1981.
[3] I. Sommerville, Ingenieria del Software, Séptima Edición ed., Madrid: Pearson Educación
S.A, 2005.
[4] R. S. Pressman, Ingeniería del Software UIn enfoque práctico, Septima edición ed.,
McGraw-Hill, 2010.
[5] R. H. Thayer y M. Dorfman, Software Requirements Engineering, Segunda edición ed.,
1997.
[6] R. S. Pressman, Ingeniería del software, un enfoque práctico, Sexta edición ed., Madrid:
McGraw-Hill, 2006.
[7] R. Oberg, L. Probasco y M. Ericsson, «Applying requirements management with use
cases,» 2003. [En línea]. Available:
http://www.uml.org.cn/RequirementProject/pdf/apprmuc.pdf.
[8] L. Merchan, A. Urrea y R. Rebollar, «Definición de una metodología ágil de ingeniería de
requerimientos para empresas emergentes de desarrollo de software del sur-occidente
colombiano,» Revista Científica Guillermo de Ockham, Universidad de San
Buenaventura, vol. 6, nº 1, pp. 37-50, 2008.
[9] A. Toro, L. E. Peláez y L. Cardona Benjumea, «Revisión de propuestas de ingeniería del
software: una mirada desde las organizaciones internacionales que tratan la disciplina,»
Entre ciencia e ingeniería, pp. 189-191, 2010.
[10] K. Wiegers y J. Beatty, Software Requierements, Third Edition ed., Redmon, Washington:
Microsoft Press, 2013.
[11] IEEE, SWEBOK Guide V3.0, Piscataway: IEEE, 2014.
[12] J. D. Murcia Torres, «Guía para la integración de métodos formales de ingeniería,»
Bogotá, 2014.
[13] K. Jackson, E. Hull y J. Dick, «Requeriments Engineering,» Londrés, 2011.
[14] E. Sandoval y A. Alarcón, «Herramientas CASE para ingeniería de requisitos,» Cultura
científica, Madrid, 2011.
51
[15] SUPERSOCIEDADES, «Desempeño del sector software 2012-2014,» Superintendencia
de sociedades, Bogotá, 2015.
[16] C. A. De la Cruz Londoño y G. A. Castro Guevara, «Metodología para la adquisición y
gestión de requerimientos en el desarrollo de software para pequeñas y medianas (tesis de
posgrado),» Universidad Tecnológica de Pereira, Pereira, 2014.
[17] J. Moeller, «IBM,» 2010. [En línea]. Available:
https://www.ibm.com/developerworks/ssa/rational/library/10/managedevelopmentofdocu
mentbasedrequirementsinparallelwithrationalrequisitepro/. [Último acceso: Octubre 2017].
[18] Insco, «Insco Requisite,» 2007. [En línea]. Available:
http://www.dkse.ual.es/es/insco/index.do. [Último acceso: Noviembre 2017].
[19] Sparx Systems, «RaQuest,» 2017. [En línea]. Available: http://www.raquest.com. [Último
acceso: Octubre 2017].
[20] IBM, «IBM,» 2016. [En línea]. Available: http://www-
03.ibm.com/software/products/es/ratidoor. [Último acceso: Octubre 2017].
[21] Sparx Systems, «Enterprise Architec,» 2016. [En línea]. Available:
http://www.sparxsystems.com.ar. [Último acceso: Octubre 2017].
[22] Goda software, «Case Spec,» 2017. [En línea]. Available: http://casespec.net. [Último
acceso: Noviembre 2017].
[23] Case Complete, «Casecomplete,» 2014. [En línea]. Available: www.casecomplete.com.
[Último acceso: Noviembre 2017].
[24] SourceForge, «DRES - Requirements Engineering Support,» 2017. [En línea]. Available:
https://sourceforge.net/projects/dres/. [Último acceso: Noviembre 2017].
[25] Martinig & Associates, «Open source,» 2016. [En línea]. Available:
http://www.requirementsmanagementtools.com/opensource.php. [Último acceso: Octubre
2017].
[26] A. Florath, «rmToo,» 2015. [En línea]. Available: http://rmtoo.florath.net. [Último acceso:
Octubre 2017].
[27] A. D. Toro, «Herramienta REM,» 2014. [En línea]. Available:
http://www.lsi.us.es/descargas/descarga_programas.php?id=3. [Último acceso: Noviembre
2017].
[28] REMAS, «Release Management System,» 2016. [En línea]. Available:
https://sourceforge.net/projects/remas/. [Último acceso: Noviembre 2017].
52
[29] REQTIFY, «REQTIFY,» 2015. [En línea]. Available: https://www.3ds.com/es/productos-
y-servicios/catia/productos/reqtify/. [Último acceso: Noviembre 2017].
[30] Jama Software, «Jama,» 2017. [En línea]. Available: https://www.jamasoftware.com.
[Último acceso: Octubre 2017].
[31] Accept360, «Accept360,» 2015. [En línea]. Available:
http://www.accept360.com/solutions/requirements-management/. [Último acceso:
Noviembre 2017].
[32] A. Durán, «Un Entorno Metodológico de Ingeniería de Requisitos para Sistemas de
Información,» 2000. [En línea]. Available: http://www.lsi.us.es/. [Último acceso: 27 10
2017].
[33] E. Pérez Rodríguez y K. Pérez Teruel, «Tool for Requirements Management in Cuban’s
Small and Medium Enterprises,» La Habana, 2013.
[34] K. Wiegers y J. Beaty, Software Requierements, Third Edition ed., Redmon, Washington:
Microsoft Press, 2013.
[35] L. E. Pelaez, D. C. Lopez y D. L. Carvajal, «Formato para elicitación de requerimientos,»
Pereira, 2010.
[36] A. Toro y J. G. Galvez, «Procedimiento para la Especificación y Validación de Requisitos
de Software,» Pereira, 2016.
[37] A. N. Camacho Zambrano, «Herramienta para el análisis de requerimientos dentro de la
pequeña empresa desarrolladora de software en Bogota,» Bogota, 2005.
[38] R. Thayer y M. Dorfam, Software Requirements Engineering, Segunda edición ed., Los
Alamitos, California: IEEE Computer Science Press, 2000.
[39] L. E. Peláez Valencia, «SWEBOK – IEEE | Guide to the Software Engineering Body of
Knowledge; Un resumen ejecutivo,» Pereira, 2010.
[40] R. S. Pressman, Ingenieria del Software. Un enfoque práctico, Quinta edición ed., Madrid:
McGraw-Hill, 2002.
[41] IEEE, «Swebok,» Washington, 2004.
[42] A. N. Camacho, «HERRAMIENTA PARA EL ANÁLISIS DE REQUERIMIENTOS
DENTRO DE LA PEQUEÑA EMPRESA DESARROLLADORA DE SOFTWARE EN
BOGOTÁ,» Bogotá, 2005.
[43] M. Rodríguez, «¿Qué debe esperar realmente como resultado de su inversión en un
Sistema de Gestión de la Calidad (SGC) ISO 9001:2015?,» [En línea]. Available:
53
http://www.normas9000.com/Company_Blog/tomar-la-decision-de-certificarse-en-ISO-
9001-2015.aspx.
[44] F. D'Angelo, Norma ISO 9000-3, 2017.
[45] EntlT Software, «Quality Center Enterprise (QC),» 2016. [En línea]. Available:
https://saas.hpe.com/es-mx/software/quality-center. [Último acceso: Noviembre 2017].
[46] GNU, «GNU,» 2014. [En línea]. Available: https://www.gnu.org/philosophy/free-
sw.en.html. [Último acceso: Octubre 2017].
[47] L. Cardona Benjumea, A. Toro y L. E. Pelaez, Revisión de Propuestas de Ingeniería del
Software: una mirada desde las organizaciones internacionales que tratan la disciplina.,
Pereira: Entre Ciencia e Ingeniería, 2010.
[48] I. Lasso, «Proyecto Autodidacta,» 2015. [En línea]. Available:
http://www.proyectoautodidacta.com/comics/software-propietario-de-pago-demo-
shareware-y-freeware/. [Último acceso: Octubre 2017].
[49] E. Perez Rodríguez, Tool for Requirements Management in Cuban’s Small and Medium
Enterprises, Bogotá, 2017.
![4 - Modelo Conceptual UML.ppt [Autoguardado]](https://img.pdfslide.es/doc/110x75/5571f8c349795991698e09fb/4-modelo-conceptual-umlppt-autoguardado.jpg)
