Ingeniería de Requisitos: de la especificación de requisitos de software al aseguramiento de la calidad. Cómo lo hacen las Mipymes desarrolladoras de software de la ciudad de Pereira1
Requirements Engineering: from software requirements specification to quality assurance. How MSMEs developers of software in Pereira city do it
Engenharia de Requisitos: da especificação de requisitos de software à garantia de qualidade. Como fazem as Mipymes desenvolvedoras de software da cidade de Pereira
A. Toro* y L.E. Peláez**
1 Este artículo es un producto derivado de la tesis doctoral "Modelo de Aseguramiento de Calidad de Requerimientos en Proyectos de Desarrollo de Software para las MiPymes de la ciudad de Pereira", perteneciente a la Línea de Investigación en Ingeniería del Software del Grupo de Investigación e Innovación en Ingenierías GIII, adscrito a la Facultad de Ciencias Básicas e Ingeniería de la Universidad Católica de Pereira.
* A. Toro-Lazo, es docente de tiempo completo de la Universidad Católica de Pereira, Pereira (Colombia); email: alonso.toro@ucp.edu.co.
** L. E. Peláez-Valencia, es docente de tiempo completo de la Universidad Católica de Pereira, Pereira (Colombia); email: luis.pelaez@ucp.edu.co.
Recibido Marzo 15 de 2016 - Aceptado Mayo 30 de 2016
Resumen
]]> El proceso de requisitos es una etapa fundamental en todo proyecto de desarrollo de software pues, junto con la gestión de requisitos, garantizan que el producto desarrollado satisfaga efectivamente las necesidades que realmente tiene el cliente. Para lograrlo, la Ingeniería de Requisitos plantea la ejecución disciplinada de una serie de actividades entre las que adquiere gran relevancia, por su papel en la consecución de la calidad, la especificación o definición de los requisitos. Sin embargo, este es un proceso riguroso, complejo y que requiere de conocimiento muy específico que pocas universidades en el país ofrecen, razón por la cual, en la región se dificulta encontrar profesionales con dominio en esta temática. Entonces, ¿Cómo logran las MiPymes de la industria local del software realizar una adecuada especificación de requisitos?, el presente trabajo pretende hacer un acercamiento a la manera en que las empresas de la ciudad de Pereira manejan el tema de los requisitos, análisis que hace parte de la tesis doctoral titulada "modelo de aseguramiento de calidad para los requerimientos en proyectos de software desarrollados en las MiPymes de la ciudad de Pereira", como aporte a un sector que busca aumentar sus niveles de madurez y calidad.Palabras clave: Ingeniería de Requisitos; Aseguramiento de Calidad de Requerimientos; calidad de software; proyectos de software.
Abstract
The development of requirements is a fundamental step in any software development project because, along with requirements management, ensures that the product developed effectively meets the needs that the customer really has. To achieve this, the Requirements Engineering raises the disciplined execution of a series of activities, among which is highly significant for its role in achieving quality, specification or definition of the requirements. However, this is a complex and rigorous process, and requires very specific knowledge that few universities in the country offer, so that, it is difficult to find qualified professionals for this specific domain in the region. So, ¿how can the local software industry (MSME) offer an appropriate specification requirements?, this article aims to make an approach to the way companies located in the city of Pereira face the topic about requirements; the analysis makes part of an ongoing research project that aims to "develop a procedure to specify and validate software requirements based on previous studies in the region", as a contribution to a sector that seeks to increase its levels of maturity and quality.
Key words: Requirements Engineering, Requirements Quality Assurance, software quality, software projects.
Resumo
O processo de requisitos é uma etapa fundamental em todo projeto de desenvolvimento de software, pois, junto com a gestão de requisitos, garantem que o produto desenvolvido satisfaça efetivamente as necessidades que o cliente realmente tenha. Para alcança-lo a Engenharia de Requisitos elabora e propõe a execução disciplinada de uma serie de atividades entra as que adquire grande relevância, por seu papel na consecução de qualidade, a especificação ou definição dos requisitos. Entretanto este é um processo rigoroso, complexo e que requer conhecimento muito especifico que poucas universidades no país oferecem, razão pela qual, na região se dificulta encontrar profissionais com domínio nesta temática. Então, Como logram as MiPymes da indústria local de software realizar uma adequada especificação de requisitos? O presente trabalho pretende fazer uma aproximação à maneira em que as empresas da cidade de Pereira manejam o tema de requisitos, análise que faz parte da tese doutoral titulada "modelo de garantia de qualidade para os requerimentos em projetos e software desenvolvido nas MiPymes da cidade de Pereira", como aporte a um setor que busca aumentar seus níveis de maturidade e qualidade.
Palavras chave: Engenharia de Requisitos; Garantia de qualidade de Requerimentos, qualidade software; projetos de software.
I. INTRODUCCIÓN
La tesis doctoral tiene el propósito de concluir en un modelo para el aseguramiento de la calidad de los requerimientos en proyectos de software. Previo al modelo, se hace necesario explorar el estado de la cuestión, reconocer los antecedentes, documentar en detalle el marco teórico y a partir de estos elementos, considerar la formulación del modelo propuesto. Como parte de la exploración del estado del arte, se ha detectado un alto nivel de desarrollo en temas relacionados con la especificación, educción, sistematización y validación de requisitos (tratados por otros autores de manera análoga como requerimientos). El presente trabajo dará cuenta de la exploración en esta especificidad.
]]> Los requisitos son, por definición "una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo" [1] y, en la línea de [2] "expresan las necesidades y limitaciones impuestas a un producto de software que contribuyen a la solución de algún problema en el mundo real".Sin embargo, buena parte de los problemas que surgen, a lo largo del proceso de desarrollo, se deben a la carencia de un proceso adecuado de definición y entendimiento del problema y a la definición poco clara de las necesidades del cliente [3]. Es allí donde cobra relevancia el tema, pues según [4], la Ingeniería de Requisitos es tratada como una disciplina que tiene por propósito "desarrollar una especificación de requerimientos 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".
Pese a esto, los requisitos incompletos siguen siendo uno de los principales factores de fracaso de los proyectos software [5], como se muestra en la fig 1.
También se reconoce en [6] que el 56% del total de errores encontrados en los productos software son generados en la fase de Requisitos y el porcentaje total del esfuerzo del proyecto que se destina en esta fase no llega al 20%, independientemente del modelo de desarrollo (iterativo, en cascada, etc.) o del tipo de proyecto (nuevo, o de mantenimiento) [7].
Para hacer frente a dichas causas de fracaso generalmente se aplican procesos de mejoramiento de desarrollo de software e iniciativas aceptadas internacionalmente, por ejemplo: CMMI, SPICE y PSP/TSP [8] y [9]. Sin embargo, la implementación de estas iniciativas en micro y pequeñas empresas implica mayor complejidad, mayor cantidad de prácticas, rigidez y costos, como lo expresan [10] y [11], y son ajenas a condiciones y/o características propias de la organización como lo indica [12] y lo confirma [13].
II. EL ESTADO ACTUAL
De manera general, "no existe un instrumento que sugiera un proceso de Desarrollo de Software con base en características de la organización y en buenas prácticas, sobre el cual la organización pueda iniciar su proceso de mejoramiento" [14]. Sumado a esto, autores como [15] identifican que los siguientes son los principales inconvenientes que presentan las pequeñas empresas de la región al trabajar con los requisitos:
En el caso de Colombia, según estudios de la Asociación Colombiana de Ingenieros de Sistemas (ACIS) [14], en la industria del software cerca del 70% de los proyectos no son exitosos, siendo uno de los principales problemas la ejecución de los procesos relacionados con la ingeniería de requisitos.
Entre sus causas más frecuentes esta la falta de comprensión de los requisitos iniciales y la inhabilidad para gestionar los cambios durante el desarrollo del mismo, factores que, seguramente se podrían evitar al hacer uso de las buenas prácticas propuestas por la Ingeniería de Requisitos, como las mencionadas en [16].
Entonces, si se entiende, como lo expresa [17] que "el fundamento básico de cualquier software recae sobre su proceso de ingeniería de requisitos"; que el éxito o fallo del software depende casi siempre de qué tan bien se hayan capturado, entendido y usado los requisitos como base para el desarrollo; y que la Ingeniería de Requisitos es la fase de un proyecto software donde se definen las propiedades y la estructura del mismo, comprendiendo a la vez el desarrollo y gestión de requisitos… ¿por qué entonces este proceso tan importante se realiza de manera inadecuada y en muchos casos incompleta?, la razón a primera vista resulta ser simple: no hay profesionales especializados en ingeniería de requisitos que suplan las estas necesidades en la industria colombiana.
]]> Lo anterior se debe a la desconexión que se presenta entre la academia y el sector real, distancia que ha llevado a que, mientras el sector software requiere profesionales especializados en cada área de los procesos de gestión y desarrollo, como en este caso: ingeniero de requisitos; el sector de la educación superior sigue formando profesionales muy genéricos con conocimientos superficiales de muchos temas, pero ninguno especializado [18].Se encuentra entonces debido a esta situación, que en las empresas desarrolladoras el tratamiento de los requisitos es precario, cosa que algunas veces imposibilita ver el alcance real del proyecto y no se realiza el modelado del negocio antes de desarrollar el software; el equipo desarrollador o analista no se involucran en el problema y aunque se tiene claro que el sistema debe desarrollarse para dar soporte a los procesos de la organización, si el equipo no se involucra en la problemática se corre el riesgo de que los requisitos identificados no correspondan a las necesidades para lo que se debe crear [19].
En resumen, un gran número de las empresas de la región, a pesar de conocer la importancia de la ingeniería de requisitos y de la importancia que tiene para ella el desarrollo de una buena especificación, esto es: completa, consistente, modificable y trazable [20]; optan por hacer de forma empírica esta actividad, como lo menciona [15] "la comunicación con los usuarios es un aspecto prioritario para las empresas que desarrollan sistemas software; aun así confían más en la experiencia acumulada que no en la aplicación de métodos pensados para capturar la experiencia de los usuarios y sus verdaderas necesidades".
Finalmente, existe una gran tendencia a emplear diversos formatos, plantillas y herramientas, muchas de ellas propias, que ayudan a superar, al menos de una forma superficial esta etapa del proyecto software. Sin embargo, en la mayoría de los casos, las mismas no están basadas en técnicas estandarizadas o ampliamente reconocidas para el tratamiento de los requisitos como diagramas de flujo de datos (DFD), casos de uso, historias de usuario, prototipos o especificación en lenguaje formal. En su lugar, se hace uso de especificaciones realizadas en lenguaje natural no estructurado, sin mucho conocimiento y nivel de dominio del mismo, sino más bien tratando de aplicar sentido común y entender las necesidades del cliente en su lenguaje, lo cual, generalmente, se presta para malas interpretaciones.
Según [21], "se considera lenguaje natural al lenguaje utilizado a diario entre los integrantes de la organización. Se caracteriza por estar orientado a una descripción más humana y generalizada, y no regido por consideraciones técnicas específicas."
En [22] por ejemplo, menciona que existe una gran variedad de técnicas y herramientas utilizadas en las diferentes fases de dicho proceso, como se puede notar en la siguiente tabla:
Con la intensión de no dejar de lado las metodologías ágiles, muy posiblemente utilizadas por las Mipymes desarrolladoras de software, se incluye también en el estudio algunos aspectos de Agile Modeling [23] y Lean Software Development [24], metodologías seleccionadas como representativas de los procesos ágiles, pues son quizá las que tienen mayores elementos para la especificación y validación de requisitos de software.
De la primera se destaca que, para lograr los modelos y documentos relacionados con los requisitos, propone el uso de las siguientes técnicas y artefactos durante las diferentes etapas del proceso:
De la segunda, se destaca que su enfoque ágil asume que los requisitos no pueden ser establecidos con seguridad desde el comienzo del proyecto y se acepta el cambio como algo inevitable y cuestiones como el plazo y el coste se pueden establecer antes del alcance, pues se persigue la puesta a disposición del cliente cada cierto tiempo y dentro de un coste de un determinado conjunto de requisitos (los de mayor prioridad). De esta forma, el cliente puede saber cuándo obtendrá un conjunto de requisitos y el proveedor los recursos de los que dispone para producirlos. Las decisiones se toman en torno a la prioridad de los requisitos y el rol del proveedor será asegurar el flujo constante de producto según esta prioridad. Además, parte del conjunto de requisitos no abordados, por tener menor prioridad y no estar en el alcance de la iteración, a menudo acaban considerándose innecesarios. El producto obtenido con este enfoque es más acorde a la filosofía "Lean" [24].
]]> III. ESTRATEGIA METODOLÓGICA Y RESULTADOS PREVIOSCon la intensión de determinar la manera en la que las Mipymes desarrolladoras de software de la ciudad de Pereira llevan a cabo la especificación y validación de requisitos de software, se realiza una investigación del corte cualitativo que consiste en una exploración respecto a la especificación de requisitos, teniendo en cuenta, de un lado, el estado del arte y del otro una descripción y una caracterización de una muestra por conveniencia representativa de una población (empresas desarrolladoras de software de la ciudad de Pereira).
El levantamiento del estado del arte de los requisitos de software se realizó mediante la búsqueda en diferentes fuentes de información como repositorios institucionales, bases de datos especializadas y bibliografía física de las diferentes bibliotecas de la región, con el propósito de consolidar un referente contextual que comprendiera una descripción del área problemática y una revisión de antecedentes, conocido también como el estado del arte de la investigación. Esta última, está desagregada desde el ámbito regional, nacional e internacional y se consolida con un marco teórico en el que se detallan las diferentes teorías y conceptos relacionados con el proceso de desarrollo de los requisitos de software y en especial, de la especificación y validación de los mismos. Como instrumentos para la recolección e identificación de los antecedentes tanto del orden regional, como nacional e internacional se usaron tablas como las siguientes, que permitieran describir de manera concreta la información relevante de los mismos:
Para la descripción y caracterización de la forma en que las MiPymes desarrolladoras de software de la ciudad de Pereira llevan a cabo la especificación de requisitos de software, y en el contexto del proyecto de investigación [25], se realizan encuentros con los empresarios del software de la ciudad de Pereira y las empresas que hacen parte del modelo de emprendimiento de Parquesoft Pereira. Las empresas participantes fueron seleccionadas de acuerdo a los siguientes criterios:
La encuesta que consta de 35 preguntas estuvo conformada por tres conjuntos de preguntas: uno relacionado con características generales del grupo de desarrollo y de los proyectos que llevan a cabo, otro relacionado con las técnicas de adquisición y especificación de requisitos usadas actualmente y un último conjunto de preguntas relacionado con los errores o dificultadas encontradas con la forma actual de especificar los requisitos. Con los resultados obtenidos a partir de la encuesta, se realizó un análisis de fiabilidad para determinar la correlación interna entre los ítems de la misma.
Como resultado del levantamiento de la información se obtuvo principalmente conocimiento:
Una vez realizado el análisis de las técnicas que, según el resultado de las encuestas, usan las MiPymes desarrolladoras de software de la ciudad de Pereira, de acuerdo a la muestra, se encuentra que la mayoría de las técnicas son conocidas y en varios casos utilizadas para llevar a cabo los procesos de especificación y validación de requisitos de software. Sin embargo, se nota claramente que el promedio de uso de las técnicas de especificación conocidas, tales como Diagramas de casos de uso, Historias de usuario o Prototipos es bajo, pues alcanza solo un 23,5%. La fig. 5 muestra un resumen de las técnicas más usadas por las empresas.
Con respecto a las técnicas para la validación de requisitos se encuentra que son usadas en un 42,5% de las empresas y corresponden principalmente a Prototipos, Walkthroughs o recorridos y algunos Formatos propios. La fig. 6 hace alusión a dichos resultados.
]]>
Lo anterior permite inferir que es necesario motivar la implementación de estas técnicas para facilitar el desarrollo de los requisitos y contribuir a la calidad de los mismos.
IV. TENDENCIAS Y TRABAJO FUTURO
Teniendo en cuenta que 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" [2].
Es notorio que la especificación, según el proceso iterativo propuesto por [20] 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.
El documento resultante en esta etapa conjuga entonces todos los aspectos necesarios, que, relacionados entre sí, proveen de forma transparente y clara las necesidades del cliente, como también la información necesaria para que el desarrollador del sistema entienda de forma correcta y exacta qué es lo que se debe realizar. Además, la especificación de requisitos es la fuente de lectura primaria donde todos los involucrados en el proyecto pueden conocer el alcance del mismo, en síntesis, es el acuerdo formal entre el cliente y el equipo desarrollador del sistema donde las necesidades del usuario son entendidas y donde se plantea una posible solución. Por tal razón un documento de especificación de requisitos influye en gran medida en la calidad del producto esperado.
Considerando lo anterior y, de acuerdo a las fuentes antes citadas en las que se recalca que existen grandes dificultades respecto a la calidad del software, se puede inferir la necesidad que tiene la industria de disponer de nuevas propuestas que contribuyan al mejoramiento de la calidad a través del proceso de requisitos, teniendo en cuenta el impacto que ellos generan en el éxito de los proyectos software.
Así mismo, ayudaría a suplir esta necesidad la existencia de procesos, procedimientos y/o lineamientos que permitan llevar a cabo la especificación y validación de requisitos en un proyecto software a cargo de las MiPymes desarrolladoras de software de manera sencilla, que no requieran de personas expertas en el área de requisitos al momento de su aplicación ni tampoco la necesidad de contar con conocimiento específico en lenguajes formales para especificar requisitos de software.
De igual forma, los nuevos instrumentos deberían suministrar en detalle las actividades que lo comprenden, con la ayuda de guías explícitas para llevarlas a cabo, de tal manera que las MiPymes desarrolladoras de software lo puedan apropiar fácilmente.
Se propone además dar continuidad a proyectos de investigación desarrollados en la región, de tal manera que se logre su actualización y validación para que las empresas del sector se apropien del conocimiento ya logrado.
]]> En la misma línea, se debe propiciar una mayor articulación entre la tirada universidad, empresa, estado, de tal manera que se favorezcan los procesos de formación de talento humano especializado, en áreas específicas de desarrollo de software, en este caso en ingenieros de requisitos con habilidades para desarrollar especificaciones bien elaboradas.V. CONCLUSIONES
Respecto a los avances logrados en los trabajos que hicieron parte del estado de la cuestión, y propuestos como futuras líneas de investigación, es necesario destacar que las MiPymes de la ciudad de Pereira requieren adoptar mejores prácticas en todas las fases del proceso de desarrollo, de tal manera que éstas puedan redundar en un producto software de más y mejor calidad; con el fin de que sus clientes directos, locales la mayoría, aumenten el nivel de satisfacción frente a los entregables comprometidos y ellas mismas aumenten sus expectativas de competitividad a nivel regional y nacional, a medida que vayan logrando mejores productos con procesos de distribución menos dependientes de soporte y mantenimiento in situ.
Un gran porcentaje de los proyectos de software que fracasan, es atribuible a un deficiente tratamiento de los requisitos del mismo. Para evitarlo, 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" [26], lo cual, contribuye en gran medida al aseguramiento de la calidad del producto.
Además de lo anterior, un factor determinante para la industria del software, y respecto a la gestión de requisitos, es que muchos de los proyectos que se emprenden están en manos de organizaciones unipersonales o Mipymes; organizaciones que en su mayoría evitan seguir estándares o metodologías aceptadas mundialmente, llevando entonces la definición de requisitos a su mínima expresión y engordando así las estadísticas de proyectos fracasados.
La especificación de requisitos o SRS2 que hace parte de la Ingeniería de Requisitos, es entendida comúnmente como parte de la documentación de un proyecto de software. Es importante resaltar que dicho documento no solo permitirá plasmar las necesidades del cliente respecto al sistema a desarrollar, sino que también hará posible el hecho de llevar a cabo una adecuada gestión de los mismos.
La SRS establece las funciones y capacidades que un sistema de software debe proporcionar, sus características y las limitaciones que debe respetar. Debe describir de formas tan completas como sean necesarias, los comportamientos del sistema en distintas condiciones, así como las cualidades del sistema deseadas, tales como el rendimiento, la seguridad y facilidad de uso. Así, la SRS es la base para la planificación, diseño y codificación del proyecto, como también para las pruebas del sistema y la documentación del usuario.
Existen diversos enfoques, técnicas y herramientas que apoyan la elaboración del documento de especificación de requisitos y que además son conocidas por las empresas desarrolladoras de software de la ciudad de Pereira. Sin embargo, no son regularmente aplicadas, lo cual, sumado a la falta de talento humano especializado en esta área, en gran medida atribuible al conocimiento genérico que forman las universidades en los profesionales del sector TI; hace que éstos documentos queden incompletos o con un insuficiente nivel de detalle, ocasionando el desarrollo de un producto que difiere en gran medida de aquel que el cliente realmente necesitaba o había solicitado.
El lenguaje natural estructurado es una forma de redactar los requisitos del sistema donde la libertad del redactor de los mismos está li mitada y donde todos los requisitos se redactan de una forma estándar. La ventaja de este enfoque es que mantiene la mayor parte de la expresividad y comprensión del lenguaje natural, pero asegura que se imponga cierto grado de uniformidad en la especificación [21]. La dificultad con esta manera de documentar las necesidades es que, generalmente, tampoco se tiene un adecuado dominio ni del problema, ni de la técnica.
Por otro lado, siendo tal vez la generalidad en las empresas Mipymes de la ciudad de Pereira la utilización de un enfoque basado en formularios para especificar los requisitos del sistema, esto requiere definir formatos o plantillas específicas que sirvan como estándar para expresar los requisitos. En muchas ocasiones se ve más como un formalismo que como un instrumento que realmente ayuda a comprender las necesidades del sistema.
]]> Es importante también mencionar, que, para la especificación de requisitos de software en proyectos ágiles, los equipos podrían comenzar la especificación escribiendo la información suficiente para cada historia de usuario, de modo que las partes interesadas tengan una comprensión general de lo que trata la historia y así puedan priorizar su relación con otras historias. Esto permite al equipo planificar la asignación de historias de usuario específicas a las iteraciones [20].Dado el sentido de los presentes resultados, en el contexto de una tesis doctoral que se apoya en estudios que justifican la elaboración de un modelo de aseguramiento de calidad de requerimientos en proyectos de software, se ha logrado evidenciar que "el desarrollo de software ha sido abordado incorrectamente por la industria local; en gran proporción por la dificultad que se presenta al momento de adoptar y apropiar modelos diseñados para el aseguramiento de la calidad en un proyecto de software. Lo anterior, redundando en productos de baja calidad y en niveles mínimos de satisfacción por parte del cliente.
Finalmente, y no con menor prioridad, se considera importante que los profesionales no se queden con el enfoque genérico que brindan a las carreras relacionadas con software, sino que se especialicen en las áreas específicas que requiere la industria. De igual forma, las empresas deben propiciar mejores escenarios de articulación con la academia, para retroalimentar el proceso de formación, investigación y proyección social de manera más cercana a sus necesidades.
NOTAS
2 SRS hace referencia a la Especificación de Requisitos de Software.
REFERENCIAS
[1] IEEE, «IEEE Software Engineering Standard: Glossary of Software Engineering Terminology,» 1993. [En línea]. Available: http://dis.unal.edu.co/~icasta/GGP/_Ver_2012_1/Documentos/Normas/610-12-1990.pdf. [ Links ]
[2] IEEE, SWEBOK Guide V3.0, Piscataway: IEEE, 2014. [ Links ]
]]>[3] L. F. Londoño, R. Anaya y M. Silva, «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. [ Links ]
[4] B. Boehm, Software Engineering Economics, New Jersey: Prentice Hall, 1981. [ Links ]
[5] M. Cristiá, «Introducción a la Ingeniería de Requerimientos,» 2011. [En línea]. Available: http://www.fceia.unr.edu.ar/~mcristia/publicaciones/ingreq-a.pdf. [ Links ]
[6] R. M. Torres de Paz, «Departamento de Lenguajes y Sistemas Informáticos Universidad de Sevilla,» 2009. [En línea]. Available: http://www.lsi.us.es/docs/doctorado/memorias/memo-inv-rosa-mtorres.pdf. [ Links ]
[7] Y. Yang, M. He, M. Li, Q. Wang y B. Barry, «Phase distribution of software,» ACM, pp. 61-69, 2008. [ Links ]
]]>[8] L. E. Peláez Valencia, A. Toro Lazo y L. Cardona Benjumea, «Estado del arte que soporta el proceso de desarrollo de software en las pymes colombianas: una mirada desde las organizaciones nacionales que tienen que ver con la disciplina,» Entre Ciencia e Ingeniería, vol. 5, nº 10, pp. 93-107, 2012. [ Links ]
[9] L. E. Peláez Valencia, A. Toro Lazo y L. Cardona Benjumea, «Relación entre la carta del proyecto del PMBOK (PMI) y SQA,» Ventana Informática, nº 29, pp. 63-79, 2013. [ Links ]
[10] R. Casallas, «Algunos mitos y desafíos de la Ingeniería de Software,» Revista Sistemas ACIS, pp. 8-17, 2007. [ Links ]
[11] H. Arboleda y R. Casallas, «QualDev Process: Procesos Adaptables de Desarrollo de Software para Proyectos Ágiles,» Journal INGENIERIA Y COMPETITIVIDAD - Facultad de Ingeniería, Universidad del Valle, vol. 6, nº 2, pp. 64-74, 2004. [ Links ]
[12] 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. [ Links ]
]]>[13] C. Laporte, Contributions to Software Engineering and to the Development and Deployment of International Software Engineering Standards for Very small Entities, Brest: UNIVERSITÉ DE BRETAGNE OCCIDENTALE, 2010. [ Links ]
[14] A. Varela Galvis y G. E. Arango Sterling, «INSTRUMENTO PARA LA GENERACIÓN DEL PROCESO DE DESARROLLO DE REQUERIMIENTOS DE SOFTWARE PARA MICRO Y PEQUEÑAS EMPRESAS (tesis de maestría),» 2012. [En línea]. Available: http://bibliotecadigital.icesi.edu.co/biblioteca_digital/bitstream/10906/70626/1/instrumento_generacion_proceso.pdf. [ Links ]
[15] 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,» Lámpsakos, nº 12, pp. 110, 2014. [ Links ]
[16] L. E. Peláez Valencia, A. Toro Lazo y L. Cardona Benjumea, «La relación existente entre la calidad del software y el uso de modelos internacionales vs el uso de modelos autóctonos: el caso de las pymes en el eje cafetero -Colombia-., » Informática 2013, vol. 1, nº 1, 2013. [ Links ]
[17] INTECO, «Guía práctica de gestión de requisitos,» 2008. [En línea]. Available: https://www.inteco.es/file/NRDmviQoTbI_jZcyjTYRlw. [ Links ]
]]>[18] L. E. Peláez Valencia y A. Toro Lazo, «Ingeniería de Software. Formación en pregrado con identidad más específica que Ingeniería de Sistemas,» 2016. [ Links ]
[19] Red colaborativa postgrados UCV, «Los Requerimientos y su importancia en el desarrollo del Software,» 2012. [En línea]. Available: http://kuainasi.ciens.ucv.ve/red_educativa/blogs/20?language_id=1. [ Links ]
[20] K. Wiegers y J. Beaty, Software Requierements, Third Edition ed., Redmon, Washington: Microsoft Press, 2013. [ Links ]
[21] A. N. Camacho Zambrano, «Herramienta para el análisis de requerimientos dentro de la pequeña empresa desarrolladora de software en Bogota,» Bogota, 2005. [ Links ]
[22] N. D. Dávila, «Ingeniería de requerimientos: Una guía para extraer, analizar, especificar y validar los requerimientos de un proyecto,» Montevideo, 2001. [ Links ]
]]>[23] A. Burgos Pintos y S. M. Garbarino de la Rosa, «Agile modeling,» 2010. [En línea]. Available: http://osl2.uca.es/wikiCE/index.php/Agile_modeling. [ Links ]
[24] P. Letelier Torres y E. A. Sánchez López, «Metodologías Ágiles en el Desarrollo de Software,» Ciencia y Técnica Administrativa, vol. 5, nº 26, pp. 1-7, 2006. [ Links ]
[25] J. G. Gálvez y A. Toro Lazo «Procedimiento para especificar y validar requisitos de software en MiPymes desarrolladoras de software, basado en estudios previos en la región,» Informe parcial, Universidad Autónoma de Manizales. [ Links ]
[26] R. S. Pressman, Ingeniería del software, un enfoque práctico, Sexta edición ed., Madrid: McGraw-Hill, 2006. [ Links ]
Alonso Toro Lazo. Ingeniero de Sistemas y Telecomunicaciones, 2010 de la Universidad Católica de Pereira, Risaralda, Colombia. Estudiante de Maestría en Gestión y Desarrollo de Proyectos de Software de la Universidad Autónoma de Manizales, Caldas Colombia. Actualmente docente del programa de Ingeniería de Sistemas y Telecomunicaciones, de la Facultad de Ciencias Básicas e Ingeniería en la Universidad Católica de Pereira UCP, Pereira, Risaralda, pertenece al grupo de Investigación e Innovación en Ingeniería (GIII) de la Universidad Católica de Pereira.
Luis Eduardo Peláez Valencia. Ingeniero de Sistemas, Especialista en Propiedad intelectual, Magister en Ingeniería de Software, Master en Gestión y Desarrollo de Proyectos de Software, Doctor (c) en Proyectos. Actualmente Profesor Asociado del programa de Ingeniería de Sistemas y Telecomunicaciones, de la Facultad de Ciencias Básicas e Ingeniería en la Universidad Católica de Pereira UCP, Pereira, Risaralda, pertenece al grupo de Investigación e Innovación en Ingeniería (GIII) de la Universidad Católica de Pereira en calidad de Investigador Asociado.
]]>
