Está en la página 1de 38

1

CAPTULO 1: INTRODUCCIN
1.1 DESCRIPCIN DEL PROBLEMA

La captura de requerimientos es la piedra angular en el desarrollo de sistemas informticos para clientes. Aunque es el primer eslabn no se encuentra exento de problemas, los cuales son originados por diversos factores. El primer factor proviene de los involucrados (usuarios finales, gerentes, etc.) en cuanto ellos no saben expresar con claridad lo que desean porque esto lo realizan de una manera informal, es decir en sus propios trminos. El segundo factor es derivado del hecho de que participan diferentes involucrados, lo cual conlleva en la mayora de los casos a generar conflictos en cuanto a los requisitos (necesidades) que desean satisfacer. Un tercer factor es derivado tanto del hecho de que los requerimientos van cambiando en el proceso de anlisis como la aparicin de nuevos involucrados en la captura de requerimientos. Un cuarto factor es derivado tanto del hecho de que el comportamiento humano que presenta un Ingeniero Informtico esta determinado por el tipo de organizacin donde trabaja, lo cual claramente puede influir al momento de realizar la toma de requerimientos, como de la experticia que tenga para realizar dicha labor. Para analizar todos los factores expuestos anteriormente, es menester destacar las habilidades y competencias que tiene el Ingeniero Informtico para la toma de requerimientos. Adems es importante tomar en cuenta el proceso de la toma de requerimientos de un sistema informtico y la manera de participacin del informtico en este proceso. Otro elemento a considerar son las acciones concretas que realiza este profesional para lograr extraer todo el conocimiento de los usuarios y de la organizacin. Por otra parte, se descubrir la relacin entre las acciones o actividades del proceso de toma de requerimientos (realizadas por el Informtico) y las habilidades y competencias que estn asociadas a dicho proceso. Finalmente, es destacable mencionar que todo lo relatado anteriormente se realizar utilizando, tanto entrevistas, como observaciones directas.

1.2

OBJETIVOS

A continuacin, se ilustran tanto los objetivos generales como especficos. El objetivo general explica lo que pretende entregar el presente escrito; mientras que los objetivos especficos se relacionan con todas las aristas y como se proceder para resolver el problema en cuestin. 1.2.1 Objetivo general Establecer una lista de competencias y habilidades que debe poseer un Ingeniero Informtico para realizar una adecuada toma de requerimientos. Dicha lista se basa en las experiencias de Ingenieros Informticos dedicados al rea en cuestin (toma de requerimientos).

Captulo 1: Introduccin 1.2.2 Objetivo especfico

1. Describir las cuatro etapas en que consiste el proceso de Ingeniera de requerimiento: estudio de factibilidad, obtencin y anlisis de requerimientos, especificacin de requerimientos y validacin de ellos. 2. Desarrollar el pilar terico en que se basa esta investigacin, el cual es una metodologa de trabajo titulada Soft System Methodology (de ahora en adelante SSM). 3. Exponer la situacin actual sobre la toma de requerimientos que debe realizar un Ingeniero Informtico. 4. Proponer un manual de buenas prcticas sobre la toma de requerimientos.

1.3

MARCO TERICO

Para que un proyecto de desarrollo de software pueda tener xito es crucial realizar una comprensin total de los requisitos del software a disear. Segn [1] aunque se desarrolle una implementacin muy buena del sistema si se realiza esta etapa de forma inadecuada lo ms seguro es que el usuario se sienta defraudado lo cual conllevar a que el desarrollador se frustre con el trabajo desarrollado por l. En la etapa del anlisis y la especificacin de requerimientos tanto el cliente como el desarrollador juegan un rol fundamental, debido a que el primero se encarga de describir las necesidades que le apremian, mientras que el segundo es el encargado dar solucin a dichas necesidades. Segn [1] esta etapa es dificultosa debido a que existe demasiado flujo de informacin y predominan las malas interpretaciones y la falta de informacin. Es por todo esto que desde el comienzo de los desarrollos de sistemas se ha tratado de realizar una adecuada identificacin de los requisitos del sistema derivadas de las necesidades de los usuarios. La dificultad radica en que la toma de requerimientos no es un proceso que se pueda detallar matemticamente, todo esto derivado de que la toma de requerimientos se introduce en el campo de las relaciones humanas. Por todo esto existe dentro de la Ingeniera una rama que se dedica a la captura de requerimientos, la cual es la Ingeniera de requerimientos cuyo propsito general es desarrollar tcnicas para que este proceso fundamental se realice en forma eficiente y segura [2]. De acuerdo con [3] la Ingeniera de requerimientos es un proceso que consta fundamentalmente de cuatro etapas las cuales son: estudio de factibilidad del sistema, obtencin y anlisis de requerimientos, especificacin de requerimientos y documentacin, y validacin de los requerimientos documentados. En la siguiente seccin se explicar las etapas del proceso de ingeniera de requerimientos que se muestran en la figura 3.1.

Captulo 1: Introduccin Estudio de Factibilidad Obtencin y anlisis de requerimiento s Informe de factibilidad Modelo de sistemas Requerimientos del usuario y del sistema Documentacin de requerimientos Figura 3.1: Etapas de la ingeniera de requerimientos

Especificacin de requerimiento s

Validacin de Requerimientos

3.1

ETAPAS DE LA INGENIERA DE REQUERIMIENTOS

El proceso de Ingeniera de requerimientos posee cuatro etapas: estudio de factibilidad, obtencin y anlisis de requerimientos, especificacin de requerimientos y validacin de requerimientos. Cada una de las siguientes etapas se especifica a continuacin. 3.1.1 Estudio de factibilidad Es la primera etapa que se debe desarrollar en la ingeniera de requerimientos. El resultado de esta etapa es producir un informe de factibilidad como se ilustra en la figura 3.1 que consiste tanto en realizar una recoleccin y evaluacin de la informacin, como redactar el informe del estudio de la factibilidad. Segn [3] para realizar la recaudacin y evaluacin se debe recurrir a las fuentes de informacin quienes son todas las personas que utilizarn el sistema (ingenieros, expertos en tecnologa, usuarios finales, etc.), todo esto con el objetivo de responder tres preguntas fundamentales las cuales son: El sistema contribuye a los objetivos de la organizacin? El sistema se puede implementar utilizando la tecnologa actual y con las restricciones de costo y tiempo? El sistema puede integrarse a otros existentes en la organizacin?; mientras que la creacin de un informe de factibilidad consiste en estipular el presupuesto, calendarizacin del sistema y en caso de que fuese necesario estipular requerimientos adicionales a las necesidades de los usuarios.

3.1.2 Obtencin y anlisis de requerimientos

Captulo 1: Introduccin

Es la segunda etapa que se debe desarrollar en la ingeniera de requerimientos, la cual consiste en determinar: el dominio de la aplicacin, desempeo del sistema, las restricciones que el sistema debe poseer, entre otras cosas. En esta etapa toman principal importancia los stakeholders, los cuales son aquellas personas con alguna influencia ya sea directa o indirecta en los requerimientos del sistema, es decir, pueden ser los usuarios finales, ingenieros desarrolladores, ingenieros de mantenimiento, etc. Segn [3], la dificultad en la obtencin y anlisis de requerimientos es difcil por las siguientes razones: 1. Los stakeholders no conocen realmente lo que desean obtener del sistema. 2. Los stakeholders representan sus demandas en trminos de su propio lenguaje (dominio), con lo cual los ingenieros de requerimientos deben adecuadarse al lenguaje de ellos. 3. Los stakeholders poseen requerimientos distintos lo que conlleva a que en muchas ocasiones los requerimientos de ellos entren en conflicto. 4. Los requerimientos son dinmicos debido a que estos van cambiando durante el proceso de anlisis ya que pueden surgir nuevos stakeholders que eventualmente pueden tener requerimientos distintos a los que ya existan estipulados. En la figura 3.2 se muestra el modelo del proceso de obtencin y anlisis. Segn [3] las actividades son: 1. Comprensin del dominio. El analista debe desarrollar su propia comprensin del dominio de la aplicacin. 2. Recoleccin de requerimientos. El analista debe interactuar con los stakeholders, para determinar las necesidades que poseen y de esta manera solucionarlas. 3. Clasificacin. Esta etapa permite organizar y agrupar los requerimientos. 4. Resolucin de conflictos. Esta tarea permite resolver los conflictos que surgen de la intervencin de los distintos stakeholders. 5. Priorizacin. Esta tarea permite dar prioridad a los distintos requerimientos coherentes encontrados. 6. Verificacin de requerimientos. Esta tarea permite verificar que los requerimientos sean completos, consistentes y tengan relacin a las necesidades planteadas por los stakeholders.

Captulo 1: Introduccin Especificacin de requerimientos

Verificacin de requerimientos Comprensin del dominio Entrada del proceso

Priorizacin Documento de requerimientos

Recoleccin de requerimientos

