martes, 23 de diciembre de 2008

Resumen

En todo proyecto de software esta la etapa de captura de requerimientos, la cual es una de las etapas más importantes dentro de todo el desarrollo, ya que en está se descubren y estudian las necesidades de los futuros usuarios del sistema a implementar. Dentro de esta etapa pueden manifestarse una serie de problemas, entre los cuales esta el transmitir de buena manera cada una de las necesidades y requerimientos que tienen los usuarios a los ingenieros y desarrolladores.

Existen numerosas metodologías y métodos que se enfocan en realizar y apoyar la etapa de toma de requerimientos de un sistema, estás a grandes rasgos definen los pasos que se deben seguir para efectuar de buena forma la toma de requerimientos, aún así estos métodos no contemplan de buena manera la interacción entre las personas participantes, por lo cual los procesos de negocios no son bien comprendidos por los desarrolladores y conlleva a que el sistema final sea defectuoso.

Dentro de este documento se aplicara la Metodología de Sistemas Blandos de Peter Checkland herramienta con la cual se extraerán las causas, responsables y soluciones a los problemas que surgen dentro de la etapa de toma de requerimientos. La metodología nombrada está enfocada a solucionar dificultades que surgen dentro de las actividades humanas. Primero se identifica el inconveniente, luego se analiza detalladamente la información y por último se genera un listado con las soluciones y mejoras al actual sistema. Sistemas blandos abarca todas las perspectivas de los involucrados y llega a un consenso entre estos para así lograr el progreso deseado.

Se entrevistaran a diversos ingenieros con la experiencia suficiente en la captura de requerimientos. Con esta información se identificaran los inconvenientes a través de una visión enriquecida (Rich Ricture), para luego diseñar la transformación necesaria utilizando las definiciones raíces. Luego se realizara una definición del sistema actual comparándola con la definición de un sistema propuesto, ambas definiciones serán expresadas como sistemas de actividad humana (HAS). Por último se evaluaran las nuevas mejoras y se darán a conocer los cambios propuestos a través de un listado de competencias y habilidades que se debe tener para la correcta realización de la captura de requerimientos, tanto los desarrolladores como los analistas del sistema.

Introducción

El siguiente documento tiene como objetivo presentar al lector los conocimientos básicos que debe poseer para comprender la fase de Toma de Requerimientos, cuando se trabaja en el desarrollo de software, como comienzo para que éste pueda comprender a cabalidad el posterior análisis a través de la Metodología de Sistemas Blandos, SSM, de cuáles deben ser las características y cualidades que debe poseer el Ingeniero Informático que hará de analista en esta importante etapa del desarrollo de software. Es por este hecho que el presente informe está estructurado en 5 grandes etapas, que engloban éste trabajo, las cuales son: la de descripción del problema, la de entrega de información al lector o marco teórico, aplicación de la SSM, el análisis de los datos obtenidos y por último las conclusiones sacadas de este análisis.

Problema

Como toda actividad la fabricación o elaboración de un software cuenta con un paso de inicial del cual dependerá el éxito o el fracaso de ésta, dicha etapa es la etapa de captura de requisitos o requerimientos. Esta fase por su importancia debe hacerse de forma de evitar posibles errores y complicaciones, pero esto no es una tarea sencilla debido que presenta una serie de problemáticas, las cuales son originadas por diversos factores. El primero, y quizás la más importante, es el de que los actores involucrados, ya sean usuarios del sistema en sí, directivos, gerentes, etc., tienen problemas para explicarse claramente a la hora de señalar que es lo que necesitan y/o desean, debido a que esto lo hacen informalmente por el desconocimiento de las tecnologías. Una segunda problemática son las variaciones que pueden surgir de estos requisitos a lo largo del proceso, ya sea por cambios de opinión del cliente, o la aparición de de nuevos requisitos o nuevos actores del proceso. También dentro de estas problemáticas están los posibles conflictos que se pueden presentar entre los requisitos indicados por diferentes actores. Otra problemática quizás no tan reconocible, es la falta de participación por parte de algunos actores, por lo general usuarios finales, debido a el pensamiento de que pueden ser reemplazados o la empresa puede prescindir de ellos si la tareas se desarrollan de manera más sencilla con una nueva herramienta. Además de estas problemáticas esta un factor muy importante como lo es la experticia que pueda tener el Ingeniero Informático para la tarea de captura de requerimientos, así como su capacidad de relacionarse con el cliente.

Son estas problemáticas mencionadas, las que nos llevan a analizar cuáles son las habilidades y competencias que debe poseer un Ingeniero Informático para una adecuada toma de requerimientos. Todo esto se hará tomando en cuenta el proceso por el cual se hace esta toma de requerimientos y la participación del Ingeniero Informático en ésta.

