UNIDAD ACADÉMICA DE INGENIERÍA CIVIL

CARRERA DE INGENIERÍA DE SISTEMAS

MACHALA2017

MURILLO SUÁREZ ALEX DAVIDINGENIERO DE SISTEMAS

DESARROLLO Y EVALUACIÓN DE UN MODELO REFERENCIALHÍBRIDO BASADO EN LA FASE DE ANÁLISIS DE REQUERIMIENTOS,

APLICADO AL SOFTWARE WEB

UNIDAD ACADÉMICA DE INGENIERÍA CIVIL

CARRERA DE INGENIERÍA DE SISTEMAS

MACHALA2017

MURILLO SUÁREZ ALEX DAVIDINGENIERO DE SISTEMAS

DESARROLLO Y EVALUACIÓN DE UN MODELO REFERENCIALHÍBRIDO BASADO EN LA FASE DE ANÁLISIS DE

REQUERIMIENTOS, APLICADO AL SOFTWARE WEB

UNIDAD ACADÉMICA DE INGENIERÍA CIVIL

CARRERA DE INGENIERÍA DE SISTEMAS

MACHALA23 de agosto de 2017

MURILLO SUÁREZ ALEX DAVIDINGENIERO DE SISTEMAS

DESARROLLO Y EVALUACIÓN DE UN MODELO REFERENCIAL HÍBRIDOBASADO EN LA FASE DE ANÁLISIS DE REQUERIMIENTOS, APLICADO AL

SOFTWARE WEB

MACHALA, 23 DE AGOSTO DE 2017

VALAREZO PARDO MILTON RAFAEL

EXAMEN COMPLEXIVO

Urkund Analysis Result Analysed Document: MURILLO SUAREZ ALEX DAVID.docx (D29674959)Submitted: 2017-07-17 22:11:00 Submitted By: mvalarezo@utmachala.edu.ec Significance: 1 %

Sources included in the report:

http://sistemas.unla.edu.ar/sistemas/redisla/ReLAIS/relais-v4-n5-216-230.pdf

Instances where selected sources appear:

1

U R K N DU

RESUMEN

El presente trabajo tiene como finalidad crear un modelo referencial para reducir esfuerzos,

reducir tiempos y agilizar el proceso de recolección y análisis de los requisitos de software

aplicados a la web, para ello se realiza una comparación entre los distintos modelos

propuestos por diferentes autores, los mismos que se analizaron entre sus ventajas y

desventajas, posteriormente se desarrolla un nuevo modelo referencial que contenga las

características y ventajas de los modelos comparados, el cual es evaluado dentro de la fase de

análisis de requisitos de la metodología ICONIX, adicional se desarrolla un prototipo de

página web en el que se cumplen las necesidades expuestas por un grupo de personas, para

conseguir los requisitos se utilizaron técnicas de obtención, entre ellas una encuesta a

usuarios que regularmente adquieren productos mediante la web para conocer las necesidades

que se presentan al momento de realizar dichas compras, una vez obtenido los requisitos del

sistema, se procedió a analizarlos y documentarlos en un borrador, para finalmente validar

dicho borrador y crear un documento en el que se detallan los requisitos y sus respectivos

diagramas dentro de la primera fase de análisis de requisitos de la metodología de software.

Palabras claves: Modelo de proceso, Ingeniería de Software, Ingeniería de Requisitos.

ABSTRACT

The present work aims to create a referential model to reduce efforts, reduce time and speed

up the process of collection and analysis of software requirements applied to the web, for this

is done a comparison between different models proposed by different authors, which were

analyzed between their advantages and disadvantages, later developed a new reference model

containing the characteristics and advantages of the compared models, which is evaluated

within the requirements analysis phase of the ICONIX methodology, a prototype is

developed further of web page in which the needs exposed by a group of people are met, to

obtain the requisites were used obtaining techniques, among them a survey to users who

regularly buy products through the web to know the needs that are presented at the time of to

make such purchases, once the requirements of the system, they were analyzed and

documented in a draft, to finally validate the draft and create a document detailing the

requirements and their respective diagrams within the first phase of analysis of requirements

of the software methodology.

Keywords: Process model, Software Engineering, Requirements Engineering,