Resolucin de conflictos

Clasificacin Figura 3.2: Proceso de obtencin y anlisis de requerimientos Segn [2] existen distintas tcnicas que se pueden aplicar para la obtencin de los requisitos: 1. Introspeccin. Esta tcnica consiste en que el ingeniero (en esta etapa tambin llamado analista) se pone en el lugar del cliente y le da recomendaciones de la funcionalidad imaginando el sistema que se desea construir. 2. Entrevistas. Esta tcnica consiste en obtener mediante algn tipo de entrevista con los stakeholders los requerimientos que desean. Dentro de los tipos de entrevistas existentes se puede destacar Open ended Interview, entrevistas en grupos de desarrollo, discusiones. La entrevista Open ended Interview consiste en que el cliente narra su problemtica y que el ingeniero lo gue a travs de esta charla, de modo que se pueda especificar los requerimientos. Las entrevistas en grupo de desarrollo consiste en generar grupos con el personal del cliente de modo que tengan entre ellos una especialidad en comn. La idea es reclutar a los expertos de las distintas reas de la empresa para generar los requerimientos de una manera global. Las discusiones consisten en que el ingeniero de requerimientos establezca una discusin con el cliente referente a la problemtica a tratar de modo que se genere un conjunto de requerimientos del sistema. 3. Casos de Uso. Esta tcnica consiste en identificar los escenarios para obtener los requerimientos. Un escenario indica como debe interactuar el sistema con el usuario para obtener un objetivo especfico; dicho de otra manera, un caso de uso es una secuencia de interacciones entre el sistema y los stakeholders en respuesta a un evento que desea realizar un stakeholder con el sistema.

Captulo 1: Introduccin

4. Vord. Este mtodo se basa en la obtencin de los requerimientos mediante distintos puntos de vista. Este mtodo esta formado por distintas etapas las cuales son segn [3] son: 4.1 Identificacin de puntos de vista, lo que permite definir tanto los distintos puntos de vista como los servicios especficos que se entregan a cada punto de vista. 4.2 Estructuracin de puntos de vista, permite agrupar y jerarquizar los distintos servicios. En la jerarqua se posicionan en la parte superior aquellos servicios comunes y se heredan los puntos de vista de bajo nivel. 4.3 Documentacin de puntos de vista, esto comprende refinar los puntos de vista y los servicios identificados. 4.4 Trazado del punto de vista del sistema, comprende identificar los objetos en un diseo orientado a objetos utilizando la informacin obtenido en los puntos de vista. Es menester destacar que aunque existen diferentes mtodos o tcnicas, que se han desarrollado a travs de las dcadas, todos estos mtodos de anlisis se basan en los siguientes principios operativos segn [1]: 1. Se debe poder representar y entender el dominio de informacin de un problema planteado por un cliente. 2. Se debe definir la funcionalidad que debe cumplir el software. 3. Se debe representar el comportamiento del software. 4. Se deben describir los modelos que representan tanto la informacin como la funcin y el comportamiento del sistema de una manera jerrquica. 5. El proceso de anlisis de requerimientos debe estar en todo el desarrollo el sistema, es decir desde la informacin esencial hasta la implementacin. 3.1.3 Especificacin de requerimientos En esta etapa se establece la especificacin de los requerimientos, es decir lo que el sistema debe realizar. Esta etapa es muy complicada debido a que la naturaleza de los problemas es muy compleja. Es menester destacar que la especificacin puede verse como un proceso independiente del modo en que se realice, todo esto con el objetivo de lograr una adecuada implementacin de software. Segn [1] se han determinado los siguientes principios para representar los requisitos de software: 1. Separar la funcionalidad de la implementacin 2. Desarrollar un modelo de comportamiento de un sistema que comprenda los datos y las respuestas funcionales de un sistema a varios estmulos del entorno. 3. Establecer los componentes del sistema que interactan con l. 4. Definir el entorno en que operara el sistema 5. Crear un modelo intuitivo 6. Considerar que una especificacin es una abstraccin de una situacin real por lo cual ser incompleta y existir a muchos niveles de detalle. 7. Definir un contenido y estructura que sea susceptible a cambios.

Captulo 1: Introduccin

Es importante destacar que aunque los requerimientos pueden expresarse de cualquier manera hay que considerar que los principios enunciados anteriormente se deben llevar a la realidad, por ello es recomendable expresar los requerimientos mediante algn dibujo en papel. Segn [1] se presentan las siguientes directrices a seguir: 1. El formato de la representacin y el contenido deberan estar relacionados con el problema. Esto quiere decir que se puede realizar una representacin general de la especificacin de requerimientos del software independiente de las distintas simbologas que dependen del rea de aplicacin en la cual se este realizando la especificacin de requerimientos. 2. La informacin contenida dentro de la especificacin debera estar escalonada. Las representaciones deberan permitir que el lector pueda manejar la informacin en distintos niveles hasta llegar a los detalles de la especificacin. 3. La numeracin de prrafos y diagramas debera indicar el nivel de detalle que se muestra. Esto permite que la informacin se pueda presentar con distintos niveles de abstraccin. 4. Los diagramas y otras formas de notacin deberan restringirse en nmero y ser consistentes en su empleo. Esto permite evitar notaciones que produzcan confusin en la comprensin. 5. Las representaciones deben permitir revisiones. Esto permite que se pueda cambiar el contenido de una especificacin si vara el contenido de esta. Es recomendable utilizar una herramienta CASE que permite actualizar dicha informacin. Finalmente existe un documento de requerimientos del software, tambin llamado especificacin de requerimientos del software el cual es la declaracin oficial de lo que requieren los desarrolladores del sistema. Segn [1] las actividades son:

Captulo 1: Introduccin I. Introduccin A. Referencia del sistema B. Descripcin general. C. Restricciones del proyecto de software. II. Descripcin de la informacin A. Representacin del contenido de la informacin B. Representacin del flujo de la informacin 1. Flujo de datos 2. Flujo de control III. Descripcin funcional A. Particin funcional B. Descripcin funcional 1. Descripcin del procesamiento 2. Restricciones/limitaciones 3. Requisitos de rendimiento 4. Restricciones de diseo 5. Diagramas de soporte C. Descripcin del control 1. Especificacin de control 2. Restricciones de diseo IV. Descripcin del comportamiento A. Estados del sistema B. Eventos y acciones V. Criterios de validacin A. Lmites del rendimiento B. Clases de prueba C. Respuesta esperada del software D. Consideraciones especiales VI. Bibliografa VII. Apndice. Figura 3.3: Proceso de obtencin y anlisis de requerimientos

1. La introduccin permite establecer metas y objetivos que debe poseer el software a desarrollar. 2. La descripcin de la informacin establece una descripcin detallada del software a desarrollar. En esta etapa se documentan el contenido de la informacin y sus relaciones. 3. En la descripcin funcional se describen todas las funciones necesarias para desarrollar la problemtica en cuestin. Adems se describe cada funcin, estableciendo restricciones y sus debidas justificaciones. Adems se establecen caractersticas del rendimiento. 4. La descripcin del comportamiento describe el operar del software que se ve afectado por acontecimientos externos. 5. Los criterios de validacin no se profundizan en esta etapa debido a que en la prxima seccin se describe, sin embargo se pude describir que la especificacin de los criterios de validacin acta como una revisin de todos los requerimientos.

Captulo 1: Introduccin 3.1.4 Validacin de requerimientos

En esta etapa se establecen los requerimientos finales completos que definirn el sistema que el cliente desea. Segn [3] para validar los requerimientos se deben realizar las siguientes verificaciones: 1. Verificacin de Validez. Esta verificacin se refiere a que un usuario puede pensar que se necesita un sistema para llevar a cabo ciertas funciones; sin embargo, el razonamiento y el anlisis identifican que se requieren funciones adicionales y diferentes 2. Verificacin de consistencia. Esta verificacin se refiere a que los requerimientos en el documento de requerimientos no deben de contradecirse; es decir no deben existir contradicciones con respecto a cualquier funcionalidad del sistema. 3. Verificacin de integridad. Esta verificacin hace alusin a que en el documento de requerimientos deben de estar todas las funcionalidades y restricciones propuestas por el usuario para el sistema 4. Verificacin de realismo. Esta verificacin hace referencia a que los requerimientos definidos han de poder implementarse utilizando las tecnologas existentes. Adems estas tecnologas deben considerar el presupuesto, fechas de entrega y desarrollo del sistema. 5. Verificabilidad. Consiste en establecer un conjunto de verificaciones que permitan demostrar que el sistema cumple con los requerimientos definidos en el documento de requerimientos. Existen diversos tipos de enfoques que permiten realizar una verificacin de los requerimientos dentro de las cuales se puede destacar, segn [3], las siguientes: 1. Revisiones de requerimientos. Esta es una tcnica manual que consiste en que los requerimientos son analizados nuevamente entre los clientes y los desarrolladores. En caso de que existan omisin o error en algn requerimiento se recomienda que el desarrollador negocie alguna solucin con el cliente. 2. Construccin de prototipos. Esta tcnica consiste en crear un modelo en base a los requerimientos ya establecidos. Existen dos tipos de prototipos, tanto los prototipos desechables como los prototipos evolutivos. Los prototipos desechables consisten en definir un modelo para demostrar el cumplimiento de los requerimientos definidos con lo cual se puede reducir los costos involucrados en el ciclo de de vida del desarrollo. Una vez hecha esta evolucin el prototipo se desecha. Los prototipos evolutivos consisten en desarrollar una implementacin inicial, exponerla a los stakeholders e irla refinando hasta llegar a un desarrollo de sistema adecuado, este tipo de prototipo tiene como objetivo desarrollar un prototipo rpida para que el cliente valore los resultados y recomiende cambios de una manera oportuna.