Objetivos

A continuación se presentan los objetivos que se persiguen en el presente documento, ya sean estos del tipo general, como específicos, referentes a lo que se espera lograr en el ámbito global del proyecto y los que comprenden los pasos propios de la metodología utilizada.

Objetivos Generales

El objetivo general de este proyecto es establecer una lista con las competencias y habilidades que debe poseer un Ingeniero Informático para realizar una adecuada Toma de Requerimientos. Esta lista se extrae de las experiencias de Ingenieros Informáticos, los cuales están dentro de esta área.
Cabe destacar que estas experiencias se obtendrán a través de un cuestionario el cual será contestado por estos Ingenieros.

Objetivos Específicos

Los objetivos específicos identificados son:

  • Describir y desarrollar la metodología de trabajo “Soft System Methodology”.
  • Exponer adecuadamente la situación actual sobre la Toma de Requerimientos.
  • Proponer un manual de buenas prácticas para la Toma de Requerimientos.

Metodologia de Sistemas Blandos

Esta metodología propuesta por Peter Checkland, es la ideal para analizar y encontrar una respuesta satisfactoria a la problemática de la Toma de Requerimientos en el desarrollo de Software. Esta metodología como ya se mencionó, hace uso de un estudio de un sistema a través de las visiones de observadores o actores de éste.

A continuación se indica las etapas, actividades y productos que componen esta metodología.

Descripción de la SSM

La SSM contempla siete etapas las cuales se encuentran divididas en 2 categorías, las cuales son: Experiencia en el Sistema y Pensamiento de Sistema, tal como lo muestra la siguiente figura.



Etapa 1: La situación problema no estructurada.

Es esta primera etapa la situación problema es experimentada, por el investigador. Aquí es donde el investigador debe de obtener y retener la mayor cantidad de percepciones del problema.

Etapa 2: La situación problema expresada

En esta segunda etapa el investigador desarrolla una descripción detallada, una “visión enriquecida” de la situación, esto se hace a través, la mayoría de las veces, de un una representación gráfica llamada “Rich Picture”, la cual contempla los puntos de vista de de los actores involucrados y a partir de éste se analizará el problema. En este diagrama se debe señalar los conflictos y acuerdos para poder pasar a la siguiente fase.

Etapa 3: Definiciones raíz de los sistemas

En la tercera etapa se obtienen las definiciones raíz, Sistema Social (a la VIckers) y Sistemas Políticos, el CATWOE y la definición raíz elaborada. A continuación se describen estas actividades.

  • Definiciones Raíz

Estas definiciones se obtienen del análisis del Rich Picture, las cuales son hipótesis para mejorar la situación actual, esto se hace por medio de cambios en los que el investigador y dueños del problema consideran que son viables.

  • Sistema Social a la Vickers y Sistemas Político.

Los Sistemas Sociales a la Vickers permiten observar los sistemas sociales al interior de la organización a través de una representación del tipo vector de la forma . Siendo el rol, el papel que cumple una persona en la organización, la norma, el comportamiento que se espera que cumpla el rol dentro de la organización y el valor, es el desempeño actual de un rol para juzgarle. Los Sistemas Políticos se crean a partir de los Sistemas Sociales a la Vickers y permiten mostrar como el poder se expresa a través de la situación problema mediantes grupos de poder.

  • CATWOE

Esta etapa la cual es una sigla de Clientes (C), Actores (A), Transformación (T), Weltanschauung (W), Dueño o Owner (O) y Entorno (E). Donde los Clientes son los que se ven beneficiados o perjudicados por el sistema, los Actores son aquellos que permiten la Transformación, el Weltanschauung es el punto de vista que origina la definición raíz, los Dueños son quienes pueden parar la transformación si así lo desean y por último el Entorno es el medio donde se encuentra el sistema y sucede la Transformación.

  • Definición raíz elaborada

Esta etapa es una reformulación de la definiciones raíz anteriores, la cual se obtiene de los datos obtenidos en el CATWOE. La diferencia entre estas 2 es que la definición raíz indica “qué” se debe hacer, mientras que la definición raíz elaborada indica el “qué” hay que hacer, “cómo” debe hacerse y “para qué” hacerse.

Etapa 4: Modelos Conceptuales

En esta etapa se crean modelos de sistemas de actividad humanas (HAS), que describen las definiciones raíz, y que describen la actividad necesaria para lograr la transformación. Esta etapa está dividida en 2 fases.

  • 4A Conceptos de Sistemas Formales

En esta fase se verifica que los modelos construidos sean eficientes, a través de un modelo general de sistema de actividad humana, un modelo formal sistémico.

  • 4B Otros pensamientos de sistema