CONTENIDO

Pág.

INTRODUCCIÓN 12

DESARROLLO 13

1. Ingeniería de Software. 13

2. Ingeniería de Software en sistemas web 13

3. Factores que impactan el desarrollo de proyectos de software. 13

4. Ingeniería de Requisitos. 14

4.1. UML en escenarios de Ingeniería de Requisitos 15

4.2. Técnicas para la definición de requisitos. 15

4.3. Modelo de proceso de conceptualización de Requisitos 16

4.4. Modelos de proceso para la Ingeniería de requisitos 16

4.4.1. Modelo en Espiral 16

4.4.2. Modelo de Pohl 17

4.4.3. Modelo Swebok 18

5. Comparación entre modelos 19

6. Modelo referencial propuesto 20

CONCLUSIONES 22

BIBLIOGRAFÍA 23

https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.3j2qqm3https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.tyjcwthttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.26in1rghttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.26in1rghttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.2et92p0https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.3znysh7https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.17dp8vuhttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.2jxsxqhhttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.2et92p0https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.tyjcwthttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.3j2qqm3https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.1ksv4uvhttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.2jxsxqhhttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.4d34og8https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.2et92p0https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.1t3h5sfhttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.2s8eyo1https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.3znysh7https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.26in1rghttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.1t3h5sfhttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.3znysh7https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.2s8eyo1https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.4i7ojhphttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.lnxbz9https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.3znysh7https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.2s8eyo1https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.4d34og8https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.4i7ojhphttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.1ksv4uvhttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.lnxbz9https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.17dp8vuhttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.17dp8vuhttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.1t3h5sfhttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.4i7ojhphttps://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.4d34og8https://docs.google.com/document/d/1P1D3qRrlWGrEAb_fE5Jof84ZmNuqqL2XNz1waWqXlgo/edit#heading=h.tyjcwt

LISTA DE ILUSTRACIONES

Pág.

Figura 1. Factores que impactan el desarrollo de proyectos de software. 14

Figura 2. Modelo de conceptualización de Requisitos. 16

Figura 3. Modelo en espiral de un proceso general de IR. 17

Figura 4. Modelo de Pohl para IR. 18

Figura 5. Modelo Swebok para IR. 19

Figura 6. Modelo Referencial híbrido para la IR.. 21

LISTA DE TABLAS

Pág.

Tabla 1. Cuadro comparativo entre Modelos de conceptualización de Requisitos. 19

Tabla 2. Matriz de Roles y Actividades del proyecto. 28

LISTA DE ANEXOS

Pág.

ANEXO A. Matriz de Roles y Actividades del Proyecto…………………………………...28

ANEXO B. Formato de Encuesta para Requisitos…………………………………………...29

INTRODUCCIÓN El desarrollo de nuevas tecnologías de la información y comunicación ha venido mejorando

procesos y han logrado incluirse en las distintas ramas de la ciencia [1] [2] . Hoy en día

desarrollar un software implica muchos factores que deben ser considerados, uno de ellos y el

más importante es el análisis de los requisitos del sistema, el cual ayuda a conocer el

propósito y la función que debe cumplir un producto o servicio, para una mejor comprensión

de los requisitos se ha visto la necesidad de crear modelos referenciales que muestren el

proceso de desarrollo en los cuales incluyen las actividades realizadas que sirven como guía

en la creación de un software. Otra característica importante de un software es su fiabilidad la

cual consta de la probabilidad de que funcione correctamente el software [3].

Una de las ramas de la Ingeniería de Software que trabaja con las necesidades del cliente, se

llama Ingeniería de Requisitos (IR) la cual aplica principios, métodos, técnicas y

herramientas para el levantamiento de información y descubrimiento de los requisitos de un

producto, la participación de la IR ayuda a los encargados del área a conocer bien los

requisitos, caso contrario se corre el riesgo de fracasar al momento de entregar los resultados

del proyecto, teniendo como consecuencias mala calidad del software, clientes insatisfechos,

entre otros. [4] [5]

Gran parte de los problemas que se presentan en el ciclo de vida de un proyecto de software,

se deben al mal proceso de recolección y análisis de los requisitos del cliente, es por ello que

