Presentado por: John Jairo Morenorepository.udistrital.edu.co/bitstream/11349/7525/1... · 3.31....

DISENO DE UN PROCEDIMIENTO PARA IDENTIFICACION DEREQUERIMIENTOS EN LA CONSTRUCCION DE SOFTWARE

FORMULADO DESDE LA METODOLOGIA DE SISTEMAS SUAVES.

Presentado por:Luisa Fernanda Gomez Munoz

[email protected]

John Jairo Moreno20171099013

[email protected]

Grupo 1

Proyecto de grado para optar al tıtulo de Especialistas en Ingenierıade Software

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDASFACULTAD DE INGENIERIA

PROYECTO CURRICULAR DE INGENIERIA DE SISTEMASBOGOTA

2017

DISENO DE UN PROCEDIMIENTO PARA IDENTIFICACION DEREQUERIMIENTOS EN LA CONSTRUCCION DE SOFTWARE

FORMULADO DESDE LA METODOLOGIA DE SISTEMAS SUAVES.

Presentado por:Luisa Fernanda Gomez Munoz

[email protected]

John Jairo Moreno20171099013

[email protected]

Director:Sandro Javier Bolanos Castro

Revisor:Sandra Milena Cortes Munoz

Proyecto de grado para optar al tıtulo de Especialistas en Ingenierıade Software

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDASFACULTAD DE INGENIERIA

PROYECTO CURRICULAR DE INGENIERIA DE SISTEMASBOGOTA

2017

AGRADECIMIENTOSAgradecemos al Ingeniero Sandro Javier Bolanos Castro y la Ingeniera Sandra

Milena Cortes Munoz que con gran profesionalismo asesoraron nuestro proyectode investigacion.

A los companeros de especializacion y amigos que nos retroalimentaron yparticiparon de alguna manera en nuestro proyecto.

Un especial agradecimiento a la Universidad Distrital Francisco Jose de Cal-das Facultad de Ingenierıa, institucion donde realizamos nuestros estudios de post-grado y adquirimos el conocimiento para llevar a cabo este proyecto.

I

INTRODUCCION

Uno de los principales problemas en los proyectos de desarrollo de softwarees la falta de comprension parcial o total de los requerimientos. En esta etapael cliente y el desarrollador juegan un papel muy importante, ya que el primerodescribe su necesidad y el otro debe entenderla para dar la solucion tecnica masadecuada.

La especificacion de requerimientos tiene un alto grado de complejidad y enmuchos casos ha sido el factor que mas influye en el fracaso de los proyectos desoftware (Hastie S. and Wojewoda S., 2015), por esta razon se han desarrolladometodologıas para facilitar la identificacion de los requisitos.

La metodologıa de sistemas suaves, en adelante MSS, surgio como una alter-nativa para entender y describir los problemas existentes en los sistemas socio-culturales; fue formulada por un equipo de investigadores de la Universidad deLanchaster constituido al final de los anos 60.

El presente proyecto pretende aplicar la MSS en el estudio de las caracterısticaspropias del procedimiento de identificacion de requerimientos como etapa fun-damental en la construccion de software, con el fin de incorporar al analisis elcomponente social que define a los actores que intervienen en el proceso. Esta in-vestigacion nace de la necesidad de disminuir los fallos en la implementacion desistemas de informacion que son evidenciados en la literatura y el quehacer diariode los autores.

En el primer capıtulo 1 se establece el contexto de la investigacion, se realizauna descripcion de la metodologıa de sistemas suaves y la ingenierıa de requeri-mientos, por ultimo se presenta un primer acercamiento de la situacion problemaque se pretende analizar.

En 2 se avanza con el diseno y explicacion de las herramientas necesarias pararecopilar la informacion que sirve como insumo para el desarrollo de la investi-gacion, el cual es descrito en 3. Las secciones de este capıtulo corresponden conlas fases de la metodologıa de sistemas suaves: En primera instancia se presenta

II

la situacion problema no estructurada 3.1, tras la aplicacion de la encuesta, losresultados obtenidos se presentan en forma de situcacion problema expresada 3.2.A partir de la informacion anterior se crean las definiciones raız, los sistemas deactividad humana correspondientes y modelos conceptuales en 3.3, para luego sercomparados con la situacion problema real en 3.4. Esta comparacion da lugar aun conjunto de cambios deseables identificados en 3.5.

Por ultimo, en 4 se muestran los resultados obtenidos y conclusiones finalesdel trabajo. Haciendo uso de los cambios emergentes se construye el diseno delprocedimiento propuesto y es presentado en 4.1.

III

Indice general

AGRADECIMIENTOS . . . . . . . . . . . . . . . . . . . . . . . . . . IINTRODUCCION . . . . . . . . . . . . . . . . . . . . . . . . . . . . II

1. CONCEPTUALIZACION 61.1. Metodologıa de Sistemas Suaves . . . . . . . . . . . . . . . . . . 61.2. Ingenierıa de requerimientos . . . . . . . . . . . . . . . . . . . . 71.3. Situacion problematica a abordar . . . . . . . . . . . . . . . . . . 13

2. DISENO DE LA INVESTIGACION 152.1. Diseno de la encuesta para obtencion de datos . . . . . . . . . . . 15

3. DESARROLLO DE LA INVESTIGACION 183.1. Situacion de problema no estructurada . . . . . . . . . . . . . . . 183.2. Situacion de problema expresada . . . . . . . . . . . . . . . . . . 22

3.2.1. Resultados de la fase . . . . . . . . . . . . . . . . . . . . 423.3. Definiciones Raız y Sistemas de Actividad Humana . . . . . . . . 443.4. Comparacion de modelos conceptuales con la realidad . . . . . . 563.5. Identificacion de cambios factibles y deseables . . . . . . . . . . 63

4. RESULTADOS Y CONCLUSIONES 654.1. Propuesta de procedimiento de elicitacion de requerimientos . . . 654.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.2.1. Sobre la metodologıa aplicada . . . . . . . . . . . . . . . 724.2.2. Sobre los datos recopilados . . . . . . . . . . . . . . . . . 734.2.3. Sobre el procedimiento analizado y propuesto . . . . . . . 73

4.3. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

1

Indice de figuras