Captulo 1: Introduccin

10

Adems segn [1] existen distintas metodologas para la realizacin de prototipos, dentro de los cuales se puede destacar: I. Tcnica de Cuarta Generacin. Esta tcnica comprende muchos lenguajes de cuarta generacin (4GT), los cuales permiten realizar cdigos ejecutables de una manera rpida lo que conlleva a crear prototipos rpidamente. II. Componentes de Software reutilizables. Esta tcnica consiste, en vez de disear, utilizar componentes de software ya creados. En caso de que se tenga que crear componentes de software es recomendable disear componentes que puedan ser realizados posteriormente. III. Especificaciones formales y entornos para prototipos. Esta tcnica es referente a crear entornos interactivos que permitan facilitar la tarea de especificacin tanto al analista como al cliente, es decir que permita al analista crear una especificacin basada en algn lenguaje de modo que se puedan invocar herramientas automticas que traduzcan la especificacin basada en el lenguaje a un cdigo ejecutable, y que permitan a los clientes usar el cdigo ejecutable del prototipo para refinar los requerimientos IV. Generacin de casos de prueba. Consiste en disear pruebas que permitan verificar los requerimientos establecidos. Se recomienda que si una prueba es difcil de disear se debe reconsiderar la estipulacin del requerimiento, debido a que lo ms probable es que ese requerimiento sea difcil de implementar. V. Anlisis de consistencia automtico. Esta tcnica es muy til cuando se expresan los requerimientos como un modelo del sistema, por lo que la consistencia del modelo debe ser verificada por alguna herramienta CASE, la cual construye una base de datos de requerimientos basada en los requerimientos establecidos.

11

CAPTULO 2: METODOLOGA DE TRABAJO


En este captulo se especificar, a partir del problema enunciado, qu metodologa de trabajo podra emplearse a fin de cumplir los objetivos propuestos. Es decir, se evaluarn las caractersticas del problema y se plantear y especificar la metodologa acorde a las necesidades a cubrir.

2.1

ANLISIS DEL PROBLEMA

El objeto de estudio, en este proyecto, es el proceso de levantamiento de requerimientos dentro del proceso de desarrollo de software. Como se vio en la definicin del problema en el captulo anterior, ste proceso esta determinado en gran medida por el papel que juega la organizacin y comunicacin entre los actores humanos. Es por esto que la eleccin de un mtodo reduccioncita, aparentemente es poco auspiciosa por la complejidad de estudio que presentan los distintos tipos de organizaciones humanas. En cambio, existen variadas metodologas de pensamiento sistmico que contemplan muchos aspectos que se dan dentro de las organizaciones humanas, las cuales finalmente son consideradas no como sistemas deterministas o duros, si no como un sistema donde se tienen distintos puntos de vista y de inters y donde se corre el riesgo (y a menudo ocurre) de confundir o colisionar los objetivos que se tienen sobre la situacin. A los sistemas que cumplen con estas caractersticas, como nuestro objeto de estudio, se les denominan sistemas blandos.

2.2 METODOLOGA Metodlogy)

DE

SISTEMAS

BLANDOS