las empresas de desarrollo de software deben implementar nuevos mecanismos que ayuden a

ganar confiabilidad en los requisitos de tal modo que se disminuyan riesgos y costos

adicionales durante el proceso de desarrollo [6].

Un modelo referencial puede ser considerado un mecanismo para ganar confiabilidad en los

requisitos, un modelo es usado en la IR para definir el orden secuencial según la importancia

de cada actividad, para luego validar el cumplimiento de las expectativas del cliente.

Como objetivo de la investigación se encuentra: desarrollar y evaluar mediante un prototipo,

un modelo referencial híbrido basado en la fase de análisis de requisitos, aplicado al software

web.

DESARROLLO

1. Ingeniería de Software.

La Ingeniería está formada por diferentes ramas, las cuales se concentran en estudiar muy a

fondo determinados objetos, actualmente en el mundo informático el software es considerado

un objeto a estudiar, el estudio del mismo ha venido presentando fallas al igual que otras

disciplinas, es por ello que se ha visto la necesidad de implementar distintas técnicas y

métodos con el objetivo de reducir ciertos problemas identificados en la crisis del software,

de esta manera aparece la Ingeniería de Software, una rama de la ingeniería que ofrece

diferentes modelos de procesos los cuales se ajustan a las necesidades de clientes [7].

Dentro de la Ingeniería de software se utilizan metodologías para el desarrollo de proyectos,

actualmente las más utilizadas son las ágiles, por su característica de concentrarse en la

interacción del usuario con el desarrollador, este tipo de metodologías ofrecen la presentación

de cada versión del software hacia los interesados en determinados periodos de tiempo,

ayudando así a realizar cambios si se lo requiera [8]. Durante el proceso de desarrollo de

software también se identifican los interesados o también conocidos como stakeholders, los

mismos son representados en distintos diagramas del proyecto. [9]

2. Ingeniería de Software en sistemas web

Actualmente las aplicaciones web están presentes en cada empresa que desea llevar sus

productos a clientes con la mayor comodidad [10]. En el desarrollo de sistemas web, al igual

que el desarrollo de software de escritorio se utiliza técnicas y métodos para resolver

problemas o necesidades de clientes, la característica principal o desventaja del desarrollo de

sistemas web es que carecen del uso de requisitos no funcionales, y se enfocan más a los

requisitos funcionales [11].

3. Factores que impactan el desarrollo de proyectos de software.

Dentro del desarrollo de software existen ciertos factores de mayor impacto que intervienen

en el fracaso o éxito de los proyectos, en la figura 1 se muestra dichos factores, para los

cuales se usaron datos estadísticos tomados de más de 170 mil proyectos de desarrollo de

software [12].

Figura 1. Factores que impactan el desarrollo de proyectos de software.

Fuente: Reporte CHAOS (2013) [13].

4. Ingeniería de Requisitos.

El mayor problema que enfrentan las empresas de desarrollo de software se encuentra en la

fase de elicitación y descubrimiento de requisitos, puesto que los productos finales no

cumplen las expectativas de los clientes [14]. Es ahí donde actúa la IR, tratando el

entendimiento de las necesidades y compresión de los problemas que presentan las personas

al momento de realizar cierta actividad [15]. M. A. Chaves [16] afirma que la IR es la etapa

más importante dentro del desarrollo de un proyecto de software, se considera un proceso de

recopilar, analizar y verificar con claridad las necesidades de un cliente o usuario. La IR

permite identificar, analizar y validar los requisitos que posteriormente serán utilizados para

el desarrollo del futuro software, esto ayuda a los desarrolladores a determinar si es factible

llevarlo a cabo o no el software [17]. Se debe tener en cuenta que las etapas siguientes

dependen de la correcta definición de los requisitos [18].

La comunidad de la Ingeniería de Software indica que es de vital importancia realizar

correctamente la etapa de requisitos, para obtener el mejor resultado en cuanto a la calidad

del desarrollo de productos software [19].

Es recomendable para las empresas de desarrollo de software, mantener una investigación

continua en cuanto a mecanismos que generen confiabilidad de los requisitos, para evitar

sobrecostos y disminuir riesgos, la investigación de las nuevas técnicas debe orientarse hacia

