REQUERIMIENTOS DE PROCESOS CONCEPTOS BASICOS.

Proceso: Conjunto de recursos y actividades interrelacionados que transforman elementos de entrada en elementos de salida. Los recursos pueden incluir personal, finanzas, instalaciones, equipos, tcnicas y mtodos.

Proceso clave: Son aquellos procesos que inciden de manera significativa en los objetivos estratgicos y son crticos para el xito del negocio. Subprocesos: son partes bien definidas en un proceso. Su identificacin puede resultar til para aislar los problemas que pueden presentarse y posibilitar diferentes tratamientos dentro de un mismo proceso.

Sistema: Estructura organizativa, procedimientos, procesos y recursos necesarios para implantar una gestin determinada, como por ejemplo la gestin de la calidad, la gestin del medio ambiente o la gestin de la prevencin de riesgos laborales. Normalmente estn basados en una norma de reconocimiento internacional que tiene como finalidad servir de herramienta de gestin en el aseguramiento de los procesos.

Procedimiento: forma especifica de llevar a cabo una actividad. En muchos casos los procedimientos se expresan en documentos que contienen el objeto y el campo de aplicacin de una actividad; que debe hacerse y quien debe hacerlo; cuando, donde y como se debe llevar a cabo; que materiales, equipos y documentos deben utilizarse; y como debe controlarse y registrarse. Actividad: es la suma de tareas, normalmente se agrupan en un procedimiento para facilitar su gestin. La secuencia ordenada de actividades da como resultado un subproceso o un proceso. Normalmente se desarrolla en un departamento o funcin. Proyecto: suele ser una serie de actividades encaminadas a la consecucin de un objetivo, con un principio y final claramente definidos. La diferencia fundamental con los procesos y procedimientos estriba en la no repetitividad de los proyectos. Indicador: es un dato o conjunto de datos que ayudan a medir objetivamente la evolucin de un proceso o de una actividad. Mtodo IDEF0: gua en la descripcin de cada proceso (o actividad) considerada como combinacin de cinco magnitudes bsicas (figura IDEF-1) que se representan grficamente como: 1) Procesos o actividades 2) inputs (insumos) 3) controles, 4) mecanismos o recursos para la realizacin de tareas 5) Outputs o resultados conseguidos en el proceso (que podrn ser a su vez inputs o controles de otros procesos

REQUISITOS DE LOS PROCESOS.

Todos los procesos tienen que tener un Responsable designado que asegure su cumplimiento y eficacia continuados. Todos los procesos tienen que ser capaces de satisfacer los ciclos P, D, C, A del siguiente grfico. Todos los procesos tienen que tener indicadores que permitan visualizar de forma grfica la evolucin de los mismos. Tienen que ser planificados en la fase P, tienen que asegurarse su cumplimiento en la fase D, tienen que servir para realizar el seguimiento en la fase C y tiene que utilizarse en la fase A para ajustar y/o establecer objetivos.

MTODOS PARA LA IDENTIFICACIN DE PROCESOS Bsicamente se puede asegurar que existen muchos mtodos para la identificacin de los procesos. Pero a mi entender se pueden englobar en dos grandes grupos: Mtodo "ESTRUCTURADO": En este apartado estoy englobando todos aquellos sistemas bsicamente complejos que sirven para la identificacin de los procesos de gestin. Estamos hablando de los sistemas informatizados, ejemplo: idefo y los sistemas mas o menos estructurados. Lo que tienen en comn todos estos sistemas es que los mismos estn diseados por personas expertas. Normalmente su implantacin requiere de algn tipo de asistencia externa.

Ventajas: Son sistemas estructurados que sirven para identificar y documentar un proceso de gestin. Se dan pautas, guas, soportes y hasta plantillas. El caso Idefo esta soportado por todo un sistema informtico ideado "en origen " por militares

americanos. Estos sistemas permiten identificar reas de gestin que no se abordan y/o ineficientes. Los procesos y subprocesos relacionados estn perfectamente documentados. Si se consigue mantener actualizada toda la documentacin asociada a los mismos se convierten en herramientas validas para la formacin de los nuevos ingresos.

Inconvenientes: Los procesos de gestin estn tan documentados que mas parecen "cdices de Amurabi" que herramientas de gestin operativas. He visto documentos que contenan 230 paginas y estamos hablando de un solo proceso. La empresa en cuestin todava tenia que documentar otros 20 procesos mas con el citado mtodo. Me imagino que despus de tres aos seguirn con tan honorable tarea. A esto hay que aadir el trabajo que debe costar su mantenimiento y no digamos el dominio del mismo por parte del personal. Los mtodos informticos requieren menos papel, pero si nos atenemos al mtodo idefo y todos los diagramas-crucigramas que el mismo requiere, se puede asegurar que para entenderlos-interpretarlos se requiere de una persona experta que por un lado conozca la herramienta y por otro lado domine la gestin que supuestamente esta reflejada en dichos grficos. Otro de los problemas asociados a este tipo de sistemas es que normalmente no suelen saber que hacer con los procedimientos existentes y sus sistemas relacionados. Me estoy refiriendo a los procedimientos y a los Sistemas de Calidad, etc. De esta forma una empresa se encuentra con un nuevo Sistema de Procesos que no sabe muy bien relacionar con los otros sistemas existentes.

Mtodo "CREATIVO": En este apartado estoy englobando todos aquellos mtodos que las empresas estn ideando e implantado de forma interna. Normalmente motivadas por las nefastas experiencias y/o por la ineficiencia del mtodo anterior.

Ventajas: El Sistema de Gestin esta mucho mas integrado, ya que tanto el mtodo ideado como todos los soportes relacionados estn creados internamente por miembros de la organizacin. Estos soportes y mtodos se convierten con poco esfuerzo en documentos "entendibles" por el resto del personal. La documentacin se reduce drsticamente. Los procedimientos desaparecen y se "convierten" y/o se incorporan a los procesos relacionados.

Inconvenientes: Se requiere de personas expertas en todos los campos citados. Es decir alguien que conozca el Sistema de Calidad y Gestin de o por Procesos. Se debe hacer mas nfasis en la formacin de las nuevas incorporaciones ya que buena parte del conocimiento no esta ni en papel ni en soportes informticos. Se tiene que fomentar la formacin de "odo a odo".

SELECCIN DEL MTODO

La eleccin del mtodo depender del conocimiento que tengan los miembros de la empresa y/o del "estado " en el cual se encuentre la misma. En caso de dudas lo mejor es escoger el mtodo estructurado aunque tambin podra ser una combinacin de ambos.

REQUERIMIENTOS DE LOS USUARIOS.

Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es importante saber que cada una de esas personas tienen diversos intereses y juegan roles especficos dentro de la planificacin del proyecto; el conocimiento de cada papel desempeado, asegura que se involucren a las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR. No conocer estos intereses puede ocasionar una comunicacin poco efectiva entre clientes y desarrolladores, que a la vez traera impactos negativos tanto en tiempo como en presupuesto. Los roles ms importantes pueden clasificarse como sigue: Usuario final: Son las personas que usarn el sistema desarrollado. Ellos estn relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; estn familiarizados con los procesos especficos que debe realizar el software, dentro de los parmetros de su ambiente laboral. Sern quienes utilicen las interfaces y los manuales de usuario. Usuario Lder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde ser empleado el software desarrollado. Ellos proporcionan al equipo tcnico los detalles y requerimientos de las interfaces del sistema. Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, stas personas son las responsables de la administracin de cambios, de la implementacin y resolucin de anomalas. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado. Analistas y programadores: Son los responsables del desarrollo del producto en s; ellos interactan directamente con el cliente. Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente. Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser: administradores de proyecto, documentadores, diseadores de base de datos, entre otros.

Puntos a considerar durante la Ingeniera de Requerimientos Aunque la lista no est completa, se enumeran los puntos ms importantes. Objetivos del negocio y ambiente de trabajo Aunque los objetivos del negocio estn definidos frecuentemente en trminos generales, son usados para descomponer el trabajo en tareas especficas. En ciertas situaciones IR se enfoca en la descripcin de las tareas y en el anlisis de sistemas similares. Esta informacin proporciona la base para especificar el sistema que ser construido; aunque frecuentemente se aadan al sistema tareas que no encajan con el ambiente de trabajo planificado. El nuevo sistema cambiar el ambiente de trabajo, sin embargo, es muy difcil anticipar los efectos actuales sobre la organizacin. Los cambios no ocurren solamente cuando un nuevo software es implementado y puesto en produccin; tambin ocurren cuando cambia el ambiente que lo rodea (nuevas soluciones a problemas, nuevo equipo para instalar, etc.). La necesidad de cambio es sustentada por el enorme costo de mantenimiento; aunque existen diversas razones que dificultan el mantenimiento del software, la falta de atencin a la IR es la principal. Frecuentemente la especificacin inicial es tambin la especificacin final, lo que obstaculiza la comunicacin y el proceso de aprendizaje de las personas involucradas; esta es una de las razones por las cuales existen sistemas inadecuados. Punto de vista de los clientes Muchos sistemas tienen diferentes tipos de clientes. Cada grupo de clientes tiene necesidades diferentes y, diferentes requerimientos tienen diferentes grados de importancia para ellos. Por otro lado, escasas veces tenemos que los clientes son los mismos usuarios; trayendo como consecuencia que los clientes soliciten procesos que causan conflictos con los solicitados por el usuario. Diferentes puntos de vistas tambin pueden tener consecuencias negativas, tales como datos redundantes, inconsistentes y ambiguos. El tamao y complejidad de los requerimientos ocasiona desentendimiento, dificultad para enfocarse en un solo aspecto a la vez y dificultad para visualizar relaciones existentes entre requerimientos. Barreras de comunicacin La ingeniera de requerimientos depende de una intensa comunicacin entre clientes y analistas de requerimientos; sin embargo, existen problemas que no pueden ser resueltos mediante la comunicacin. Para remediar esto, se deben abordar nuevas tcnicas operacionales que ayuden a superar estas barreras y as ganar experiencia dentro del marco del sistema propuesto. Evolucin e integracin del sistema Pocos sistemas son construidos desde cero. En la prctica, los proyectos se derivan de sistemas ya existentes. Por lo tanto, los analistas de requerimientos deben comprender esos sistemas, que por lo general son una integracin de componentes de varios proveedores. Para encontrar una solucin a problemas de este tipo, es muy importante hacer planeamientos entre los requerimientos y la fase de diseo; esto minimizar la cantidad de fallas directas en el cdigo. Documentacin de requerimientos Los documentos de ingeniera de requerimientos son largos. La mayora estn compuestos de cientos o miles de pginas; cada pgina contiene muchos detalles que pueden tener efectos profundos en el resto del sistema. Normalmente, las personas se encuentran con dificultades para comprender documentos de este tamao, sobre todo si lo leen cuidadosamente. Es casi imposible leer un documento de especificacin de gran tamao, pues difcilmente una persona puede memorizar los detalles del documento. Esto causa problemas y errores que no son detectados hasta despus de haberse construido el sistema.

REQUERIMIENTOS PARA EL ANALISIS Y LA NEGOCIACIN

La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria un anlisis de los mismos antes de definir si son adecuados para el cliente. El trmino "adecuado" significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades tcnicas y econmicas, a la vez que se buscan resultados completos, correctos y sin ambigedades. En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstraccin y descomposicin de cada problema presentado. Los principales pasos de esta actividad son: Descubrir problemas potenciales En este paso se asegura que todas las caractersticas estn presentes en cada uno de los requerimientos, es decir, se identifican aquellos requerimientos ambiguos, incompletos, inconsistentes, etc. Clasificar los requerimientos: En este paso se busca identificar la importancia que tiene un requerimiento en trminos de implementacin. A esta caracterstica se le conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirn las actividades de diseo y prueba de cada requisito. La prioridad de cada requerimiento depender de las necesidades que tenga el negocio. En base a la prioridad, cada requerimiento puede ser clasificados como mandatorio, deseables o innecesarios. Un requerimiento es mandatorio si afecta una operacin crtica del negocio. Si existe algn proceso que se quiera incluir para mejorar los procesos actuales, estamos ante un requerimiento deseable; y si se trata de un requerimiento informativo o que puede esperar para fases posteriores, el requerimiento es catalogado como innecesario. Una vez hecha esta categorizacin de los requerimientos, puedo tomar como estrategia general el incluir los mandatorios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusin de un requerimiento, tambin debe analizarse su costo, complejidad, y una cantidad de otros factores. Por ejemplo, si un requerimiento fuera trivial de implementar, puede ser una buena idea incluirlo por ms que ste sea slo deseable. Evaluar factibilidades y riesgos: Involucra la evaluacin de factibilidades tcnicas (pueden implementarse los requerimientos con la tecnologa actual?); factibilidades operacionales (puede ser el sistema utilizado sin alterar el organigrama actual?); factibilidades econmicas (ha sido aprobado por los clientes el presupuesto?). En la actividad de analisis y negociacin, se incrementa la comunicacin entre el equipo de desarrollo y los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta; entre las principales tenemos: Documentar todos los requerimientos a un nivel de detalle apropiado. Mostrar todos los requerimientos a los involucrados en el sistema. Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos. Establecer las relaciones entre requerimientos que indiquen dependencias. Negociar con flexibilidad para que exista un beneficio mutuo. Enfocarse en intereses y no en posiciones.