(Soft

System

En consideracin con lo expresado en la seccin anterior, una metodologa que cumple con esos requisitos de pensamiento sistmico, es la metodologa de sistemas blandos (SSM) de Peter Checkland.
[La metodologa de sistemas blandos, soft systems methodology (SSM en ingls, o MSB en espaol] es una metodologa que busca lograr mejoras en reas de inters social [v.gr., organizaciones humanas] catalizando un nmero indefinido de ciclos de aprendizaje en la gente involucrada en la situacin [blanda que es objeto de atencin]. El aprendizaje se canaliza a travs de un proceso iterativo que consiste [primero] en reflexionar y debatir diferentes percepciones del mundo real, usando conceptos de sistemas; [segundo] llevando a cabo acciones en el mundo real [influenciadas por estas reflexiones y debates], y [tercero] usando conceptos sistmicos para reflexionar sobre los resultados obtenidos con dichas acciones. Tanto la reflexin como los debates se estructuran usando diferentes modelos sistmicos. Estos modelos son concebidos como tipos ideales holsticos [holones] de ciertos aspectos de la situacin problemtica y no como descripciones [o fotografas] de la situacin... (Lpez & Sotaquir, [4] en cita a Checkland & Scholes, 1990, pag.28,

traduccin libre).

Captulo 2: Metodologa de trabajo

12

Como se explica en la cita anterior, la SSM ayuda a dar tratamiento a problemticas como las que presenta el proceso de captura de requerimientos en el desarrollo de software a travs del concepto de Weltanschauung. ste concepto, segn [5], habla del estudio de un sistema a travs de las distintas visiones de los distintos observadores que actan sobre ste. Es as como en el desarrollo de este proyecto, se ha optado por aplicar esta metodologa. La especificacin de sus etapas, actividades y productos se detalla a continuacin. 2.2.1 Esquema general La SSM esta compuesta por siete diferentes actividades divididas en dos grupos: un grupo sobre la experiencia en el sistema y uno sobre el pensamiento de sistemas. Las siete actividades o estadios poseen un orden lgico de entendimiento y otro orden distinto de aplicacin. Como se menciona en [5], mientras que la numeracin de los estadios sigue un orden en pos de describir la metodologa, el desarrollo de cada uno puede efectuarse perfectamente en forma paralela a otros. En la figura 2.1 se muestra las actividades de la SSM. Segn [7] las actividades son:

Figura 2.1: Actividades de la SSM.

Captulo 2: Metodologa de trabajo 2.2.2 Actividad 1: La situacin problema no estructurada

13

En esta primera actividad de la SSM se identifica una primera impresin de la situacin problema, presentando la porcin de la realidad social en la que existe. Es el primer encuentro con la situacin problema, por lo que el investigador debe coleccionar la mayor cantidad de percepciones del problema provenientes de gente que posee roles en esta situacin problema. Esta es una etapa complicada, porque generalmente se expresa el deseo de realizar alguna accin inmediatamente para combatir el problema. 2.2.2 Actividad 2: La situacin problema expresada En esta segunda actividad se convierte la primera impresin de la situacin problema en una representacin pictrica llamada Rich Picture del cual se seleccionarn el o los puntos de vista a partir de los cuales se estudiar con mayor detalle la situacin problema. El Rich Picture debe considerar las situaciones conflictivas, intereses en comn, ideologas existentes y sus consecuencias futuras y el modo en los involucrados ven la situacin problema. 2.2.3 Actividad 3: Definiciones raz de los sistemas pertinentes En esta tercera actividad se obtienen definiciones raz, sistema social a la Vickers y sistemas polticos, CATWOE y definicin raz elaborada, los cuales se definen a continuacin: 1. Definiciones raz. Las definiciones raz son derivadas del anlisis del Rich Picture las cuales son hiptesis que tienen relacin con el mejoramiento de la situacin problema por medio de cambios en los que tanto el investigador como los dueos del problema acuerdan que son viable 2. Sistemas sociales a la Vickers y sistemas polticos. Los sistemas sociales a la Vickers permiten observar los sistemas sociales al interior de la organizacin y poder representarlos como instancia de un vector <rol,norma,valor>. En este vector, rol es un papel que cumple una persona en una organizacin, mientras que norma es el comportamiento que se espera cumpla ese rol dentro de la organizacin y valor representa el desempeo actual de un rol para jugarle sobre lo que es bueno y lo que es malo. 3. Los sistemas polticos, originados del estudio de los sistemas sociales a la Vickers, permiten mostrar como el poder (grupos cohesionados que tiene un punto de vista y estn en contra de otros que tiene una posicin contraria) se expresa a travs de la situacin problema mediante distintos grupos de poder. 4. CATWOE. Es un nemnico que tiene agrupado a los clientes(C), actores (A), transformacin (T), weltanschauung (W), dueo (O) y entorno (E). Los clientes son quienes se ven beneficiados o perjudicados por el funcionamiento del sistema. Los actores son los que permiten que el proceso de transformacin se lleve a cabo. El weltanschauung es el punto de vista que origina la definicin raz. Los owners son quienes pueden detener la transformacin si lo desean. El entorno es el medio que restringe o posibilita las acciones dentro del sistema donde la transformacin se efecta.

Captulo 2: Metodologa de trabajo

14

5. Definicin raz elaborada. Es la reformulacin de la definicin raz original que se determina con los datos obtenidos del CATWOE. La diferencia existente entre la definicin raz y la definicin raz elaborada radica en que la primera solo indica el qu se debe hacer, mientras que la definicin raz elaborada indica el qu hay que hacer, el cmo hay que hacerlo y el para qu hay que hacerlo. 2.2.4 Actividad 4: Confeccin y verificacin de modelos conceptuales En esta etapa se generan modelos que logren realizar lo que se describe en las definiciones races mediante sistemas de actividad humana (HAS) que describen la actividad necesaria para lograr la transformacin, es decir, consiste en la creacin de los modelos conceptuales de los sistemas que se definen en las etapas anteriores. Esta cuarta etapa es nutrida por otras dos etapas. 2.2.4.1 Actividad 4a: Concepto de sistema formal Esta sub-etapa consiste, bsicamente, en verificar que los modelos construidos no sean deficientes, para esto se usa un modelo general de sistema de actividad humana, un modelo formal. 2.2.4.2 Actividad 4b: Otros pensamientos de sistemas Con fin de estructurar el sistema en cuestin mediante una perspectiva distinta, es necesario modelar la situacin para as identificar todas las variables del sistema. Un mtodo que colabora con ste fin, es el modelo formal de los Nueve niveles de Jean Louis Le Moigne. ste modelo, habla de nueve etapas que ayudan a estructurar el sistema identificando los subsistemas existentes y sus roles. Primer nivel: Distincin base El observador identifica un sistema operando en un determinado ambiente o entorno.

Entorno Sistema
Figura 2.2: Primer nivel de Le Moigne

Captulo 2: Metodologa de trabajo Segundo nivel: Sistema operacional

15

El observado identifica lo que hace el sistema a travs de las entradas, salidas y transformaciones observadas.

Entorno Sistema
Figura 2.3: Segundo nivel de Le Moigne Tercer nivel: Sistema de regulacin El observador reconoce dos subsistemas: regulador y operacional, donde ste ltimo es gobernado por el primero.

Sistema
Sistema regulador

Sistema operacional
Figura 2.4: Tercer nivel de Le Moigne

Captulo 2: Metodologa de trabajo Cuarto nivel: Sistema de informacin

16

Dentro del sistema de regulacin, se encuentran sistemas de flujo de informacin que permiten la regulacin del operar.

Sistema regulador
Sistema de informacin

Sistema operacional
Figura 2.5: Cuarto nivel de Le Moigne Quinto nivel: Sistema de memorizacin El observador identifica sistemas de almacenamiento de la informacin.

SR

Sistema de informacin

Sistema de memorizacin on

Sistema operacional

Figura 2.6: Quinto nivel de Le Moigne

Captulo 2: Metodologa de trabajo Sexto nivel: Sistema de decisin Se postula la existencia de un sistema que decide sobre los comportamientos.

17

SR

Sistema de decisin

Sistema de informacin

Sistema de memorizacin on

Sistema operacional
Figura 2.7: Sexto nivel de Le Moigne

Captulo 2: Metodologa de trabajo Sptimo nivel: Sistema de coordinacin El observador identifica un sistema que coordina las decisiones de accin.

18

Sistema de decisin Sistema de coordinacin

SR
Sistema de informacin

Sistema de memorizacin on

Sistema operacional

Figura 2.8: Sptimo nivel de Le Moigne

Captulo 2: Metodologa de trabajo Octavo nivel: Sistema que imagina

19

El observador encuentra un subsistema que concibe nuevas decisiones en eventuales situaciones.

Sistema de decisin
Sistema de imaginacin

Sistema de coordinacin

SR
Sistema de informacin

Sistema de memorizacin on

Sistema operacional
Figura 2.9: Octavo nivel de Le Moigne

Captulo 2: Metodologa de trabajo Noveno nivel: Sistema de clausura El sistema presenta un subsistema de clausura o finalizacin

20

Sistema de decisin

Sistema de clausura

Sistema de imaginacin

SR
Sistema de coordinacin

Sistema de informacin

Sistema de memorizacin on

Sistema operacional

Figura 2.10: Noveno nivel de Le Moigne

Captulo 2: Metodologa de trabajo 2.2.5 Actividad 5: Comparacin de los modelos conceptuales con la realidad

21

En esta etapa se realiza una comparacin entre los modelos conceptuales o mentales obtenidos en la actividad 4 versus el mundo real obtenido en la etapa 2, para llevar a cabo esta comparacin se debe de considerar a los participantes involucrados en el problema de estudio, para con esto generar el debate sobre la condiciones del problema en cuestin. Esta confrontacin o debate permite realizar una real evaluacin del pensamiento desde el punto de vista de la epistemologa, es decir la posibilidad de conocer la realidad en forma ms profunda y lo mas fidedigna posible. Es menester destacar que para realizar una adecuada comparacin sta debe ser consciente, coherente y defendible. 2.2.6 Actividad 6: Diseo de cambios deseables, viables Esta fase tiene por objetivo hacer comparaciones entre modelos conceptuales y generar tres tipos posibles de cambios, los cuales son: estructurales, procedimientos, actitudes. Los cambios estructurales tienen que ver con modificar o cambiar hechos de la realidad que en ocasin continan corriendo. Los cambios en los procedimientos cambian a los elementos dinmicos. Finalmente los cambios en las actitudes tienen que ver con cambios en la influencia, cambios en las expectativas, cambios en la prontitud para tasar ciertos tipos de comportamiento. Es menester destacar que para cumplir con los objetivos de esta fase (cambios estructurales, procedimientos, actitudes), deben estar las personas que forman parte del problema. 2.2.7 Actividad 7: Acciones para mejorar la situacin problema En esta fase se llevan a cabo las aplicaciones de los cambios realizados anteriormente (etapa 6). Esta introduccin de cambios puede modificar o cambiar la situacin del problema percibido originalmente para lograr que surjan nuevos problemas, que corresponde al objetivo principal de esta etapa debido a que el problema esta en constantes cambios, y para tratar estos nuevos problemas se puede utilizar la misma metodologa descrita hasta ahora.

Captulo 3: Bibliografa

22

BIBLIOGRAFA
A continuacin se ilustra el material bibliogrfico utilizado para la realizacin de este trabajo. [1] [2] ROGER PRESUMAN, Ingeniera del Software Un enfoque prctico. Cuarta edicin. Mc Graw Hill JOS LUIS TORRES, Especificacin de requisitos en ingeniera de software. http://www.ewh.ieee.org/r9/guadalajara/boletin/sep01/requerimientos.htm ltima visita 09/10/07 IAN SOMERVILLE, Ingeniera del Software. Sexta edicin, Addison Wesley, Mxico. HERNN LPEZ, RICARDO SOTAQUIR, La Metodologa De Sistemas Blandos De Chekcland: El Heraldo De Un Cambio Paradigmtico En El Movimiento De Sistemas. ANDRES MARTNEZ, Una metodologa para el diseo de sistemas de informacin, basada en el estudio de sistemas blandos, Revista Espacios Vol. 25 (2) 2004. http://www.revistaespacios.com/a04v25n02/04250231.html Un Resultado Principal de la Investigacin: La Metodologa de Sistemas para Enfrentar Problemas No Estructurados, Documentacin del Curso Ingeniera de Sistemas, Diinf, Usach. Segundo semestre 2007 JOS MUOZ GAMBOA, Aplicando la metodologa de los sistemas blandos. Documentacin del Curso Ingeniera de Sistemas, Diinf, Usach. Segundo semestre 2006.

[3] [4]

[5]

[6]

23

APNDICE A: CUESTIONARIO APLICADO


A continuacin se exponen las preguntas realizadas a los entrevistados. Estos entrevistados fueron dos Ingenieros Civiles Informticos con ms de 10 aos de experiencia laboral y un Ingeniero Civil Informtico 1 ao 5 meses de experiencia laboral. Es menester destacar que las siguientes preguntas fueron realizadas con los objetivos planteados en el captulo 1, seccin 1.2. Como se aplica la SSM las siguientes preguntas se han dividido en cuatro grupos. El primer grupo es Identificacin del problema. El segundo grupo es Definicin de Actores Sociales. El tercer grupo es Rich Picture. El cuarto grupo es Sistemas sociales y polticos. El quinto grupo es CATWOE, HAS. 1. Identificacin del problema 1.1 Cules son los principales problemas que posee el proceso y de dnde provienen dichos problemas. 1.2 De qu forma afectan a usted y al proceso de captura de requerimientos dichos problemas? 2. Definicin de actores sociales 2.1 Cules son los actores (personas/unidad) fundamentales en el funcionamiento del proceso de captura de requerimientos? 2.2 Quin o Quines regulan el proceso de captura de requerimientos y su actividad? 2.3 Quin o Quienes son sus clientes? 3. Rich Picture 3.1 Cree que el proceso es burocrtico o expedito? 3.2 Cmo es la relacin entre las personas con las que usted tiene comunicacin directa en el trabajo? 3.3 Realiza labores no asociadas con el trabajo propio del proceso de captura de requerimientos? 3.4 Existen problemas que tengan que ver con contradicciones, poca claridad en los requerimientos o desconocimiento de los mismos? 4. Sistemas sociales y polticos 4.1 Cul es su rol dentro del proceso? 4.2 Qu es lo que debe resaltarse positivamente del servicio que usted entrega? 4.3 Se rige su trabajo particular por algn reglamento externo o interno?, Cul es ese reglamento y dnde se encuentra?

Apndice A: Cuestionario aplicado 5. CATWOE, HAS

24

5.1 Cules seran las mejoras que realizara para mejorar el funcionamiento del proceso? y Por qu stas no se han realizado? 5.2 Quin o quienes poseen la atribucin de modificar la operatividad del proceso de captura de requerimientos si lo desean?

Apndice B: Respuestas cuestionario

25

APNDICE B: RESPUESTAS CUESTIONARIO


A continuacin se exponen las argumentaciones de los entrevistados al cuestionario descrito anteriormente. Es menester destacar que las siguientes respuestas son una transcripcin literal de las respuestas otorgadas por los entrevistados, lo que implica que no se ha alterado nada ni siquiera su redaccin debido a que se considera que cualquier modificacin podra alterar la informacin obtenida por parte de los entrevistados.

Ingeniero un ao y medio de experiencia: Luis Berrios


1. Identificacin del problema 1.1 Cules son los principales problemas que posee el proceso y de dnde provienen dichos problemas? Uno de los problemas que hay, propios del levantamiento de requerimientos, es que si bien existe un lenguaje estndar que es para hacer este proceso, UML, el usuario, por lo general, no sabe ocuparlo y an as, aunque el analista pueda hacer un levantamiento de requerimientos y plasmar los requerimientos funcionales y no funcionales del usuario, al llevarlo a UML a veces se olvidan cosas o hay cosas que no son claras como para redactarlas en un prrafo o en una serie de puntos que describan el sistema que va a desarrollarse. 1.2 De qu forma afectan a usted y al proceso de captura de requerimientos dichos problemas? Uno de los grandes problemas, cuando se llevan los requerimientos a desarrollar el sistema, es saber si se est haciendo lo que quiere el cliente. Para evitar eso, se desarrollan prototipos funcionales y se muestran antes de mostrar la implementacin al final. Si no que se muestran estos prototipos funcionales para saber con anticipacin si se esta haciendo lo que el cliente quiere, o no. 2. Definicin de actores sociales 2.1 Cules son los actores (personas/unidad) fundamentales en el funcionamiento del proceso de captura de requerimientos? El director de orquesta del proceso es el arquitecto de diseo o de dominio, quien es la persona que define los procesos para el levantamiento de requerimientos y despus llevar esos requerimientos al equipo de desarrollo para plasmarlo en el sistema que se quiere desarrollar. Por otro lado el tiene que estar monitoreando cmo los analistas de negocios estn interviniendo con los usuarios y si el levantamiento de requerimientos es el adecuado o no. Los otros actores, los analistas de negocios, son las personas encargadas de interactuar con el cliente para recabar cuales son los aspectos que ste espera que contemple el sistema. Esto tiene que ver con la funcionalidad y lo que espera el cliente.

Apndice B: Respuestas cuestionario

26

Por otro lado estn los analistas funcionales, que son los que, entre comillas, dominan el mdulo de la aplicacin y que son los que interactan con el desarrollador, para que el desarrollador, en vez de ir con el cliente, interacte con ese analista para saber qu es lo que necesita el cliente. 2.2 Quin o Quines regulan el proceso de captura de requerimientos y su actividad? Como te deca en el punto anterior, el que regula realmente el proceso de levantamiento de requerimientos es el arquitecto de dominio o el arquitecto general del proyecto. No obstante, tambin hay un ente que regula el proyecto, que sera el jefe de proyecto. Y si el proyecto es lo suficientemente grande en tiempo y dinero, incluso existe hasta un gerente de proyecto. No obstante, cuando existe este gerente, ste no regula lo que es el proceso de levantamiento de requerimientos. Pero el jefe de proyectos s lo puede hacer, ya que l es el que se encarga de revisar a nivel macro tanto lo que es el levantamiento de requerimientos, como el proceso de desarrollo y los procesos posteriores como es soporte o el paso del sistema a produccin. 2.3 Quin o Quienes son sus clientes? El trabajo anterior donde estaba yo, era ING. Ese era un caso particular en el desarrollo de software, pues el cliente era una persona miembro de ING, que se le llama sponsor. El sponsor es una persona que solicita una cantidad de dinero para desarrollar sistemas informticos, para que funcionen de mejor forma o para apoyar procesos nuevos dentro de la compaa. Ese es un caso particular. Pero por lo general, los clientes son empresas o personas naturales externas. En este ultimo caso, en mi trabajo, nuestros clientes son empresas mineras y petroleras en general. 3. Rich Picture 3.1 Cree que el proceso es burocrtico o expedito? Mientras ms grande es la empresa de desarrollo de software, siempre es ms burocrtico. Por ejemplo en ING, como estaban con el modelo CMMI, estaba todo demasiado definido y estructurado. Por ejemplo, desde que tu terminas de producir un cierto componente o mdulo del sistema hasta que los analistas de calidad, que son los QA (el analista de calidad es el que mediante una serie de pruebas revisa si lo que tu produjiste es lo que quera el cliente o no). Bueno, la iteracin entre que t desarrollas y pasas a QA, que es el ambiente donde se hacen las pruebas funcionales a tu sistema, a veces se haca muy tedioso. Podan estar desde una semana hasta un mes. Por otro lado, desde que t tienes una duda como desarrollador, para pasrsela al analista funcional y que este a su vez se la transmitiera el cliente y que retornara la respuesta, poda demorar hasta dos semanas, dentro de mi experiencia, por eso a veces es muy tedioso. Mientras que en empresas chicas, el desarrollador puede ser el mismo analista funcional e ir a preguntar directamente al cliente. El problema es que no hay una persona que se abstraiga de lo que es el desarrollo y otra del levantamiento de requerimientos.

Apndice B: Respuestas cuestionario

27

3.2 Cmo es la relacin entre las personas con las que usted tiene comunicacin directa en el trabajo? Yo era analista de sistema y desarrollador. A nosotros nos llegaban los requerimientos a travs del analista funcional, que era el encargado de desarrollar el caso de uso, para que t lo desarrollaras. Entonces mi relacin se basaba entre mi team lder, que es la persona que manejaba el equipo de desarrollo, y el analista funcional. Una vez al mes se hacan reuniones con el analista de planificacin, que era la persona que bsicamente se encargaba del cumplimiento de las cartas Gantt y cada tres meses, con el jefe de proyecto que era donde se ponan todas las cartas sobre la mesa y se comentaban los problemas que haban ocurrido en el pasado. 3.3 Realiza labores no asociadas con el trabajo propio del proceso de captura de requerimientos? Te voy a nombrar los roles que tuve en mi antiguo cargo: Uno de ellos era analista de impacto, que cuando llegaban los requerimientos del cliente, en caso de realizar soporte a una aplicacin o modificacin a una aplicacin, tenias que ver cmo iba a impactar lo que estaba pidiendo el cliente en lo que ya haba hecho. Entonces t tenas que ver en los modelos de datos, el cdigo de las aplicaciones hechas, y ver si lo que estaba pidiendo era posible o no de hacerlo y cuanto iba a demorar. Entonces ah tambin venia una especie de planificacin donde tu tenias que dar una estimacin de cuanto iba a demorar. Despus, vena un tiempo de desarrollo y un tiempo de testing, que si bien ya haba un equipo encargado de hacer testing, el equipo de QA, nosotros tambin hacamos pruebas funcionales para tratar reducir los tiempos de iteracin entre nosotros y el equipo de QA. Pero bsicamente los roles que tena siempre estaban dentro de mis funciones. 3.4 Existen problemas que tengan que ver con contradicciones, poca claridad en los requerimientos o desconocimiento de los mismos? Te voy a decir un caso bien puntual. El problema que hay ahora con las empresas informticas es que como muchas estn trabajando con recursos out sourcing, por ejemplo, si bien la persona de ese proyecto de ING, era sponsor de ese proyecto y era gerente del rea comercial. l debera saber todo lo que eran las condiciones de negocio o las reglas de negocio, por ejemplo cuando dar crdito a una persona. Pero como ella, supongo yo que no saba, delegaba toda esa responsabilidad de sabidura o conocimiento a personas externas que tampoco lo saban. Entonces eso haca que cuando llegaban los requerimientos al analista funcional, estos eran poco claros y an as como algo natural, quizs, cuando se pasan las cosas de una persona a otra, se va perdiendo informacin. 4. Sistemas sociales y polticos 4.1 Cul es su rol dentro del proceso? Se respondi en la pregunta N 3.3 4.2 Qu es lo que debe resaltarse positivamente del servicio que usted entrega?

Apndice B: Respuestas cuestionario

28

Si bien, en ING haba demasiada burocracia. La misma burocracia permita ordenar el trabajo, otorgar responsabilidades cosa de que si una persona o proyecto X tena alguna disfuncin, t ya sabas a quien recurrir. O si tenas algn problema de cualquier ndole, estaba todo bien documentado, entonces tu ya sabes quien era el responsable y haban los mecanismos necesarios para reportar los errores o saber escalar y a quin escalar si es que esa persona no poda responder por cualquier motivo. 4.3 Se rige su trabajo particular por algn reglamento externo o interno? Cul y dnde se encuentra? En el caso de ING, el reglamento lo daba directamente la casa matriz, que reside en estados unidos. Son las personas que envan todo lo que son los procedimientos bsicos de la empresa y en caso de nosotros como informticos, el departamento de arquitectura de ING en estados unidos, son los que envan los documentos a ING Chile para normar los roles y funciones de cada persona y ac en Chile lo que hace el arquitecto es velar por que esas normas se cumplan. 5. CATWOE, HAS 5.1 Cules seran las mejoras que realizara para mejorar el funcionamiento del proceso? y Por qu stas no se han realizado? Yo creo que a veces, como en ING se estaba trabajando directamente con un cliente que esta dentro de la empresa, ms que saltar como catlicamente que yo tena que transmitirle a una persona y esa a otra y as sucesivamente, podra haber... Entrevistador: Reuniones grupales? Entrevistado: Claro, reuniones grupales o la posibilidad de consultar directamente a esa persona, porque son cosas tan pequeas que te las pueden responder con una llamada telefnica o un email, pero que por la norma de la empresa, en este caso el modelo CMMI a veces no se puede, pues est contradiciendo a lo que te dice el modelo o la especificacin de los roles. 5.2 Quin o quienes poseen la atribucin de modificar la operatividad del proceso de captura de requerimientos si lo desean? En caso de ING, arquitectura, porque el jefe de proyecto no puede violar los procedimientos o polticas de una empresa. Pero el arquitecto s lo puede hacer, o sea, mas que violarlo puede modificar el reglamento en forma excepcional para un proyecto si es requerido, pero ni el team lder ni el jefe de proyecto lo pueden hacer.

Apndice B: Respuestas cuestionario

29

Ingeniero diez aos de experiencia: Arnoldo Carrillanca


1. Identificacin del problema 1.1 Cules son los principales problemas que posee el proceso y de dnde provienen dichos problemas? Estas preguntas las voy a responder dentro del contexto de un proyecto que estoy gerenciando para el sector pblico. Este proyecto ya culmin su etapa de diseo y actualmente esta en su etapa de construccin. De un total de nueve mdulos se han construido cinco, de los cuales dos hay que hacer de nuevo. El problema fue que esta institucin de gobierno hizo un cambio en su directiva y se dieron cuenta que lo que se estaba construyendo no se ajustaba a lo que el cliente final quera. Se procedi a solicitar un control de cambio. Este control de cambio, finalmente no fue aprobado por el cliente, porque el proyecto lleva un atraso de un ao. Negociamos con el cliente y una de las cosas que result, es que nosotros nunca hemos logrado entender lo que ellos realmente quieren. Ellos tambin asumen su responsabilidad por el cambio en su directiva. Pero, bsicamente, se determino que nuestros analistas no pudieron extraer lo que ellos queran. 1.2 De qu forma afectan a usted y al proceso de captura de requerimientos dichos problemas? A nosotros nos afecta, porque esta empresa se maneja con rentabilidades de un cuarenta a un cuarenta y cinco por ciento sobre el precio de venta. Eso significa que de diez pesos que nosotros vendemos, cinco son para cubrir costos y cinco, para cubrir rentabilidad y riesgos asociados. Como sabemos que todos estos proyectos de software se demoran, pues no existe una buena comunicacin entre los analistas y el cliente, asumimos que nuestra rentabilidad, finalmente, es de un veinte por ciento. En el caso del proyecto que estoy mencionando, la rentabilidad va en cero. Es ms, ya esta resultando negativa. Tambin nos afecta en trminos de confianza. El cliente pierde la confianza y cuando esto sucede, no est dispuesto a negociar y es por esto que no quisieron aceptar nuestros controles de cambio sobre esos dos mdulos que ya estaban construidos. Esto no oblig a nosotros como empresa a asumir esta prdida de confianza y aceptar el control de cambio sin un pago de por medio, ya que lo que nos conviene es mantener la imagen. 2. Definicin de actores sociales 2.1 Cules son los actores (personas/unidad) fundamentales en el funcionamiento del proceso de captura de requerimientos? Este proyecto tiene un gerente de tecnologas de informacin, por parte del cliente, quien podra llamarse el dueo del proceso. Est el sponsor, quin es el cliente final, el que recibe el sistema, el que lo va a usar. Estn los clientes finales de este sponsor, que son los usuarios finales del sistema. Est el equipo de proyecto de este sistema, que est compuesto cuatro analistas, seis programadores, cuatro analistas de proceso, de levantamiento de requerimientos, seis programadores especialistas en

Apndice B: Respuestas cuestionario

30

.NET, de varias universidades. Tenemos, tambin, un jefe de proyecto, ejerciendo por primera vez el cargo, por lo tanto existe un factor de riesgo. Este proyecto ha tenido un cambio de jefatura varias veces. Yo debo ser el cuarto gerente que ha pasado por la jefatura de este proyecto. Por lo tanto a mi me toca terminarlo. Yo soy como un -como un salvavidas?-, no como un salvavidas, porque sera catalogarse como un superhombre. Un superhombre en un proyecto de tecnologa, donde se involucra a varias personas, no existe. Esto es trabajo en equipo. Esto significa que se deben fijar normas y objetivos claros y proveer al jefe de proyecto de todo lo que necesita. 2.2 Quin o Quines regulan el proceso de captura de requerimientos y su actividad? Ac se plantean varios procesos. En trminos del proceso de desarrollo de software, nosotros estamos trabajando bajo normas CMMI y CMM2. Hay testing, hay pruebas funcionales y unitarias, hay pruebas de negocios. Hay gente que est especializada en estos temas y son quienes los van resolviendo. Por lo tanto, en cada etapa del proceso, necesitamos entregables. Ahora, uno de los problemas que tiene este proyecto es que estos entregables existen, pero nunca fueron formalizados, producto de malas gestiones anteriores a las mas. Yo en este proyecto, tuve que involucrar a gente de QA y a gente de una oficina de PMO con el fin de aplicar buenas prcticas en la gestin de proyectos. Tenemos otro proceso, que es la negociacin con el cliente. Yo soy el responsable de ello. Discutir todo los temas econmicos, cualquier cambio que involucre el poner ms gente, sacar gente, etc. Es un proceso de negociacin constante. Tambin tenemos un proceso administrativo. Hay problemas contractuales que tenemos que ir regulando en un proyecto que lleva de atraso, un ao, esta el problema de vigencia. Hay multas asociadas. Este proceso administrativo lo llevo junto a la gente de PMO, que es gente que bsicamente se preocupa de ver todo el tema contractual, el tema logstico, etc. Y hay un proceso de gestin de recursos humanos, que es parte de las buenas prcticas de CMMI, cuyo fin es discutir la sobrecarga que tendr el personal y que todo esto se vea compensado. 2.3 Quin o Quienes son sus clientes? En este caso es una empresa del sector pblico. Mi finalidad es terminar este proyecto que no se ha terminado en un ao, finalizarlo en tres meses. Para m, el cliente final es todo el sector pblico. 3. Rich Picture 3.1 Cree que el proceso es burocrtico o expedito? En mi caso, yo soy muy apegado a las buenas prcticas de CMMI, pero me gusta trabajar rpidamente, entonces cuando veo cuellos de botella, hago todas las gestiones para que sea rpido. O sea, por parte de nosotros existen sistemas de gestin, sistemas de control y por parte del cliente tambin, porque es el gobierno. Pero el cliente es muy burocrtico, ya que hacer cambios de contrato y anexos de contrato es muy engorroso, y por parte nuestra es engorroso, porque estamos recin

Apndice B: Respuestas cuestionario

31

aprendiendo a usar estos sistemas. Hoy da podramos catalogar como burocrticos los sistemas, pero en mi caso, como tengo bastantes aos de experiencia, trato de acelerar el proceso. Entrevistador: Cmo soluciona estos cuellos de botella que se producen? Entrevistado: Generalmente lo que hago es tratar de identificar las fallas y su causa, en un proceso normal a veces consiste en reclutar un nuevo profesional, por ejemplo un programador, proceso que puede durar 2 meses, desde que nos ponemos en contacto, realizar la entrevista, buscar la persona idnea, etc., al final yo elijo a esta persona, pero luego viene el proceso de reclutamiento por parte de Recursos Humanos, los que realizan entrevistas psicolgicas y las evaluaciones necesarias, y como estos procesos se estn recin implementando en nuestra empresa, lo que yo hago hoy, es adelantarme, hablo con Recursos Humanos para facilitar la entrada del nuevo profesional, informndome bien como es el proceso. Entrevistador: Esta estrategia que aplica se debe a la experiencia? Entrevistado: A la experiencia bsicamente, he tenido la suerte de gerenciar proyectos con presupuestos anuales de 4 millones de dlares, y para manejar esas cifras te tienen que haber pasado muchas cosas. Me ha pasado de todo en los proyectos. Entrevistador: Para planificar los proyectos Ud. establece un tiempo determinado, es decir, ha estandarizado el tiempo necesario para finalizar el proyecto? Entrevistado: S, como he participado en varios puestos en el rubro de informtica, uno de los puestos que ocup fue el de Gerente de Preventas, quien es el responsable de preparar la oferta que va a salir al mercado, crear la propuesta, estimar plazos, roles, recursos involucrados, etc. Y eso entregrselo al Gerente Comercial. Hoy da yo cumplo el rol de Gerente Comercial, como ves he estado en toda la cadena productiva. Empec en el rea tecnolgica y ahora estoy en el ltimo eslabn de la cadena de valor. Nosotros tenemos planillas de clculo para evaluar proyectos, y estas planillas han sido elaboradas principalmente con Juicio Experto, inicialmente ocupbamos Puntos de Funcin, pero hoy da no se ocupa porque los Ingenieros no vienen especializados en el tema. 3.2 Cmo es la relacin entre las personas con las que usted tiene comunicacin directa en el trabajo? Es bastante buena, porque como te coment he hecho cuatro Magster, dos de los cuales son del rea de ciencias polticas y sector pblico, los otros dos del rea tecnolgica, pero me he titulado de tres. El xito de los proyectos se basa en la comunicacin, y para tener buena comunicacin hay que ser cercano a las personas, hay que saber ponerse en su lugar y darse el tiempo para hacer una llamada telefnica, saber como estn, y cuando el equipo es un equipo cercano aprovechaba de almorzar con ellos, mantena reuniones diarias, reuniones semanales para hacer un seguimiento del rendimiento de la semana, me daba el tiempo de escuchar a las personas, escuchar

Apndice B: Respuestas cuestionario

32

sus problemas, etc. Mantengo una comunicacin muy abierta. Con los jefes de proyecto la comunicacin es ms profesional, yo les tengo que exigir a ellos y ellos obviamente me tienen que pedir cosas, para que ellos puedan cumplir su misin. Entrevistador: Ud. cree que la clave es tener buenas relaciones con el personal? Entrevistado: S, efectivamente, el xito hoy en da de todo proceso est en mantener buenas relaciones. Todo lo que est relacionado con la inteligencia emocional, todo lo que es soft de lo que se aplica muy poco en las universidades. Dentro del mundo de los informticos, no solo trabajan informticos, si no que tambin hay gente de diversas especialidades, Ingenieros Agrnomos, Contadores Auditores, Gerentes de Proyectos, Gerentes de reas de empresas tecnolgicas. Mi primer jefe, quien fue mi gua, tena el ttulo de Tcnico Programador estudi en un colegio y hoy da trabaja en un grupo empresarial, ha crecido mucho. Y su xito se basa en tener muy buena relacin con el personal, hacia arriba, hacia abajo y hacia los lados. 3.3 Realiza labores no asociadas con el trabajo propio del proceso de captura de requerimientos? S. Veo oportunidades de negocios, veo temas ms comerciales, hoy da tuve dos reuniones para concretar dos nuevos proyectos, me toca dirigir, armar los grupos de trabajo para atacar estas oportunidades de negocios; la idea aqu no es seguir un proyecto, si no que seguir un proceso comercial, cuya funcin es principalmente estimar costos, estimar la viabilidad de la ejecucin del proyecto, ver como estamos posicionados frente al cliente para asegurarnos si nos conviene o no presentarnos, si hay que realizar algo de marketing, alguna promocin, auspiciar algn evento, etc. 3.4 Existen problemas que tengan que ver con contradicciones, poca claridad en los requerimientos o desconocimiento de los mismos? S, principalmente este problema se da, volviendo al proyecto que comentbamos al principio del sector pblico, porque el cliente no tiene claro lo que quiere y por esto lo transmite muy mal al analista, y como el analista generalmente no tiene mucha experiencia en el negocio, el resultado del anlisis de requerimientos no es lo que espera el cliente. 4. Sistemas sociales y polticos 4.1 Cul es su rol dentro del proceso? El rol que cumplo es Gerencial. 4.2 Qu es lo que debe resaltarse positivamente del servicio que usted entrega? Particularmente, lo que resalto es que soy bastante proactivo, gestiono muy bien los riesgos, me trato de adelantar a las situaciones, pienso con 2 o tres meses de anticipacin. En el equipo de proyecto con el cual estoy involucrado, estoy pensando con dos o tres semanas de anticipacin, porque los plazos no nos dan, voy atacando

Apndice B: Respuestas cuestionario

33

los riesgos, lo que se podra decir que es la clave del xito. Detectar, analizar, evaluar los riesgos e inmediatamente comunicrselo al cliente, para que en conjunto los resolvamos. Esta deteccin la realiza en base a la experiencia o de acuerdo a los estudios que Ud. ha realizado? Bueno, aparte de los Magster, soy relator de CMMI y soy apegado a stos estndares, he gerenciado el rea de calidad bajo las normas CMM2, y estoy en proceso de certificacin de normas ITIL; todo eso sumado, te entrega una serie de cimientos, para mi es una forma muy natural de detectar los problemas y llegar a la causa inmediatamente, para proponer rpidamente soluciones. Es ah donde juega la experiencia. 4.3 Se rige su trabajo particular por algn reglamento externo o interno? Cul y dnde se encuentra? Bsicamente, apegarse a las buenas prcticas, no es necesario tener un MBA para saber que hay instituciones que se han dedicado a normar e indicar que es lo que se tiene que hacer en un proyecto, que no es ninguna novedad, es igual a las ISO 9001, no inventan nada. Para cumplir las expectativas del cliente hay que seguir una serie de buenas prcticas. Aparte de eso, hay que tener habilidades directivas, que si yo siento que los ingenieros nuevos no las tienen, y esas habilidades directivas, estn muy relacionadas con lo que yo te comentaba, a tener buenas relaciones en el trabajo, es decir, ser un componente ms del equipo, que los invita a comer algo y les da la oportunidad contar sus temas, cuando la gente tiene problemas entenderlos, y cuando hay que jugar un rol duro y drstico, no dudar en tomar las acciones necesarias, sobre todo si uno ya ha rayado la cancha. 5. CATWOE, HAS 5.1 Cules seran las mejoras que realizara para mejorar el funcionamiento del proceso? y Por qu stas no se han realizado? Hasta ahora, las mejoras del proyecto han sido dar un enfoque ms estratgico, no es una visin tctica la que he aplicado, el proyecto lo he visto en tres dimensiones, una, el proyecto tecnolgico en s, en donde existe una fase de anlisis que hay que realizar de nuevo, que fueron nuestros controles de cambios, y otra fase en que hay que terminar de programar lo que no se ha programado, para eso he puesto ha un jefe de un proyecto antiguo, que acaba de llegar de una reunin de donde lo confirman en su puesto, y l va a tener la visin conceptual, va a ser el jefe de proyecto, as mismo he designado ha otro jefe de proyecto, cuya funcin velar por el tema operativo, el da a da, los temas administrativos, he creado una pequea oficina de proyectos para ver todos los temas administrativos y aplicacin de las buenas prcticas. Desde el punto de vista de Recursos Humanos, me he preocupado de conocer todas las falencias, ya he hecho el levantamiento de carencias, y estoy canalizando que sean resueltas, por quien corresponda que tienen que ser resueltas, no tomo decisiones yo. Desde el punto de vista gestional, las expectativas del cliente o velar por el proyecto en si, por el proceso completo e involucrado a la alta gerencia en este proyecto en particular, porque as

Apndice B: Respuestas cuestionario

34

estamos todos preocupados del proyecto, y no que pasen 6 meses y nos enteremos nuevamente que estamos atrasados. 5.2 Quin o quienes poseen la atribucin de modificar la operatividad del proceso de captura de requerimientos si lo desean? En este caso en particular, desde el punto de vista de la ejecucin proyecto, yo puedo hacer modificaciones de toda ndole, yo soy el responsable final y yo reporto al Director Regional de toda Sudamrica, y tambin reporto a Espaa, pero yo reporto resultados, no reporto problemas buscando soluciones; y por parte del cliente, al Director de TI y al usuario, que tambin tiene un cargo gerencial.

Ingeniero diez aos de experiencia: Rodrigo Riquelme


1. Identificacin del problema 1.1 Cules son los principales problemas que posee el proceso y de dnde provienen dichos problemas? Lo primero es tener la claridad de donde tienen que llamar, los usuarios necesitan saber, tener claro, cual es el proceso de requerimientos y gestin del caso. Nosotros ahora estamos cambiando el sistema justamente, estamos cambiando un sistema hecho en Visual Basic, por nosotros, estamos cambiando por un sistema que se llama ARAMDA, es un proveedor que se est certificando con las normas ITIL. El principal problema ms que nada es la comunicacin hacia el usuario, cmo va el caso, el usuario siempre tiene que sentirse, yo creo, atendido, porque ser puede que un problema no lo puedas resolver en el instante, puede ser un problema un poquito ms complejo de lo que t crees, pero lo que tiene que tener el usuario es la visibilidad de que esta haciendo considerado, esta siendo tratado, su problema es importante, sino ah entra el conflicto de que el usuario siente que no le estn solucionando el problema, se frustra y eso te puede llevar a niveles de otros problemas. Entrevistador: Considera que los usuarios no saben expresar lo que necesitan? Entrevistado: No, por lo general los usuarios son bastante proactivos, poseen un nivel bastante tcnico, te llaman por temas muy especficos, y es muy especial, porque tienes que solucionarlo en el momento, no es un usuario que te llame por un problema a futuro, es un problema del momento, y hay que solucionarlo en el momento, adems l te hace la validacin tambin en el momento. Es muy distinto a otras empresas, en donde los llamas por un problema y te dicen que no lo pueden ver en el momento. 1.2 De qu forma afectan a usted y al proceso de captura de requerimientos dichos problemas? La comunicacin estamos mejorndola con el nuevo sistema, donde en el sistema, t dejas un caso y enva un reporte al usuario, tambin si no hay una respuesta o el caso no se cierra cada cierto tiempo pasa a una siguiente escala,

Apndice B: Respuestas cuestionario

35

supongamos de nivel 2 y se comunica al supervisor de informtica con el supervisor del proveedor, si no me llega a mi ah vemos que podemos hacer. 2. Definicin de actores sociales 2.1 Cules son los actores (personas/unidad) fundamentales en el funcionamiento del proceso de captura de requerimientos? Tenemos centros de soporte, que son dos personas, dos tcnicos, tenemos un nivel dos que es un experto del proveedor y tambin est la otra empresa. Y como recurso vamos a tener ARAMDA, tenemos a disposicin dos telfonos para poder llamar, tenemos tambin controles remotos, acceso a control remoto, y ahora estamos implantando un procedimiento que si no se puede solucionar el problema por telfono, o sea, la primera opcin es tratar de que el usuario resuelva el problema para que el aprenda, con la experiencia que tiene l, aprenda a hacerlo de nuevo. El segundo nivel es tomar la mquina va remota, y si ya no se puede esto, va a partir una persona de nuestro proveedor hacia la sucursal para solucionar el problema. 2.2 Quin o Quines regulan el proceso de captura de requerimientos y su actividad? Est Erasmo Fuentes que es nuestro IT manager, l es el que esta encargado de contactar al proveedor. Tenemos por parte de nosotros, a Erasmo que es el inspector de contrato y tambin tenemos por parte del proveedor, a Pamela, que es tambin nuestra asesora. 2.3 Quin o Quienes son sus clientes? Todos los usuarios, tengo usuarios en Chile, tambin tengo otros clientes, que ya son corporativos, que son ITC que son nuestra corporacin de IT y esos son los principales clientes. 3. Rich Picture 3.1 Cree que el proceso es burocrtico o expedito? Yo pienso que el proceso que estamos implantando se ve bastante expedito, por lo menos en el papel se ve bien, vamos a partir la prxima semana. Entrevistador: Y lo que estaban ocupando anteriormente? Entrevistado: Lo anterior era bastante malo, no haba comunicacin con el usuario, entonces cuando explotaba la situacin era cuando el usuario o el jefe del usuario me llamaba a mi y me deca oye Rodrigo esta pasando esto y ah tenia que tomar medias al respecto. 3.2 Cmo es la relacin entre las personas con las que usted tiene comunicacin directa en el trabajo? Buena, yo me llevo bastante bien con todo el mundo.

Apndice B: Respuestas cuestionario Entrevistador: Cree que es fundamental una buena comunicacin?

36

Entrevistado: S, es fundamental una buena comunicacin y hacerlos sentir que t trabajas para ellos, primero eres persona, segundo trabajas para darles solucin a ellos, no para complicarles ms la vida, o sea, de hecho tambin hay que hacerlos entender de que hay normas, t no les quitas software por ejemplo, los restringes, y no es porque quieras hacerlo sino porque hay normas corporativas y tambin lo que hacen ellos es sper purgador, y como trabajamos en una red afecta otro usuario. Entrevistador: En su percepcin, Ud. cree que es un buen lder? Entrevistado: Yo creo que si. Entrevistador: Y cul es la clave para ser un buen lder? Entrevistado: Trabajar en equipo. Es un da a da, porque es tratar de darle confianza a la gente, y que ellos confen en ti. No pasndose los cnones de jerarqua, pero s que ellos tengan la confianza de decirte, estoy molesto, tengo problemas con esto 3.3 Realiza labores no asociadas con el trabajo propio del proceso de captura de requerimientos? Si, bueno, mi funcin ac en ALSTOM es IT manager y IS manager, yo tengo que ver todo lo que es IT (Information Technology) y todo lo que es IS (Information Solution). Tengo que ver desde la compra de hardware, mantencin del hardware y prestacin de redes. Y la captar la implantacin de los sistemas de gestin. Entrevistador: Esto afecta en algn grado el papel que Ud. desempea? Entrevistado: Es que son muchas cosas a la vez. Lo bonito es que ves todo el proceso, t sabes que si vas a tener un 20 o 30 de usuarios ms, vas a estar en el rea internacional, vas a ser ms grande, etc. 3.4 Existen problemas que tengan que ver con contradicciones, poca claridad en los requerimientos o desconocimiento de los mismos? Generalmente, cuando ellos hacen algn desastre, no falta el usuario que es inquieto, entonces, normalmente est todo restringido, pero siempre hay alguna manera de vulnerar el sistema o hay una pgina nueva. Cuando hay un problema y ellos saben que el problema lo causaron ellos, es ah donde aparecen las contradicciones y la experiencia de nuestros tcnicos. 4. Sistemas sociales y polticos 4.1 Cul es su rol dentro del proceso? Controlar. Comunicar y controlar.

Apndice B: Respuestas cuestionario 4.2 Qu es lo que debe resaltarse positivamente del servicio que usted entrega?

37

Tratamos de que el usuario tenga sus recursos la mayor cantidad de tiempo disponible. Pensar que un usuario puede estar media hora sin PC, eso es inaceptable. 4.3 Se rige su trabajo particular por algn reglamento externo o interno? Cul y dnde se encuentra? Nosotros tenemos normas corporativas que provienen de ITC y esto se ubica en Francia. Hay una jerarqua, est ITC France, y despus se divide por regiones, Amrica, Portugal, Espaa, Norteamrica y Asia. Nosotros dependemos jerrquicamente de Brasil. Entrevistador: En el caso de que exista algn problema, Ud. aplica alguna estrategia? Entrevistado: En un momento de crisis hay que tomar la mejor decisin, y esa decisin la tomo yo. Pero depende del problema, por ejemplo, en general en los problemas hay que tratar de realizar el procedimiento normal. 5. CATWOE, HAS 5.1 Cules seran las mejoras que realizara para mejorar el funcionamiento del proceso? y Por qu stas no se han realizado? Estamos en un proceso de mejoras. Por qu no se haban realizado?, porque tenamos un contrato con un antiguo proveedor, del cual no nos podamos deshacer. No era un problemas de recursos o de no querer arreglar la situacin, si no que estbamos restringidos porque no nos podamos cambiar de proveedor. 5.2 Quin o quienes poseen la atribucin de modificar la operatividad del proceso de captura de requerimientos si lo desean? Como estoy a cargo, yo podra cambiar el proceso si no me gusta, pero generalmente es un equipo de trabajo, entonces en el equipo de trabajo se toma la decisin. No se trabaja con eso del yo impongo. Hay un estudio del porqu lo vamos a cambiar, eso lo va diciendo la experiencia

Apndice B: Resultados Cuestionario

38