las características de un proceso de desarrollo de software tales como; un análisis de

requisitos ágil, unión entre los integrantes del grupo de desarrollo, detección de errores a

tiempo en la identificación y especificación de requisitos, definición de controles para cada

fase del proyecto [20]. Los sistemas distribuidos son un ejemplo del uso de nuevas

tecnologías las cuales permiten reducir costes y crear sistemas flexibles e independientes del

hardware [21].

4.1. UML en escenarios de Ingeniería de Requisitos

El lenguaje de Modelado Unificado (UML) es usado en el desarrollo de sistemas de software

como un estándar para la especificación, construcción y documentación de los distintos

modelos creados durante el proceso de desarrollo de un sistema, se considera una técnica

efectiva el uso de escenarios, puesto que muestran las necesidades de los usuarios y cómo

estas se podrían reflejar en el sistema, un escenario puede representar una actividad que el

usuario realiza al efectuar una tarea, para posteriormente dicha actividad se logre automatizar

[22].

4.2. Técnicas para la definición de requisitos.

La definición de requisitos se basa en la especificación y verificación de las actividades que

un sistema debe brindar [23]. Para la definición de requisitos se utilizan técnicas una de ellas

es la entrevista, en la cual participan el ingeniero de requisitos en conjunto con la parte de los

interesados, como primer paso para elaborar una entrevista es identificar los posibles

candidatos, luego se prepara un banco de preguntas que se pueden utilizar, seguido de esto se

define el lugar donde se realizará la entrevista, luego de la entrevista se tabulan los requisitos

obtenidos y se realiza la documentación de los mismos [24]. Otra técnica muy utilizada son

las encuestas de satisfacción al cliente, en la cual se elabora un cuestionario de preguntas y se

las realizan a un determinado número de personas. [25]. Una técnica adicional empleada para

la recolección de requisitos es el uso de ontologías (relación de conceptos relacionados

jerárquicamente en forma de árbol), las mismas que permiten establecer un conocimiento

común por parte de los interesados y el ingeniero de requisitos, esto permite mejorar la

comunicación entre ambas partes y conseguir una recopilación de requisitos completa [24].

4.3. Modelo de proceso de conceptualización de Requisitos

Ferrer, Lautaro [26] indica que un proceso de conceptualización de requisitos para proyectos

de Software tiene como objetivo comprender los problemas definidos por los usuarios.

Romero, Natalia [27] asegura que comprender y capturar requisitos sirve como vínculo entre

la educción de requisitos y modelado conceptual. En la figura 2 se muestra un modelo de

conceptualización de estructura básica basado en los escenarios de usuarios, el mismo que

está formado por las actividades de educción de requisitos ayudando a comprender el

problema planteado por el usuario, para posteriormente crear los modelos conceptuales [28].

La educción de requisitos es una actividad que pertenece al proceso de IR con la tarea de

recuperar información acerca del dominio del problema y necesidades de los interesados,

para evaluar la educción se desarrollan modelos de contexto. [29]

Figura 2. Modelo de conceptualización de Requisitos

Fuente: Alejandro Hossian [28].

4.4. Modelos de proceso para la Ingeniería de requisitos

Un proceso de software es considerado como un grupo de actividades que tiene como

objetivo el desarrollo o evolución del software. Un modelado de proceso consiste en agrupar

cierta cantidad de procesos que se deben llevar a cabo para completar una determinada fase

del ciclo del proyecto, en el cual incluye actividades y artefactos relacionados entre sí [30].

4.4.1. Modelo en Espiral

B. M. Valle [30] demuestra en la figura 3 el modelo en espiral de un proceso general de IR

con las actividades comunes de un proceso general, como primera actividad se encuentra la

elicitación la cual trata de la identificación de los requisitos, utilizando técnicas de

recolección de información, tales como; encuestas, entrevistas, lluvia de ideas, entre otras,

como segunda actividad se observa el análisis y negociación, aquí participan los interesados

para discutir cuáles serán los requisitos que intervendrán durante todo el proceso de

desarrollo del software, la tercera actividad es la documentación de los requisitos tomados en

la actividad anterior, la manera de documentar se la realiza en un lenguaje natural y en por

medio diagramas, como última actividad se encuentra la validación de los requisitos en la