Para poder estructurar el sistema, es necesario modelar la situación para así definir las variables del sistema.

Para este fin se puede utilizar un modelo formal llamado los Nueves Niveles de Jean Louis Le Moigne. A continuación se describen estos nueve niveles.

NIVEL 1: “En un determinado ambiente un observador distingue un sistema".

NIVEL 2: “El observador distingue lo que el sistema hace a través de identificar entradas, salidas y transformaciones”.

NIVEL 3: “El observador postula la existencia de mecanismos de regulación (S.R.) que gobiernan las actividades del sistema operacional (S.O.)”.

NIVEL 4: “El observador postula la existencia de flujos de información (S.IN.) que permitan la regulación”.

NIVEL 5: “El observador postula la existencia de un sistema de memorización (S.M.) de información”.

NIVEL 6: “El observador postula la existencia de un sistema de decisión (S.D.) de sus comportamientos”.

NIVEL 7: “El observador postula la existencia de un sistema que coordina (S.C.) sus decisiones de acción”.

NIVEL 8: “El observador postula la existencia de un sistema que imagina (S.IM.) y concibe nuevas decisiones posibles”.
Es necesario mencionar que este nivel no siempre puede existir en el sistema identificado, lo cual no influye en el análisis de la metodología.

NIVEL 9: “El observador postula la existencia de un sistema que otorga clausura o finalización (S.F.)”.

Etapa 5: Comparación de 4 con 2

En esta etapa se realiza una comparación entre los modelos conceptuales obtenidos en la etapa 2 versus el mundo real que se obtuvo en la etapa 2, para esto se considera los actores involucrados, de forma de generar un debate sobre las condiciones del problema en cuestión.
Esta comparación debe ser consciente, coherente y defendible.

Etapa 6: Cambios deseables, viables, …

Esta etapa hace comparaciones entre los modelos conceptuales y generan 3 tipos de cambios, los cuales pueden ser: estructurales, procedimientos y actitudes. Los cambios estructurales tienen relación con la modificación de hechos que ocurren en la realidad, los cambios en los procedimientos cambian los elementos dinámicos y los cambios en las actitudes tienen que ver con cambios en ciertos tipos de comportamientos.

Etapa 7: Acción para mejorar la situación problema

En esta etapa se efectúan los cambios detectados en la etapa anterior, a fin de modificar la situación problema anterior, la cual puede llevar a nuevos problemas, lo cual es uno de los objetivos de la metodología, y los cuales se pueden evaluar nuevamente con ésta, de forma de ir iterando.

Manual de Buenas Practicas

Las acciones que se presentan después de haber analizado el problema y aplicado la metodología SSM, se basan en una lista con habilidades y competencias que debe poseer un Ingeniero Informático en la Toma de Requerimiento.

  • Conocimiento del dominio del negocio.
El ingeniero debe poseer un conocimiento a cabalidad del proceso de negocio a analizar, de manera que al momento de identificar y realizar las tareas, pueda centrarse en las realmente importantes, dejando de lado las trivialidades.

  • Desarrollar prototipos, anticipándose a los clientes, para adelantar trabajo.
Es importante que el ingeniero al tener una idea clara del proceso pueda idear un prototipo de lo que se requiere para el sistema, de manera que el usuario solo compare éste con las necesidades propias.

  • Desarrollar empatía con el cliente, de modo de mejorar la comunicación con éste.
El analista en su afán de mejorar la comunicación son el cliente, debe ser capaz de ponerse en el lugar del cliente, de manera de estrechar lazos con éste, trayendo con esto una relación de complicidad con el cliente en el desarrollo del software.

  • Ser capaz de guiar y apoyar al cliente en el proceso.
El ingeniero debe presentar disposición y conocimiento para el proyecto del cliente, de forma guiarlo, si es necesario, y apoyarlo en las dudas que pueda presentar.

  • Mantener una buena comunicación con el equipo de trabajo.
El ingeniero como un miembro de un equipo, debe ser capaz de relacionarse de buena forma con sus pares, de forma de mantener un buen ambiente de trabajo y por ende una buena relación laboral.

Entrevista Javier Jara Ingeniero de más de 8 años.

Jefe Proyecto, Taisa Chile. E-mail: j.jara.v@gmail.com

¿Cuáles son las problemáticas que presenta el proceso de captura de requerimientos?
La inmadurez de las ideas o necesidades de los clientes.

¿De dónde vienen dichos problemas?
La poca claridad de qué problema resolver y a veces sólo viendo el cómo, sin saber si es una buena solución. También del desconocimiento de las capacidades de las tecnologías.

¿Estás problemáticas lo afectan o al proceso en general?
Las problemáticas de la captura de requerimientos afectan al proceso en general.

