Diseño de un Procedimiento para Identificación de Requerimientos en la Construcción de Software Formulado Desde la Metodología de Sistemas Suaves

Texto completo

(1)DISE ÑO DE UN PROCEDIMIENTO PARA IDENTIFICACI ÓN DE REQUERIMIENTOS EN LA CONSTRUCCI ÓN DE SOFTWARE FORMULADO DESDE LA METODOLOG ÍA DE SISTEMAS SUAVES.. Presentado por: Luisa Fernanda Gomez Muñoz 20171099009 [email protected] John Jairo Moreno 20171099013 [email protected] Grupo 1. Proyecto de grado para optar al tı́tulo de Especialistas en Ingenierı́a de Software. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS BOGOTA 2017.

(2) DISE ÑO DE UN PROCEDIMIENTO PARA IDENTIFICACI ÓN DE REQUERIMIENTOS EN LA CONSTRUCCI ÓN DE SOFTWARE FORMULADO DESDE LA METODOLOG ÍA DE SISTEMAS SUAVES.. Presentado por: Luisa Fernanda Gomez Muñoz 20171099009 [email protected] John Jairo Moreno 20171099013 [email protected] Director: Sandro Javier Bolaños Castro Revisor: Sandra Milena Cortés Muñoz. Proyecto de grado para optar al tı́tulo de Especialistas en Ingenierı́a de Software. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS BOGOTA 2017.

(3) AGRADECIMIENTOS Agradecemos al Ingeniero Sandro Javier Bolaños Castro y la Ingeniera Sandra Milena Cortes Muñoz que con gran profesionalismo asesoraron nuestro proyecto de investigación. A los compañeros de especialización y amigos que nos retroalimentaron y participaron de alguna manera en nuestro proyecto. Un especial agradecimiento a la Universidad Distrital Francisco José de Caldas Facultad de Ingenierı́a, institución donde realizamos nuestros estudios de postgrado y adquirimos el conocimiento para llevar a cabo este proyecto.. I.

(4) INTRODUCCIÓN Uno de los principales problemas en los proyectos de desarrollo de software es la falta de comprensión parcial o total de los requerimientos. En esta etapa el cliente y el desarrollador juegan un papel muy importante, ya que el primero describe su necesidad y el otro debe entenderla para dar la solución técnica más adecuada. La especificación de requerimientos tiene un alto grado de complejidad y en muchos casos ha sido el factor que más influye en el fracaso de los proyectos de software (Hastie S. and Wojewoda S., 2015), por esta razón se han desarrollado metodologı́as para facilitar la identificación de los requisitos. La metodologı́a de sistemas suaves, en adelante MSS, surgió como una alternativa para entender y describir los problemas existentes en los sistemas socioculturales; fue formulada por un equipo de investigadores de la Universidad de Lanchaster constituido al final de los años 60. El presente proyecto pretende aplicar la MSS en el estudio de las caracterı́sticas propias del procedimiento de identificación de requerimientos como etapa fundamental en la construcción de software, con el fin de incorporar al análisis el componente social que define a los actores que intervienen en el proceso. Esta investigación nace de la necesidad de disminuir los fallos en la implementación de sistemas de información que son evidenciados en la literatura y el quehacer diario de los autores. En el primer capı́tulo 1 se establece el contexto de la investigación, se realiza una descripción de la metodologı́a de sistemas suaves y la ingenierı́a de requerimientos, por último se presenta un primer acercamiento de la situación problema que se pretende analizar. En 2 se avanza con el diseño y explicación de las herramientas necesarias para recopilar la información que sirve como insumo para el desarrollo de la investigación, el cual es descrito en 3. Las secciones de este capı́tulo corresponden con las fases de la metodologı́a de sistemas suaves: En primera instancia se presenta II.

(5) la situación problema no estructurada 3.1, tras la aplicación de la encuesta, los resultados obtenidos se presentan en forma de situcación problema expresada 3.2. A partir de la información anterior se crean las definiciones raı́z, los sistemas de actividad humana correspondientes y modelos conceptuales en 3.3, para luego ser comparados con la situación problema real en 3.4. Esta comparación da lugar a un conjunto de cambios deseables identificados en 3.5. Por último, en 4 se muestran los resultados obtenidos y conclusiones finales del trabajo. Haciendo uso de los cambios emergentes se construye el diseño del procedimiento propuesto y es presentado en 4.1.. III.

(6) Índice general AGRADECIMIENTOS . . . . . . . . . . . . . . . . . . . . . . . . . . INTRODUCCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . .. I II. 1. CONCEPTUALIZACIÓN 6 1.1. Metodologı́a de Sistemas Suaves . . . . . . . . . . . . . . . . . . 6 1.2. Ingenierı́a de requerimientos . . . . . . . . . . . . . . . . . . . . 7 1.3. Situación problemática a abordar . . . . . . . . . . . . . . . . . . 13 2. DISEÑO DE LA INVESTIGACIÓN 15 2.1. Diseño de la encuesta para obtención de datos . . . . . . . . . . . 15 3. DESARROLLO DE LA INVESTIGACIÓN 3.1. Situación de problema no estructurada . . . . . . . . . 3.2. Situación de problema expresada . . . . . . . . . . . . 3.2.1. Resultados de la fase . . . . . . . . . . . . . . 3.3. Definiciones Raı́z y Sistemas de Actividad Humana . . 3.4. Comparación de modelos conceptuales con la realidad 3.5. Identificación de cambios factibles y deseables . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 18 18 22 42 44 56 63. 4. RESULTADOS Y CONCLUSIONES 4.1. Propuesta de procedimiento de elicitación de requerimientos 4.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1. Sobre la metodologı́a aplicada . . . . . . . . . . . . 4.2.2. Sobre los datos recopilados . . . . . . . . . . . . . . 4.2.3. Sobre el procedimiento analizado y propuesto . . . . 4.3. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . .. . . . . . .. 65 65 72 72 73 73 75. 1. . . . . . .. . . . . . ..