cual se comprueba toda la documentación, esto se realiza antes de que los requisitos sean

usados como base para el desarrollo del software. Kotonya y Sommerville [31] aseguran que

un proceso en espiral es la mejor forma de llevar a cabo un proceso de IR, ya que las

actividades se repiten en cada iteración, logrando corregir algún problema que se presente y

finalmente obtener un documento de requisitos aceptable.

Figura 3. Modelo en espiral de un proceso general de IR.

Fuente: Begoña Moros Valle [30].

4.4.2. Modelo de Pohl

[32] Es un modelo iterativo en el que intervienen cuatro actividades las mismas que se vieron

en el modelo espiral, algunas con un nombre diferente, al igual que el modelo anterior se

mantiene una secuencia que comienza con la elicitación u obtención de requisitos en la cual

se trata de dar a conocer las necesidades de los clientes y usuarios a los participantes para que

logren entender el problema, en la siguiente actividad se encuentra la negociación en la cual

se logran acuerdos entre los participantes sobre los requisitos obtenidos en la primera

actividad, como siguiente fase se documentan los requisitos anteriormente obtenidos y

negociados, y finalmente estos requisitos deben ser validados asegurando que cumplan las

necesidades de los clientes. En la figura 4 se muestra el modelo de Pohl y se observa que

adicional a las cuatro actividades, en este modelo interviene la participación de ocho

interesados del proyecto, entre ellos se encuentran; un ingeniero de requisitos, expertos en

marketing, usuarios, grupo de calidad, director de proyecto, programadores, clientes y

expertos en el dominio.

Figura 4. Modelo de Pohl para IR.

Fuente: Belkis Grissel González Rodríguez [32]

4.4.3. Modelo Swebok

B. G. González Rodríguez [32] detalla el modelo Swebok (Software Engineering Body of

Knowledge), este modelo está basado en la IR la cual es una de las diez áreas del

conocimiento de la Ingeniería de Software, en la figura 5 se muestra las cuatro fases de este

modelo, entre ellas se encuentra la elicitación de requisitos la cual se considera importante

para lograr entender los problemas a resolver, siguiendo con la fase de análisis y negociación

de requisitos en la cual se determinan los límites del sistema y se transforman los requisitos

de usuario a requisitos de sistema, como tercera fase se realiza la documentación de los

requisitos para finalmente como última fase validar los requisitos documentados.

Figura 5. Modelo Swebok para IR.

Fuente: Belkis Grissel González Rodríguez [32]

5. Comparación entre modelos

Una vez revisado los modelos anteriores de procesos de conceptualización de Requisitos, se

realiza un análisis de los tres modelos, revisando su estructura, contenido y su participación

dentro de la fase de análisis de los requisitos, se comparan entre sí para determinar sus

ventajas y desventajas.

Tabla 1. Cuadro comparativo entre Modelos de conceptualización de Requisitos

MODELO VENTAJAS DESVENTAJAS

Modelo en Espiral

Las repeticiones de las actividades ayudan a encontrar fallas y resolverlos hasta obtener un documento de requisitos aceptado

Exceso de tiempo para lograr determinar los requisitos, debido al número de iteraciones

Modelo de Pohl

Participación de varios grupos de interesados dentro del proceso de la ingeniería de requisitos

No existe una orden durante el proceso, lo cual ocasiona conflictos al definir los requisitos

El modelo Swebok

El Modelo detalla elementos que podrían intervenir para la fase de elicitación de requisitos

Podrían encontrarse errores en los requisitos obtenidos puesto que solo trabaja una iteración

Fuente: Elaboración propia

6. Modelo referencial propuesto

Como propuesta de este trabajo de investigación, se desarrolla un nuevo modelo referencial

híbrido basado en los requisitos de software, tomando como referencia las ventajas obtenidas

de la tabla 1, al comparar los tres modelos vistos con anterioridad, en la figura 6 se observa

el modelo con las cuatro fases primordiales dentro del área de conocimiento de la IR. La

primera consideración que se tuvo fueron las iteraciones del modelo espiral, el modelo

propuesto puede dar las iteraciones que se consideren necesarias por los interesados, hasta