1.1. La metodologıa de Checkland. Fuente:(Checkland, 1981) . . . . . 71.2. Ciclo Experiencia - Accion. Fuente: (Checkland P. and Scholes J.,

1994) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1. Formula para calculo del Tamano de la Muestra. Fuente:(A. Martınezet al., 2004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1. Diseno Encuesta, parte 1. Fuente:Elaboracion propia . . . . . . . 203.2. Diseno Encuesta, parte 2. Fuente:Elaboracion propia . . . . . . . 203.3. Tamano de Muestra por Rol. Fuente:Elaboracion propia . . . . . . 223.4. Analista:Tipos de organizaciones. Fuente:Elaboracion propia . . . 233.5. Analista:Tecnicas de levantamiento de requerimientos. Fuente:Elaboracion

propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.6. Analista:Modelos de prototipo. Fuente:Elaboracion propia . . . . 243.7. Analista:Caracteristicas levantamiento de requerimientos. Fuen-

te:Elaboracion propia . . . . . . . . . . . . . . . . . . . . . . . . 253.8. Analista:Duracion del proyecto. Fuente:Elaboracion propia . . . . 263.9. Analista:Duracion real del proyecto. Fuente:Elaboracion propia . . 263.10. Analista:Cumplimiento de las espectativas. Fuente:Elaboracion pro-

pia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.11. Analista: caracteristicas involucrados en el proyecto. Fuente:Elaboracion

propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.12. Analista: Madurez equipo de trabajo. Fuente:Elaboracion propia . 283.13. Programador:Tipos de Organizacion. Fuente:Elaboracion propia . 303.14. Programador:Tipos de Tecnicas de Elicitacion. Fuente:Elaboracion

propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.15. Programador:Modelos de Prototipado. Fuente:Elaboracion propia 313.16. Programador:Calificacion de las caracterısticas de los requerimien-

tos. Fuente:Elaboracion propia . . . . . . . . . . . . . . . . . . . 32

2

3.17. Programador:Cumplimiento de las Expectativas del Cliente. Fuen-te:Elaboracion propia . . . . . . . . . . . . . . . . . . . . . . . . 32

3.18. Lıder o PM: Tipo de Organizacion. Fuente:Elaboracion propia . . 343.19. Lıder o PM: Tipo de Tecnicas. Fuente:Elaboracion propia . . . . . 343.20. Lıder o PM: Ciclos de Desarrollo. Fuente:Elaboracion propia . . . 353.21. Lıder o PM: Modelos de Prototipado. Fuente:Elaboracion propia . 353.22. Lıder o PM: Calificacion de las caracterısticas de requerimientos.

Fuente:Elaboracion propia . . . . . . . . . . . . . . . . . . . . . 363.23. Lıder o PM: Cumplimiento de expectativas del cliente. Fuente:Elaboracion

propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.24. Usuario:Tipo de organizaciones . Fuente:Elaboracion propia . . . 383.25. Usuario:Tecnicas de levantamiento de informacion . Fuente:Elaboracion

propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.26. Usuario:Caracteristicas de los proyectos . Fuente:Elaboracion propia 393.27. Usuario:Duracion de los proyectos . Fuente:Elaboracion propia . . 403.28. Usuario:Cumplimiento de las expectativas . Fuente:Elaboracion

propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.29. Sistema de Actividad Humana para el desarrollo de software usan-

do prototipos. Fuente: Elaboracion propia . . . . . . . . . . . . . 463.30. Sistema de Actividad Humana para comunicar los requerimientos

eficazmente. Fuente: Elaboracion propia . . . . . . . . . . . . . . 483.31. Sistema de actividad humana para proponer requerimientos ali-

neados con los objetivos empresariales. Fuente: Elaboracion propia 503.32. Sistema de actividad humana para involucrar a los usuarios finales

en el desarrollo del proyecto. Fuente: Elaboracion propia . . . . . 513.33. Sistema de actividad humana para realizar pruebas de concepto.

Fuente: Elaboracion propia . . . . . . . . . . . . . . . . . . . . . 523.34. Sistema de actividad humana para involucrar a los stakeholders . . 533.35. Sistema de actividad humana para desarrollar software usando in-

terfaces y flujos de la solucion . . . . . . . . . . . . . . . . . . . 543.36. Sistema de actividad humana para obtener informacion sobre el

alcance antes de iniciar el proyecto . . . . . . . . . . . . . . . . . 553.37. Comparacion SHA para el desarrollo de software usando prototi-

pos. Fuente: Este trabajo . . . . . . . . . . . . . . . . . . . . . . 573.38. SAH para comunicar requerimientos. Fuente: Elaboracion propia . 583.39. Modelo conceptual del proceso de ingenierıa de requerimientos.

Elaborado a partir de 3.2 . . . . . . . . . . . . . . . . . . . . . . 61

3

4.1. Ciclo de vida del desarrollo de software. Fuente: (PMO Informatica,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: Elaboracion propia 71

4

Indice de tablas

3.1. Diseno de la encuesta . . . . . . . . . . . . . . . . . . . . . . . . 213.2. Analista: Tendencia de datos . . . . . . . . . . . . . . . . . . . . 293.3. Programador: Tendencia de datos . . . . . . . . . . . . . . . . . . 333.4. Lıder o PM: Tendencia de datos . . . . . . . . . . . . . . . . . . 373.5. Cliente, Usuario final: Tendencia de datos . . . . . . . . . . . . . 41

4.1. Caracterizacion del procedimiento IVC de Necesidades de soft-ware. Fuente: este proyecto . . . . . . . . . . . . . . . . . . . . . 68

5

Capıtulo 1

CONCEPTUALIZACION

La presente investigacion adopta un nivel de estudio descriptivo, puesto quepretende a traves de la aplicacion de una metodologıa previamente definida, iden-tificar caracteristicas propias de los procedimientos utilizados en la construccionde requerimientos de software que conlleven a una posible mejora de los mismos.con este fin, son explorados comportamientos sociales dentro de la(s) organiza-cion(es) que constituyen el caso de estudio y que, reflejan en alguna medida, larealidad de las empresas colombianas en esta materia.

1.1. Metodologıa de Sistemas SuavesLa MSS proporciona un paradigma orientado al aprendizaje, aplicado a pro-

blemas no estructurados, normalmente asociados a situaciones en las que hay unalto componente de subjetividad (Cardoso E.O. et al., 2013).

Esta disenada como un proceso de siete etapas en el cual se diferencian aque-llas fases que son propias del mundo real y las que se derivan del analisis sistemico,como puede verse en 1.1. La MSS encuentra su fundamento en el ciclo de experiencia-accion, modelado por el autor y que define el proceso de conocimiento de un hu-mano en el mundo real, el cual surge de la experiencia, que lo conlleva a tomaracciones, de las cuales se derivan nuevas experiencias, ver figura 1.2 (ChecklandP. and Scholes J., 1994).

6

Figura 1.1: La metodologıa de Checkland. Fuente:(Checkland, 1981)

Figura 1.2: Ciclo Experiencia - Accion. Fuente: (Checkland P. and Scholes J.,1994)

1.2. Ingenierıa de requerimientosLos requerimientos de un sistema, son basicamente, la informacion relaciona-

da con el mismo (Geogy M. and Dharani A., 2016). Partiendo de la definicion de(Bertalanffy, 1968), un sistema comprende un conjunto de elementos interreala-cionados y las relaciones establecidas entre ellos, proporcionandole caracterısticasestructurales y comportamentales. Por otra parte, la informacion, en concordan-cia con la teorıa que la estudia, es una cantidad mesurable de organizacion en unsistema (Johansen, 2004), de acuerdo con lo anterior; de la complejidad de lasrelaciones de los elementos, depende el esfuerzo o energıa requerida para recopi-lar, procesar, resguardar y dar a conocer dicha cantidad de datos. La ingenierıa derequerimientos, provee un conjunto de herramientas y tecnicas para realizar estas

7

actividades en un sistema computacional.La ingenierıa de requerimientos, tiene por objetivo definir y describir las ne-

cesidades del sistema, ası como gestionar los cambios sobre los requisitos en elproceso de desarrollo de software. Dichas necesidades son expresadas en diferen-tes tipos de requerimiento, que en conjunto determinan la funcionalidad, estruc-tura, desempeno y demas aspectos que caracterizan al sistema. Usualmente, lascaracterısticas del sistema a construir son conocidas y definidas por los interesa-dos en el desarollo del mismo y fundamentados en procedimientos previamentedefinidos. Lo anterior genera que, a medida que se avanza en la descripcion de losrequisitos, lo que se ha definido previamente sufra constantes cambios (ZielinskiK. and Szmuc T, 2005). La IR surge como respuesta a los mas recurrentes errorescometidos en el traspaso de informacion, para lograr que se produzca de la maneramas fluida posible. De acuerdo con (Zielinski K. and Szmuc T, 2005) las princi-pales falencias en el desarrollo de las actividades de elicitacion de requerimientosconstituyen:

Permitir que los requerimientos no tengan coherencia entre ellos o se regis-tren multiples veces.

No priorizar adecuadamente para evitar consumir tiempo de desarrollo enaquellos que no son realmente necesarios o pueden ser abarcados en versio-nes posteriores

No llevar un seguimiento claro entre los requerimientos que fueron defini-dos y aquellos que han sido implementados.

No incluir en el proyecto la totalidad de los requerimientos, incumpliendoası la expectativa del cliente final.

Iniciar el desarrollo y realizar estimaciones de tiempo sin haber ejecutadola fase de analisis previamente.

Principales Tecnicas de Elicitacion de Requerimientos

Existen diversos metodos que facilitan la obtencion de los requisitos de unsistema, a continuacion se nombran los mas usados comunmente:

Entrevistas: Constituyen sesiones con los interesados del proyecto, en lasque se realizan uns serie de preguntas para conocer sus expectativas y de-terminar los requisitos del proyecto. Las entrevistas pueden ser cerradas,

8

aquellas en las que se cuenta con un listado de preguntas previamente pre-parado, o abiertas, en las que no se han estructurado las preguntas, sino quese 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 tecnica es considerada poco eficaz, debido a que usualmente, laspersonas entrevistadas no son exhaustivas en la descripcion de sus funcio-nes y los conceptos relacionados con su trabajo, puesto que para ellos, sontriviales. Por esta razon, siempre se recomienda usarla como complementode otras tecnicas.

Escenarios: Para los usuarios de una herramienta de software resulta masfacil compartir sus conocimientos relacionados con las actividades que rea-lizan a traves de ejemplos. La descripcion de estas situaciones particularesse conoce como escenario (Hadad G. et al., 1998). usualmente se encuen-tran los siguientes componentes en la documentacion de un escenario: titulo,objetivo, contexto del sistema en el que se presenta, condiciones requeridaspara que se de inicio a la situacion particular, flujo normal de eventos, res-tricciones y excepciones que puedan presentarse, condiciones de salida yposibles flujos alternos de eventos. Esta tecnica proporciona mayor detallede los requerimientos que las entrevistas.

Casos de uso: Quizas esta corresponda a la tecnica mayormente adoptada;fue presentada por Ivar Jacobson en 1991 (Hunt, 2002) en el metodo Ob-jectory Method, corresponde a la representacion de la interrelacion de losusuarios (actores) con el sistema, a traves de funciones (usos). El ObjectoryMethod describe tres fases que constituyen un conjunto de modelos: modelode casos de uso, modelo de dominio y modelo de interfaz de usuario. Anosmas tarde, el modelo fue adoptado como una caracterıstica principal en lanotacion UML.

Prototipos: Los prototipos son versiones preliminares del sistema a desa-rrollar, para trabajar con ellos es necesario que la aplicacion sea modulariza-ble, con el fin de minimizar tiempos en la fase de construccion del prototipoy se incluyan funcionalidades importantes, pero no necesariamente todaslas identificadas (Kendall K. and Kendall J., 2005). El modelo sera iteradoen varıas ocasiones para permitir su evolucion, hasta alcanzar los resulta-dos esperados. De esta manera, el usuario podra visualizar rapidamente elavance del desarollo.

9

Aspectos Sociales en Ingenierıa de Requerimientos

De acuerdo con (Sommerville, 2005): ”los ingenieros de sistemas no solo tra-tan con el software, sino tambien con el hardware y las interacciones de los siste-mas con los usuarios y su entorno...necesitan tener conocimientos en ingenierıade sistemas, porque los problemas dela ingenierıa de software son a menudo elresultado de las decisiones de la ingenierıa de sistemas”. Esta dinamica socio-tecnica, exige que, para el correcto dimensionamiento y diseno del sistemas, seanadoptadas estrategias que faciliten la definicion de actividades estructuradas par-tiendo de un problema con cierto grado de complejidad, narrado en lenguaje na-tural.

Por lo anterior, se han realizado investigaciones que incorporan herramientasde entendimiento de sistemas sociales en las fases de obtencion y validacion derequerimientos las herramientas de software (Niu N. et al., 2011).

Ambiguedad en la documentacion

En investigacion liderada por (Muhtasham A. et al., 2016) en el COMSATSInstitute of Information Technology, se analizaron los inconvenientes que puedenpresentarse durante la definicion de requerimientos de software y que alteran elentendimiento del dominio. En su publicacion, identifican atributos de los reque-rimientos que los hace dificiles de expresar, tales como que puedan provenir dediferentes fuentes y no ser obvios, no sean faciles de expresar de manera consis-tente en lenguaje natural, no sean unicos y se relacionen estrechamente con otrosrequerimientos. Detectan entonces diferentes clases de ambiguedades en la lec-tura de los requisitos documentados, propias del lenguaje natural: ambiguedadlexica, cuando las palabras utilizadas para describir el requerimiento puede tenermas de un significado; ambiguedad sintactica, una frase puede interpretarse dediferentes maneras dada su estructura gramatical; ambiguedad semantica, ocu-rre cuando una frase tiene varias interpretaciones en su contexto y ambiguedadpragmatica, en la cual, el significado de un frase esta sujeto al entendimiento dequien la lee.

Validacion de Requerimientos

De acuerdo con la norma ISO 9000...2005 ISO 9000 (2005), que se encarga

de la especificacion de la terminologıa a utilizar para los sistemas de gestion decalidad, cuyos requisitos de diseno de producto se encuentran definidos en la nor-

10

ma ISO 9001, define la revision, verificacion y validacion de un producto de lasiguiente manera:

Revision: Actividad ejecutada sobre el producto o servicio que permite eva-luar la conveniencia y eficacia del mismo en relacion con los objetivos pre-viamente definidos.

Verificacion: Comprobacion del cumplimiento de los requisitos especifica-dos.

Validacion: Comprobacion del cumplimiento de los requisitos, para un usoespecifico, es decir, que el producto tenga la capcidad de satisfacer los re-querimientos del cliente.

En el proceso de desarrollo de software, la ejecucion de estas tres actividadeses fundamental en el aseguramiento de calidad del producto final y su planeaciony resultado dependen en gran medida de la buena descripcion que se haya reali-zado de los requisitos del software. Para llevar a cabo estas actividades puedenser empleadas diferentes tecnicas, tales como la construccion de prototipos, ca-sos de pruebas o creacion de equipos de trabajo que involucren a los interesadosy responsables en el proceso. (Sommerville, 2005) identifica diferentes tipos deverificacion a llevar a cabo sobre los requerimientos:

Verificaciones de validez: Comprobar que los requerimientos sean validosen relacion con las funcionalidades a cumplir. Estas funciones deben corres-ponder con las esperadas por parte de los interesados.

Verificaciones de consistencia: Los requerimientos han de ser claros, cohe-rentes y no contradictorios.

Verificaciones de completitud: Todos los tipos de requerimieno deben sertenidos en cuenta en la documentacion, si bien, siempre pensamos primeroen la funcionalidad de las aplicaciones, es necesario tener en cuenta losrequistos no funcionales que proporcionan directrices sobre el desempeno,usabilidad, seguridad del software, entre otras.

Verificaciones de realismo: Dadas las restricciones en cuanto a recursos ypresupuesto, es importante validar que los requisitos expuestos puedan serejecutados tecnicamente.

11

Verificabilidad: Para poder ejecutar la actividades de verificacion del pro-ducto final, es importante que se defina para los requerimientos, posiblesescenarios de pruebas.

Cambios sobre los requerimientos

La organizacion es un sistema abierto de complejidad creciente, por ende susprocesos y estructura no pueden ser estaticos. Los requisitos de software tienenuna estrecha relacion con los requisitos de arquitectura empresarial y lo objetivosdel negocio, es por esto que su evolucion es inevitable (Sommerville, 2005). Lostiempos de implementacion de una herramienta de software son directamente pro-porcionales al tamano del mismo, durante este delta de tiempo, la organizacion,procesos, objetivos y en consecuencia los requisitos pueden presentar cambios.De acuerdo con el autor, los requerimientos pueden, desde esta perspectiva, ser dedos clases:

Duraderos: Estan relacionados con el dominio del sistema, por lo que laprobabilidad de cambio es mınima.

Volatiles: Tienen una lata probabilidad de presentar modificaciones, ya seaen el transcurso del proceso de desarrollo o posterior a la implementaciondel sistema.

Teniendo como base la realidad anteriormente descrita, resulta importantecontar con un proceso claro de gestion de cambios para asegurar la consisten-cia y evolucion de los mismos. (Sommerville, 2005) propone tres fases dentro dedicho proceso.

Analisis del problema y especificacion del cambio: En esta etapa se validantecnica y funcionalmente los cambios a ser incorporados.

Analisis del cambio y calculo de costes: Partiendo del conocimiento delalcance y requerimientos del sistema y haciendo uso de tecnicas de estima-cion, en esta fase se evalua el impacto del cambio en los recursos y el duenodel sistema toma la decision con base en estos datos, para incorporar o no,el cambio al proyecto.

Implementacion del cambio: Se deben actualizar todos los documentos im-pactados: requerimientos, cronograma del proyecto, escenarios, etc.

12

1.3. Situacion problematica a abordarLa IR implica la ejecucion de multiples actividades que tienen estrecha rela-

cion con el contexto humano (expectativa, intencion, organizacion, estructura so-cial, etc.), entre ellas se encuentran, pero no se restringen a: la planeacion, enten-dimiento, elicitacion, modelado, analisis, comunicacion, validacion, aceptacion,evolucion, negociacion y priorizacion de los requerimientos para el diseno y desa-rrollo de los componentes de software (Niu N. et al., 2011). Este hecho conllevaa la atribucion de responsabilidad sobre las fallas en los sistemas de informaciona las complejas relaciones sociales. En (Lyytinen K. and Hirschheim R., 1988) yase mencionaban cuatro tipos de fallas presentadas en los sistemas de informacionderivados de esta relacion:

Falla de correspondencia: Se presenta si los objetivos de diseno fueronpreviamente 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 recursosde los presupuestados.

Falla de interaccion; Si un usuario usa recurrentemente el sistema, estoquiere decir que este cumple con su objetivo final y el usuario esta satisfechocon su funcionamiento, por otra parte, si la interaccion con el sistema es bajao nula, esto quiere decir que hay una falla por resolver.

Falla de expectativa: El sistema no cumple las expectativas de los usuariosfinales.

En estudios mas recientes, se ha demostrado que, si bien se han incorporadonuevas herramientas metodologicas en la fase de elicitacion de requerimientos desoftware, el porcentaje de proyectos que no son considerados como exitosos aunes importante. De acuerdo con (Hastie S. and Wojewoda S., 2015), en el ano depresentacion del reporte, el 52 % de los proyectos fueron discutidos y el 19 % seconsideraron fallidos, por otra parte, entre los princiales factores de exito del 29 %restante de los proyectos se consideraron aspectos ”blandos”:

Apoyo de la direccion

Madurez emocional de los participantes

13

Implicacion del usuario final en la definicion de los requerimientos del sis-tema

Nivel de competencia de los recursos

Objetivos claramente definido

Procesos agiles de desarrollo

14

Capıtulo 2

DISENO DE LA INVESTIGACION

La seccion anterior nos da el contexto de la investigacion a realizar, sin em-bargo, para proceder con la aplicacion de la metodologıa de sistemas suaves esnecesario contar con datos que nos permitan efectuar el analisis correctamente, esdecir, compresiones subjetivas de la realidad cercanas al sistema de construccionde software conocido y que comprende nuestra realidad. Con este fin, fueron ele-gidas dos herramientas: encuestas y recopilacion de investigaciones previas. En elpresente capıtulo se describe el diseno y uso de dichas herramientas.

2.1. Diseno de la encuesta para obtencion de datosComo herramienta principal de recopilacion de informacion se hizo uso de

una encuesta con las siguientes caracteristicas:

Ficha Tenica de la encuesta:

1. Poblacion objetivo: Profesionales en Ingenierıa que participen en el proce-so de construccion de software en una organizacion y usuarios o clientesque hayan participado en un proyecto de implantacion o construccion desoftware.

2. Tipo de Muestreo: Con el fin de conocer a las personas que contestan laencuesta, para en un momento determinado, de ser necesario, contactarlas yrealizar entrevistas personales para ası facilitar la aplicacion de la MSS, seutiliza un muestreo no probabilıstico intencional (Avila, 2006).

15

3. Tamano de la muestra: El tamano de la muestra se determina en conformi-dad con las siguientes caracterısticas:

Tamano de la poblacion: Comprende el numero total de personas alque desea realizarse la encuesta. En el cotexto de este proyecto, laspoblacion esta conformada por los empleados del area de desarrollode las empresas en las que los autores ejecutan sus actividades pro-fesionales, incluyendo algunos usuarios finales y la totalidad de estu-diantes de las especializaciones en Ingenierıa de software y Gestionde proyectos de software de la Universidad Distrital Fransciso Jose deCaldas. El tamano de la poblacion es de 100 personas.

Nivel de confianza: En el caso de estudio, no es necesario que el valorreal sea aproximado al 100 % puesto que es para nosotros mas valiosoconocer la realidad de cada uno de los participantes y su vision delproceso que la asertividad con respecto a lo que se desea o esperade las actividades relacionadas con las IR. Por esta razon, el nivel deconfianza definido es del 80 %.

Margen de error: Corresponde al porcentaje de respuesta que puedenvariar en la muestra. Dado el nivel de confianza establecido, el margende error para la encuesta es en proporcion del 5 %

El tamano de la muestra esta determinado entonces por:

Figura 2.1: Formula para calculo del Tamano de la Muestra. Fuente:(A. Martınezet al., 2004)

Donde:

z = Cantidad de desviaciones estandar. Para el nivel de confianza estableci-do es de 1,28.p = nivel de confianza.e = Margen de error.

16

N = Tamano de la poblacion.

Entonces:

4. Forma de recoleccion de datos: La encuesta se realiza haciendo uso de for-mularios de google, la invitacion para la misma es enviada a traves de correoelectronico.

17

Capıtulo 3

DESARROLLO DE LAINVESTIGACION

La investigacion objeto de este proyecto se realiza en conformidad con lasfases propuestas en la Metodologıa de Sistemas Suaves. En el presente capıtulo semuestran la definicion, desarrollo y los resultados obtenidos tras la ejecucion decada etapa.

3.1. Situacion de problema no estructuradaDebido a que el problema tiene un contexto social, para nuestro caso de estu-

dio, organizaciones; se pretende, en conjunto con los involucrados e interesadosen el proceso de desarrollo de software, identificar los elementos que constituyenlas caracterısticas relacionadas con el poder, la comunicacion, estructura y demasactividades o relaciones propias del comportamiento humano en la ejecucion delas actividades relacionadas con el proceso en mencion.

Para la recopilacion de dicha informacion, dado el volumen de posibles parti-cipantes, se decidio que la aproximacion mas cercana serıa a traves de la ejecucionde una encuesta. Los pasos para la realizacion de la encuesta se encuentran sondetallados en la seccion 2.1.

Para establecer un listado de preguntas que nos permita comprender la situa-cion problema, es necesario definir inicialmente de manera lo que se requiereconocer de las personas a entrevistar.En el contexto de esta investigacion, la in-formacion principal que deseamos conocer es: ¿cuales son los metodos y tecnicasutilizados en las actividades de elicitacion y validacion de requerimientos y la

18

opinion de los involucrados o interesados en el proceso de desarrollo de softwareen relacion a las mismas?.

Haciendo uso anticipado de una etapa posterior de la MSS, podemos formularla pregunta anterior como una definicion raız(Checkland, 1981):

”Un sistema para que los involucrados e interesados en el proceso deconstruccion de software identifiquen los principales aspectos y efectos de las

tecnicas de recopilacion 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 desoftware.”

En conformidad con lo anterior, es posible identificar cinco aspectos diferen-tes(Nielsen, 1990):

1. Identificar el grado de participacion en el proceso de quien responde la en-cuesta (interesado o involucrado)

2. Entender las caracterısticas de las tecnicas de recopilacion de requerimien-tos utilizadas

3. Conocer los efectos (positivos y negativos) del uso de dichas tecnicas en elproceso desde la perspectiva de quien responde la encuesta

4. Conocer el contexto en el que se desarrolla el proyecto: tipo de negocio uorganizacion, tipo de proyectos, entre otros.

5. Identificar el nivel de experiencia y conocimiento de cada uno de los parti-cipantes

Con base en lo anterior, es posible dimensionar las preguntas a utilizar en laelaboracion de la encuesta:

19

Figura 3.1: Diseno Encuesta, parte 1. Fuente:Elaboracion propia

Figura 3.2: Diseno Encuesta, parte 2. Fuente:Elaboracion propia

20

Cuestionario: Las preguntas que conforman el cuestionario fueron expresadasen conformidad con el rol de cada participante:

Tabla 3.1: Diseno de la encuesta

ROL/ PREGUNTA Analista Programador PM/ Lıder Usuario¿En que tipo de organizacion serealizo el proyecto? X X X X

¿Cuales tecnicas se usan para laidentificacion derequerimientos? X X X X

¿Cuales modelos de prototipo utilizano utilizaron en el desarrollo? X X X

¿Cuales de las siguientes opciones deciclos de desarrollo describe mejor elusado en el proyecto?

X X X

Clasificacion de caracterısticas de losrequerimientos X X X

Duracion estimada del proyecto X X X XDuracion real del proyecto X X X XCumplimiento de expectativas delusuario final X X X X

Clasificacion de caracterısticas delproyecto X X X X

Durante los ultimos 5 anos, ¿Encuantos proyectos ha estadoinvolucrado?

X X X X

Recomendaciones para el proceso X X X X

Resultados: La encuesta fue atendida por 66 personas, numero que se en-cuentra en el rango del tamano de la muestra esperado. El detalle de las respuestasobtenidas se presenta en 3.2.

21

3.2. Situacion de problema expresadaPara el analisis de los resultados obtenidos tras la aplicacion de la encuesta,

se realizo un filtro por rol o perfil del encuestado, ya que las preguntas para cadauno varıan dependiendo de las actividades realizadas en el(los) proyecto(s) comose explico en 3.1.

Se pretende expresar la situacion problema mediante diagramas o graficos devisiones enriquecidas para contar con una vista mas objetiva y precisa, lograndohacer evidentes las posibles relaciones, su entorno y las situaciones conflictivas(epistemologıa).

Las cosmovisiones de las personas involucradas y las relacion con la situa-cion problema (fenomenologıa) se puede evidenciar tambien en la construccionde la situacion problema de manera estructurada. En la figura 3.3 se visualiza lacantidad de respuestas obtenidas de acuerdo al tipo de rol del participante.

Figura 3.3: Tamano de Muestra por Rol. Fuente:Elaboracion propia

22

A continuacion se presentan los resultados recopilados en funcion del rol quelos proporciona.

Analista

Se conoce como analista en la rama de la ingenierıa de software a aquel pro-fesional encargado de analizar sistemas informaticos y describir el problema es-pecıfico. En muchas empresas tambien es el encargado de revisar modelos o solu-ciones ya dadas (k. Kendall and J. Kendall, 2005).

Al indagar sobre el tipo de empresas en las que han laborado los analistas, seevidencia que los proyectos se han ejecutado principalmente en empresas de con-sultorıa y el sector financiero, figura 3.4, siendo esta ultima la de mayor tendencia.En la figura 3.5 se puede observar las tecnicas de levantamiento de requerimientos,siendo las historias de usuario, casos de uso y escenarios las mas usadas.

Figura 3.4: Analista:Tipos de organizaciones. Fuente:Elaboracion propia

23

Figura 3.5: Analista:Tecnicas de levantamiento de requerimientos. Fuen-te:Elaboracion propia

Figura 3.6: Analista:Modelos de prototipo. Fuente:Elaboracion propia

24

Figura 3.7: Analista:Caracteristicas levantamiento de requerimientos. Fuen-te:Elaboracion propia

Para los analistas, los objetivos de los requerimientos del usuario final se cum-plieron satisfactoriamente, tan solo el 6,3 % de los encuestados respondieron queno, el 43,8 % contestaron que se dio parcialmente y el 50 % indico que si se cum-plieron como se muestra en la figura 3.10.

En la figura 3.7 se observa la evaluacion hecha sobre algunas caracterısticas dela fase de identificacion de requerimientos, encontrando que la calificacion dadaa la claridad sobre el alcance del proyecto y la especificacion de requerimientoses considerablemente menor que la asignada a la priorizacion de requerimientos eimplicacion del usuario final en la definicion de los mismos. Es decir, que a pesarde que son involucrados los clientes, los analistas consultados indican no tenercompleta claridad sobre los requisitos o alcance.

25

Figura 3.8: Analista:Duracion del proyecto. Fuente:Elaboracion propia

Figura 3.9: Analista:Duracion real del proyecto. Fuente:Elaboracion propia

26

Figura 3.10: Analista:Cumplimiento de las espectativas. Fuente:Elaboracion pro-pia

Figura 3.11: Analista: caracteristicas involucrados en el proyecto. Fuen-te:Elaboracion propia

27

Figura 3.12: Analista: Madurez equipo de trabajo. Fuente:Elaboracion propia

28

Tabla 3.2: Analista: Tendencia de datos

CARACTERISTICA ESPECIFICACION VALOR

Tipo organizacionConsultorıa 33,3 %Financiera 33,3 %

Tecnicas de levantamientode requerimientos

Escenarios 15Casos de uso 15Historias de usuario 15

Caracterısticas requerimientos

Implicacion del usuario final 4Claridad en la especificacion de losrequerimientos 5

Claridad en el alcance 5Priorizacion 5

Ciclos de desarrollo Incremental 7

Caracterısticas Proyecto

Comunicacion involucrados 5Direccion/coordinacion del proyecto 5Alineacion con lo esperado por el usuario final 3-4Metodologıas y tecnicas aplicadas 4-5Madurez, compromiso de trabajo 4-5

Cumplimiento expectativas usuariofinal

Si 50 %Parcialmente 43,8 %

Duracion estimada del proyectoMenor a un ano 56,3 %Entre 1 y 3 anos 43,8 %

Duracion real del proyecto Mayor a la estimada 56,3 %

Modelo de prototipadoIncremental 8Interfaz de usuario 8

29

Programador

El programador o desarrollador, es el encargado de codificar el software yrealizar pruebas de tipo unitario. Es de gran importancia para el desempeno desus 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 encontramosque tan solo el 5 % de los encuestados se encuentran laborando en casas de desa-rrollo, ver figura 3.13. Es decir que esta actividad se lleva a cabo, principalmenteen empresas que deciden contratar un equipo de desarrollo o implementacion desoftware. En la figura 3.14 se pueden evidenciar los tipos de tecnicas utilizados encada uno de los proyectos, siendo, al igual que en el caso del analista, los casosde uso, historias de usuario y escenarios aquellas tecnicas que son mayormenteutiLizadas, lo anterior, debido a la tendencia creciente de las empresa por adoptarmetodologıas agiles de desarrollo (Hitachi, 2017). En la figura 3.15 se listan losmodelos de prototipado identificados por cada entrevistado, siendo la interface deusuario el mas reconocido.

Figura 3.13: Programador:Tipos de Organizacion. Fuente:Elaboracion propia

Se solicito a los programadores calificar de 1 a 5, algunos aspectos de losrequerimientos que les fueron entregados. Los resultados pueden apreciarse en lafigura 3.16.

En cuanto al cumplimiento de las expectativas del cliente, el 90 % de los pro-gramadores encuentra que fueron cumplidas en su totalidad o parcialmente, comose aprecia en la figura 3.17.

30

Figura 3.14: Programador:Tipos de Tecnicas de Elicitacion. Fuente:Elaboracionpropia

Figura 3.15: Programador:Modelos de Prototipado. Fuente:Elaboracion propia

31

Figura 3.16: Programador:Calificacion de las caracterısticas de los requerimien-tos. Fuente:Elaboracion propia

Figura 3.17: Programador:Cumplimiento de las Expectativas del Cliente. Fuen-te:Elaboracion propia

32

Tabla 3.3: Programador: Tendencia de datos

CARACTERISTICA ESPECIFICACION VALORTipo organizacion Telecomunicaciones 35,0 %


Historias de usuario 25,4 %Casos de uso 25,4 %Escenarios 22,7 %

Modelos de prototipadoIncremental 4Interfaz de usuario 5


Implicacion usuario final 4Claridad en la especificacion derequerimientos 3

Claridad en el alcance de losrequerimientos 3

Priorizacion de los requerimientos 4Cumplimiento expectativas delcliente Si 50,0 %

Duracion real del proyecto Parcialmente 40,0 %

33

Lıder o Director de Proyecto

El lıder del proyecto o lıder de equipo es el facilitador entre el equipo dedesarrollo y el cliente o usuario final. Se encarga de la gestion de cronogramasy seguimiento al desarrollo del proyecto. Los directores de proyecto encuestadoscoinciden con los analistas en que las tecnicas mas utilizadas en el levantamientode requisitos constituyen aquellas asociadas a metodologıas agıles de desarrollo,tales como las historias de usuario y el prototipado incremental es considerado elmodelo con mayor acogida. Ver figuras 3.19 y 3.21.

Figura 3.18: Lıder o PM: Tipo de Organizacion. Fuente:Elaboracion propia

Figura 3.19: Lıder o PM: Tipo de Tecnicas. Fuente:Elaboracion propia

En lo que a las caracterısticas de la fase de identificacion de requerimientosrespecta, como puede observarse en la figura 3.22, las personas que lideran el

34

Figura 3.20: Lıder o PM: Ciclos de Desarrollo. Fuente:Elaboracion propia

Figura 3.21: Lıder o PM: Modelos de Prototipado. Fuente:Elaboracion propia

proyecto de desarrollo, consideran que se debe mejorar la claridad en la especifi-cacion de los requerimientos identificados.

Se enfrentan entonces, las personas que cumplen este rol, a una insatisfaccionpor parte de los usuarios cercana al 40 %, segun se muestra en 3.23.

35

Figura 3.22: Lıder o PM: Calificacion de las caracterısticas de requerimientos.Fuente:Elaboracion propia

Figura 3.23: Lıder o PM: Cumplimiento de expectativas del cliente. Fuen-te:Elaboracion propia

36

Tabla 3.4: Lıder o PM: Tendencia de datos

CARACTERISTICA ESPECIFICACION VALORTipo organizacion Financiera 33,3 %


Historias de usuario 22,7 %Casos de uso 22,7 %Escenarios 22,7 %

Ciclos de desarrollo Incremental 37,0 %

Modelos de prototipadoIncremental 9Evolutivo 7


Implicacion usuario final 5Claridad en la especificacion derequerimientos 4

Claridad en el alcance de losrequerimientos 3

Priorizacion de los requerimientos 5Cumplimiento expectativas delcliente Si 61,9 %

Duracion real del proyecto Parcialmente 38,1 %

37

Cliente o Usuario Final

El usuario final o cliente es la persona o grupo de personas a la que va a desti-nada el producto de software, o en muchos casos quien conoce el funcionamientoy estructura. En el caso de ingenierıa de requerimientos, es la persona encargadade hacer la solicitud 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 organi-zacion de telecomunicaciones como lo indica la figura 3.24, ademas en este rolsigue la tendencia de las tecnicas de levantamiento de informacion como se puedeobservar en la figura 3.25:

EscenariosCasos de usoHistoria de usuario.En las caracterısticas principales de los proyectos se nota una baja calificacion

leve en la comunicacion entre los involucrados en el proyecto, como lo podemosobservar en la figura 3.26.

El cumplimiento de las expectativas por parte del usuario final esta dividido enel 55,6 con respuesta afirmativa y el 44,4 con respuesta negativa como lo indica lafigura 3.28 .

Figura 3.24: Usuario:Tipo de organizaciones . Fuente:Elaboracion propia

38

Figura 3.25: Usuario:Tecnicas de levantamiento de informacion . Fuen-te:Elaboracion propia

Figura 3.26: Usuario:Caracteristicas de los proyectos . Fuente:Elaboracion propia

39

Figura 3.27: Usuario:Duracion de los proyectos . Fuente:Elaboracion propia

Figura 3.28: Usuario:Cumplimiento de las expectativas . Fuente:Elaboracion pro-pia

40

Tabla 3.5: Cliente, Usuario final: Tendencia de datos

CARACTERISTICA ESPECIFICACION VALORTipo organizacion Telecomunicaciones 77,8 %Tecnicas de levantamientode requerimientos

Escenarios 5Entrevistas 5

Caracterısticas Proyecto

Comunicacion involucrados 3Direccion/coordinacion del proyecto 4Metodologıas y tecnicas aplicadas 4Madurez, compromiso de trabajo 4

Cumplimiento de espectativas Si 60 %No 40 %

Duracion estimada del proyectoMenor a un ano 50 %Entre 1 y 3 anos 50 %

Duracion real del proyecto Mayor a la estimada 56,3 %

41

3.2.1. Resultados de la faseUna vez se ha analizado la informacion recopilada es posible concluir lo si-

guiente respecto a los aspectos a evaluar identificados en 3.1:

Grado de participacion en el proceso de quien responde la encuesta: Enel diseno de la encuesta fueron planteados 4 roles diferentes: 3 participan-tes activos, analista, programador y lıder o director de proyecto, ademas unrol que corresponde al principal interesado, cliente o usuario final. Como seaprecia en la figura 3.3, se obtuvieron respuestas principalmente de Lıderesde proyecto y programadores, 62 % en total, estos dos roles usualmente evi-dencian en su quehacer diario los efectos de una buena o mala practica enla identificacion de requerimientos, por lo que el analisis posterior se veraenriqeucdido por su punto de vista.

El 24 % de los encuestados desempenan el rol de analistas en su organiza-cion, con este rango se completa la visual de las personas que participancomo ejecutores en un proyecto de desarrollo de software. El 14 % restantede las opniones proviene de personas que han tenido la oportunidad de serclientes o usuarios finales en el proyecto, su percepcion es de gran valorpara el desarrollo de este trabajo,

Caracterısticas de las tecnicas de recopilacion de requerimientos utili-zadas: El 48 % de los encuestados coincidio en que la tecnica mayormenteutilizada para especificar los requerimientos es la elaboracion de escena-rios, historias de usuario y casos de uso, usualmente identificados por me-dio de entrevistas, segun confirma el 38 % de los participantes. Las personasque usan prototipado como herramienta, suelen hacerlo en forma evolutiva(37 %) o incremental (43 %). Tambien son comunmente utilizadas las inter-faces de usuario (41 %).De igual manera, el ciclo de desarrollo empleadocon mayor frecuencia corresponde con el incremental, 41 %, seguido delmodelo en cascada con tan solo un 14 %.

Segun los datos anteriores, es posible identificar una tendencia en el uso deherramientas que permitan proporcionar avances al usuario final y eviden-ciar el avance del proyecto.

Efectos del uso de dichas tecnicas en el proceso: Al consultar a los en-cuestados respecto a las caracterısticas de los requerimientos entregados enel proyecto, las calificaciones mas bajas fueron asignadas a la claridad en la

42

especificacion tanto de los requerimientos como del alcance. Tambien fue-ron identificados problemas en la priorizacion de los requerimientos. Sinembargo, consideran que la implicacion del usuario final en el proceso fuesatisfactoria. El 39.7 % de los encuestados coincidieron en que las expecta-tivas del usuario final fueron satisfechas parcialmente, versus un 55 % queconsidera fueron cumplidas a cabalidad.

Contexto en el que se desarrolla el proyecto: Alrededor del 50 % de losparticipantes desarrollo el proyecto de software evaluado en empresas delsector tecnologıa o gobierno, mientras que el 77.8 % de los encuestados quedesempenaron el rol de cliente o usuario final pertenencen al sector teleco-municaciones. Lo anterior nos lleva a contar con evaluaciones mayormentede equipos que se encargan de desarrollar o implementar soluciones parasus propias empresas.

El 58 % indico que el proyecto tuvo una duracion mayor a la esperada. Elprimer equipo evaluado considera que las metodologıas y tecnicas aplica-das pueden mejorar, ası como la alineacion con el usuario final. Por otraparte, los clientes asignaron la calificacion mas baja a la comunicacion en-tre los involucrados del proyecto, seguido por la direccion o coordinacionde actividades.

Nivel de experiencia y conocimiento de cada uno de los participantes:El 22.4 % de las personas que contestaron la encuesta han participado enmas de 10 proyectos en los ultimos 5 anos, mientras que alrededor del 39 %ha estado entre 5 y 10 proyectos. Esto nos da un buen margen de perso-nas con suficiente experiencia en el proceso de construccion de software yprincipalmente en el sector de tecnologıa, como es descrito en el aspectoanterior.

43

3.3. Definiciones Raız y Sistemas de Actividad Hu-mana

Con base en lo ilustrado en la seccion anterior, en esta fase son identificadoslos diferentes sistemas de actividad mediante lo que el autor llama ”DefinicionRaız”, que describen el sistema en consideracion y estan formadas por tres com-ponentes: Que, define el proposito inmediato del sistema. Como, en donde seexplicara la manera en que sera conseguido el ”que” y Por que, parte del enun-ciado que aclara la finalidad de la actividad. (Checkland P. and Scholes J., 1994)sugieren que se haga la formulacion de las definiciones raız, respectando estos treselementos, de tal forma que puedan ser expresadas de la siguiente manera: ”Unsistema para...(que), mediante...(como) para contribuir con ...(por que)”. Paracada una de las definicones raız construida, es realizado un analisis de roles delsistema representado en una expresion cuya estructura se encuentra fundamentadaen seis factores claves y cuyo nemonico es CATWOE (Checkland P. and ScholesJ., 1994):

1. C(Customers): Corresponde a los interesados en los resultados de la ejecu-cion de la actividad.

2. A(Actors): Quienes ejecutan la actividad.

3. T(Trasnformation Process): Proceso de transformacion.

4. W(Weltanschauung): Termino aleman para describir la vision del mundoque da significado a la accion.

5. O(Owner): Dueno 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 delas definiciones raız, tomando como referencia los verbos de accion. Los modelosconceptuales estan constituidos por el conjunto de actividades que debe realizarel sistema

Las definiciones raız y los posteriores sistemas de actividad humana, se elabo-ran a partir de los puntos de vista analizados en la seccion anterior y nos brindanuna perspectiva de los procesos que se ejecutan. Los diagramas de PERT asocia-dos a cada sistema de actividad humana funcionan como modelos conceptuales yse componen de:

44

Frontera del sistema Al interior de ella se encuentra el conjunto de activi-dades que ejecuta el sistema

Actividades Se encuentran representadas por medio de ovalos, estan enu-meradas y conectadas por medio de lıneas, para identificar la secuencia enla que se ejecutan. El objetivo principal de cada una se representa median-te un verbo. El modelo conceptual debe tener aproximadamente entre sietemas o menos dos actividades.

Monitoreo y control Las actividades que conforman el proceso de monito-reo y control se ubican fuera de la frontera del sistema y tienen el propositode realizar seguimiento, evaluacion y control sobre la ejecucion de las acti-vidades del sistema.

Un modelo conceptual es valido si cumple con las siguientes caracterısticas(University, 2016):

Cumple con una mision o proposito

Puede asignarse al sistema una medida de desempeno para determinar suprogreso.

Incluye un proceso de toma de decisiones

Tiene componentes que interactuan o tienen cierto grado de conectividadentre sı.

Tiene un lımite

Existe en sistemas mas grandes

Cuenta con una garantıa de continuidad

Segun lo descrito anteriormente y de la situacion problema a analizar, funda-mentada en las respuestas obtenidas tras la aplicacion de la encuesta, se abstraenlos siguientes sistemas de actividad humana, su definicion raız y el modelo con-ceptual que representa su proceso.

45

Sistema de actividad humana para el desarrollo de software usando prototi-pos

C Cliente o Usuario Final

A Programador, Analistas

T Disenar, desarrollar y entregar prototipos funcionales incrementales conbase en los requerimientos identificados.

W Llevar a cabo entregas parciales del software en construccion permitevalidar el funcionamiento del mismo en conformidad con lo requerido porel cliente.

O Analista

E Proyecto de desarrollo de software

Definicion Raız Un sistema poseıdo por los analistas, para disenar, desarro-llar y entregar prototipos funcionales incrementales con base en los requerimien-tos identificados, llevado a cabo por los programadores y analistas con el fin devalidar el funcionamiento del software en conformidad con lo requerido por elcliente.

Figura 3.29: Sistema de Actividad Humana para el desarrollo de software usandoprototipos. Fuente: Elaboracion propia

46

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 ma-nera clara a los desarrolladores el alcance, restricciones, necesidades y prio-ridades del cliente.

O Analista

E Proyecto de desarrollo de software

Definicion Raız Un sistema poseıdo por los analistas, para comunicar eficaz-mente los requerimientos expresados por el cliente, llevado a cabo por los ana-listas con el fin de transmitir de manera clara a los desarrolladores el alcance,restricciones, necesidades y prioridades del cliente.

47

Figura 3.30: Sistema de Actividad Humana para comunicar los requerimientoseficazmente. Fuente: Elaboracion propia

48

Sistema de actividad humana para proponer requerimientos alineados conlos objetivos empresariales

C Cliente o usuario final

A Analistas

T Diseno y propuesta de los requerimientos de software orientados en elcumplimiento de los objetivos de negocio

W El conocimiento de los objetivos y modelos de negocio, ası como delalcance y potencial de las herramientas tecnologicas permite reconocer alsoftware y su desarrollo como herramientas estrategicas.

O Cliente o usuario final

E Proyectos de desarrollo o implementacion de software

Definicion Raız Un sistema poseıdo por el cliente o usuario final, para disenarlos requerimientos de software con base en los objetivos de negocio mediante elconocimiento de los modelos de negocio, el alcance y potencial de las herramien-tas tecnologicas, llevado a cabo por los analistas con el fin de reconocer al soft-ware y su desarrollo como herramientas estrategicas que apoyan la consecuon delos objetivos empresariales.

49

Figura 3.31: Sistema de actividad humana para proponer requerimientos alineadoscon los objetivos empresariales. Fuente: Elaboracion propia

50

Sistema de actividad humana para involucrar a los usuarios finales en el desa-rrollo del proyecto

C Lıder o Director de proyecto

A Analistas

T Consultar al usuario sobre los requerimientos, realizar la documentacionen conjunto con el y ejecutar las validaciones correspondientes.

W Involucrar a los usuarios o clientes finales en todas las fases del procesode desarrollo de software facilita tener claridad sobre el alcance del proyectoy los requerimientos.

O Lıder o Director de proyecto, Analistas


Definicion Raız Un sistema poseıdo por el Lıder o Director de proyecto y losanalistas, para consultar al usuario sobre los requerimientos, realizar la docu-mentacion en conjunto con el y ejecutar las validaciones correspondientes, lleva-do a cabo por los analistas con el fin de involucrar a los usuarios o clientes finalesen todas las fases del proceso de desarrollo de software y tener claridad sobre elalcance del proyecto y los requerimientos.

Figura 3.32: Sistema de actividad humana para involucrar a los usuarios finales enel desarrollo del proyecto. Fuente: Elaboracion propia

51

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 baseen los requerimientos identificados permite validar la pertinencia y alcancede los mismos.

O Lıder o Director de proyecto


Definicion Raız Un sistema poseıdo por el lıder o director de proyecto, pararealizar pruebas de concepto con base en los requerimientos definidos, llevado acabo por los analistas y el director de proyecto con el fin de validar la pertinenciay alcance de los mismos.

Figura 3.33: Sistema de actividad humana para realizar pruebas de concepto.Fuente: Elaboracion propia

52

Sistema de actividad humana para involucrar a todos los stakeholders

C Cliente o usuario final, analistas, programadores

A Analistas

T Diseno y propuesta de estrategia para involucrar a todos los interesadosdel proyecto de software

W Involucrar a todos los interesados en el proyecto, en especial al usuariofinal en todas las fases del proyecto para tener mas claridad en lo que elusuario desea.

O Cliente o usuario final

E Disponibilidad de los stakeholders

Definicion Raız Un sistema poseıdo por el cliente o usuario final, para invo-lucrar a las personas operativas y usuario final mediante las reuniones de valida-cion con el usuario , llevado a cabo por los analistas, lıderes de proyecto con elfin de validar los requerimientos del proyecto en todas sus etapas.

Figura 3.34: Sistema de actividad humana para involucrar a los stakeholders

53

Sistema de actividad humana para desarrollar software usando interfaces yflujos de la solucion

C Cliente o usuario Final

A Analistas

T Identificar interfaces y flujos de software basados en los requerimientosespecificados por el cliente.

WIdentificar interfaces y flujos de software que esten basados en los reque-rimientos expresados por el cliente.

O Analista

E Proyectos de desarrollo de software.

Definicion Raız Un sistema poseıdo por los analistas, para desarrollar flu-jos de software mediante la identificacion de interfaces que interactuan con elsistema con el fin de validar y entender el funcionamiento del software.

Figura 3.35: Sistema de actividad humana para desarrollar software usando inter-faces y flujos de la solucion

54

Sistema de actividad humana para obtener informacion sobre el alcance an-tes de iniciar el proyecto

C Cliente o usuario Final

A Analistas

T Consultar al usuario final sobre la documentacion necesaria sobre losrequerimientos, estos se transformaran en el alcance del proyecto.

W Los requerimientos son la principal fuente de informacion para determi-nar las expectativas del cliente.

O Analista, lıder de proyecto

E Proyectos de desarrollo e implementacion de software.

Definicion Raız Un sistema poseıdo por los analistas, para transformar losrequerimientos identificados en el alcance del proyecto llevado a cabo por analis-tas, lıder de proyecto y usuario final con el fin de utilizar los requerimientos comola principal fuente de informacion para determinar las expectativas del cliente.

Figura 3.36: Sistema de actividad humana para obtener informacion sobre el al-cance antes de iniciar el proyecto

55

3.4. Comparacion de modelos conceptuales con larealidad

En esta fase son comparados los modelos conceptuales con la realidad expre-sada en la etapa 2, con el fin de identificar diferencias emergentes. La comparacionrealizada dara lugar a un conjunto de resultados que pueden ser considerados co-mo sugerencias (Checkland, 1981). Para llevar a cabo esta comparacion, puedenemplearse diferentes metodos que permitan hacer la transicion entre el analisis da-do en un lenguaje sistemico y debatir el resultado en el lenguaje del mundo real,se definen principalmente cuatro metodos que pueden ser utilizados de maneraunitaria o en conjunto:

1. Mediante un debate organizado, tomando como referencia los modelos con-ceptuales para la formulacion de preguntas acerca de la situacion.

2. Consiste en reconstruir una secuencia de sucesos ocurridos en el marco dela situacion problema, comparandola con los posibles resultados obtenidossi se hubiese aplicado el modelo conceptual que es objeto de comparacion.

3. Mediante el planteamiento de preguntas estrategicas acerca de las activida-des actuales.

4. Se debe construir un modelo conceptual con las actividades que son ejecu-tadas en ”la realidad” y determinar las diferencias existentes entre los dosmodelos. esto permite identificar los aspectos puntuales en los cuales difie-ren los dos modelos.

Haciendo uso de los metodos descritos, se realiza la comparacion entre losmodelos conceptuales y la situacion problematica. Los resultados se presentan acontinuacion:

La comparacion del sistema de actividad humana (SAH) para el desarrollode software usando prototipos se realiza con base en una historia obtenidade una encuesta realizada por (Westfall, 2011): ”En uno de nuestros proyec-tos intercambiamos informacion con los clientes durante un mes y recogi-mos abundante informacion sobre los requisitos, que nos parecio bastantecompleta en ese momento. El producto se desarrollo en los siguientes tresmeses, perıodo durante el cual no fueron necesarios nuevos requisitos ocambios. Sin embargo, cuando estabamos a punto de entregar el producto,

56

tres meses mas tarde, el lıder rechazo muchas de las funciones anteriormen-te confirmadas, lo que condujo a otro sistema de procesos de tres meses”.

Si este escenario se hubiera ejecutado haciendo uso del modelo conceptualen evaluacion, el resultado obtenido probablemente hubiera sido el siguien-te:

Figura 3.37: Comparacion SHA para el desarrollo de software usando prototipos.Fuente: Este trabajo

1. Se habrıan realizado entregas funcionales parciales que permitieranvalidar las expectativas del usuario final.

2. Los tiempos de entrega posiblemente se habrıan acortado, contrario atener un proyecto con una duracion de 7 meses, se proponen ciclos de1 mes hasta completar el total del proyecto.

La comparacion del SAH para comunicar los requerimientos eficazmentese lleva a cabo mediante la construccion de un modelo conceptual basadoen la percepcion de realidad de los analistas encuestados:

En comparacion con lo representado en la figura 3.30 los principales cam-bios consisten en:

1. Se evidencia una necesidad por el desarrollo de habilidades de comu-nicacion.

57

Figura 3.38: SAH para comunicar requerimientos. Fuente: Elaboracion propia

2. Se realiza una contextualizacion a los demas miembros del equipo detrabajo respecto al alcance y expectativas del usuario final.

3. Se valida la comprension del mensaje entregado para confirmar quesea lo mas acertado posible.

4. Existen criterios de aceptacion relacionados con la comunicacion, esdecir, no solo se mide el grado de asertividad en la identificacion derequerimientos, sino en como son transmitidos.

La comparacion del sistema de actividad humana (SAH) obtener informa-cion sobre el alcance antes de iniciar el proyecto se realiza con base en unahistoria obtenida de una encuesta realizada por (Westfall, 2011): ”Una veztuvimos un proyecto para desarrollar el software a una cadena de alquilerde video, en el que el cliente expreso su interes de utilizar el mismo productopara expandirse internacionalmente. Sin embargo, solo mas tarde llegamosa conocer el hecho de que los estandares en el extranjero son muy diferen-tes a los nacionales, por lo que el producto tuvo que ser completamentereimplementado para cumplir con este requisito”

1. Se habrıa evitado re-procesos en el momento de que el cliente deseoimplementar nuevas funcionalidades.

58

2. Los tiempos de entrega ciertamente se reducen si se tiene un alcanceespecificado.

3. Se habrıa construido un software altamente escalable para no dependerde estandares especificos.

Se pretende comparar el sistema de actividad humana involucrar a todos losstakeholders haciendo uso del tercer metodo propuesto, indagacion median-te preguntas estrategicas y sus respuestas (Mate, 2005):

1. ¿Quien elige la persona dentro de la companıa para definir los usua-rios? ”Elegir una persona dentro de la companıa encargada de definirlos usuarios, por lo general el gerente o la persona que paga por eldesarrollo”

2. ¿Que acciones toman cuando hay conflictos entre requerimientos? ”Nose hace uso de grupos de stakeholders y, por lo general, esta decisionla toma la persona que tiene mas poder de decision por parte delcliente”

3. ¿Como es la seleccion de stakeholders dentro de la organizacion? “Esmuy basica, por cuanto es muy comun que deleguen a una personadentro de la organizacion para identificar los involucrados o simple-mente 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 mas importantes pa-ra establecer las bases tempranas dirigidas a la planificacion, ejecuciony monitoreo y control de la informacion y comunicacion del proyectopara alcanzar el exito.

2. Se debe analizar el contexto de requerimientos de negocio de acuerdocon el punto de vista de cada uno de los stakeholders.

3. validar la incorporacion de un lenguaje generico para los stakeholdersy ası poder modelar de manera uniforme los requerimientos.

El sistema de actividad humana para proponer requerimientos alineados conlos objetivos empresariales es evaluado a traves de debate con algunos usua-rios finales o clientes de proyecto que apoyaron la encuesta.

59

Consultamos a los encuestados que tenıan asociado el rol de clientes o usua-rios finales respecto a las caracterısticas del proyecto de software que esta-ban evaluando, a lo cual se obtuvieron respuestas del tipo: desarrollo defuncionalidades, integracion de plataformas, informacion de determinadomodulo. Esto nos lleva a considerar dos posibilidades: O bien, los encues-tados son usuarios de bajo rango, o, los proyectos de software no tenıan unproposito estrategico.

Se indago entonces al respecto con usuarios finales y clientes con posicionesde alta jerarquıa de una companıa del sector Telecomunicaciones. Las res-puestas obtenidas fueron similares, sus expectativas del software se orientana tres aspectos principalmente:.

• Automatizacion de tareas operativas

• Reducir la interaccion con el sistema

• Optmizar procesos de negocio

Al traer a revision el modelo conceptual propuesto, se identifico como unproceso propio de arquitectura empresarial mas que de desarrollo o imple-mentacion de software. Se realizo entonces la aplicacion del modelo con-ceptual sobre los requerimientos de un desarrollo que tenıa por requerimien-tos:

• Permitir el ingreso masivo de registros de costos (entre 2 y 20 registrossimultaneamente)

• Crear automaticamente los asientos contables que correspondıan concada registro

Tras la aplicacion del modelo conceptual, tomando como base el objetivo denegocio ”Reducir en un 30 % los costos de operacion” los requerimientosfueron cambiados por:

• Generacion de reportes y dashboards para monitoreo de costos

• Integracion del proceso de compras al de Ingenierıa de negocios

• Creacion automatica de los costos emergentes del proceso de Inge-nierıa de negocios y sus correspondientes asientos contables

Del ejercicio anterior es posible identificar los siguientes cambios:

60

1. Alinear el proceso de elicitacion de requerimientos con la vision yestrategia de la companıa, facilita la identificacion de los mismos.

2. Una perspectiva holıstica de la companıa y sus procesos permite en-tender las aplicaciones de software como herramientas de apoyo a laestrategia.

El SAH para realizar pruebas de concepto resuelve principalmente las fallasde expectativa de los sistemas de informacion (Lyytinen K. and HirschheimR., 1988). Con base en lo expresado por los participantes, se crea un mo-delo de desarrollo cercano a la realidad que cubra los aspectos mayormentecalificados e la encuesta, para ser comparado con el SAH en cuestion. Elresultado es expuesto en la figura 3.39.

Figura 3.39: Modelo conceptual del proceso de ingenierıa de requerimientos. Ela-borado a partir de 3.2

Como resultado de la comparacion de este modelo con 3.33 se identificanvarios cambios:

1. Incluir el termino ”prueba de concepto” en el procedimiento de desa-rrollo, puesto que ahora es utilizado como una actividad previa a la

61

compra de una herramienta. Si bien son presentados los bocetos de in-terfaz grafica a los usuarios, no cumplen con el objetivo de una PoC,que de acuerdo con (Kotler, 2002) consiste en ”presentar el conceptode producto a los consumidores... y determinar sus reacciones.”

2. La validacion del alcance del proyecto a traves de la presentacion deun concepto reduce la cantidad de re-procesos en etapas posteriores.Al tener ciclos mas cortos de verificacion y ajuste, los tiempos podrıantambien verse impactados positivamente.

62

3.5. Identificacion de cambios factibles y deseablesUna vez concluida la etapa 5 3.4, la comparacion realizada dara lugar a un con-

junto de resultados que pueden ser considerados como sugerencias, esto conducea la fase 6, en la cual se recopilan las recomendaciones de cambio, que seran eva-luadas para determinar su deseabilidad y viabilidad en conformidad con el analisisrealizado previamente y la dimension cultural del contexto.

Estos cambios, que conformaran lo ”que” se desea hacer, deben ser posterior-mente implementados mediante el establecimiento de un ”como” en la fase finalde la metodologıa. Dichos cambios pueden ser de tres tipos diferentes:

Cambios de Actitud: Comprenden cambios sobre la conciencia individualy/o colectiva de quienes interactuan en el sistema.

Cambios Estructurales: Constituyen cambios sobre los componentes delsistema que tienen baja probabilidad de variacion a corto plazo, tales comola estructura organizacional, infraestructura, etc.

Cambios de Procedimiento: Son aquellos que se realizan sobre elementosdinamicos, es decir, que se modifican constantemente para optimizar losresultados o situaciones. Pueden afectar las actividades que se ejecutan, laforma o secuencia en que se ejecutan o anadir nuevas actividades.

Para el caso de estudio, nos enfocaremos principalmente en los cambios deprocedimiento, puesto que no es del alcance de este trabajo sugerir o realizar cam-bios en estructuras organizacionales o en el comportamiento de los participantesde la investigacion. A continuacion se recopilan los cambios de procedimientoidentificados en la seccion 3.4:

1. Optimizacion de tiempos, producto de entregas funcionales parciales y de-limitacion del alcance del proyecto por etapas.

2. Contextualizacion a los demas miembros del equipo de trabajo respecto alalcance y expectativas del usuario final.

3. Validar la comprension de los requerimientos por parte de los miembros delos equipos de desarrollo y calidad.

4. Definir criterios de aceptacion relacionados con la comunicacion, es decir,no solo se debe medir el grado de asertividad en la identificacion de reque-rimientos, sino en como son transmitidos.

63

5. La evaluacion de requerimientos guiada por la estrategıa de negocio, cambiala perspectiva de las personas involucradas respecto al uso y expectativa delas herramientas de software.

6. Realizar entregas funcionales parciales que permitieran validar el cumpli-miento de las expectativas del usuario final.

7. Tener un alcance claramente especificado conlleva a la optimizacion de lotiempos de entrega y construir aplicaciones escalables.

8. Alinear el proceso de elicitacion de requerimientos con la vision y estrategiade la companıa, facilita la identificacion de los mismos.

9. Una perspectiva holıstica de la companıa y sus procesos permite entenderlas aplicaciones de software como herramientas de apoyo a la estrategia.

64

Capıtulo 4

RESULTADOS YCONCLUSIONES

En esta seccion se presenta el resultado esperado del trabajo: Un procedimien-to basado en los aspectos evaluados sobre la elicitacion de requerimientos a travesde la metodologıa de sistemas suaves. Tambien son presentadas las conclusionesfinales sobre la ejecucion del presente trabajo y las propuestas de acciones pararealizar a futuro con base en los resultados obtenidos.

4.1. Propuesta de procedimiento de elicitacion de re-querimientos

De acuerdo con (ISO 9000, 2005) un proceso es ”una actividad o un con-junto de actividades que utiliza recursos, y que se gestiona con el fin de permitirque los elementos de entrada se transformen en resultados”. En esta definicionencontramos cuatro componentes fundamentales de un proceso:

Entradas: Consisten en especificaciones, recursos o registros que provienenusualmente de otros procesos.

Actividades: Tareas a ejecutar en el marco del proceso.

Recursos: Todo aquello que es necesario para la correcta ejecucion delproceso, pueden comprender personas, herramientas, infraestructura, entreotros.

65

Salidas: Corresponde al resultado o producto de la ejecucion del proceso.

Con base en lo descrito anteriormente y teniendo en mente el ciclo PHVA (Pla-near - Hacer - Verificar - Actuar) propuesto por Edwards Deming fue construidoel procedimiento que se detalla en esta etapa y el cual se encuentra fundamentadoen los cambios identificados en la seccion 3.5.

El ciclo de vida de desarrollo del software comprende varias etapas y estaconformado por multiples procesos. En una comparacion realizada por (PMO In-formatica, 2012) con el marco de trabajo ITIL es posible evidenciar su dimensionen la figura 4.1.

Figura 4.1: Ciclo de vida del desarrollo de software. Fuente: (PMO Informatica,2012)

Es importante entonces aclarar que el procedimiento descrito a continuacionencapsula unicamente las actividades propias de la especificacion funcional delalcance de un proyecto de construccion de software, por lo que procedimientostales como la administracion del ciclo de vida del desarrollo, especificacion de laarquitectura, gestion de capacidades, pruebas y entrega no hacen parte, sino quese relacionan con el.

66

En la tabla 4.1 se describen las principales caracterısticas del procedimientoque lleva por nombre Procedimiento IVC de necesidades de software, las siglasIVC hacen referencia a los terminos: Identificacion, Validacion y Comunicacion,actividades esenciales en el procedimiento. Se ha decidido usar el termino Nece-sidades, en lugar de requerimientos, pues se considera que resume en buna formael objetivo definido.

El procedimiento recibe como entradas las necesidades de los interesados, lastecnicas de especifcacion y de indentificacion de requerimientos que defina usarel lıder o director de proyecto, los objetivos derivados de la estrategia corporativay los resultados de las fases de arquitectura, codificacion, pruebas y despliegue delproceso de desarrollo. El procedimiento debe tener la misma salida que el procesomacro: Las necesidades identificadas, plenamente satisfechas.

Notese que en los recursos no se especifica el rol que debe ejecutar las activi-dades del procedimiento, puesto que se consideran como responsables todos losactores que participan en el procedimiento.

67

Caracterizacion del procedimiento:

Nombre Procedimiento IVC (identificacion, validacion y comunicacion) denecesidades de software

ObjetivoEntender el negocio, sus objetivos y necesidades de construccion desoftware para asegurar la comunicacion asertiva de los requerimientosdurante el ciclo de desarrollo.

Alcance

Este procedimiento inicia con la identificacion de una necesidad,abarca la comunicacion eficaz de dichas necesidades a losinteresados en las diferentes etapas del proceso y culmina con laentrega del proyecto.

Referencias1. Este trabajo2. Ciclo PHVA3. ISO 9001:2008

ResponsabilidadesEs responsabilidad de todos los actores en el proceso de desarrollode software conocer los requerimientos de negocio y velar porqueestos se materialicen con un alto nivel de confiabilidad

Entradas

Necesidades de los interesadosTecnicas de especificacion de requerimientosTecnicas de identificacion de requerimientosEstrategia corporativa - ObjetivosResultados de la arquitectura, diseno codificacion,pruebas y despliegue

Salidas Necesidades de los interesados plenamente satisfechas

Recursos

1. Tiempo suficiente dedicado al proyecto por parte de todos losinteresados.2. Personas cuyas habilidades de comunicacion se encuentrenaltamente desarrolladas

Tabla 4.1: Caracterizacion del procedimiento IVC de Necesidades de software.Fuente: este proyecto

En la figura 4.2 se presenta un modelo del procedimiento. Los diversos intere-sados en el proyecto, generan diferentes puntos de vista o perspectivas, de acuerdocon lo que evidenciamos en secciones anteriores, esto nos abre paso a la prime-ra actividad en el procedimiento Identificar los stakeholders. Estas perspectivas,que deben estar orientadas al cumplimiento de los objetivos estrategicos de lacompanıa, se transforman en necesidades, es necesario entonces Comprender las

68

expectativas de los stakeholders. El conjunto de necesidades expresadas consti-tuye el alcance del proyecto de desarrollo. Tal cual lo identificamos en la seccion3.5, es importante segmentar el alcance para asegurar entregables de menor di-mension, a los paquetes de entregables los hemos llamado Unidades funcionales.

Una vez asmiladas las necesidades de los interesados, es necesario definircriterios de aceptacion para las actividades subsecuentes, deben girar en torno ala asertividad en la comunicacion, especificacion y aseguramiento de la validacionde los requerimientos.

Contextualizar a los stakeholders es una actividad de vital importancia enel procedimiento. Se entiende en esta fase, que los interesados no se encuentranexclusivamente del lado del cliente, sino que son todos los actores que participanen el proceso de construccion de una aplicacion, por lo que el contexto que tienendel proyecto y el negocio debe ser igual para todos. El siguiente paso es disenarmodelos funcionales y es el equivalente a la especificacion de requerimientosmediante la tecnica que haya sido adoptada. Estos modelos deben estar basadosen las necesidades previamente identificadas y que, como se aclaro, deben co-rresponder con los puntos de vista de todos los participantes en el proceso, razonpor la cual, dichos modelos contaran con caracterısticas funcionales, tecnicas, denegocio y de proceso.

La siguiente actividad en el proceso consiste en comunicar las necesidades atraves de los modelos a quienes se encargan de las etapas posteriores o en cursodel ciclo de vida del desarrollo, de manera que en conjunto se realice la construc-cion de conceptos funcionales, para proceder con la validacion de los mismospor parte de los interesados mediante la ejecucion de un prueba de concepto. Siel resultado de la validacion es positivo, como resultado, los modelos en los cua-les se fundamente el concepto seran validados tambien y sobre esta base se debeproceder con las demas etapas del desarrollo.

El procedimiento IVC de necesidades de software debe soportar todo el ciclode desarrollo, conforme se expone en la figura 4.3.

69

Figura 4.2: Modelo del Procedimiento IVC Necesidades de Software. Fuente: Estetrabajo

70

Figura 4.3: Ciclo de vida del desarrollo de software. Fuente: Elaboracion propia

71

4.2. ConclusionesEl objetivo principal del presente proyecto consiste en disenar un procedi-

miento para la identificacion , analisis y validacion de requerimientos de softwareen organizaciones, a partir de los resultados obtenidos tras la aplicacion de la me-todologıa de sistemas suaves en el analisis de las caracterısticas de la ingenierıade requerimientos, en busqueda de la incorporacion de aspectos “blandos” en elestudio de su pertinencia. En el resultado obtenido y presentado en la seccion 4.1,se evidencia su cumplimiento.

A continuacion se expresan las conclusiones tras el desarrollo del trabajo entres diferentes perpectivas: Desde el punto de vista de la aplicacion de la meto-dologıa de sistemas suaves en el apartado 4.2.1, respecto a la tecnica y los datosrecopilados en 4.2.2 y por ultimo, en 4.2.3 se muestran las conclusiones con baseen los resultados del analisis realizado y que dieron paso a la estructuracion delprocedimiento presentado en la seccion 4.1.

4.2.1. Sobre la metodologıa aplicadaLa metodologıa de sistemas suaves es una manera util de acercarse a situa-

ciones complejas donde hay una actividad de alto componente social, polıtico yhumano, por lo que se puede decir que no tiene un lımite de implementacion y quecabe perfectamente en la actividad de elicitacion de requerimientos. Su enfoqueson las situaciones problema, pero no se debe ver como problema sino como unaoportunidad de mejora de la situacion a evaluar en la que se dificulta la identifica-cion de un sistema para su analisis.

En la metodologıa, la obtencion de definiciones raız serıa el equivalente en unametodologıa de sistemas duros a identificar un sistema con un proposito definido.CATWOE son los elementos que son considerados para validar una definicionraız, siendo T(transformacion) y W (Weltanschauung) las mas importantes pararealizar una definicion raız.

La decision del uso de la metodologıa de sistemas suaves, tanto para el disenode la encuesta como en el posterior analisis de los datos, se considera fue acer-tado, puesto que permitio identificar claramente la percepcion de los encuestadosrespecto a las fallas en el proceso, pero tambien obtener sugerencias. Gracias aque la elicitacion de requerimientos depende en mayor cantidad del componentehumano, la MSS se presenta como un lenguaje de modelado para los sistemashumanos que emergen del comportamiento e ideas de cada uno de los actores.

72

4.2.2. Sobre los datos recopiladosLos principales resultados y conclusiones obtenidos tras la aplicacion de la

encuesta son expuestos en la seccion 3.2.A partir de la encuesta realizada se obtuvieron ideas respecto a como poten-

ciar el procedimiento de definicion de requerimientos para el desarrollo de soft-ware desde el punto de vista de cada rol evaluado (analista, programador, lıderesousuario final) encontrando similitudes en aspectos que giran entorno a las inter-acciones humanas.

Uno de los principales aspectos encontrados corresponde con la contextualiza-cion de todos los miembros del proyecto sobre el alcance, objetivos de negocio yexpectativas del cliente. Para ello es necesario identificar a todos los involucradosdel proyecto, problema tambien expresado por todos los roles y que se presentafrecuentemente en los proyectos de software.

Los datos recopilados resultaron ser suficientes para la aplicacion del ejerciciopropuesto, sin embargo, la amplicacion de la muestra podrıa permitir establecerun procedimiento con aplicacion global.

4.2.3. Sobre el procedimiento analizado y propuestoA pesar de que no corresponde al alcance de este trabajo la implementacion de

los cambios identificados, con base en la experiencia obtenida y las percepcionesde los participantes, es posible concluir que:

La entrega de resultados a corto plazo, mediante la definicion temprana yacertada de alcances parciales es clave en el exito de los proyectos de soft-ware.

Plantear las actividades propias de la ingenierıa de requerimientos comoresponsabilidad de todo el equipo de trabajo, evidencia que el ciclo de vi-da de los requerimientos debe coincidir con el del desarrollo y entrega delsoftware, puesto que en todas las fases se debe tener claridad sobre los re-querimientos y realizar las validaciones correspondeientes.

Las habilidades de comunicacion son indispensables en el proceso de desa-rrollo de software, puesto que aseguran el entendimiento acertado de losrequerimientos.

El cambio del concepto ”requerimientos” por ”necesidades” cambia la pers-pectiva y expectativa respecto al proceso, puesto que ya no se trata solo de

73

atender solicitudes, sino de entender los problemas de la organizacion pardarles una solucion a traves de soluciones de software.

74

4.3. Trabajo FuturoComo continuacion de este proyecto de investigacion, existen diversas lıneas

que quedan abiertas y en las que es posible seguir trabajando y se espera que seanatacadas a futuro.

A continuacion se presentan algunos aspectos que pueden desarrollarse comoresultado de esta investigacion o que, por exceder el alcance de este proyecto nohan podido ser tratados con la suficiente profundidad.

Realizar la implementacion de un piloto del procedimiento propuesto (IVC)en diferentes tipos de organizacion , de esta forma se podra evidenciar o nosu grado de viabilidad.

Integrar el diseno del procedimiento propuesto (IVC) con las diferentestecnicas de elicitacion de requerimientos existentes o con alguna metodo-logıa de desarrollo.

Realizar el estudio con una poblacion mas amplia, es decir, en otros contex-tos, tipos de organizacion, roles etc, de esta forma se tendra un estudio masrepresentativo y se integrara a la investigacion mayor informacion relevanteque puede surgir en la identificacion de mas y mejores cambios.

75

Bibliografıa

A. Martınez, J. Munoz, and A. Pascual (2004). Tamano de la Muestra y PrecisionEstadıstica. Universidad de Almerıa, Almerıa.

Avila, H. (2006). Introduccion a la Metodologıa de la Investigacion. EdicionElectronica eumed.net, Mexico.

Bertalanffy, L. (1968). General System Theory. George Braziller Inc., New York.

Cardoso E.O., Cerecedo M.T., and Ramos J.R. (2013). Evaluacion institucionalbasada en los sistemas suaves. Palibrio LLC, Bloomington, Estados Unidos.

Checkland, P. (1981). Systems Thinking, Systems Practice. Wiley.

Checkland P. and Scholes J. (1994). La metodologa de sistemas suaves en accion.Limusa.

G. Panataleo and L. Rinaudo (2016). Ingenierıa de SOftware. Editorial Ink,Mexico.

Geogy M. and Dharani A. (2016). A scrutiny of the software requirement engi-neering process. ScienceDirect, pages 405–410.

Hadad G., Doorn J., and Kaplan G. (1998). Explicitar requisitos del softwareusando escenarios.

Hastie S. and Wojewoda S. (2015). Standish group 2015 chaos report. InfoQ.

Hitachi, D. (2017). Tendencias de ti 2017. ACIS.

Hunt, J. (2002). Guide to C# and Object Orientation. Springer, Great Britain.

ISO 9000 (2005). Norma Internacional - Sistemas de gestion de la calidad —Fundamentos y vocabulario.

76

Johansen, O. (2004). Introduccion a la teorıa general de sistemas. Limusa,Mexico.

k. Kendall and J. Kendall (2005). Analisis y diseno de sistemas. Pearson Educa-cion, Mexico.

Kendall K. and Kendall J. (2005). Analisis y Diseno de Sistemas. Pearson Educa-cion, Mexico.

Kotler, P. (2002). Direccion de marketing: conceptos esenciales. Pearson Educa-cion, Mexico.

Lyytinen K. and Hirschheim R. (1988). Information systems failures – a surveyand classification of the empirical literature. Oxford University Press, 4:257–309.

Mate, J. (2005). Requirements engineering for sociotechnical systems. IdeaGroup Inc.

Muhtasham A., Usama A., and Shahzaib K. (2016). Ambiguity in requirementengineering.

Nielsen, P. (1990). Approaches to appreciate information systems methodologies.Scandinavian Journal of Information Systems, 2:43–60.

Niu N., Lopez A.Y., and Cheng J.-R.C. (2011). Using soft systems methodologyto improve requirements practices: an exploratory case study. IET Software.

PMO Informatica (2012). Itil y el desarrollo de software.

Sommerville, I. (2005). Ingenierıa del Software. Pearson Educacion S.A., Madrid,Espana.

University, L. (2016). Professor peter checkland.

Westfall, L. (2011). Las fallas en la ingenierıa de requisitos. Ing. USBMed.

Zielinski K. and Szmuc T (2005). Software Engineering: Evolution and EmergingTechnologies. IOS Press, Amsterdan, Netherlands.

77

Presentado por: John Jairo Morenorepository.udistrital.edu.co/bitstream/11349/7525/1... · 3.31....

Documents

Transcript of Presentado por: John Jairo Morenorepository.udistrital.edu.co/bitstream/11349/7525/1... · 3.31....