¿Una planificación y preparación previa del tema ayuda en el proceso?
Por supuesto. Conocer el negocio ayuda a entender mejor las necesidades del cliente.

¿Los usuarios saben explicar sus necesidades?
En general no, pero hay excepciones.

¿Quiénes son los actores principales en el proceso?
Los usuarios directos de la aplicación.

¿Quiénes dirigen el proceso de captura de requerimientos y su actividad?
Los analistas y el jefe de proyectos.

¿Cree que el proceso es burocrático o expedito?
Depende del cliente, de su organización y cultura. Ambos casos existen.

¿Cómo es la relación entre las personas con las que usted tiene comunicación directa en el trabajo?
Buena.

¿Existen problemas que tengan que ver con contradicciones, poca claridad en los requerimientos o desconocimiento de los mismos?
Sí. Existen en todos los proyectos.

¿Cuál es su rol dentro del proceso?
Asistir a reuniones de captura de requerimientos, atender y lograr entender el problema del cliente y luego proponer una solución.

¿Qué es lo que debe resaltarse positivamente del servicio que usted entrega?
Que me involucro en el problema del cliente.

¿Se rige su trabajo particular por algún reglamento externo o interno?, ¿Cuál es ese reglamento y dónde se encuentra?
Seguimos normativas de procesos internos para lograr niveles CMMi.

¿Cuáles serían las mejoras que realizaría para mejorar el funcionamiento del proceso? y ¿Por qué éstas no se han realizado?
Control abierto de los entregables. Costo y tiempo.

¿Quién o quienes poseen la atribución de modificar la operatividad del proceso de captura de requerimientos si lo desean?
En la empresa donde trabajo, yo y el gerente comercial.

Entrevista Carlos Torres Ingeniero de más de 7 años.

Analista Programador, Banco Santander. E-mail: carlos_torres_a@gmail.com

¿Cuáles son las problemáticas que presenta el proceso de captura de requerimientos?
El poco interés del usuario con respecto al tiempo que dedica a definir sus necesidades. Por lo general la forma de comunicar sus requerimientos es muy básica, por ejemplo un mail, diciendo necesito esto, sin profundizar mayormente.

¿De dónde vienen dichos problemas?
Por parte del cliente o usuario.

¿Estás problemáticas lo afectan o al proceso en general?
Si, debido a la mala definición inicial, es necesario iterar continuamente durante el desarrollo, alargando los plazos originales.

¿Una planificación y preparación previa del tema ayuda en el proceso?
Si, ayuda a ordenarse y así poder orientar al usuario para que exprese con mayor claridad sus necesidades.

¿Los usuarios saben explicar sus necesidades?
No, principalmente porque el usuario no conoce o no le interesa conocer la área informática. El analista debe interiorizarse en el área o negocio para la cual va a desarrollar, para poder comunicarse con mayor facilidad y entender al cliente; éste a su vez debería realizar el mismo proceso.

¿Quiénes son los actores principales en el proceso?
Usuarios en los distintos niveles, jefe de Proyecto, analistas y desarrolladores.

¿Quiénes dirigen el proceso de captura de requerimientos y su actividad?
El Jefe de Proyecto

¿Cree que el proceso es burocrático o expedito?
Expedito, ya que todos tienen la oportunidad de participar.

¿Cómo es la relación entre las personas con las que usted tiene comunicación directa en el trabajo?
Buena, de pares, independiente del cargo que ocupen.

¿Existen problemas que tengan que ver con contradicciones, poca claridad en los requerimientos o desconocimiento de los mismos?
Sí, siempre, por eso es importante iterar muchas veces con el usuario en las primeras etapas del desarrollo, mostrando prototipos, modelos, flujos, para detectar posibles problemas.

¿Cuál es su rol dentro del proceso?
Principalmente crear la solución a partir de los requerimientos entregados.

¿Qué es lo que debe resaltarse positivamente del servicio que usted entrega?
Estar constantemente en contacto con el usuario para hacerlo parte del proyecto y así detectar en etapas tempranas posibles errores.

¿Se rige su trabajo particular por algún reglamento externo o interno?, ¿Cuál es ese reglamento y dónde se encuentra?
No.

¿Cuáles serían las mejoras que realizaría para mejorar el funcionamiento del proceso? y ¿Por qué éstas no se han realizado?
Dedicar más tiempo a la etapa de toma de requerimientos, pero no se aplica por que el mercado te lo exige, además que los clientes no le dan la importancia a esta etapa, queriendo ver lo antes posible resultados.

¿Quién o quienes poseen la atribución de modificar la operatividad del proceso de captura de requerimientos si lo desean?
El jefe de proyecto y los usuarios mismos pero para lograr esto hay que realizar una constante educación a los usuarios para que le tomen la real importancia a este proceso.