obtener un documento final de requisitos pulido, como segunda consideración se tomó el

grupo de interesados como lo hace el modelo de Pohl, agregando como parte interesada a los

siguientes grupos de personas; Ingenieros de Requisitos, expertos en marketing,

usuarios/clientes, director de proyecto, grupo de calidad. Y por último se consideró el detalle

de los elementos que pueden intervenir en la actividad de la recolección de requisitos, entre

ellos; las necesidades de los usuarios, sistemas similares y estándares.

Para la evaluación del modelo desarrollado se creó un prototipo de una página web para una

empresa de ventas de artículos electrónicos, en el cual se realizó la fase de análisis de

requisitos basado en la metodología ICONIX, para demostrar la participación de cada

interesado se desarrolla una matriz (ver el Anexo A.) en donde se determina las actividades

en donde participan cada uno, la fase de análisis se desarrolla para cada una de las actividades

del modelo propuesto, iniciando desde la recolección de los requisitos. Para la primera

actividad del modelo se realizará una encuesta (ver el Anexo B.) a un determinado número de

usuarios, para determinar los problemas que presentan al momento de adquirir un nuevo

producto, se tabularon los datos conseguidos por los encuestados, luego se analizaron dichas

necesidades obtenidas para desarrollar un borrador de requisitos y luego validarlo, obteniendo

de esta manera el documento resultante de la fase de análisis de requisitos de la metodología

mencionada anteriormente.

.

Figura 6. Modelo Referencial híbrido para la IR

Fuente: Elaboración propia.

CONCLUSIONES

El uso de modelos de referencia basados en requisitos de software ayuda en el proceso de

desarrollo para seleccionar de la manera más eficiente las necesidades que presentan los

individuos al momento de realizar cierta actividad. Los diferentes autores citados durante el

proceso de esta investigación permiten concluir lo siguiente:

● Después de realizar una breve investigación bibliográfica se determina que el uso de

modelos de procesos en la ingeniería de requisitos, ayuda a obtener requisitos pulidos

para ser utilizados en fases posteriores de un proyecto y lograr como resultado un

producto de calidad.

● La comparación entre distintos los modelos revisados en esta investigación

bibliográfica, permiten analizar las características de cada uno de ellos, para

desarrollar un modelo propio que integre las ventajas de los antes mencionados

propuestos por los diversos autores.

● El desarrollo de un nuevo modelo de referencia basado en requisitos de software web,

permite mejorar la fase de análisis dentro del ciclo de vida de un proyecto, debido a la

versión mejorada que integra las ventajas de los tres modelos propuestos en la

investigación, el resultado de los requisitos de software obtenidos son satisfactorios

por parte de los interesados.

● Se evalúa el nuevo modelo de referencia de requisitos de software mediante el

desarrollo del documento de análisis de requisitos basado en la metodología ICONIX,

comprobando la efectividad de cada una de sus fases al momento de definir requisitos

para un sistema

BIBLIOGRAFÍA

[1] J. M. Delgado, C. Giraldo, A. F. Millán, C. Zuñiga y J. Albadía, «Desarrollo de un

software Web y Móvil para la gestión de información de campo de cultivos

agrícolas,» Sistemas & Telemática, vol. 4, nº 8, pp. 113-124, 2006.

[2] J. Molina Rios, M. Valarezo Pardo y M. Zea Ordoñez, Repositorio Digital de la

UTMACH, Machala: Ediciones UTMACH, 2015.

[3] R. Arunava y C. Subhashish , «Web software fault prediction under fuzzy

environment using MODULO-M multivariate overlapping fuzzy clustering algorithm

and newly proposed revised prediction algorithm,» Elsevier, vol. 22, pp. 372-396,

2014.

[4] C. A. De la Cruz Londoño y G. A. Castro Guevara, «La Ingeniería de Requerimientos

en las Pequeñas Empresas del Departamento de Risaralda,» Lampsakos, vol. 0, nº 12,

pp. 110-119, 2014.

[5] J. R. Molina Ríos, J. A. Honores Tapia y M. P. Zea Ordóñez, Nociones de Ingeniería

de Software, Machala: Ediciones UTMACH, 2015.

[6] S. González Viloria, «Sistemas integrados de gestión, un reto para las pequeñas y