(7) Índice de figuras 1.1. La metodologı́a de Checkland. Fuente:(Checkland, 1981) . . . . . 1.2. Ciclo Experiencia - Acción. Fuente: (Checkland P. and Scholes J., 1994) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7 7. 2.1. Fórmula para cálculo del Tamaño de la Muestra. Fuente:(A. Martı́nez et al., 2004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. 3.2. 3.3. 3.4. 3.5.. Diseño Encuesta, parte 1. Fuente:Elaboración propia . . . . . . . 20 Diseño Encuesta, parte 2. Fuente:Elaboración propia . . . . . . . 20 Tamaño de Muestra por Rol. Fuente:Elaboración propia . . . . . . 22 Analista:Tipos de organizaciones. Fuente:Elaboración propia . . . 23 Analista:Técnicas de levantamiento de requerimientos. Fuente:Elaboración propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.6. Analista:Modelos de prototipo. Fuente:Elaboración propia . . . . 24 3.7. Analista:Caracteristicas levantamiento de requerimientos. Fuente:Elaboración propia . . . . . . . . . . . . . . . . . . . . . . . . 25 3.8. Analista:Duración del proyecto. Fuente:Elaboración propia . . . . 26 3.9. Analista:Duración real del proyecto. Fuente:Elaboración propia . . 26 3.10. Analista:Cumplimiento de las espectativas. Fuente:Elaboración propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.11. Analista: caracteristicas involucrados en el proyecto. Fuente:Elaboración propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.12. Analista: Madurez equipo de trabajo. Fuente:Elaboración propia . 28 3.13. Programador:Tipos de Organización. Fuente:Elaboración propia . 30 3.14. Programador:Tipos de Técnicas de Elicitación. Fuente:Elaboración propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.15. Programador:Modelos de Prototipado. Fuente:Elaboración propia 31 3.16. Programador:Calificación de las caracterı́sticas de los requerimientos. Fuente:Elaboración propia . . . . . . . . . . . . . . . . . . . 32 2.

(8) 3.17. Programador:Cumplimiento de las Expectativas del Cliente. Fuente:Elaboración propia . . . . . . . . . . . . . . . . . . . . . . . . 32 3.18. Lı́der o PM: Tipo de Organización. Fuente:Elaboración propia . . 34 3.19. Lı́der o PM: Tipo de Técnicas. Fuente:Elaboración propia . . . . . 34 3.20. Lı́der o PM: Ciclos de Desarrollo. Fuente:Elaboración propia . . . 35 3.21. Lı́der o PM: Modelos de Prototipado. Fuente:Elaboración propia . 35 3.22. Lı́der o PM: Calificación de las caracterı́sticas de requerimientos. Fuente:Elaboración propia . . . . . . . . . . . . . . . . . . . . . 36 3.23. Lı́der o PM: Cumplimiento de expectativas del cliente. Fuente:Elaboración propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.24. Usuario:Tipo de organizaciones . Fuente:Elaboración propia . . . 38 3.25. Usuario:Tecnicas de levantamiento de información . Fuente:Elaboración propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.26. Usuario:Caracteristicas de los proyectos . Fuente:Elaboración propia 39 3.27. Usuario:Duración de los proyectos . Fuente:Elaboración propia . . 40 3.28. Usuario:Cumplimiento de las expectativas . Fuente:Elaboración propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.29. Sistema de Actividad Humana para el desarrollo de software usando prototipos. Fuente: Elaboración propia . . . . . . . . . . . . . 46 3.30. Sistema de Actividad Humana para comunicar los requerimientos eficazmente. Fuente: Elaboración propia . . . . . . . . . . . . . . 48 3.31. Sistema de actividad humana para proponer requerimientos alineados con los objetivos empresariales. Fuente: Elaboración propia 50 3.32. Sistema de actividad humana para involucrar a los usuarios finales en el desarrollo del proyecto. Fuente: Elaboración propia . . . . . 51 3.33. Sistema de actividad humana para realizar pruebas de concepto. Fuente: Elaboración propia . . . . . . . . . . . . . . . . . . . . . 52 3.34. Sistema de actividad humana para involucrar a los stakeholders . . 53 3.35. Sistema de actividad humana para desarrollar software usando interfaces y flujos de la solución . . . . . . . . . . . . . . . . . . . 54 3.36. Sistema de actividad humana para obtener información sobre el alcance antes de iniciar el proyecto . . . . . . . . . . . . . . . . . 55 3.37. Comparación SHA para el desarrollo de software usando prototipos. Fuente: Este trabajo . . . . . . . . . . . . . . . . . . . . . . 57 3.38. SAH para comunicar requerimientos. Fuente: Elaboración propia . 58 3.39. Modelo conceptual del proceso de ingenierı́a de requerimientos. Elaborado a partir de 3.2 . . . . . . . . . . . . . . . . . . . . . . 61. 3.

(9) 4.1. Ciclo de vida del desarrollo de software. Fuente: (PMO Informática, 2012) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.2. Modelo del Procedimiento IVC Necesidades de Software. Fuente: Este trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.3. Ciclo de vida del desarrollo de software. Fuente: Elaboración propia 71. 4.

(10) Índice de tablas 3.1. 3.2. 3.3. 3.4. 3.5.. Diseño de la encuesta . . . . . . . . . . . Analista: Tendencia de datos . . . . . . . Programador: Tendencia de datos . . . . . Lı́der o PM: Tendencia de datos . . . . . Cliente, Usuario final: Tendencia de datos. . . . . .. 21 29 33 37 41. 4.1. Caracterización del procedimiento IVC de Necesidades de software. Fuente: este proyecto . . . . . . . . . . . . . . . . . . . . .. 68. 5. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . ..

(11) Capı́tulo 1 CONCEPTUALIZACIÓN La presente investigación adopta un nivel de estudio descriptivo, puesto que pretende a través de la aplicación de una metodologı́a previamente definida, identificar caracteristicas propias de los procedimientos utilizados en la construcción de requerimientos de software que conlleven a una posible mejora de los mismos. con este fin, son explorados comportamientos sociales dentro de la(s) organizacion(es) que constituyen el caso de estudio y que, reflejan en alguna medida, la realidad de las empresas colombianas en esta materia.. 1.1.. Metodologı́a de Sistemas Suaves. La MSS proporciona un paradigma orientado al aprendizaje, aplicado a problemas no estructurados, normalmente asociados a situaciones en las que hay un alto componente de subjetividad (Cardoso E.O. et al., 2013). Está diseñada como un proceso de siete etapas en el cual se diferencian aquellas fases que son propias del mundo real y las que se derivan del análisis sistémico, como puede verse en 1.1. La MSS encuentra su fundamento en el ciclo de experienciaacción, modelado por el autor y que define el proceso de conocimiento de un humano en el mundo real, el cual surge de la experiencia, que lo conlleva a tomar acciones, de las cuales se derivan nuevas experiencias, ver figura 1.2 (Checkland P. and Scholes J., 1994).. 6.

(12) Figura 1.1: La metodologı́a de Checkland. Fuente:(Checkland, 1981). Figura 1.2: Ciclo Experiencia - Acción. Fuente: (Checkland P. and Scholes J., 1994). 1.2.. Ingenierı́a de requerimientos. Los requerimientos de un sistema, son basicamente, la información relacionada con el mismo (Geogy M. and Dharani A., 2016). Partiendo de la definición de (Bertalanffy, 1968), un sistema comprende un conjunto de elementos interrealacionados y las relaciones establecidas entre ellos, proporcionandole caracterı́sticas estructurales y comportamentales. Por otra parte, la información, en concordancia con la teorı́a que la estudia, es una cantidad mesurable de organización en un sistema (Johansen, 2004), de acuerdo con lo anterior; de la complejidad de las relaciones de los elementos, depende el esfuerzo o energı́a requerida para recopilar, procesar, resguardar y dar a conocer dicha cantidad de datos. La ingenierı́a de requerimientos, provee un conjunto de herramientas y técnicas para realizar estas 7.

(13) actividades en un sistema computacional. La ingenierı́a de requerimientos, tiene por objetivo definir y describir las necesidades del sistema, ası́ como gestionar los cambios sobre los requisitos en el proceso de desarrollo de software. Dichas necesidades son expresadas en diferentes tipos de requerimiento, que en conjunto determinan la funcionalidad, estructura, desempeño y demás aspectos que caracterizan al sistema. Usualmente, las caracterı́sticas del sistema a construir son conocidas y definidas por los interesados en el desarollo del mismo y fundamentados en procedimientos previamente definidos. Lo anterior genera que, a medida que se avanza en la descripción de los requisitos, lo que se ha definido previamente sufra constantes cambios (Zielinski K. and Szmuc T, 2005). La IR surge como respuesta a los más recurrentes errores cometidos en el traspaso de información, para lograr que se produzca de la manera más fluida posible. De acuerdo con (Zielinski K. and Szmuc T, 2005) las principales falencias en el desarrollo de las actividades de elicitación de requerimientos constituyen: Permitir que los requerimientos no tengan coherencia entre ellos o se registren múltiples veces. No priorizar adecuadamente para evitar consumir tiempo de desarrollo en aquellos que no son realmente necesarios o pueden ser abarcados en versiones posteriores No llevar un seguimiento claro entre los requerimientos que fueron definidos y aquellos que han sido implementados. No incluir en el proyecto la totalidad de los requerimientos, incumpliendo ası́ la expectativa del cliente final. Iniciar el desarrollo y realizar estimaciones de tiempo sin haber ejecutado la fase de análisis previamente. Principales Técnicas de Elicitación de Requerimientos Existen diversos métodos que facilitan la obtención de los requisitos de un sistema, a continuación se nombran los más usados comunmente: Entrevistas: Constituyen sesiones con los interesados del proyecto, en las que se realizan uns serie de preguntas para conocer sus expectativas y determinar los requisitos del proyecto. Las entrevistas pueden ser cerradas, 8.

(14) aquellas en las que se cuenta con un listado de preguntas previamente preparado, o abiertas, en las que no se han estructurado las preguntas, sino que se lleva a cabo un dialogo abierto con los interesados y a medida que avanza, son construidas las preguntas a partir de las dudas que surgen (Sommerville, 2005). Esta técnica es considerada poco eficaz, debido a que usualmente, las personas entrevistadas no son exhaustivas en la descripción de sus funciones y los conceptos relacionados con su trabajo, puesto que para ellos, son triviales. Por esta razón, siempre se recomienda usarla como complemento de otras técnicas. Escenarios: Para los usuarios de una herramienta de software resulta más facil compartir sus conocimientos relacionados con las actividades que realizan a través de ejemplos. La descripción de estas situaciones particulares se conoce como escenario (Hadad G. et al., 1998). usualmente se encuentran los siguientes componentes en la documentación de un escenario: titulo, objetivo, contexto del sistema en el que se presenta, condiciones requeridas para que se dé inicio a la situación particular, flujo normal de eventos, restricciones y excepciones que puedan presentarse, condiciones de salida y posibles flujos alternos de eventos. Esta técnica proporciona mayor detalle de los requerimientos que las entrevistas. Casos de uso: Quizás esta corresponda a la técnica mayormente adoptada; fue presentada por Ivar Jacobson en 1991 (Hunt, 2002) en el método Objectory Method, corresponde a la representación de la interrelación de los usuarios (actores) con el sistema, a través de funciones (usos). El Objectory Method describe tres fases que constituyen un conjunto de modelos: modelo de casos de uso, modelo de dominio y modelo de interfaz de usuario. Años más tarde, el modelo fue adoptado como una caracterı́stica principal en la notación UML. Prototipos: Los prototipos son versiones preliminares del sistema a desarrollar, para trabajar con ellos es necesario que la aplicación sea modularizable, con el fin de minimizar tiempos en la fase de construcción del prototipo y se incluyan funcionalidades importantes, pero no necesariamente todas las identificadas (Kendall K. and Kendall J., 2005). El modelo será iterado en varı́as ocasiones para permitir su evolución, hasta alcanzar los resultados esperados. De esta manera, el usuario podrá visualizar rapidamente el avance del desarollo.. 9.

(15) Aspectos Sociales en Ingenierı́a de Requerimientos De acuerdo con (Sommerville, 2005): ”los ingenieros de sistemas no sólo tratan con el software, sino también con el hardware y las interacciones de los sistemas con los usuarios y su entorno...necesitan tener conocimientos en ingenierı́a de sistemas, porque los problemas dela ingenierı́a de software son a menudo el resultado de las decisiones de la ingenierı́a de sistemas”. Esta dinámica sociotécnica, exige que, para el correcto dimensionamiento y diseño del sistemas, sean adoptadas estrategias que faciliten la definición de actividades estructuradas partiendo de un problema con cierto grado de complejidad, narrado en lenguaje natural. Por lo anterior, se han realizado investigaciones que incorporan herramientas de entendimiento de sistemas sociales en las fases de obtención y validación de requerimientos las herramientas de software (Niu N. et al., 2011). Ambigúedad en la documentación En investigación liderada por (Muhtasham A. et al., 2016) en el COMSATS Institute of Information Technology, se analizaron los inconvenientes que pueden presentarse durante la definición de requerimientos de software y que alteran el entendimiento del dominio. En su publicación, identifican atributos de los requerimientos que los hace dificiles de expresar, tales como que puedan provenir de diferentes fuentes y no ser obvios, no sean fáciles de expresar de manera consistente en lenguaje natural, no sean únicos y se relacionen estrechamente con otros requerimientos. Detectan entonces diferentes clases de ambigüedades en la lectura de los requisitos documentados, propias del lenguaje natural: ambigüedad léxica, cuando las palabras utilizadas para describir el requerimiento puede tener más de un significado; ambigüedad sintáctica, una frase puede interpretarse de diferentes maneras dada su estructura gramátical; ambigüedad semántica, ocurre cuando una frase tiene varias interpretaciones en su contexto y ambigüedad pragmática, en la cual, el significado de un frase está sujeto al entendimiento de quien la lee. Validación de Requerimientos . De acuerdo con la norma ISO 9000..2005 ISO 9000 (2005), que se encarga de la especificación de la terminologı́a a utilizar para los sistemas de gestión de calidad, cuyos requisitos de diseño de producto se encuentran definidos en la nor10.

(16) ma ISO 9001, define la revisión, verificación y validación de un producto de la siguiente manera: Revisión: Actividad ejecutada sobre el producto o servicio que permite evaluar la conveniencia y eficacia del mismo en relación con los objetivos previamente definidos. Verificación: Comprobación del cumplimiento de los requisitos especificados. Validación: Comprobación del cumplimiento de los requisitos, para un uso especifico, es decir, que el producto tenga la capcidad de satisfacer los requerimientos del cliente. En el proceso de desarrollo de software, la ejecución de estas tres actividades es fundamental en el aseguramiento de calidad del producto final y su planeación y resultado dependen en gran medida de la buena descripción que se haya realizado de los requisitos del software. Para llevar a cabo estas actividades pueden ser empleadas diferentes técnicas, tales como la construcción de prototipos, casos de pruebas o creación de equipos de trabajo que involucren a los interesados y responsables en el proceso. (Sommerville, 2005) identifica diferentes tipos de verificación a llevar a cabo sobre los requerimientos: Verificaciones de validez: Comprobar que los requerimientos sean validos en relación con las funcionalidades a cumplir. Estas funciones deben corresponder con las esperadas por parte de los interesados. Verificaciones de consistencia: Los requerimientos han de ser claros, coherentes y no contradictorios. Verificaciones de completitud: Todos los tipos de requerimieno deben ser tenidos en cuenta en la documentación, si bien, siempre pensamos primero en la funcionalidad de las aplicaciones, es necesario tener en cuenta los requistos no funcionales que proporcionan directrices sobre el desempeño, usabilidad, seguridad del software, entre otras. Verificaciones de realismo: Dadas las restricciones en cuanto a recursos y presupuesto, es importante validar que los requisitos expuestos puedan ser ejecutados técnicamente.. 11.

(17) Verificabilidad: Para poder ejecutar la actividades de verificación del producto final, es importante que se defina para los requerimientos, posibles escenarios de pruebas. Cambios sobre los requerimientos La organización es un sistema abierto de complejidad creciente, por ende sus procesos y estructura no pueden ser estáticos. Los requisitos de software tienen una estrecha relación con los requisitos de arquitectura empresarial y lo objetivos del negocio, es por esto que su evolución es inevitable (Sommerville, 2005). Los tiempos de implementación de una herramienta de software son directamente proporcionales al tamaño del mismo, durante este delta de tiempo, la organización, procesos, objetivos y en consecuencia los requisitos pueden presentar cambios. De acuerdo con el autor, los requerimientos pueden, desde esta perspectiva, ser de dos clases: Duraderos: Están relacionados con el dominio del sistema, por lo que la probabilidad de cambio es mı́nima. Volátiles: Tienen una lata probabilidad de presentar modificaciones, ya sea en el transcurso del proceso de desarrollo o posterior a la implementación del sistema. Teniendo como base la realidad anteriormente descrita, resulta importante contar con un proceso claro de gestión de cambios para asegurar la consistencia y evolución de los mismos. (Sommerville, 2005) propone tres fases dentro de dicho proceso. Análisis del problema y especificación del cambio: En esta etapa se validan técnica y funcionalmente los cambios a ser incorporados. Análisis del cambio y cálculo de costes: Partiendo del conocimiento del alcance y requerimientos del sistema y haciendo uso de técnicas de estimación, en esta fase se evalua el impacto del cambio en los recursos y el dueño del sistema toma la decisión con base en estos datos, para incorporar o no, el cambio al proyecto. Implementación del cambio: Se deben actualizar todos los documentos impactados: requerimientos, cronograma del proyecto, escenarios, etc. 12.

(18) 1.3.. Situación problemática a abordar. La IR implica la ejecución de multiples actividades que tienen estrecha relación con el contexto humano (expectativa, intención, organización, estructura social, etc.), entre ellas se encuentran, pero no se restringen a: la planeación, entendimiento, elicitación, modelado, análisis, comunicación, validación, aceptación, evolución, negociación y priorización de los requerimientos para el diseño y desarrollo de los componentes de software (Niu N. et al., 2011). Este hecho conlleva a la atribución de responsabilidad sobre las fallas en los sistemas de información a las complejas relaciones sociales. En (Lyytinen K. and Hirschheim R., 1988) ya se mencionaban cuatro tipos de fallas presentadas en los sistemas de información derivados de esta relación: Falla de correspondencia: Se presenta si los objetivos de diseño fueron previamente establecidos, pero no son conocidos en la etapa de desarrollo, por tanto el sistema no corresponde con lo que fue inicialmente requerido. Falla de proceso: La entrega del sistema conlleva mayor tiempo o recursos de los presupuestados. Falla de interacción; Si un usuario usa recurrentemente el sistema, esto quiere decir que este cumple con su objetivo final y el usuario está satisfecho con su funcionamiento, por otra parte, si la interacción con el sistema es baja o nula, esto quiere decir que hay una falla por resolver. Falla de expectativa: El sistema no cumple las expectativas de los usuarios finales. En estudios más recientes, se ha demostrado que, si bien se han incorporado nuevas herramientas metodológicas en la fase de elicitación de requerimientos de software, el porcentaje de proyectos que no son considerados como exitosos aún es importante. De acuerdo con (Hastie S. and Wojewoda S., 2015), en el año de presentación del reporte, el 52 % de los proyectos fueron discutidos y el 19 % se consideraron fallidos, por otra parte, entre los princiales factores de éxito del 29 % restante de los proyectos se consideraron aspectos ”blandos”: Apoyo de la dirección Madurez emocional de los participantes. 13.

(19) Implicación del usuario final en la definición de los requerimientos del sistema Nivel de competencia de los recursos Objetivos claramente definido Procesos ágiles de desarrollo. 14.

(20) Capı́tulo 2 DISEÑO DE LA INVESTIGACIÓN La sección anterior nos da el contexto de la investigación a realizar, sin embargo, para proceder con la aplicación de la metodologı́a de sistemas suaves es necesario contar con datos que nos permitan efectuar el análisis correctamente, es decir, compresiones subjetivas de la realidad cercanas al sistema de construcción de software conocido y que comprende nuestra realidad. Con este fin, fueron elegidas dos herramientas: encuestas y recopilación de investigaciones previas. En el presente capı́tulo se describe el diseño y uso de dichas herramientas.. 2.1.. Diseño de la encuesta para obtención de datos. Como herramienta principal de recopilación de información se hizo uso de una encuesta con las siguientes caracteristicas: Ficha Ténica de la encuesta: 1. Población objetivo: Profesionales en Ingenierı́a que participen en el proceso de construcción de software en una organización y usuarios o clientes que hayan participado en un proyecto de implantación o construcción de software. 2. Tipo de Muestreo: Con el fin de conocer a las personas que contestan la encuesta, para en un momento determinado, de ser necesario, contactarlas y realizar entrevistas personales para ası́ facilitar la aplicación de la MSS, se utiliza un muestreo no probabilı́stico intencional (Avila, 2006).. 15.

(21) 3. Tamaño de la muestra: El tamaño de la muestra se determina en conformidad con las siguientes caracterı́sticas: Tamaño de la población: Comprende el número total de personas al que desea realizarse la encuesta. En el cotexto de este proyecto, las población está conformada por los empleados del área de desarrollo de las empresas en las que los autores ejecutan sus actividades profesionales, incluyendo algunos usuarios finales y la totalidad de estudiantes de las especializaciones en Ingenierı́a de software y Gestión de proyectos de software de la Universidad Distrital Fransciso José de Caldas. El tamaño de la población es de 100 personas. Nivel de confianza: En el caso de estudio, no es necesario que el valor real sea aproximado al 100 % puesto que es para nosotros más valioso conocer la realidad de cada uno de los participantes y su visión del proceso que la asertividad con respecto a lo que se desea o espera de las actividades relacionadas con las IR. Por esta razón, el nivel de confianza definido es del 80 %. Margen de error: Corresponde al porcentaje de respuesta que pueden variar en la muestra. Dado el nivel de confianza establecido, el margen de error para la encuesta es en proporción del 5 % El tamaño de la muestra está determinado entonces por:. Figura 2.1: Fórmula para cálculo del Tamaño de la Muestra. Fuente:(A. Martı́nez et al., 2004) Donde: z = Cantidad de desviaciones estándar. Para el nivel de confianza establecido es de 1,28. p = nivel de confianza. e = Margen de error. 16.

(22) N = Tamaño de la población. Entonces:. 4. Forma de recolección de datos: La encuesta se realiza haciendo uso de formularios de google, la invitación para la misma es enviada a través de correo electrónico.. 17.

(23) Capı́tulo 3 DESARROLLO DE LA INVESTIGACIÓN La investigación objeto de este proyecto se realiza en conformidad con las fases propuestas en la Metodologı́a de Sistemas Suaves. En el presente capı́tulo se muestran la definición, desarrollo y los resultados obtenidos tras la ejecución de cada etapa.. 3.1.. Situación de problema no estructurada. Debido a que el problema tiene un contexto social, para nuestro caso de estudio, organizaciones; se pretende, en conjunto con los involucrados e interesados en el proceso de desarrollo de software, identificar los elementos que constituyen las caracterı́sticas relacionadas con el poder, la comunicación, estructura y demás actividades o relaciones propias del comportamiento humano en la ejecución de las actividades relacionadas con el proceso en mención. Para la recopilación de dicha información, dado el volumen de posibles participantes, se decidió que la aproximación más cercana serı́a a través de la ejecución de una encuesta. Los pasos para la realización de la encuesta se encuentran son detallados en la sección 2.1. Para establecer un listado de preguntas que nos permita comprender la situación problema, es necesario definir inicialmente de manera lo que se requiere conocer de las personas a entrevistar.En el contexto de esta investigación, la información principal que deseamos conocer es: ¿cuáles son los métodos y técnicas utilizados en las actividades de elicitación y validación de requerimientos y la 18.

(24) opinión de los involucrados o interesados en el proceso de desarrollo de software en relación a las mismas?. Haciendo uso anticipado de una etapa posterior de la MSS, podemos formular la pregunta anterior como una definición raı́z(Checkland, 1981): ”Un sistema para que los involucrados e interesados en el proceso de construcción de software identifiquen los principales aspectos y efectos de las técnicas de recopilación de requerimientos empleadas en las compañı́as, mediante su experiencia y conocimiento acerca del tema, para contribuir con la mejora los procedimientos propios de la ingenierı́a de requerimientos de software.” En conformidad con lo anterior, es posible identificar cinco aspectos diferentes(Nielsen, 1990): 1. Identificar el grado de participación en el proceso de quien responde la encuesta (interesado o involucrado) 2. Entender las caracterı́sticas de las técnicas de recopilación de requerimientos utilizadas 3. Conocer los efectos (positivos y negativos) del uso de dichas técnicas en el proceso desde la perspectiva de quien responde la encuesta 4. Conocer el contexto en el que se desarrolla el proyecto: tipo de negocio u organización, tipo de proyectos, entre otros. 5. Identificar el nivel de experiencia y conocimiento de cada uno de los participantes Con base en lo anterior, es posible dimensionar las preguntas a utilizar en la elaboración de la encuesta:. 19.

(25) Figura 3.1: Diseño Encuesta, parte 1. Fuente:Elaboración propia. Figura 3.2: Diseño Encuesta, parte 2. Fuente:Elaboración propia. 20.

(26) Cuestionario: Las preguntas que conforman el cuestionario fueron expresadas en conformidad con el rol de cada participante: Tabla 3.1: Diseño de la encuesta ROL/ PREGUNTA Analista Programador PM/ Lı́der Usuario ¿En qué tipo de organización se X X X X realizó el proyecto? ¿Cuáles técnicas se usan para la X X X X identificación derequerimientos? ¿Cuáles modelos de prototipo utilizan X X X o utilizaron en el desarrollo? ¿Cuáles de las siguientes opciones de ciclos de desarrollo describe mejor el X X X usado en el proyecto? Clasificación de caracterı́sticas de los X X X requerimientos Duración estimada del proyecto X X X X Duración real del proyecto X X X X Cumplimiento de expectativas del X X X X usuario final Clasificación de caracterı́sticas del X X X X proyecto Durante los últimos 5 años, ¿En cuántos proyectos ha estado X X X X involucrado? Recomendaciones para el proceso X X X X Resultados: La encuesta fue atendida por 66 personas, número que se encuentra en el rango del tamaño de la muestra esperado. El detalle de las respuestas obtenidas se presenta en 3.2.. 21.

(27) 3.2.. Situación de problema expresada. Para el análisis de los resultados obtenidos tras la aplicación de la encuesta, se realizó un filtro por rol o perfil del encuestado, ya que las preguntas para cada uno varı́an dependiendo de las actividades realizadas en el(los) proyecto(s) como se explicó en 3.1. Se pretende expresar la situación problema mediante diagramas o gráficos de visiones enriquecidas para contar con una vista más objetiva y precisa, logrando hacer evidentes las posibles relaciones, su entorno y las situaciones conflictivas (epistemologı́a). Las cosmovisiones de las personas involucradas y las relación con la situación problema (fenomenologı́a) se puede evidenciar también en la construcción de la situación problema de manera estructurada. En la figura 3.3 se visualiza la cantidad de respuestas obtenidas de acuerdo al tipo de rol del participante.. Figura 3.3: Tamaño de Muestra por Rol. Fuente:Elaboración propia. 22.

(28) A continuación se presentan los resultados recopilados en función del rol que los proporciona. Analista Se conoce como analista en la rama de la ingenierı́a de software a aquel profesional encargado de analizar sistemas informáticos y describir el problema especı́fico. En muchas empresas también es el encargado de revisar modelos o soluciones ya dadas (k. Kendall and J. Kendall, 2005). Al indagar sobre el tipo de empresas en las que han laborado los analistas, se evidencia que los proyectos se han ejecutado principalmente en empresas de consultorı́a y el sector financiero, figura 3.4, siendo esta última la de mayor tendencia. En la figura 3.5 se puede observar las técnicas de levantamiento de requerimientos, siendo las historias de usuario, casos de uso y escenarios las más usadas.. Figura 3.4: Analista:Tipos de organizaciones. Fuente:Elaboración propia. 23.

(29) Figura 3.5: Analista:Técnicas de levantamiento de requerimientos. Fuente:Elaboración propia. Figura 3.6: Analista:Modelos de prototipo. Fuente:Elaboración propia. 24.

(30) Figura 3.7: Analista:Caracteristicas levantamiento de requerimientos. Fuente:Elaboración propia Para los analistas, los objetivos de los requerimientos del usuario final se cumplieron satisfactoriamente, tan sólo el 6,3 % de los encuestados respondieron que no, el 43,8 % contestaron que se dio parcialmente y el 50 % indicó que si se cumplieron como se muestra en la figura 3.10. En la figura 3.7 se observa la evaluación hecha sobre algunas caracterı́sticas de la fase de identificación de requerimientos, encontrando que la calificación dada a la claridad sobre el alcance del proyecto y la especificación de requerimientos es considerablemente menor que la asignada a la priorización de requerimientos e implicación del usuario final en la definición de los mismos. Es decir, que a pesar de que son involucrados los clientes, los analistas consultados indican no tener completa claridad sobre los requisitos o alcance.. 25.

(31) Figura 3.8: Analista:Duración del proyecto. Fuente:Elaboración propia. Figura 3.9: Analista:Duración real del proyecto. Fuente:Elaboración propia. 26.

(32) Figura 3.10: Analista:Cumplimiento de las espectativas. Fuente:Elaboración propia. Figura 3.11: Analista: caracteristicas involucrados en el proyecto. Fuente:Elaboración propia. 27.

(33) Figura 3.12: Analista: Madurez equipo de trabajo. Fuente:Elaboración propia. 28.

(34) Tabla 3.2: Analista: Tendencia de datos CARACTERÍSTICA. ESPECIFICACIÓN Consultorı́a Tipo organización Financiera Escenarios Técnicas de levantamiento Casos de uso de requerimientos Historias de usuario Implicación del usuario final Claridad en la especificación de los Caracterı́sticas requerimientos requerimientos Claridad en el alcance Priorización Ciclos de desarrollo Incremental Comunicación involucrados Dirección/coordinación del proyecto Caracterı́sticas Proyecto Alineación con lo esperado por el usuario final Metodologı́as y técnicas aplicadas Madurez, compromiso de trabajo Cumplimiento expectativas usuario Si Parcialmente final Menor a un año Duración estimada del proyecto Entre 1 y 3 años Duración real del proyecto Mayor a la estimada Incremental Modelo de prototipado Interfaz de usuario. 29. VALOR 33,3 % 33,3 % 15 15 15 4 5 5 5 7 5 5 3-4 4-5 4-5 50 % 43,8 % 56,3 % 43,8 % 56,3 % 8 8.

(35) Programador El programador o desarrollador, es el encargado de codificar el software y realizar pruebas de tipo unitario. Es de gran importancia para el desempeño de sus actividades que los requerimientos se encuentren claramente expresados (G. Panataleo and L. Rinaudo, 2016). Al indagar sobre las empresas en las que se desarrollo el proyecto encontramos que tan solo el 5 % de los encuestados se encuentran laborando en casas de desarrollo, ver figura 3.13. Es decir que esta actividad se lleva a cabo, principalmente en empresas que deciden contratar un equipo de desarrollo o implementación de software. En la figura 3.14 se pueden evidenciar los tipos de técnicas utilizados en cada uno de los proyectos, siendo, al igual que en el caso del analista, los casos de uso, historias de usuario y escenarios aquellas técnicas que son mayormente utiLizadas, lo anterior, debido a la tendencia creciente de las empresa por adoptar metodologı́as ágiles de desarrollo (Hitachi, 2017). En la figura 3.15 se listan los modelos de prototipado identificados por cada entrevistado, siendo la interface de usuario el más reconocido.. Figura 3.13: Programador:Tipos de Organización. Fuente:Elaboración propia Se solicitó a los programadores calificar de 1 a 5, algunos aspectos de los requerimientos que les fueron entregados. Los resultados pueden apreciarse en la figura 3.16. En cuanto al cumplimiento de las expectativas del cliente, el 90 % de los programadores encuentra que fueron cumplidas en su totalidad o parcialmente, como se aprecia en la figura 3.17. 30.

(36) Figura 3.14: Programador:Tipos de Técnicas de Elicitación. Fuente:Elaboración propia. Figura 3.15: Programador:Modelos de Prototipado. Fuente:Elaboración propia. 31.

(37) Figura 3.16: Programador:Calificación de las caracterı́sticas de los requerimientos. Fuente:Elaboración propia. Figura 3.17: Programador:Cumplimiento de las Expectativas del Cliente. Fuente:Elaboración propia. 32.

(38) Tabla 3.3: Programador: Tendencia de datos CARACTERÍSTICA Tipo organización Técnicas de levantamiento de requerimientos Modelos de prototipado. Caracterı́sticas requerimientos. ESPECIFICACIÓN Telecomunicaciones Historias de usuario Casos de uso Escenarios Incremental Interfaz de usuario Implicación usuario final Claridad en la especificación de requerimientos Claridad en el alcance de los requerimientos Priorización de los requerimientos. Cumplimiento expectativas del Si cliente Duración real del proyecto Parcialmente. 33. VALOR 35,0 % 25,4 % 25,4 % 22,7 % 4 5 4 3 3 4 50,0 % 40,0 %.

(39) Lı́der o Director de Proyecto El lı́der del proyecto o lı́der de equipo es el facilitador entre el equipo de desarrollo y el cliente o usuario final. Se encarga de la gestión de cronogramas y seguimiento al desarrollo del proyecto. Los directores de proyecto encuestados coinciden con los analistas en que las técnicas más utilizadas en el levantamiento de requisitos constituyen aquellas asociadas a metodologı́as agı́les de desarrollo, tales como las historias de usuario y el prototipado incremental es considerado el modelo con mayor acogida. Ver figuras 3.19 y 3.21.. Figura 3.18: Lı́der o PM: Tipo de Organización. Fuente:Elaboración propia. Figura 3.19: Lı́der o PM: Tipo de Técnicas. Fuente:Elaboración propia En lo que a las caracterı́sticas de la fase de identificación de requerimientos respecta, como puede observarse en la figura 3.22, las personas que lideran el 34.

(40) Figura 3.20: Lı́der o PM: Ciclos de Desarrollo. Fuente:Elaboración propia. Figura 3.21: Lı́der o PM: Modelos de Prototipado. Fuente:Elaboración propia proyecto de desarrollo, consideran que se debe mejorar la claridad en la especificación de los requerimientos identificados. Se enfrentan entonces, las personas que cumplen este rol, a una insatisfacción por parte de los usuarios cercana al 40 %, segun se muestra en 3.23.. 35.

(41) Figura 3.22: Lı́der o PM: Calificación de las caracterı́sticas de requerimientos. Fuente:Elaboración propia. Figura 3.23: Lı́der o PM: Cumplimiento de expectativas del cliente. Fuente:Elaboración propia. 36.

(42) Tabla 3.4: Lı́der o PM: Tendencia de datos CARACTERÍSTICA Tipo organización Técnicas de levantamiento de requerimientos Ciclos de desarrollo Modelos de prototipado. Caracterı́sticas requerimientos. ESPECIFICACIÓN Financiera Historias de usuario Casos de uso Escenarios Incremental Incremental Evolutivo Implicación usuario final Claridad en la especificación de requerimientos Claridad en el alcance de los requerimientos Priorización de los requerimientos. Cumplimiento expectativas del Si cliente Duración real del proyecto Parcialmente. 37. VALOR 33,3 % 22,7 % 22,7 % 22,7 % 37,0 % 9 7 5 4 3 5 61,9 % 38,1 %.

(43) Cliente o Usuario Final El usuario final o cliente es la persona o grupo de personas a la que va a destinada el producto de software, o en muchos casos quien conoce el funcionamiento y estructura. En el caso de ingenierı́a de requerimientos, es la persona encargada de hacer la solicitúd de lo que se requiere convertir en un producto de software. Para el cliente o usuario final se ve una clara tendencia en el tipo de organización de telecomunicaciones como lo indica la figura 3.24, además en este rol sigue la tendencia de las técnicas de levantamiento de información como se puede observar en la figura 3.25: Escenarios Casos de uso Historia de usuario. En las caracterı́sticas principales de los proyectos se nota una baja calificación leve en la comunicación entre los involucrados en el proyecto, como lo podemos observar en la figura 3.26. El cumplimiento de las expectativas por parte del usuario final está dividido en el 55,6 con respuesta afirmativa y el 44,4 con respuesta negativa como lo indica la figura 3.28 .. Figura 3.24: Usuario:Tipo de organizaciones . Fuente:Elaboración propia. 38.

(44) Figura 3.25: Usuario:Tecnicas de levantamiento de información . Fuente:Elaboración propia. Figura 3.26: Usuario:Caracteristicas de los proyectos . Fuente:Elaboración propia. 39.

(45) Figura 3.27: Usuario:Duración de los proyectos . Fuente:Elaboración propia. Figura 3.28: Usuario:Cumplimiento de las expectativas . Fuente:Elaboración propia. 40.

(46) Tabla 3.5: Cliente, Usuario final: Tendencia de datos CARACTERÍSTICA Tipo organización Técnicas de levantamiento de requerimientos. ESPECIFICACIÓN Telecomunicaciones Escenarios Entrevistas Comunicación involucrados Dirección/coordinación del proyecto Caracterı́sticas Proyecto Metodologı́as y técnicas aplicadas Madurez, compromiso de trabajo Cumplimiento de espectativas Si No Menor a un año Duración estimada del proyecto Entre 1 y 3 años Duración real del proyecto Mayor a la estimada. 41. VALOR 77,8 % 5 5 3 4 4 4 60 % 40 % 50 % 50 % 56,3 %.

(47) 3.2.1.. Resultados de la fase. Una vez se ha analizado la información recopilada es posible concluir lo siguiente respecto a los aspectos a evaluar identificados en 3.1: Grado de participación en el proceso de quien responde la encuesta: En el diseño de la encuesta fueron planteados 4 roles diferentes: 3 participantes activos, analista, programador y lı́der o director de proyecto, además un rol que corresponde al principal interesado, cliente o usuario final. Como se aprecia en la figura 3.3, se obtuvieron respuestas principalmente de Lı́deres de proyecto y programadores, 62 % en total, estos dos roles usualmente evidencian en su quehacer diario los efectos de una buena o mala práctica en la identificación de requerimientos, por lo que el análisis posterior se verá enriqeucdido por su punto de vista. El 24 % de los encuestados desempeñan el rol de analistas en su organización, con este rango se completa la visual de las personas que participan como ejecutores en un proyecto de desarrollo de software. El 14 % restante de las opniones proviene de personas que han tenido la oportunidad de ser clientes o usuarios finales en el proyecto, su percepción es de gran valor para el desarrollo de este trabajo, Caracterı́sticas de las técnicas de recopilación de requerimientos utilizadas: El 48 % de los encuestados coincidió en que la técnica mayormente utilizada para especificar los requerimientos es la elaboración de escenarios, historias de usuario y casos de uso, usualmente identificados por medio de entrevistas, según confirma el 38 % de los participantes. Las personas que usan prototipado como herramienta, suelen hacerlo en forma evolutiva (37 %) o incremental (43 %). También son comunmente utilizadas las interfaces de usuario (41 %).De igual manera, el ciclo de desarrollo empleado con mayor frecuencia corresponde con el incremental, 41 %, seguido del modelo en cascada con tan solo un 14 %. Según los datos anteriores, es posible identificar una tendencia en el uso de herramientas que permitan proporcionar avances al usuario final y evidenciar el avance del proyecto. Efectos del uso de dichas técnicas en el proceso: Al consultar a los encuestados respecto a las caracterı́sticas de los requerimientos entregados en el proyecto, las calificaciones más bajas fueron asignadas a la claridad en la 42.

(48) especificación tanto de los requerimientos como del alcance. También fueron identificados problemas en la priorización de los requerimientos. Sin embargo, consideran que la implicación del usuario final en el proceso fue satisfactoria. El 39.7 % de los encuestados coincidieron en que las expectativas del usuario final fueron satisfechas parcialmente, versus un 55 % que considera fueron cumplidas a cabalidad. Contexto en el que se desarrolla el proyecto: Alrededor del 50 % de los participantes desarrolló el proyecto de software evaluado en empresas del sector tecnologı́a o gobierno, mientras que el 77.8 % de los encuestados que desempeñaron el rol de cliente o usuario final pertenencen al sector telecomunicaciones. Lo anterior nos lleva a contar con evaluaciones mayormente de equipos que se encargan de desarrollar o implementar soluciones para sus propias empresas. El 58 % indicó que el proyecto tuvo una duración mayor a la esperada. El primer equipo evaluado considera que las metodologı́as y técnicas aplicadas pueden mejorar, ası́ como la alineación con el usuario final. Por otra parte, los clientes asignaron la calificación más baja a la comunicación entre los involucrados del proyecto, seguido por la dirección o coordinación de actividades. Nivel de experiencia y conocimiento de cada uno de los participantes: El 22.4 % de las personas que contestaron la encuesta han participado en más de 10 proyectos en los últimos 5 años, mientras que alrededor del 39 % ha estado entre 5 y 10 proyectos. Esto nos da un buen margen de personas con suficiente experiencia en el proceso de construcción de software y principalmente en el sector de tecnologı́a, como es descrito en el aspecto anterior.. 43.

(49) 3.3.. Definiciones Raı́z y Sistemas de Actividad Humana. Con base en lo ilustrado en la sección anterior, en esta fase son identificados los diferentes sistemas de actividad mediante lo que el autor llama ”Definición Raı́z”, que describen el sistema en consideración y están formadas por tres componentes: Qué, define el proposito inmediato del sistema. Cómo, en donde se explicará la manera en que será conseguido el ”qué” y Por qué, parte del enunciado que aclara la finalidad de la actividad. (Checkland P. and Scholes J., 1994) sugieren que se haga la formulación de las definiciones raı́z, respectando estos tres elementos, de tal forma que puedan ser expresadas de la siguiente manera: ”Un sistema para...(qué), mediante...(cómo) para contribuir con ...(por qué)”. Para cada una de las definicones raı́z construida, es realizado un análisis de roles del sistema representado en una expresión cuya estructura se encuentra fundamentada en seis factores claves y cuyo nemónico es CATWOE (Checkland P. and Scholes J., 1994): 1. C(Customers): Corresponde a los interesados en los resultados de la ejecución de la actividad. 2. A(Actors): Quienes ejecutan la actividad. 3. T(Trasnformation Process): Proceso de transformación. 4. W(Weltanschauung): Término alemán para describir la visión del mundo que da significado a la acción. 5. O(Owner): Dueño del sistema, tiene la capacidad de iniciarlo o detenerlo. 6. E(Environmental Constraints): Restricciones del medio. Luego son construidos modelos de los sistemas de actividad humana a partir de las definiciones raı́z, tomando como referencia los verbos de acción. Los modelos conceptuales están constituidos por el conjunto de actividades que debe realizar el sistema Las definiciones raı́z y los posteriores sistemas de actividad humana, se elaboran a partir de los puntos de vista analizados en la sección anterior y nos brindan una perspectiva de los procesos que se ejecutan. Los diagramas de PERT asociados a cada sistema de actividad humana funcionan como modelos conceptuales y se componen de: 44.

(50) Frontera del sistema Al interior de ella se encuentra el conjunto de actividades que ejecuta el sistema Actividades Se encuentran representadas por medio de óvalos, están enumeradas y conectadas por medio de lı́neas, para identificar la secuencia en la que se ejecutan. El objetivo principal de cada una se representa mediante un verbo. El modelo conceptual debe tener aproximadamente entre siete más o menos dos actividades. Monitoreo y control Las actividades que conforman el proceso de monitoreo y control se ubican fuera de la frontera del sistema y tienen el propósito de realizar seguimiento, evaluación y control sobre la ejecución de las actividades del sistema. Un módelo conceptual es válido si cumple con las siguientes caracterı́sticas (University, 2016): Cumple con una misión o propósito Puede asignarse al sistema una medida de desempeño para determinar su progreso. Incluye un proceso de toma de decisiones Tiene componentes que interactuan o tienen cierto grado de conectividad entre sı́. Tiene un lı́mite Existe en sistemas más grandes Cuenta con una garantı́a de continuidad Según lo descrito anteriormente y de la situación problema a analizar, fundamentada en las respuestas obtenidas tras la aplicación de la encuesta, se abstraen los siguientes sistemas de actividad humana, su definición raı́z y el modelo conceptual que representa su proceso.. 45.

(51) Sistema de actividad humana para el desarrollo de software usando prototipos C Cliente o Usuario Final A Programador, Analistas T Diseñar, desarrollar y entregar prototipos funcionales incrementales con base en los requerimientos identificados. W Llevar a cabo entregas parciales del software en construcción permite validar el funcionamiento del mismo en conformidad con lo requerido por el cliente. O Analista E Proyecto de desarrollo de software Definición Raı́z Un sistema poseı́do por los analistas, para diseñar, desarrollar y entregar prototipos funcionales incrementales con base en los requerimientos identificados, llevado a cabo por los programadores y analistas con el fin de validar el funcionamiento del software en conformidad con lo requerido por el cliente.. Figura 3.29: Sistema de Actividad Humana para el desarrollo de software usando prototipos. Fuente: Elaboración propia. 46.

(52) Sistema de actividad humana para comunicar los requerimientos eficazmente C Programador A Analistas T Comunicar eficazmente los requerimientos expresados por el cliente W Las habilidades comunicativas son indispensables para transmitir de manera clara a los desarrolladores el alcance, restricciones, necesidades y prioridades del cliente. O Analista E Proyecto de desarrollo de software Definición Raı́z Un sistema poseı́do por los analistas, para comunicar eficazmente los requerimientos expresados por el cliente, llevado a cabo por los analistas con el fin de transmitir de manera clara a los desarrolladores el alcance, restricciones, necesidades y prioridades del cliente.. 47.

(53) Figura 3.30: Sistema de Actividad Humana para comunicar los requerimientos eficazmente. Fuente: Elaboración propia. 48.

(54) Sistema de actividad humana para proponer requerimientos alineados con los objetivos empresariales C Cliente o usuario final A Analistas T Diseño y propuesta de los requerimientos de software orientados en el cumplimiento de los objetivos de negocio W El conocimiento de los objetivos y modelos de negocio, ası́ como del alcance y potencial de las herramientas tecnológicas permite reconocer al software y su desarrollo como herramientas estratégicas. O Cliente o usuario final E Proyectos de desarrollo o implementación de software Definición Raı́z Un sistema poseı́do por el cliente o usuario final, para diseñar los requerimientos de software con base en los objetivos de negocio mediante el conocimiento de los modelos de negocio, el alcance y potencial de las herramientas tecnológicas, llevado a cabo por los analistas con el fin de reconocer al software y su desarrollo como herramientas estrategicas que apoyan la consecuón de los objetivos empresariales.. 49.

(55) Figura 3.31: Sistema de actividad humana para proponer requerimientos alineados con los objetivos empresariales. Fuente: Elaboración propia. 50.

(56) Sistema de actividad humana para involucrar a los usuarios finales en el desarrollo del proyecto C Lı́der o Director de proyecto A Analistas T Consultar al usuario sobre los requerimientos, realizar la documentación en conjunto con él y ejecutar las validaciones correspondientes. W Involucrar a los usuarios o clientes finales en todas las fases del proceso de desarrollo de software facilita tener claridad sobre el alcance del proyecto y los requerimientos. O Lı́der o Director de proyecto, Analistas E Proyectos de desarrollo o implementación de software Definición Raı́z Un sistema poseı́do por el Lı́der o Director de proyecto y los analistas, para consultar al usuario sobre los requerimientos, realizar la documentación en conjunto con él y ejecutar las validaciones correspondientes, llevado a cabo por los analistas con el fin de involucrar a los usuarios o clientes finales en todas las fases del proceso de desarrollo de software y tener claridad sobre el alcance del proyecto y los requerimientos.. Figura 3.32: Sistema de actividad humana para involucrar a los usuarios finales en el desarrollo del proyecto. Fuente: Elaboración propia. 51.

(57) Sistema de actividad humana para realizar pruebas de concepto C Cliente o usuario final A Analistas, lı́der o director de proyecto T Realizar pruebas de concepto con base en los requerimientos definidos W Ejecutar una prueba de concepto previa al inicio del desarrollo con base en los requerimientos identificados permite validar la pertinencia y alcance de los mismos. O Lı́der o Director de proyecto E Proyectos de desarrollo o implementación de software Definición Raı́z Un sistema poseı́do por el lı́der o director de proyecto, para realizar pruebas de concepto con base en los requerimientos definidos, llevado a cabo por los analistas y el director de proyecto con el fin de validar la pertinencia y alcance de los mismos.. Figura 3.33: Sistema de actividad humana para realizar pruebas de concepto. Fuente: Elaboración propia. 52.

(58) Sistema de actividad humana para involucrar a todos los stakeholders C Cliente o usuario final, analistas, programadores A Analistas T Diseño y propuesta de estrategia para involucrar a todos los interesados del proyecto de software W Involucrar a todos los interesados en el proyecto, en especial al usuario final en todas las fases del proyecto para tener más claridad en lo que el usuario desea. O Cliente o usuario final E Disponibilidad de los stakeholders Definición Raı́z Un sistema poseı́do por el cliente o usuario final, para involucrar a las personas operativas y usuario final mediante las reuniones de validación con el usuario , llevado a cabo por los analistas, lı́deres de proyecto con el fin de validar los requerimientos del proyecto en todas sus etapas.. Figura 3.34: Sistema de actividad humana para involucrar a los stakeholders. 53.

(59) Sistema de actividad humana para desarrollar software usando interfaces y flujos de la solución C Cliente o usuario Final A Analistas T Identificar interfaces y flujos de software basados en los requerimientos especificados por el cliente. WIdentificar interfaces y flujos de software que estén basados en los requerimientos expresados por el cliente. O Analista E Proyectos de desarrollo de software. Definición Raı́z Un sistema poseı́do por los analistas, para desarrollar flujos de software mediante la identificación de interfaces que interactúan con el sistema con el fin de validar y entender el funcionamiento del software.. Figura 3.35: Sistema de actividad humana para desarrollar software usando interfaces y flujos de la solución. 54.

(60) Sistema de actividad humana para obtener información sobre el alcance antes de iniciar el proyecto C Cliente o usuario Final A Analistas T Consultar al usuario final sobre la documentación necesaria sobre los requerimientos, estos se transformarán en el alcance del proyecto. W Los requerimientos son la principal fuente de información para determinar las expectativas del cliente. O Analista, lı́der de proyecto E Proyectos de desarrollo e implementación de software. Definición Raı́z Un sistema poseı́do por los analistas, para transformar los requerimientos identificados en el alcance del proyecto llevado a cabo por analistas, lı́der de proyecto y usuario final con el fin de utilizar los requerimientos como la principal fuente de información para determinar las expectativas del cliente.. Figura 3.36: Sistema de actividad humana para obtener información sobre el alcance antes de iniciar el proyecto. 55.

(61) 3.4.. Comparación de modelos conceptuales con la realidad. En esta fase son comparados los modelos conceptuales con la realidad expresada en la etapa 2, con el fin de identificar diferencias emergentes. La comparación realizada dará lugar a un conjunto de resultados que pueden ser considerados como sugerencias (Checkland, 1981). Para llevar a cabo esta comparación, pueden emplearse diferentes métodos que permitan hacer la transición entre el análisis dado en un lenguaje sistémico y debatir el resultado en el lenguaje del mundo real, se definen principalmente cuatro métodos que pueden ser utilizados de manera unitaria o en conjunto: 1. Mediante un debate organizado, tomando como referencia los modelos conceptuales para la formulación de preguntas acerca de la situación. 2. Consiste en reconstruir una secuencia de sucesos ocurridos en el marco de la situación problema, comparandola con los posibles resultados obtenidos si se hubiese aplicado el modelo conceptual que es objeto de comparación. 3. Mediante el planteamiento de preguntas estratégicas acerca de las actividades actuales. 4. Se debe construir un modelo conceptual con las actividades que son ejecutadas en ”la realidad” y determinar las diferencias existentes entre los dos modelos. esto permite identificar los aspectos puntuales en los cuales difieren los dos modelos. Haciendo uso de los métodos descritos, se realiza la comparación entre los modelos conceptuales y la situación problemática. Los resultados se presentan a continuación: La comparación del sistema de actividad humana (SAH) para el desarrollo de software usando prototipos se realiza con base en una historia obtenida de una encuesta realizada por (Westfall, 2011): ”En uno de nuestros proyectos intercambiamos información con los clientes durante un mes y recogimos abundante información sobre los requisitos, que nos pareció bastante completa en ese momento. El producto se desarrolló en los siguientes tres meses, perı́odo durante el cual no fueron necesarios nuevos requisitos o cambios. Sin embargo, cuando estábamos a punto de entregar el producto, 56.

(62) tres meses más tarde, el lı́der rechazó muchas de las funciones anteriormente confirmadas, lo que condujo a otro sistema de procesos de tres meses”. Si este escenario se hubiera ejecutado haciendo uso del modelo conceptual en evaluación, el resultado obtenido probablemente hubiera sido el siguiente:. Figura 3.37: Comparación SHA para el desarrollo de software usando prototipos. Fuente: Este trabajo 1. Se habrı́an realizado entregas funcionales parciales que permitieran validar las expectativas del usuario final. 2. Los tiempos de entrega posiblemente se habrı́an acortado, contrario a tener un proyecto con una duración de 7 meses, se proponen ciclos de 1 mes hasta completar el total del proyecto. La comparación del SAH para comunicar los requerimientos eficazmente se lleva a cabo mediante la construcción de un modelo conceptual basado en la percepción de realidad de los analistas encuestados: En comparación con lo representado en la figura 3.30 los principales cambios consisten en: 1. Se evidencia una necesidad por el desarrollo de habilidades de comunicación. 57.

(63) Figura 3.38: SAH para comunicar requerimientos. Fuente: Elaboración propia 2. Se realiza una contextualización a los demás miembros del equipo de trabajo respecto al alcance y expectativas del usuario final. 3. Se valida la comprensión del mensaje entregado para confirmar que sea lo más acertado posible. 4. Existen criterios de aceptación relacionados con la comunicación, es decir, no solo se mide el grado de asertividad en la identificación de requerimientos, sino en como son transmitidos. La comparación del sistema de actividad humana (SAH) obtener información sobre el alcance antes de iniciar el proyecto se realiza con base en una historia obtenida de una encuesta realizada por (Westfall, 2011): ”Una vez tuvimos un proyecto para desarrollar el software a una cadena de alquiler de video, en el que el cliente expresó su interés de utilizar el mismo producto para expandirse internacionalmente. Sin embargo, sólo más tarde llegamos a conocer el hecho de que los estándares en el extranjero son muy diferentes a los nacionales, por lo que el producto tuvo que ser completamente reimplementado para cumplir con este requisito” 1. Se habrı́a evitado re-procesos en el momento de que el cliente deseo implementar nuevas funcionalidades.. 58.

(64) 2. Los tiempos de entrega ciertamente se reducen si se tiene un alcance especificado. 3. Se habrı́a construido un software altamente escalable para no depender de estandares especificos. Se pretende comparar el sistema de actividad humana involucrar a todos los stakeholders haciendo uso del tercer método propuesto, indagación mediante preguntas estratégicas y sus respuestas (Mate, 2005): 1. ¿Quien elige la persona dentro de la compañı́a para definir los usuarios? ”Elegir una persona dentro de la compañı́a encargada de definir los usuarios, por lo general el gerente o la persona que paga por el desarrollo” 2. ¿Qué acciones toman cuando hay conflictos entre requerimientos? ”No se hace uso de grupos de stakeholders y, por lo general, esta decisión la toma la persona que tiene más poder de decisión por parte del cliente” 3. ¿Cómo es la selección de stakeholders dentro de la organización? “Es muy básica, por cuanto es muy común que deleguen a una persona dentro de la organización para identificar los involucrados o simplemente para dirigirse a la persona que paga el desarrollo” Del anterior ejercicio se puede concluir lo siguiente: 1. Identificar los stakeholders es uno de los procesos más importantes para establecer las bases tempranas dirigidas a la planificación, ejecución y monitoreo y control de la información y comunicación del proyecto para alcanzar el éxito. 2. Se debe analizar el contexto de requerimientos de negocio de acuerdo con el punto de vista de cada uno de los stakeholders. 3. validar la incorporación de un lenguaje generico para los stakeholders y ası́ poder modelar de manera uniforme los requerimientos. El sistema de actividad humana para proponer requerimientos alineados con los objetivos empresariales es evaluado a través de debate con algunos usuarios finales o clientes de proyecto que apoyaron la encuesta.. 59.

(65) Consultamos a los encuestados que tenı́an asociado el rol de clientes o usuarios finales respecto a las caracterı́sticas del proyecto de software que estaban evaluando, a lo cual se obtuvieron respuestas del tipo: desarrollo de funcionalidades, integración de plataformas, información de determinado módulo. Esto nos lleva a considerar dos posibilidades: O bien, los encuestados son usuarios de bajo rango, o, los proyectos de software no tenı́an un propósito estratégico. Se indagó entonces al respecto con usuarios finales y clientes con posiciones de alta jerarquı́a de una compañı́a del sector Telecomunicaciones. Las respuestas obtenidas fueron similares, sus expectativas del software se orientan a tres aspectos principalmente:. • Automatización de tareas operativas • Reducir la interacción con el sistema • Optmizar procesos de negocio Al traer a revisión el modelo conceptual propuesto, se identificó como un proceso propio de arquitectura empresarial más que de desarrollo o implementación de software. Se realizó entonces la aplicación del modelo conceptual sobre los requerimientos de un desarrollo que tenı́a por requerimientos: • Permitir el ingreso masivo de registros de costos (entre 2 y 20 registros simultaneamente) • Crear automáticamente los asientos contables que correspondı́an con cada registro Tras la aplicación del modelo conceptual, tomando como base el objetivo de negocio ”Reducir en un 30 % los costos de operación” los requerimientos fueron cambiados por: • Generación de reportes y dashboards para monitoreo de costos • Integración del proceso de compras al de Ingenierı́a de negocios • Creación automática de los costos emergentes del proceso de Ingenierı́a de negocios y sus correspondientes asientos contables Del ejercicio anterior es posible identificar los siguientes cambios: 60.

(66) 1. Alinear el proceso de elicitación de requerimientos con la visión y estrategia de la compañı́a, facilita la identificación de los mismos. 2. Una perspectiva holı́stica de la compañı́a y sus procesos permite entender las aplicaciones de software como herramientas de apoyo a la estrategia. El SAH para realizar pruebas de concepto resuelve principalmente las fallas de expectativa de los sistemas de información (Lyytinen K. and Hirschheim R., 1988). Con base en lo expresado por los participantes, se crea un modelo de desarrollo cercano a la realidad que cubra los aspectos mayormente calificados e la encuesta, para ser comparado con el SAH en cuestión. El resultado es expuesto en la figura 3.39.. Figura 3.39: Modelo conceptual del proceso de ingenierı́a de requerimientos. Elaborado a partir de 3.2 Como resultado de la comparación de este modelo con 3.33 se identifican varios cambios: 1. Incluir el término ”prueba de concepto” en el procedimiento de desarrollo, puesto que ahora es utilizado como una actividad previa a la. 61.

(67) compra de una herramienta. Si bien son presentados los bocetos de interfaz gráfica a los usuarios, no cumplen con el objetivo de una PoC, que de acuerdo con (Kotler, 2002) consiste en ”presentar el concepto de producto a los consumidores... y determinar sus reacciones.” 2. La validación del alcance del proyecto a través de la presentación de un concepto reduce la cantidad de re-procesos en etapas posteriores. Al tener ciclos más cortos de verificación y ajuste, los tiempos podrı́an también verse impactados positivamente.. 62.

(68) 3.5.. Identificación de cambios factibles y deseables. Una vez concluida la etapa 5 3.4, la comparación realizada dará lugar a un conjunto de resultados que pueden ser considerados como sugerencias, esto conduce a la fase 6, en la cual se recopilan las recomendaciones de cambio, que serán evaluadas para determinar su deseabilidad y viabilidad en conformidad con el análisis realizado previamente y la dimensión cultural del contexto. Estos cambios, que conformarán lo ”que” se desea hacer, deben ser posteriormente implementados mediante el establecimiento de un ”como” en la fase final de la metodologı́a. Dichos cambios pueden ser de tres tipos diferentes: Cambios de Actitud: Comprenden cambios sobre la conciencia individual y/o colectiva de quienes interactuan en el sistema. Cambios Estructurales: Constituyen cambios sobre los componentes del sistema que tienen baja probabilidad de variación a corto plazo, tales como la estructura organizacional, infraestructura, etc. Cambios de Procedimiento: Son aquellos que se realizan sobre elementos dinámicos, es decir, que se modifican constantemente para optimizar los resultados o situaciones. Pueden afectar las actividades que se ejecutan, la forma o secuencia en que se ejecutan o añadir nuevas actividades. Para el caso de estudio, nos enfocaremos principalmente en los cambios de procedimiento, puesto que no es del alcance de este trabajo sugerir o realizar cambios en estructuras organizacionales o en el comportamiento de los participantes de la investigación. A continuación se recopilan los cambios de procedimiento identificados en la sección 3.4: 1. Optimización de tiempos, producto de entregas funcionales parciales y delimitación del alcance del proyecto por etapas. 2. Contextualización a los demás miembros del equipo de trabajo respecto al alcance y expectativas del usuario final. 3. Validar la comprensión de los requerimientos por parte de los miembros de los equipos de desarrollo y calidad. 4. Definir criterios de aceptación relacionados con la comunicación, es decir, no solo se debe medir el grado de asertividad en la identificación de requerimientos, sino en como son transmitidos. 63.

(69) 5. La evaluación de requerimientos guiada por la estrategı́a de negocio, cambia la perspectiva de las personas involucradas respecto al uso y expectativa de las herramientas de software. 6. Realizar entregas funcionales parciales que permitieran validar el cumplimiento de las expectativas del usuario final. 7. Tener un alcance claramente especificado conlleva a la optimización de lo tiempos de entrega y construir aplicaciones escalables. 8. Alinear el proceso de elicitación de requerimientos con la visión y estrategia de la compañı́a, facilita la identificación de los mismos. 9. Una perspectiva holı́stica de la compañı́a y sus procesos permite entender las aplicaciones de software como herramientas de apoyo a la estrategia.. 64.

(70) Capı́tulo 4 RESULTADOS Y CONCLUSIONES En esta sección se presenta el resultado esperado del trabajo: Un procedimiento basado en los aspectos evaluados sobre la elicitación de requerimientos a través de la metodologı́a de sistemas suaves. También son presentadas las conclusiones finales sobre la ejecución del presente trabajo y las propuestas de acciones para realizar a futuro con base en los resultados obtenidos.. 4.1.. Propuesta de procedimiento de elicitación de requerimientos. De acuerdo con (ISO 9000, 2005) un proceso es ”una actividad o un conjunto de actividades que utiliza recursos, y que se gestiona con el fin de permitir que los elementos de entrada se transformen en resultados”. En esta definición encontramos cuatro componentes fundamentales de un proceso: Entradas: Consisten en especificaciones, recursos o registros que provienen usualmente de otros procesos. Actividades: Tareas a ejecutar en el marco del proceso. Recursos: Todo aquello que es necesario para la correcta ejecución del proceso, pueden comprender personas, herramientas, infraestructura, entre otros. 65.