medianas empresas,» Escenarios, vol. 9, nº 1, pp. 69-89, 2011.

[7] A. Alarcón y E. Sandoval, «Herramientas Case para Ingeniería de Requisitos,»

Cultura Científica, nº 6, pp. 70-74, 2008.

[8] J. A. Caideco Salazar, H. E. Guerrero Arellano y P. G. Pombar Vallejos, «Sistema de

información web transaccional de control de turnos, asistencia y solicitudes de

novedades de personal,» Dominio de las Ciencias, vol. 3, nº 2, pp. 539-580, 2017.

[9] M. Taranzo, G. Cysneiros y F. Tirado, «Proceso y herramienta para la rastreabilidad

de requisitos,» Ingeniare. Revista Chilena de Ingeniería, vol. 21, nº 2, pp. 218-231,

2013.

[10] J. R. Molina Ríos, N. M. Loja Mora, M. P. Zea Ordoñez y E. L. Loaiza Sojos,

«Evaluación de los Frameworks en el Desarrollo de Aplicaciones Web con Python,»

Resvista Latinoamericana de Ingeniería de Software, vol. 4, nº 4, pp. 201-207, 2016.

[11] P. A. Duarte, S. I. Mariño, P. L. Alfonzo y M. V. Godoy, «Modelo de Proceso

Software Aplicado a la Revisión de la Accesibilidad WEB en Desarrollos Basados en

IDE,» Revista Latinoamericana de Ingeniería de Software, vol. 3, nº 4, pp. 177-182,

2015.

[12] L. Torres Pérez, M. D. Delgado Dapena, D. Rodríguez Nápoles, D. Gómez Suárez, W.

De la Torre Parejo y Y. Alonso Abreu, «Entorno de ingeniería de requisitos aplicado

para producir software en una universidad,» Ingeniería Industrial, vol. 35, nº 1, pp.

45-59, 2014.

[13] S. Q. Consulting, «swqual.com,» 2013. [En línea]. Available:

http://www.swqual.com/verification_validation.html. [Último acceso: 20 06 2017].

[14] K. Olmos Sánchez , J. Rodas Osollo, L. Fernández Martínez y V. Morales Rocha,

«Requirements engineering based on knowledge: a comparative case study of the

KMoS-RE strategy and the DMS process,» Revista Facultad de Ingeniería

Universidad de Antioquia, nº 77, pp. 88-94, 2015.

[15] J. C. Ramirez Leal, W. J. Giraldo Orozco y R. Amaya Hernandez, «UNA

PROPUESTA METODOLÓGICA PARA MEJORAR LA COMUNICACIÓN EN

INGENIERÍA DE REQUISITOS,» Revista EIA, vol. 13, nº 26, pp. 121-139, 2016.

[16] M. A. Chaves, «La ingeniería de requerimientos y su importancia en el desarrollo de

proyectos de software,» InterSedes: Revista de las Sedes Regionales, vol. 5, nº 10, pp.

1-13, 2005.

[17] J. A. Guzmán Luna, C. A. Vélez Carvajal y S. A. Gómez Arias, «Un modelo de

procesamiento de lenguaje natural para la detección de errores en requisitos de

software,» Revista Virtual Universidad Católica del Norte, nº 46, pp. 169-186, 2015.

[18] L. González Palacio y G. Urrego Giraldo, «Modelo de contexto y de dominio para la

ingeniería de requisitos de sistemas ubicuos,» Revista Ingenierías Universidad de

Medellín, vol. 19, nº 17, pp. 151-164, 2010.

[19] D. Carrizo, «Dinámica contextual de la educción de requisitos software,» Revista

Facultad de Ingeniería Universidad de Antioquia, nº 69, pp. 34-52, 2013.

[20] L. F. Londoño, R. Anaya y M. S. Tabares, «ANÁLISIS DE LA INGENIERÍA DE

REQUISITOS ORIENTADA POR ASPECTOS SEGÚN LA INDUSTRIA DEL

SOFTWARE,» Revista EIA, nº 9, pp. 43-52, 2008.

[21] D. Tejera, A. Alejandro y A. d. M. Miguel, «Diseno de un Software de Intermediación

de Comunicación para Sistemas Distribuidos de Tiempo Real Críticos en Java,»

Revista Iberoamericana de Automática e Informática Industrial RIAI, vol. 10, pp.

228-239, 2013.

[22] R. Caldera, I. Castillo y P. Morantes, «EXTENSIÓN DE UML PARA ESCENARIOS

EN LA INGENIERÍA DE REQUISITOS,» Revista Multidisciplinaria del Consejo de

Investigación de la Universidad de Oriente, vol. 18, nº 1, pp. 36-44, 2006.

[23] C. A. Cortés Bravo, M. A. Abud Figueroa y C. Romero Torres, «Propuesta de un

Catálogo de Patrones de Escenario para la Definición de Requisitos,» ReCIBE,

Revista electrónica de computación, informática, biomédica y electrónica, vol. 5, nº 1,

pp. II-II, 2016.

[24] C. M. Zapata, G. L. Giraldo y J. E. Mesa, «UNA PROPUESTA DE

METAONTOLOGÍA PARA LA EDUCCIÓN DE REQUISITOS,» Ingeniare. Revista

Chilena de Ingeniería, vol. 18, nº 1, pp. 26-37, 2010.

[25] A. A. Peña Romero, «Aplicación web complementado con multiagentes para la

gestión de la colocación laboral de egresados universitarios,» Apuntes de Ciencia &

Sociedad, vol. 3, nº 1, pp. 64-70, 2013.

[26] L. Ferrer, «Propuesta de Conceptualización de Requisitos para Proyectos Software

Basados en Formalismos de Ingeniería de Conocimiento,» Revista Latinoamericana

de Ingeniería de Software, vol. 4, nº 5, pp. 216-230, 2016.

[27] N. Romero , «Propuesta de Extensión de UML para Proceso de Conceptualización De

Requisitos,» Revista Latinoamericana de Ingeniería de Software, vol. 4, nº 2, pp.

59-72, 2016.

[28] A. Hossian, «Modelo de Proceso de Conceptualización de Requisitos,» Revista

Latinoamericana de Ingeniería de Software, vol. 1, nº 3, pp. 79-101, 2013.

[29] D. Carrizo y C. Ortiz, «Modelos del proceso de educción de requisitos: Un mapeo

sistemático,» Ingeniería y Desarrollo, vol. 34, nº 1, pp. 184-203, 2016.

[30] B. M. Valle, «Un proceso de ingeniería de requisitos dirigido por modelos centrado en

reutilización.,» 23 Enero 2013. [En línea]. Available:

https://dialnet.unirioja.es/servlet/tesis?codigo=96490. [Último acceso: 20 Junio 2017].

[31] G. Kotonya y I. Sommerville, Requirements engineering: processes and techniques,

Estados Unidos: John Wiley & Sons, 1998.

[32] B. G. González Rodríguez, «monografias.com,» 2010. [En línea]. Available:

http://www.monografias.com/trabajos81/modelo-desarrollo-requisitos-scada/modelo-

desarrollo-requisitos-scada2.shtml. [Último acceso: 25 Junio 2017].

ANEXO A. Matriz de Roles y Actividades del Proyecto Tabla 2. Matriz de Roles y Actividades del proyecto

INTERESADOS FASES DEL MODELO

Ingenieros de

Requisitos

Expertos en Marketing

Usuarios / clientes

Director de Proyecto

Grupo de Calidad

Recolección de Requisitos

X

X

X

Análisis y negociación

X

X

Documentación de

Requisitos

X

X

Validación de Requisitos

X

X

X

Fuente: Elaboración propia

ANEXO B. Formato de Encuesta para Requisitos

ENCUESTA DE LAS NECESIDADES DE CLIENTES AL COMPRAR

PRODUCTOS

Fecha de Encuesta:

Edad de Encuestado:

1. ¿Ud. realiza compras por internet? Si No A veces

2. ¿Qué tipos de productos compra usualmente en internet?

Electrónicos Limpieza Muebles Ropa Otros

3. ¿Cree que es confiable realizar compras en internet? Si No Tal vez

4. ¿Prefiere ver lo que va a comprar? Si No

5. ¿Cuántos productos adquieres en una sola compra? 1 producto De 1 a 2 Más de 2