Manual Competencias y Habilidades del Informático en la Toma de Requerimientos

MANUAL COMPETENCIAS Y HABILIDADES INGENIERO INFORMÁTICO EN LA TOMA DE REQUISITOS

2007-11-19T20:39:00.000-08:00

Este manual tiene como objetivo poder contribuir al proceso de la toma de requisitos, indicando buenas prácticas que debe realizar el Ingeniero Informático para realizar el proceso.

Gracias a la aplicación de la Metodología de Sistemas Blandos de Peter Checkland, elaborada en consecuencia de entrevistar a todas las personas involucradas en la toma de requisitos para la elaboración de un Sistema Informático, se pudo corroborar que los Ingenieros carecen de habilidad comunicativa, debido a la carencia de Inteligencia Emocional, con lo cual, aunque sean unas personas talentosas en programar, elaborar sistemas, etc., no son capaces de manejar de buena manera la interacción con las personas, en particular, como es el fin de esta investigación, la interacción con los usuarios.

Lo que se expuso anteriormente, fue concebido de tal manera que los ingenieros informáticos que no poseen mucha experiencia laboral, específicamente la falta de experiencia en la toma de requisitos, poseen una gran carencia en la habilidad comunicativa. Al contrario que las personas que poseen una experiencia mayor, no carecen de ella, lo que se concluye que es un factor relevante. Por lo tanto, es una sugerencia que exista en el período de la formación del Ingeniero Informático (Universidad, o tal vez antes, en el colegio), una exposición mediante diversas actividades, en donde se logré aumentar la inteligencia emocional, consecuencia de ello aumentar la habilidad comunicativa.

Y también, enviar a los Ingenieros Informáticos a cursos en que ellos puedan desarrollar su inteligencia emocional. Iniciativa que parta de la empresa en que se desempeña el profesional.

Además se logró determinar una falencia grande en la determinación de roles en el área Informática, debido a lo cual es de suma importancia de parte de la jefatura, determinar las capacidades que posee la gente que tiene a cargo, con lo cual se tendrá un proceso de elaboración o mantención de Sistemas Informáticos mas eficiente.

Otra cosa es que los informáticos, por falta de tiempo, son un poco desordenados para trabajar, es decir, no se guían por una metodología adecuada, no realizan estudios acerca de la lógica del negocio que involucra al problema que se trata, no hay documentación suficiente.

Debido a lo expuesto, se debe tratar de invertir más en gente que se dedique exclusivamente a documentar los requisitos, a realizar buenos contratos, en los casos en que las empresas pertenezcan al rubro de servicios Informáticos. Además de estudiar mucho, eso es algo vital, para cada nuevo desafío, el cual es dar soluciones a problemáticas mediante la elaboración de Sistemas Informáticos, deben estar preparados para poder abarcarlo satisfactoriamente.

Algo que llama la atención, en el proceso de investigación de este tema, es afirmar que las personas piensan que los informáticos, da lo mismo la especialidad, son todos “bichos raros”, que manejan todo lo que tenga que ver con la tecnología y en forma particular con un computador. Desde saber armar y desarmar un computador, pasando por manejar al revés y al derecho todas las funcionalidades de Word, Excel, o cualquier aplicación, hasta realizar grandes productos informáticos.

Se necesita que la gente que no es informática, tenga más cultura computacional, es decir, que se alfabeticen digitalmente, para que se den cuenta de lo amplio y maravilloso que es el mundo de la informática, y que cada informático maneja especialidades distintas.

Resumiendo se tienen los siguientes puntos que son vitales para una buena toma de requerimientos:

1. ESPECIALIZACIÓN

En primer lugar, para el caso de Ingenieros con poca experiencia en la toma de requisitos, (quienes presentan mayormente una carencia en la habilidad comunicacional) deben desarrollar su inteligencia emocional, en donde la empresa en donde milita este ingeniero, debe enviarlo a cursos especializados en el tema, con el objetivo de comunicase mejor con el cliente de quien obtendrán los requisitos.
Es aconsejable que los establecimientos educacionales que forman al Ingeniero desarrollen actividades que potencien su inteligencia emocional.

2. INTERIORIZACIÓN CON EL PROBLEMA

El informático que toma los requisitos debe conocer a los clientes involucrados, el entorno de trabajo, el área en qué está envuelta la problemática y todo otro aspecto relevante del problema en particular.

3. REUNIONES PERMANENTES

Realizar continuas reuniones para ir desarrollando los requisitos en instancias más elaboradas y permitir la realimentación, así el cliente está al tanto del desarrollo del proyecto y pueda dar su opinión al respecto. Debe existir una comunicación permanente con el cliente o usuario.

4. ESTABLECER CONTRATOS

Plantear explícitamente los objetivos, las tareas a realizar, en general, todos los requisitos del sistema, y dejarlos establecidos a modo de contrato. Debe haber una persona especializada en esta labor.

5. SOLICITAR COOPERACIÓN USUARIOS INVOLUCRADOS EN EL SISTEMA A TRATAR

Solicitar una cooperación satisfactoria de parte de los usuarios, en donde la persona que esta a cargo de ellos, actúe como mediador para lograr un consenso de los diversos puntos de vista presentes. Además este mediador debe ser capaz de garantizar una entrega completa de la información necesaria.

Diseño Cambios Deseables y Acciones para Mejorar el Sistema

2007-11-19T20:26:00.000-08:00

Comparación del Modelo Conceptual con la Experiencia en el Sistema

2007-11-19T20:16:00.000-08:00

Modelos Conceptuales - HAS

2007-11-19T20:13:00.000-08:00

Definicion Sistemas Pertinentes - Definiciones Raices Elaboradas

2007-11-19T20:12:00.000-08:00

Un proceso que transforme a un Ingeniero Informático que no sabe actuar frente a los distintos caracteres y estados de ánimo del cliente o usuario, es decir, que no sepa manifestar en forma adecuada su inteligencia emocional, en donde no se demuestra ninguna habilidad comunicativa mediante la inscripción por parte de la Empresa a la que pertenece el Ingeniero Informático (en particular encargado del área Informática o jefe directo del Ingeniero Informático a cargo del proceso de Toma de Requisitos) en una Escuela especializada en elevar la inteligencia emocional y a la vez en potenciar la habilidad comunicativa para obtener un Ingeniero informático que pueda manejar de buena manera su inteligencia emocional en las situaciones adecuadas, presentando una habilidad comunicativa suficiente para poder extraer de buena manera los requisitos para la realización del Sistema Informático.

Un proceso que transforme a un Ingeniero Informático que no se preocupa de investigar el contexto que involucra al problema a solucionar mediante una instrucción clara por parte Empresa a la que pertenece el Ingeniero Informático (en particular encargado del área Informática o jefe directo del Ingeniero Informático a cargo del proceso de Toma de Requisitos) para obtener un Ingeniero Informático que investigue el contexto que involucra al problema a solucionar para estar bien preparado al momento de extraer los requisitos al usuario.

Un proceso que transforme el área informática de una empresa que no posee roles bien definidos mediante un juicio adecuado acerca de las capacidades, posibles funcionalidades y cargas de trabajo que vea Empresa a la que pertenece el Ingeniero Informático (en particular encargado del área Informática) para obtener un área informática que posea roles bien determinados.

Un proceso que transforme una metodología deficiente y no permanente, que utiliza el Ingeniero Informático para crear Sistemas Informáticos mediante un establecimiento riguroso y documentado por parte de la Empresa a la que pertenece el Ingeniero Informático (en particular encargado del área Informática) para obtener una metodología que sea apta para crear el/los Sistemas Informáticos deseados de una manera permanente.

Un proceso que transforme un acuerdo deficiente entre ingeniero y clientes, es decir, que no abarca tiempos de trabajo, costos, funcionalidades del sistema, procesos de desarrollo, disponibilidad necesaria requerida de usuarios y clientes para la colaboración del sistema, etc. mediante un contrato para obtener un detalle de todo el proceso que involucre la creación o mantención del Sistema Informático.

Definición Sistemas Pertinentes - CATWOE

2007-11-19T20:06:00.000-08:00

Definición Raíz 1

Clientes: Ingeniero Informático (o, en general, cualquier persona que extraiga requisitos para crear un Sistema Informático).

Actores: Empresa a la que pertenece el Ingeniero Informático (en particular encargado del área Informática o jefe directo del Ingeniero Informático a cargo del proceso de Toma de Requisitos). Una escuela especializada en elevar la inteligencia emocional y a la vez en potenciar la habilidad comunicativa.

Transformación: Un Ingeniero Informático con una inteligencia emocional deficiente y en consecuencia con una escasa habilidad comunicativa en un Ingeniero Informático con una inteligencia emocional alta y en consecuencia una excelente habilidad comunicativa.

Weltanschauung: Mejorar los dotes de Inteligencia Emocional en un Ingeniero Informático, y en consecuencia, su habilidad comunicativa, posibilita tener una extracción de requisitos de parte de este hacia el cliente o usuario de una mejor manera, contribuyendo de buena forma a la creación de un buen producto, el cual es el Sistema Informático que pretende dar solución a los problemas de los usuarios.

Owners del Sistema: Empresa a la que pertenece el Ingeniero Informático (en particular encargado del área Informática o jefe directo del Ingeniero Informático a cargo del proceso de Toma de Requisitos).

Entorno: Presupuesto y Prioridades de la Empresa.

Definición Raíz 2

Clientes: Ingeniero Informático (cualquier persona que extraiga requisitos para crear un Sistema Informático).

Actores: Empresa a la que pertenece el Ingeniero Informático (en particular encargado del área Informática o jefe directo del Ingeniero Informático a cargo del proceso de Toma de Requisitos).

Transformación: Un Ingeniero Informático que no realiza una investigación completa acerca del contexto que involucra al problema a solucionar en un Ingeniero Informático que lleve a cabo una investigación adecuada del contexto que involucra al problema a solucionar.

Weltanschauung: Realizar investigaciones de parte del Ingeniero Informático en forma adecuada acerca del contexto en que se ve involucrado el problema que se le quiere dar solución, o más bien, la lógica del negocio, para lograr una mejor extracción de requisitos para realizar un buen Sistema Informático.

Entorno: Prioridades de la Empresa a la que pertenece el Ingeniero Informático (en particular encargado del área Informática o jefe directo del Ingeniero Informático a cargo del proceso de Toma de Requisitos).

Definición Raíz 3

Clientes: Departamento Informática de una Empresa o la Empresa misma en el caso que se dedica a realizar servicios Informáticos.

Actores: Empresa a la que pertenece el Ingeniero Informático (en particular encargado del área Informática).

Transformación: El área informática de una empresa (o empresa como tal si se dedica a dar servicios Informáticos) que no posee roles bien definidos en un área informática (o empresa como tal si se dedica a dar servicios Informáticos) que posea roles bien determinados.

Weltanschauung: Mantener roles bien definidos en el equipo que realiza el Sistema Informático, para que este sea exactamente lo que el cliente pide en el tiempo más corto posible.

Owners del Sistema: Empresa a la que pertenece el Ingeniero Informático (en particular encargado del área Informática).

Entorno: Se cuenta con poca gente, no hay presupuesto suficiente.

Definición Raíz 4

Clientes: Departamento Informática de una Empresa o la Empresa misma en el caso que se dedica a realizar servicios Informáticos.

Actores: Empresa a la que pertenece el Ingeniero Informático (en particular encargado del área Informática).

Transformación: Metodología deficiente y no permanente, que utiliza el Ingeniero Informático para crear Sistemas Informáticos en una metodología que sea apta para crear el/los Sistemas Informáticos deseados.

Weltanschauung: Tener una metodología adecuada y utilizada en forma permanente es muy valioso para realizar Sistemas Informáticos de calidad.

Owners del Sistema: Empresa a la que pertenece el Ingeniero Informático (en particular encargado del área Informática).

Entorno: Variedad de Metodologías ya creadas para solucionar una gran variedad de problemas.

Definición Raíz 5

Clientes: Usuarios que necesitan el Sistema Informático.

Actores: Clientes, Ingenieros Informáticos (en particular encargado del área Informática o jefe directo del Ingeniero Informático a cargo del proceso de Toma de Requisitos).

Transformación: Acuerdo deficiente entre ingeniero y clientes, es decir, que no abarca tiempos de trabajo, costos, funcionalidades del sistema, procesos de desarrollo, disponibilidad necesaria requerida de usuarios y clientes para la colaboración del sistema, etc. en un contrato que estipule cada detalle desde el comienzo hasta el final de la creación o mantención del Sistema Informático.

Weltanschauung: Lograr estipular tiempo en que quedará listo el Sistema Informático, costos de la creación, funcionalidades que va a tener, procesos de desarrollo del Sistema, etc. para que todos los involucrados sean beneficiados y a la vez no surjan problemas.

Owners del Sistema: Clientes, Ingenieros Informáticos (en particular encargado del área Informática o jefe directo del Ingeniero Informático a cargo del proceso de Toma de Requisitos).

Entorno: Imposibilidad de concretar reuniones.

Definición Sistemas Pertinentes - Sistema Social (a la Vickers)

2007-11-19T20:04:00.000-08:00

· Ingenieros a cargo de la captura de requisitos

Rol	Reunir la información relevante que le entregan los clientes
Norma	Elaborar una documentación apropiada con los requisitos obtenidos que pueda ser la base para un contrato
Valor	Obtención eficiente de los requisitos en forma completa y que satisfagan las necesidades existentes

· Clientes

Rol	Señala la información de lo que se debe realizar. Informa sobre los procedimientos envueltos en su entorno
Norma	Entregar los requisitos con la información que poseen y que servirán para elaborar un contrato
Valor	Entregar la información de manera clara facilitando así la elaboración de las tareas a realizar

Definicion Sistemas Pertinentes - Definiciones Raices

2007-11-19T20:02:00.000-08:00

Un proceso que convierta a un Ingeniero Informático que no sabe actuar frente a los distintos caracteres y estados de ánimo del cliente o usuario, es decir, que no sepa manifestar en forma adecuada su inteligencia emocional, en donde presenta deficiencias en su habilidad comunicativa EN un Ingeniero informático que puede manejar de buena manera su inteligencia emocional en las situaciones adecuadas, presentando una habilidad comunicativa suficiente para poder extraer de buena manera los requisitos para la realización del Sistema Informático.

Un proceso que convierta a un Ingeniero Informático que no realiza una investigación completa acerca del contexto que involucra al problema a solucionar EN un Ingeniero Informático que lleve a cabo una investigación adecuada del contexto que involucra al problema a solucionar.

Un proceso que convierta el área informática de una empresa que no posee roles bien definidos EN un área informática que posea roles bien determinados.

Un proceso que convierta a una metodología deficiente y no permanente, que utiliza el Ingeniero Informático para crear Sistemas Informáticos EN una metodología que sea apta para crear el/los Sistemas Informáticos deseados.

Un proceso que convierta un acuerdo deficiente entre ingeniero y clientes, es decir, que no abarca tiempos de trabajo, costos, funcionalidades del sistema, procesos de desarrollo, disponibilidad necesaria requerida de usuarios y clientes para la colaboración del sistema, etc. EN un contrato que estipule cada detalle desde el comienzo hasta el final de la creación o mantención del Sistema Informático.

Situación Problema Expresada (Rich Picture)

2007-11-19T19:58:00.000-08:00

Situación Problema No Estructurada

2007-11-19T19:47:00.000-08:00

Realizar de una forma sistemática, y en lo posible eficiente, la extracción de requisitos para el desarrollo de un Sistema Informático es indispensable para lograr una buena base en su creación, debido a que es la primera etapa del proceso de desarrollo de software y a partir de de esta fase, no importando la metodología que se aplique, se continua trabajando en la elaboración de una buena solución para un usuario final, el cual es el que utiliza el producto terminado.

El ingeniero informático, en la mayoría de los casos, sobre todo en Chile, de acuerdo a los resultados obtenidos el realizar diversas entrevistas (como pueden consultarse en la sección entrevistas), posee deficiencias al momento de capturar requerimientos, no logrando un buen producto para los clientes que requieren alguna solución a sus problemas, o en consecuencia, para los usuarios finales, los cuales van a utilizar los Sistemas Informáticos que se creen.

Ante esta situación se desea determinar que competencias y habilidades debe poseer un Ingeniero Informático para realizar la Toma de Requerimientos para el desarrollo de un Sistema Informático.

En esta sección se describen, principalmente, los problemas obtenidos al realizar las entrevistas.

Existe mala comunicación entre la persona que toma requerimientos y los usuarios.

Se presenta una imposibilidad de realizar reuniones necesarias entre el ingeniero y los usuarios.

Hay una mala distribución de roles en el equipo de trabajo que está creando el Sistema Informático.

No se guían por alguna Metodología que oriente el proceso de desarrollo de Software.

No existe una buena educación en el sentido de cómo relacionarse socialmente por parte de las Universidades hacia los Ingenieros.

Los usuarios son reticentes a entregar la información necesaria para crear un Sistema Informático.

Existe una vaga documentación de requisitos, produciendo una vaga comprensión de estos tanto de los usuarios, como en el grupo de trabajo.

Los usuarios no participan activamente en todo el proceso de desarrollo.

Existen problemas originados por el uso del lenguaje natural, relacionados con la falta de claridad o la confusión de requisitos.

Entrevista Nº2

2007-11-13T09:44:00.000-08:00

Nombre: Mónica Villanueva.

Trabajo: Jefe Carrera Ingeniería Civil en Informática USACH

e-mail: mvilla@diinf.usach.cl

¿Es buena la comunicación que existe con los informáticos?

Es frecuente, cuando uno lo necesita, pero no siempre es fluida, ya que depende del período en el semestre, es complicada a fin de semestre sobretodo. Por lo tanto no es tan rápida la ayuda, ya que todas las coordinaciones solicitan cosas. Si son cosas urgentes y tenemos que esperar, surgen inconsistencias.

¿Cómo llegan a un acuerdo de lo que se quiere entre las distintas coordinaciones?

No hay un consenso para el sistema, ya que todas las coordinaciones tienen necesidades distintas, tienen sus propias reglas. Aunque si hay cosas estándar.

¿Le comunican al informático todas las inquietudes que tienen?

No, hay cosas que deberíamos comunicarlas, pero por razones de tiempo no se puede.

¿Debería una mejor distribución de roles en el departamento, para tener tiempo para una mejor comunicación con el informático?

Si, se necesita una mejor distribución de trabajos, alguna persona administrativa por ejemplo, para tener la planificación de asignaturas para los semestres que vienen.

¿Existen reuniones con el informático para mejorar el sistema?

No, solo comunicación telefónica, si hay algo que arreglar ellos vienen al departamento, no existe una reunión formal, lo cual haría falta.

Otro problema es que el sistema está muy parchado, es decir todo lo que se parche va a funcionar mal en un momento.

¿Cree que el sistema fue mal hecho desde el comienzo?

En realidad pienso que el sistema nunca fue pensado con todas las funcionalidades que tiene hoy en día, en donde siempre van surgiendo nuevos problemas y a consecuencia de ello, se implementan nuevas soluciones en el sistema, lo cual provoca esos parches.

¿Cómo es la forma de comunicarse del Informático?

La mayoría no se comunica de muy buena manera, es como una característica común del ingeniero. Falta comunicación, expresión, hablar más, explicar más, hablar con menos tecnicismo. Hay excepciones que se dan a nivel personal, debido tal vez a costumbres familiares, o tal vez a otros motivos.

¿Debe existir alguna asignatura en la Universidad que enseñe a como comunicarse de buena manera a un ingeniero?

Más que un ramo, es algo que hay que ir trabajando permanentemente, lo da la experiencia. Tal vez un ramo como español ayude. Deben existir ramos en que trabajen con alumnos que estudian carreras distintas a la ingeniería, para saber relacionarse.

¿Es importante que un ingeniero utilice alguna metodología?

Es fundamental utilizar una metodología para evitar futuros problemas en algún sistema.

¿Cree que los usuarios deben participar en forma activa en la creación de un sistema?

Creo que si, no se si activa, pero si en forma permanente. Estar mirando, examinando, cuando uno ya está usando el sistema, surgen las dudas.

Entrevista Nº6

2007-11-13T09:34:00.000-08:00

Nombre: Javier Ulloa

Titulo: Ingeniero en Ejecución Informática

Años de Experiencia en Toma de Requisitos: 2 años

Trabajo: Desarrollo Sistemas Área Informática, Registro Curricular Facultad Ingeniería, USACH.

e-mail: julloa@usach.cl

¿Cómo es el proceso de toma de requerimientos de un Sistema Informático?

Primero se realiza la entrevista y se le pregunta qué es lo que realmente quiere.

¿De qué manera participa el informático a cargo de este proceso en él?

Participa en las reuniones y también en el diseño para lo que sirve bastante el UML.

¿Se basa en alguna metodología para crear los sistemas?

Hasta ahora no, pero estamos comenzando a implementar la metodología OMT++.

¿Qué acciones concretas realiza usted para extraer la información a los usuarios para la creación de un Sistema Informático?

Se realizan entrevistas, encuestas, pero lo que más se hace acá es un contacto vía telefónica.

¿Cómo determina los puntos de interés del usuario?

Mediante la comunicación, uno va reconociendo que es lo que desea el cliente o los usuarios. A veces no saben realmente lo que desean, por eso uno tiene que ayudarlos a determinar que es lo que necesitan realmente.

¿Cómo enfrenta la situación en que al tomar los requerimientos de una persona que se vea directamente relacionado con el sistema no exprese de buena forma lo que necesita?

Ha pasado, por lo tanto uno tiene que ayudarlo a que explique realmente lo que desea. Otra cosa es que acá hay distintos usuarios, todos los coordinadores, en donde cada uno necesita cosas distintas, por lo tanto a veces es difícil llegar a un consenso de lo que se va a agregar al sistema.

¿Cree que la experiencia influye en la toma de requisitos?

Claro que si, yo he ido aprendiendo a desenvolverme ante los usuarios con el tiempo.

¿Cómo definiría su habilidad comunicativa?

Me cuesta expresar o llevar una buena comunicación con los usuarios, sobretodo con personas que son más conflictivas, pero la experiencia me ha ayudado a desenvolverme de mejor manera.

¡Deje su Comentario!

2007-11-12T16:10:00.000-08:00

Por favor en este espacio opine acerca de nuestro blog.

Ingeniería de Requisitos

2007-11-10T14:03:00.000-08:00

La Ingeniería de requisitos es el proceso de establecer los servicios que el cliente requiere de un sistema y las restricciones bajo las cuales el sistema va a ser desarrollado y debe operar.

Los requisitos del sistema son descripciones generadas durante el proceso de ingeniería de requisitos. Pueden variar desde una descripción de un servicio o una restricción de un sistema, en un alto nivel de abstracción, hasta una especificación funcional matemática detallada.

Los requisitos son importantes principalmente porque permiten alcanzar 2 objetivos:

Pueden ser la base de una propuesta de contrato, por lo tanto debe estar abierto a la interpretación.

Pueden ser la base de un contrato, por lo que debe estar definido en detalle.

A continuación se hace una descripción de quien necesita los requisitos y con qué objetivo:

Cliente: el objetivo del requisito es permitirle saber lo que ha pedido.

Analista: el objetivo del requisito es comunicarse con el cliente y determinar con precisión lo que necesita.

Desarrollador: el objetivo del requisito es permitirle saber que hacer.

Probador de Programas: el objetivo del requisito es permitirle construir pruebas.

Mantenedor: el objetivo del requisito es permitirle comprender el sistema y hacerle las modificaciones correctas

Una Especificación de Requisitos debe contener los siguientes Requisitos:

Abstracta: debe evitar detalles no esenciales.

Completa: debe contener todos los requisitos de la solución.

Correcta: debe llevar a implementaciones aceptables.

Consistente: no debe contradecirse a sí misma.

Detallada: debe describir completamente cada requisito.

Concisa: debe ser tan pequeña como sea posible.

Factible: debe poder ser realizable.

Modificable: debe ser fácil de adaptar y extender.

Precisa: no debe ser ambigua.

Legible: debe ser fácil de leer y comprensible.

Verificable: es fácil verificar que una implementación satisface la especificación.

Los requisitos se clasifican en 3 tipos:

Requisitos de Usuario: es escrito para el cliente. Constituye un enunciado en lenguaje natural más diagramas de los servicios que se espera que el sistema proporcione y sus restricciones de operación.

Requisitos del sistema: Escrito como un contrato entre cliente y contratista. Es un documento estructurado que expone descripciones detalladas de los servicios del sistema, lo que éste debería hacer.

Especificación de diseño de software: escrito para desarrolladores. Es una descripción detallada del software que sirve como base para una implementación o diseño.

Los requisitos también suelen clasificarse desde otra perspectiva en:

Requisitos Funcionales: Servicios que el sistema debe dar y cómo éste debe reaccionar ante entradas específicas o situaciones particulares.

Requisitos No-funcionales: restricciones de los servicios o funciones ofrecidos por el sistema.

Requisitos de Dominio: Pueden ser funcionales o no- funcionales. Provienen del dominio de la aplicación.

Uno de los problemas que surge al elaborar los requisitos, y que también ha sido desarrollado en este trabajo de investigación, está relacionado con la imprecisión de los requisitos. Esto se debe al uso de palabras ambiguas que pueden causar que haya distintas interpretaciones entre los desarrolladores y los usuarios.

En vista de lo anterior, es que surgen los conceptos de completitud y consistencia de los requisitos. Con completo se refiere a que un requisito bebería incluir descripciones de todas las facilidades requeridas. Con consistente se refiere a que no debería haber conflictos entre las descripciones de las facilidades del sistema. Aunque en la práctica es imposible producir un documento completo y consistente para sistemas grandes.

Otros de los problemas que surgen con los requisitos de dominio son:

Comprensibilidad: los requisitos son expresados en el lenguaje del dominio de la aplicación por lo que suelen no ser entendidos por los ingenieros desarrolladores del sistema.

Implicidad: los especialistas del dominio entienden el área tan bien que no piensan que sea necesario hacer explícitos sus requisitos, suelen darlos por hecho.

Los requisitos de usuario son definidos usando lenguaje natural, tablas y diagramas. Esto acarrea problemas que con inherentes al uso del lenguaje natural, entre ellos la falta de precisión, confusión entre requisitos funcionales y no-funcionales, los que tienden a mezclarse y el hecho de que haya varios requisitos en un solo enunciado.

Recomendaciones para la toma de requisitos:

Es importante entregar una explicación junto con los requisitos ya que permite entender el dominio de aplicación de éste. Además, esta explicación es particularmente importante cuando los requisitos tienden a ser cambiados, ya que reduce las posibilidades de que los cambios tengan efectos inesperados. Además para escribir requisitos se sugiere que:

Inventar un formato estándar y usarlo para todos los requisitos.

Usar el lenguaje de una manera consistente.

Usar texto resaltado para identificar partes importantes.

Evitar usar jerga computacional.

El documento de requisitos: constituye el enunciado oficial de lo que se está solicitando a los desarrolladores de un sistema. Incluye requisitos de usuario y requisitos de sistema. Debe incluir una definición y una especificación de requisitos. Debe establecer qué se debe hacer y no el cómo hacerlo. Este documento debe poseer los siguientes requisitos:

Especificar el comportamiento externo del sistema y las restricciones de implementación.

Debe ser fácil de modificar y servir como herramienta de referencia para la mantención.

Debe servir como un elemento de registro acerca de registro del ciclo de vida del sistema.

Debe caracterizar respuestas a sucesos inesperados.

REFERENCIAS

Ian Sommerville. Ingeniería de Software. 6º Edición. PEARSON EDUCACIÓN, México, 2002.

Entrevista Nº1

2007-11-10T13:49:00.000-08:00

Nombre: María del Rosario Medina.

Trabajo: Jefa Administrativa Importadora Patronato Local San Alfonso.

e-mail:sanalfonso41@imppatronato.cl

Escuchar Entrevista

¿En qué tipo de empresa trabaja?

Empresa de importaciones de ropa.

¿Cómo el informático extrae los requerimientos para crear un sistema informático?

Puede ser mediante reuniones en la casa matriz, por teléfono o correo electrónico, depende las necesidades nuevas que vayan surgiendo para la venta se van creando nuevas funcionalidades al sistema.

¿Cómo son esas reuniones?

Son pocas reuniones, pero se juntan los informáticos, preguntan que es lo que necesitamos. Ellos van creando lo que nosotros necesitamos para que se nos facilite la venta.

¿De qué manera le piden lo que necesitan?

Cuando un sistema es lento, cuando hay muchos pasos para facturar, le tratamos de pedir que sea todo más fácil y más rápido. Ellos buscan la forma de cómo arreglarlo, nosotros sólo solicitamos que el sistema sea más rápido (eficiente).

¿Es buena la comunicación que existe con los informáticos?

Es relativamente buena, por correo. Si no es rápido nosotros insistimos, para que se resuelva el problema lo más rápido posible,

¿Cómo se organiza el área informática en su empresa?

Hay un departamento informático donde hay un gerente, y existen otras personas con distintos cargos. Existe una mesa de ayuda a la cual uno puede recurrir. Uno deja su requerimiento desde esa mesa de ayuda, y el informático que este a cargo de resolver algún problema en específico que este acorde con la solicitud se dedica a encontrar la solución.

¿Ustedes están siempre dispuestos a entregar toda la información que el informático requiere?

Si, por supuesto, mientras que la venta sea rápida y que el cliente se vaya contento no existe problema en ese asunto.

¿Los informáticos entienden de inmediato lo que ustedes requieren?

No entienden de una forma rápida, ya que ellos no manejan el negocio de ventas, es por eso que se tienen que hacer las reuniones o nosotros le mandamos un correo, explicándoles como es todo el proceso de ventas. A veces ellos tienen que venir al local a observar como funciona el proceso, por ejemplo, como se hace una factura, como se hace una boleta, como se hace una nota de crédito.

¿Han existido conflictos con ellos?

A veces si, por supuesto, ningún lugar esta exento de conflictos, mediante la conversación todo se soluciona. Si no funciona algo se les manda un correo, o tienen que realizar de nuevo el sistema o cambio al sistema.

¿Usted no es la única que solicita requerimientos?

Existen otros locales.

¿Cómo llegan a un acuerdo de que es lo que se quiere en general para los locales?

Todos los locales funcionan de la misma forma, con el mismo sistema, todo lo que se requiere es lo mismo, las necesidades de los locales al fin y al cabo son las mismas.

¿Usted cree que la experiencia influye en la toma de requerimientos?

Yo no entiendo mucho como funciona el informático, solo se que si hay buena comunicación se va a trabajar de mejor manera.

¿Ustedes que la educación influye en la manera de expresarse?

Yo creo que si, por que hay muchas cosas del sistema que yo no voy a entender, entonces para que yo lo entienda el va a tener una buena comunicación hacia mi en forma de que entienda. Lo mismo yo, hay cosas que el no entiende, por lo tanto voy a tener que saber como desenvolverme hacia él de forma que el me entienda lo que requiero.

Explicación Metodología SSM

2007-11-07T15:11:00.000-08:00

Para poder realizar un manual de buenas prácticas, que incluya una lista de competencias y habilidades, que el ingeniero informático debe poseer para el proceso de la toma de requerimientos, se utilizará la metodología SSM (Metodología de los Sistemas Blandos), que se adapta de buena manera a la situación problema que se presenta, en donde se van a detectar los conflictos que existen en la Ingeniería de Requerimientos.

Esta será brevemente explicada a continuación.

¿Qué es la SSM?

La SSM fue creada por Peter Checkland, quién trabajó por muchos años en la industria adoptando diversas metodologías duras. A lo largo de esos años se dio cuenta de que estas metodologías eran insuficientes para abarcar problemas extremadamente complejos, los cuales contienen grandes contenidos sociales.

En los años `60 Checkland ingresa a la Universidad de Lancaster en donde surge, gracias a sus investigaciones, una nueva forma de pensamiento sistémico apropiado para lidiar con situaciones humanas complejas (blandas), la cual ha ido refinando con el tiempo y al adoptarla a situaciones reales en distintas empresas.

La metodología que se conoce hoy en día se estableció definitivamente en 1981.

Pasos de la SSM

Paso 1: Situación problema no estructurada

Se pretende lograr una descripción de la situación donde se percibe la existencia de un problema, sin hacer hincapié en el problema en sí, esto es sin dar ningún tipo de estructura a la situación. La situación problema puede contener varias percepciones de problemas, que darán origen a igual número de situaciones problemas expresadas y definiciones raíz.

Paso 2: Situación problema expresada (Rich Picture)

Se realiza una representación pictórica para seleccionar los distintos puntos de vista, los cuales determinan los denominados “sistemas pertinentes”. Se da forma a la situación describiendo su estructura organizativa, actividades e interrelación de éstas, flujos de entrada y salida, etc.

Paso 3: Definición Sistemas Pertinentes

A) Definiciones Raíces

Cada definición raíz corresponde a una visión de la situación problema. Una definición raíz tiene la forma: “Un proceso que convierte X en X’ “, en donde X representa el sistema que presenta el problema y X’ es el mismo sistema transformado sin presentar problema alguno.

B) Sistema Social (a la Vickers)

Los sistemas sociales se representan como instancias de un vector .

Rol: es un papel que juega una persona en la organización.

Norma: comportamiento esperado que caracteriza ese rol

Valor: Representa el desempeño actual de un rol, medido para juzgarle según creencias locales sobre los que es bueno y malo.

C) CATWOE

Se deben considerar una serie de elementos para determinar si una definición raíz esta bien formulada. A continuación se describen estos elementos:

-Clientes: victimas o beneficiarios de Transformación.

-Actores: aquellos que realizarán la Transformación.

-Transformación: es el proceso mediante el cual una entrada que contiene el sistema que presenta problemas se convierte en una salida con el mismo sistema sin que presente problemas.

-Weltanschauung: punto de vista bajo el cual tiene sentido la transformación.

-Owners: quien puede detener la transformación si lo estima necesario, en otras palabras el propietario del sistema.

-Entorno: medio ambiente o contexto que restringe o posibilita las acciones dentro del sistema donde se efectúa la transformación.

D) Definiciones Raíz Elaboradas (DRE)

Con los datos registrados en el CATWOE el investigador podrá reformular la definición raíz original, que sólo señala el “qué” en una definición raíz elaborada, que contiene el “qué”, el “cómo” y el “para qué”.

Tiene la forma: Sistema que hace X mediante Y para obtener Z.

Paso 4: Modelos Conceptuales – HAS

Para cada definición raíz se construye un HAS, en donde partiendo de los verbos de acción presentes en las definiciones raíz se elaboran modelos conceptuales que representen las actividades que se deban realizar en el sistema. Debe incluir cualquier flujo de entrada-salida de información que sea esencial para lograr la transformación que esta presente en la definición raíz. No existe un único HAS, ya que se presentarán múltiples posibilidades de actividades que combinadas lógicamente satisfagan la transformación establecida en la Definición Raíz.

A) Sistema Formal

Una guía útil para realizar un buen HAS es apoyarse en conceptos que ya estén disponibles en algunos modelos formales de actividades de la sistémica. Para verificar que el HAS sea completo y consistente se puede utilizar como guía de apoyo el modelo formal de los 9 niveles de Jean Louis Le Moigne, que permite obtener las variables esenciales del sistema.

B) Otros Pensamientos de Sistemas

Consiste en transformar el modelo obtenido en alguna otra forma de pensamiento sistémico que, dadas las particularidades del problema, pueda ser conveniente.

Paso 5: Comparación del Modelo Conceptual con la Experiencia en el Sistema

Comparar el modelo conceptual con la experiencia en el sistema. La comparación puede ser realizada mediante Tablas de comparación de los modelos versus la experiencia, discusiones informales y cuestionarios que se derivan de los modelos.

Paso6: Diseño de Cambios Deseables, Viables

Enumeración de cambios deseables y factibles. Según los resultados obtenidos de realizar las comparaciones del paso anterior, se extraen posibles candidatos a cambios a realizar sobre la situación problema, los que deben ser consensuados con las personas que habitan el sistema de manera que sean pertinentes y significativos.

Paso7: Acciones para mejorar la situación problema

Una vez obtenidos los cambios a realizar se realizan las acciones necesarias para llevarlos a cabo y solucionar la situación problema. Este paso no representa el fin de la aplicación de la metodología, pues en su aplicación se transforma en un ciclo de continua conceptualización y habilitación de cambios, siempre tendiendo a mejorar la situación.

REFERENCIAS:

Muñoz G. José. "Aplicando la metodología de los sistemas blandos" . Material de Estudio, Universidad de Santiago de Chile, 2006, vol. 2.

http://www.12manage.com/methods_checkland_soft_systems_methodology_es.html, leído 6 de Noviembre de 2007

Entrevista Nº5

2007-11-07T14:08:00.000-08:00

Nombre: Loreto Carmona.

Titulo: Ingeniero Civil en Informática.

Años de Experiencia en Toma de Requisitos: 1 Año (Ha tenido otros trabajos en empresas pero no relacionados con la Toma de Requisitos).

Trabajo: Consultora MC2G

e-mail: lcarmona@mc2g.com

Escuchar Entrevista

¿En la empresa que se desempeña (ó) se seguía alguna metodología especial para crear un sistema informático? ¿Podría hablarnos acerca de ella?

Mitologías formales no hay ninguna, nosotros conversando tomamos requerimientos, y dependiendo de esos requerimientos se propone una arquitectura de solución a sus problemas, se plantea la solución en papel, en esquemas. Empresas grandes siempre tienen documentación asociada en sus sistemas. La documentación no se hace la mayoría de las veces, porque hay que tener a una persona realizando esa labor, trasformándolo en costos adicionales. El problema surge cuando hay varios involucrados en la creación de un sistema, y como no hay documentación que explique el desarrollo del proceso como tal produce complicaciones dentro de la creación del sistema, se pierde tiempo. Si es uno riguroso en la documentación, se evitan líos de proceso de creación de sistemas. Uno siempre trabaja contra el tiempo.

¿Cuál es su rol en la empresa que trabaja?

Soy consultora. En mi equipo de trabajo somos todos consultores. Realizamos distintos roles. Estamos creciendo recién en área de desarrollo, por lo tanto por ahora realizamos distintas labores, jugamos distintos roles.

A veces surgen problemas en que no se puede tener un contacto regular con las empresas interesadas que desean tener una solución a un problema que les aqueja, en donde estas no ponen a nuestra disposición toda la información que necesitamos.

¿Ellos no quieren dar información o ustedes no la solicitan?

Ellos tienen distintas prioridades, ellos a veces nos dejan en la última prioridad, en donde no hay tiempo suficiente.

¿De que manera podrían captar de buena forma los requerimientos?

Creo que es de vital importancia que estén todos los personajes involucrados. A veces vamos a tener una reunión con nuestros clientes, pero hay usuarios involucrados que no se encuentran disponibles en ese instante. Un usuario nos dice una cosa, pero otro usuario, que no se encontraba presente a la hora de extraer requisitos, y con más importancia en la creación del sistema, nos plantea cosas distintas a las que nos planteaban los otros usuarios, produciéndonos un conflicto de pérdida de tiempo. A veces uno termina construyendo un sistema que no satisface los problemas del usuario final, teniendo que muchas veces construir todo de nuevo.

Tal vez uno hace algo correcto, de acuerdo a un usuario que nos plantea los requisitos, pero no va de acuerdo a lo que el usuario final más importante requiere, el cual es el que maneja la lógica de negocios.

¿Qué acciones concretas realiza usted para extraer todo el conocimiento a los usuarios y a la organización para la cual esta diseñando un Sistema Informático?

Conversando, haciendo esquemas, con el mismo usuario creando un modelo con el sistema actual.

¿Cómo enfrenta la situación en que al tomar los requerimientos de una persona que se vea directamente relacionado con el sistema no exprese de buena forma lo que necesita?

A mi no me ha tocado personalmente, pero conozco casos. En este tipo de casos uno tiene que tener que hacer entender al usuario que el va a tener beneficios con la creación del sistema.

¿Cómo se enfrenta a situación de que el cliente crea que maneja todos los detalles técnicos acerca de su área?

Si no le estoy entendiendo al usuario de lo que está hablando se lo comunico derechamente, si yo no entiendo algo no lo puedo dejar pasar, es mi deber como informático seguir preguntando hasta que logre entender lo que el usuario quiere.

¿Si existen distintos puntos de vista, como se llega a consenso?

Cuando no se ponen de acuerdo los involucrados, para nosotros es terrible, porque eso produce una perdida de tiempo y perdimos dinero. Es un costo que se tiene que asumir y se aprende con la experiencia.

¿Se estipulan tiempos en los contratos?

No sabemos muchas veces dimensionar el tiempo de duración de la creación de un sistema. Surgen inconvenientes en la puesta en marcha del sistema, ya que abordamos todos los aspectos por la falta de información, aún haciendo estudios de factibilidad.

¿La experiencia influye en la toma de Requerimientos?

Si influye, porque uno al cometer errores, va aprendiendo a enfrentarlos a través del tiempo.

¿Cómo definiría su habilidad comunicativa, su inteligencia emocional y su capacidad de adaptación?

Uno va mejorando a medida que va pasando el tiempo, y va logrando dominar distintos temas, y a desarrollar ciertos aspectos comunicacionales. El importante tener ramos como el tuyo que ve estos temas para saber enfrentarse a la gente. Siempre hay que tener contento al cliente, uno tiene que captar si un cliente no anda de muy buen humor, tal vez postergando alguna entrevista.

¿Qué rol juega la ética?

Ya tengo mi forma de trabajar, y si viene alguien que me haga hacer algo que no crea que es correcto, tengo otras posibilidades en donde desempeñarme.

Entrevista Nº4

2007-11-07T13:01:00.000-08:00

Nombre: Marco Jeldres (persona ubicada a la derecha de la foto).

Titulo: Ingeniero Ejecución en Informática.

Años de Experiencia en Toma de Requisitos: 17 Años.

Trabajo: Desarrollo Sistemas Área Informática Polla Chilena

e-mail: marco.jeldrez@pollachilena.cl

Nombre: Mariano Alfaro (persona ubicada a la izquierda de la foto).

Titulo: Analista y Desarrollador.

Años de Experiencia en Toma de Requisitos: 18 Años.

Trabajo: Desarrollo Sistemas Área Informática Polla Chilena

e-mail: mariano.alfaro@pollachilena.cl

Escuchar Entrevista

¿Cómo es el proceso de la toma de requerimientos de un Sistema Informático?

En nuestro caso el proceso comienza como un proyecto anual que se ve en un comité, en el cual se estudian todos los procesos de desarrollo en el año. En base a eso se definen las tareas y prioridades que se deben dar.

El usuario tiene la necesidad de resolver un problema, la gerencia revisa este listado de necesidades y ve como resolver esos problemas, en donde se revisan cuales se pueden llevar a cabo y cuales no.

¿De qué manera o como participa el Informático a cargo de este proceso en él?

Nosotros actuamos como jefe de proyecto, cada uno toma un problema a resolver, realizando las entrevistas correspondientes y se hacen bosquejos del problema, se buscan soluciones a los problemas de los usuarios mediante un análisis, y luego se desarrolla el sistema, al cual se le realizan pruebas. Se junta uno con el usuario y se le hacen modificaciones al sistema. Se da una marcha blanca y puesta en marcha y luego una mantención.

¿Han trabajado para empresas externas a polla?

No solamente acá, los sistemas que realizamos son para solucionar problemas en la misma empresa. Por ejemplo Sistemas de Gestión de Información.

¿En qué tipo de empresa trabaja?

Siempre he trabajado en polla (Marco) al igual que Mariano.

¿En la empresa que se desempeña (ó) se seguía alguna metodología especial para crear un sistema informático? ¿Podría hablarnos acerca de ella?

Básicamente la metodología que ya había comentado. Seguimos una metodología que se desarrollo acá en esta empresa. Parte del proyecto anual, que contiene subproyectos, los cuales se asignan a diversas personas que se hacen cargo de ejecutarlos. En donde el jefe de proyectos se encarga de controlar todo.

¿Cuál es su rol en el proceso de toma de requerimientos?

Nosotros tomamos requerimientos, no se tienen roles específicos. Nosotros podemos ser técnicos hasta desarrollar sistemas.

¿Se realiza un estudio de factibilidad para verificar si el sistema contribuye a los objetivos del negocio? ¿Cómo se realiza este proceso?

Se analizan los tiempos, ya que siempre surgen nuevos problemas que son de mayor urgencia que otros. Se regula con la carta Gantt, pero el problema es que aparecen problemas nuevos y con más prioridad que atrasan los otros proyectos.

¿Qué acciones concretas realiza usted para extraer todo el conocimiento a los usuarios y a la organización para la cual esta diseñando un Sistema Informático?

Entrevistas y conocimientos del negocio. Cuando uno conoce el tema, se puede realizar una buena entrevista. Uno de los plus que tenemos, es que conocemos bien el negocio de la empresa. Se hacen entrevistas y se presenta lo que uno entendió de ella y se agregan cosas que uno cree que deberían existir para ese problema. Si al mostrar al usuario lo que uno entendió del problema, y el dice que no es lo que quería, se hace modificaciones de los requerimientos.

¿Cómo usted determina los puntos de interés del usuario?

Eso lo da la entrevista, la necesidad que el usuario tenga. Un problema que se presenta es que no hay mucho tiempo para solucionar ciertos problemas, por lo tanto no hay mucho tiempo para estar con el usuario. Existe una reunión de un par de horas, y se comienza de inmediato con el análisis y desarrollo. Pero siempre en el desarrollo surgen nuevas necesidades en que uno debe tener una reunión corta con el usuario. Una o dos reuniones formales al comienzo y parar de contar.

¿Cómo enfrenta la situación en que al tomar los requerimientos de una persona que se vea directamente relacionado con el sistema no maneje demasiado o no exprese de buena forma lo que necesita?

Tratamos de entrevistar a las personas que se vean involucradas directamente con la necesidad. Si uno entrevista a un gerente y ve que no maneja la mecánica del sistema a implementar, se entrevista a una persona de mas bajo rango. Si la persona que esta directamente involucrada en el desarrollo del sistema no maneja de muy buena manera, uno como desarrollador o persona que quiere extraer buenos requisitos debe guiarlos para sacar el máximo provecho a la entrevista. A veces pasa que uno se da cuenta que el usuario puede solucionar su problema incluso con sistemas que ya existen, y no hay necesidad de crear uno nuevo. A veces ocurre que los usuarios tienen aplicaciones que tienen a su disponibilidad, y no tienen la mayor idea que les soluciona sus problemas.

¿Cómo se enfrenta a situación de que el cliente crea que maneja todos los detalles técnicos acerca de su área?

Uno debe documentarse, y debe preguntarle directamente al usuario o cliente algo que uno no entienda.

¿Si existen distintos puntos de vista, como se llega a consenso?

El consenso se obtiene cuando se cree que la solución que se presenta es la óptima. Si el usuario está equivocado en algo se le plantea caballerosamente que está equivocado nada más. Y si no quiere dar el brazo a torcer en su punto de vista, se entrega el la solución que el desea simplemente, o se busca por otros lados, como otras personas que estén involucrados, siempre hay terceros involucrados.

Para realizar un sistema informático existen distintos involucrados ¿Cómo soluciona el conflicto de puntos de interés?

Nosotros realizamos distintas tareas. En casos que hay distintos usuarios, se junta a todos los involucrados y se llega a un consenso, tomando las opiniones de todos. Si se maneja bien el negocio, “todos hablan el mismo idioma”, y se determina de inmediato si alguien esta fuera de lugar en un grupo de trabajo.

¿Cree usted que la experiencia influye en la toma de requisitos?

Si uno no maneja la información acerca de un negocio, uno debe documentarse. Es importante que uno no se quede con lo que dice el usuario, uno debe involucrarse en el tema. A medida que uno va obteniendo experiencia, tiene mayor capacidad de abstracción.

¿Cómo definiría su habilidad comunicativa, su inteligencia emocional y su capacidad de adaptación?

Mayores problemas no hemos tenido frente a los usuarios, me han tocado usuarios difíciles. Si uno tiene a usuarios conflictivos debe tratar de llegar al usuario.

Hay casos en que uno entrega sistemas terminados, el usuario al probarlo, tal vez pida más cosas que uno jamás había conversado en un comienzo, siempre surgen nuevas modificaciones, pueden ser llamadas tal vez como mantenciones.

Surge temor a cambios, por lo tanto uno tiene que hacer ver a los usuarios que es un bien para ellos ese cambio.

¿Qué rol juega la ética?

Es uno de los principales ítem con lo cual nosotros contamos, nuestra honorabilidad debe ser impecable, debido a eso llevamos tanto tiempo en esta empresa.

Entrevista Nº3

2007-11-07T12:03:00.000-08:00

Nombre: Daniel Aravena.

Titulo: Analista en Sistemas.

Años de Experiencia en Toma de Requisitos: 20 Años.

Trabajo: Jefe Area Informatica I. Municipalidad Estación Central.

e-mail: danielaravena@estacioncentral.cl

Escuchar entrevista

¿Cómo es el proceso de la toma de requerimientos de un Sistema Informático?

Primero reunirse hay que reunirse con el dueño de la información, entrevista con el usuario, realizar el workflow e interiorizarse con el problema. Pasar todo lo que dice el usuario a nemotécnico.

¿De qué manera o como participa el Informático a cargo de este proceso en él?

Primero debe conocer como piensa el usuario, dueño de la información. Ver el problema que les aqueja y ver a que tipo de problemas pertenece. Analizar el problema.

¿En qué tipo de empresa trabaja?

Empresa pública. Pero he trabajado en bancos, en la parte de desarrollo, como analista. Después trabajé en forma independiente.

¿En la empresa que se desempeña (ó) se seguía alguna metodología especial para crear un sistema informático? ¿Podría hablarnos acerca de ella?

La creé yo. Primero la reunión con el usuario para detectar el problema, luego, detectar el tipo de problema. Las metodologías de la teoría son buenas pero, en la realidad, se lleva a la práctica un 60% aproximadamente.

¿Cuál es su rol en el proceso de toma de requerimientos?

Abarco casi todo. Hace un año hacíamos el proceso completo pero ahora externalizamos el proceso

¿Se realiza un estudio de factibilidad para verificar si el sistema contribuye a los objetivos del negocio? ¿Cómo se realiza este proceso?

Los estudios de factibilidad se tienen que hacer para todo no solo en el campo de la informática. En mi caso los proyectos se aprueban de un año para otro debido a la asignación de recursos, por lo que realizar proyectos en muy dificultoso y requiere mucha planificación.

¿Qué acciones concretas realiza usted para extraer todo el conocimiento a los usuarios y a la organización para la cual esta diseñando un Sistema Informático?

La primera acción es observar. Anotar las deficiencias detectadas. Preguntar detalles no técnicos del funcionamiento del proceso. Dedicar un 60-70% al análisis y el resto al desarrollo.

Observando el proceso, interiorizarse en él, ver el workflow, buscar por otras fuentes, cerrar el círculo.

¿Cómo soluciona el conflicto de puntos de interés entre los involucrados en el proceso?

Comunicación, conectividad. Importan resultados totales. Debe haber una cabeza que dirija de acuerdo a objetivos principales, que se han desarrollado en el estudio de factibilidad. La experiencia influye mucho para el proceso en general.

¿Cómo considera la habilidad comunicativa, la inteligencia emocional y la capacidad de adaptación para el proceso?

Son fundamentales para desarrollar el proyecto. Sin comunicación no se puede realizar. Se requiere adaptación durante el desarrollo, los demás no se adaptan a uno.

¿Qué rol juega la ética?

Un rol importantísimo. Permite valorar a las personas y su trabajo.

Entrevista Nº2

2007-11-06T17:31:00.000-08:00

Nombre: Rodrigo Gálvez.

Titulo: Ingeniero Civil en Informática.

Años de Experiencia en Toma de Requisitos: 7 Años.

Trabajo: consultora Polo Sur (esta hace tres años realizando trabajos en D&S, por parte de Polo Sur).

e-mail: rodrigo.galvez@polosur.cl

Nombre: Juan Pablo Castro.

Titulo: Ingeniero Ejecución Informática.

Años de Experiencia en Toma de Requisitos: 7 Años.

Trabajo: consultora Polo Sur (esta hace tres años realizando trabajos en D&S, por parte de Polo Sur).

Escuchar Entrevista

Se agradece a Felipe Bustamante y Francisco Pavez por facilitarnos las fotos de estos dos ingenieros (Grupo 2 CHT).

¿Cómo es el proceso de la toma de requerimientos de un Sistema Informático?

En la universidad siempre se decía que hay que seguir un procedimiento, había que hacer documentos, como OMT++, que creo era súper buena, pero al momento de entrar a trabajar no se ve nada de eso. Acá existe un procedimiento, cada empresa sigue uno a su manera. (Contestado por Rodrigo)

¿Qué rol ha tenido en cada empresa que ha estado?

Consultor de SAP, dentro de esto soy desarrollador, mi rol básicamente es recibir requerimientos y programarlos, o capturar yo mismo los requerimientos y programarlos.

Cada empresa sigue sus procedimientos a través de alguna norma, tal vez una norma de auditoria, no siempre de una norma de ingeniería. (Contestado por Rodrigo)

¿Ha trabajado siempre en empresas grandes?

Si, yo pertenezco a Polo Sur (consultora externa), a nosotros nos mandan a empresas, las cuales siempre me ha tocado que sean grandes (Contestado por Rodrigo)

¿Los roles de estas empresas son bien especificados?

En empresas grandes siempre van a tener recursos para tener gente que ocupe las funciones que correspondan, al contrario de las empresas medianas y chicas que no tienen los recursos necesarios para tener mucha gente. Existen empresas que contratan consultoras externas, como en el caso de nosotros que realizamos esos servicios.

En la universidad enseñan teoría, en donde se tienen que seguir ciertos pasos, pero cada empresa tiene su estilo. Cuando uno es consulto externo, se da el caso que también tenga que ejercer roles además del que corresponde, el cual es desarrollar. (Contestado por Juan Pablo)

¿Tienen que haber distintos roles para realizar un Sistema Informático?

No existen roles específicos, en teoría debería ser así, pero el rol es un poco distribuido, a veces los requisitos los tomo yo, o en otras ocasiones lo toma otra persona, depende de las necesidades. Depende de si la persona es experta en alguna situación, puede hacerse cargo de ella, no necesariamente necesita tener un cargo especial para ejecutar esa tarea. (Contestado por Rodrigo Gálvez)

¿Existe un lenguaje especial para comunicarse con el usuario, una forma particular en como abordarlo para capturar los requisitos?

Si hay un lenguaje, pero hay una experiencia que sirve para esto. (Contestado por Rodrigo Gálvez)

A veces cuando se requiere un sistema en forma rápida, no hay tiempo para realizar una especificación de requerimientos (documentación). Ocurre muchas veces que primero se realiza el sistema, y luego se lleva a cabo la documentación, netamente por el tiempo. Si hubiera, tal vez, una buena especificación de requerimientos, no existirían a lo mejor problemas en el desarrollo. (Contestado por Juan Pablo)

¿En la empresa que se desempeña se sigue alguna metodología especial para crear un sistema informático? ¿Podría hablarnos acerca de ella?

Nos basamos en la norma SOX (se adjunta la documentación acerca de la norma), nosotros tenemos que emitir varios documentos durante el desarrollo, tiene que emitirse una solicitud de requerimiento (se adjunta documento) con el cual se empieza el proceso. (Contestado por Rodrigo)

¿Se realiza un estudio de factibilidad para verificar si el sistema contribuye a los objetivos del negocio? ¿Cómo se realiza este proceso?

Si se realiza, se verifica si se puede llevar a cabo un sistema en un tiempo determinado. Se tiene que evaluar si es costoso el sistema. (Contestado por Rodrigo)

Si no es factible realizar un sistema, ¿se desecha?

No, surgen alternativas, generalmente el requerimiento no es desechable. Existen requerimientos que son muy necesarios (como las restricciones legales), en donde pueden surgir alternativas. (Contestado por Rodrigo)

¿Qué acciones concretas realiza usted para extraer todo el conocimiento a los usuarios y a la organización para la cual esta diseñando un Sistema Informático?

La forma de abordar al usuario lo da la experiencia, si uno se queda con la primera cosa que dice el usuario, al final a medida que se realiza el proyecto van a surgir muchos problemas, al no encajar ciertas cosas con este. (Contestado por Juan Pablo)

¿Cómo usted determina los puntos de interés del usuario?

Viendo que es lo que hace y que es lo que necesita fundamentalmente (contestado por Juan Pablo)

(El jefe de proyecto emite las solicitudes que se captan de los usuarios.)

¿Existe un contacto permanente con el usuario durante el proceso de desarrollo?

No directamente con el usuario final, porque existen muchas sucursales por todo Chile, en donde estas están repartidas por todo el país (DyS), existe un intermediario, al que se le llama KeyUser, que también se le denomina usuario funcional. Existen por lo tanto tres tipos de roles en el desarrollo, los desarrolladores (nosotros), los KeyUser que entienden del manejo del negocio (la lógica del negocio), y los configuradotes que participa en ciertas partes del proyecto. (Contestado por Rodrigo)

¿Los roles están bien enlazados, se complementan bien?

Si, pero los roles tal vez no se determinan por personas, ya que las personas pueden ejercer varios roles. (Contestado por Rodrigo)

A veces con la experiencia, no es necesario preguntar ciertas cosas al funcional, uno como desarrollador ya va manejando ciertas cosas. (Contestado por Juan Pablo)

Algo que afecta mucho en la toma de requerimientos es el usuario final que se tenga, tal vez este tenga miedo ante algún cambio, ya que si le cambian el sistema que ya maneja, por alguno que tal vez le cueste acostumbrarse, puede ser que piense que lo van a echar. Debido a esto, el no va a querer entregar toda la información necesaria, quizás el va a querer que más se demoren en terminar el sistema. Entonces uno tiene que hacerles entender que si ellos aportan, y a medida que vayan aprendiendo a usar el sistema, se van a dar cuenta que son una pieza importante para la empresa. (Contestado por Juan Pablo)

Existe una resistencia al cambio, tal vez en forma natural o por miedo. (Contestado por Rodrigo)

Uno tiene que exigir una cierta disponibilidad para tomar los requerimientos al usuario, pasa que el usuario se dedica a hacer todas sus cosas, en donde si le llega a quedar un tiempo libre ayuda. En resumen si se asigna en un 100% a la persona que es usuario, en ayudar en la toma de requerimiento va a resultar un buen sistema. Tal vez el usuario, además, tenga que tener horas extras para ayudar en la toma de requisitos, va a tener que venir los Sábados, va a estar cansada, y quizás sea la persona clave en el levantamiento del sistema informático. (Contestado por Juan Pablo)

Hay que guiarlos, ayudarlos. (Contestado por Juan Pablo)

Tal vez el usuario sabe lo que quiere, pero no sabe expresarlo, por lo tanto es deber del informático guiarlo y enseñarle las posibles soluciones, en donde se debe llegar a un punto en común. (Contestado por Rodrigo).

¿Si existen distintos puntos de vista, como se llega a un consenso?

Se llega a un consenso, al fin y al cabo, todos quieren llegar a lo mismo. (Contestado por Juan Pablo.

¿Siempre le dicen “si” al cliente?

No, depende de la situación.

¿Cómo se enfrenta a la situación de que el cliente crea que maneja todos los detalles técnicos acerca de su área?

No hay tanto problema en eso, todo se lleva a términos de uno, uno directamente pregunta. (Contestado por Juan Pablo)

Hubo un seminario que se llamaba Reactiva `97. Un presentador hizo una pregunta parecida, “¿Cómo nos enteramos de las necesidades de un cliente?” Le conteste, “bueno se le pregunta como funciona su proceso”. El responde, “claro pero al cliente no le interesa como funciona su proceso, porque el sabe como funciona”.

Es decir, si yo no se como funciona el proceso, tengo que averiguarlo, tal vez, no sea directamente con el usuario. Me ha tocado clientes, en donde por ejemplo me dicen: “hay que modificar esto”. Y yo le pregunté “¿En donde se realiza esa modificación?”, yo estaba enterado que la persona sabía, pero me dijo: “no se, tu eres el desarrollador”. Fui a hablar con el líder de desarrollo, que incentiva a realizar ciertas cosas en el proyecto, al contrario del jefe de proyecto, que solo lleva un control de la Carta Gantt, al cual le conté la situación. El fue a hablar con el usuario, pero pasó lo mismo, fue una larga discusión, al final mostró la pantalla, me aprendí el proceso de memoria y fui a trabajar en el desarrollo. Yo sé programar, pero no se lo que usuario quiere hacer.

En lo antes mencionado, se ve que hay un problema de organización, que rara vez se da, en donde siempre se da el problema con la misma persona, por lo tanto, hay que acudir a otra persona, ya que siempre hay muchas personas que manejen un tema en especial. Si no me entiendo con una persona, voy por otro camino. (Contestado por Rodrigo)

¿Y si la persona conflictiva, es la única que maneja un tema en especifico?

Ahí existe un problema, es una mala práctica, no debería ser así. Tal vez no pase por el hecho de que la persona no quiera cooperar, tal vez se encuentre de viaje.

En Sony me pasó que realicé un sistema, pero el cliente me dijo está malo, le dije no de acuerdo a los requerimientos que capturé. Aquí hubo un problema de entendimiento, por lo tanto esa persona fue expulsada del proyecto. (Contestada por Rodrigo)

¿Afecta la toma de requerimientos a un sistema?

Sin duda, he visto en otras empresas, programas súper parchados, justamente por un mal levantamiento de requerimientos. (Contestada por Juan Pablo)

Pasa a veces que uno no entiende la jerga de un cliente, debido a la cultura (tanto social o de nacionalidad), uno debe pedir ayuda, ya que existe un problema de comunicación. (Contestada por Juan Pablo)

¿Qué rol juega la ética en su trabajo?

Es muy importante, si me piden hacer algo en contra de mi ética, no lo hago simplemente aunque me cueste el puesto.

Aunque manejamos información confidencial, tenemos ciertas restricciones, y además nosotros vemos todo los datos como “un simple String”, sólo pasa la información. Tal vez hay gente que no le interese divulgar información, o ocupa la información para su propio bienestar, pero obviamente eso constituye un delito.

En cualquier momento te pueden pedir algo que va en contra de tu ética. (Contestada por Rodrigo y Juan Pablo)

En resumen, ¿Cuáles son los pasos necesarios para una buena toma de requerimientos?

Como comentario final, se debe mantener un método a través del tiempo, no es bueno como practica, y a veces en forma legal, cambiar un método.

Como manual para tomar requerimientos, es como primera cosa el tener un método, regido por alguna norma. Siempre documentar documentar las cosas y hacer un manual de uso.

Para ver como enfrentarse al cliente, lo da la experiencia, pero aún así es una pregunta muy difícil. A veces uno pregunta cualquier lesera, uno creyendo que es sensato. Hay que preguntar todo lo que uno no conozca, pero con la mayor sensatez posible, cosa que uno crea que sirva para el sistema debe preguntarlo. (Contestada por Rodrigo y Juan Pablo)

Entrevista Nº1

2007-11-06T15:43:00.000-08:00

Nombre: Ana María Soto.

Titulo: Ingeniero Ejecución en Informática.

Años de Experiencia en Toma de Requisitos: 2 Años.

Trabajo: actualmente Profesora Inacap (se desempeño como jefe proyectos Plus Consulting).

e-mail:

Escuchar Entrevista

¿Cómo es el proceso de toma de requerimientos de un Sistema Informático?

Primero se entrevista al cliente, si es informática interna en la empresa se van apagando incendios. El analista se encarga de tomar los requerimientos. La base para tomar requerimientos es mediante entrevistas y encuestas. Es importante que la persona que tome los requerimientos vaya informada del tema, tiene que tener conocimientos (si es un desarrollo a terceros) acerca del mercado en que se maneja el usuario, el rubro de la empresa, hay que realizar un marco contextual acerca del usuario. Si se desea crear un software estándar hay que realizar un análisis acerca del entorno.

¿De qué manera participa el informático a cargo de este proceso en él?

El jefe de proyecto se debe hacer cargo de este proceso en forma activa. En el caso de la empresa que me desempeñé, debido a que era una empresa pequeña, en donde era jefe de proyecto, realizaba de todo, desde realizar entrevistas para tomar requisitos, pasando por el desarrollo de los programas, hasta dirigir proyectos.

¿En qué empresa se desempeñó?

Plus Consulting, empresa de cobranzas, que tiene como clientes a empresas como Cencosud. Trabajé en informática interna.

¿En la empresa que se desempeña (ó) se seguía alguna metodología especial para crear un sistema informático? ¿Podría hablarnos acerca de ella?

No se sigue una metodología específica, el que sigue el desarrollo usa su propia metodología, debido a que se requieren las cosas en poco tiempo, pero se podría decir que usamos prototipado evolutivo, en donde se presenta un avance, y de ahí se sigue, es lo que más se usa, debido a que el usuario pide soluciones inmediatas.

¿Cuál es su rol en el proceso de toma de requerimientos?

La empresa el área informática estaba dividida en soporte y desarrollo, había 4 personas en soporte y yo solamente estaba en desarrollo, estaba a cargo en realidad de las dos áreas. Se restringía a veces los permisos para realizar ciertas cosas, por lo que retrasaba el desarrollo de sistemas.

Mi rol especifico, por el cual me contrataron en un comienzo era para sacar informes de un sistema por medio día. Empecé a proponer proyectos los cuales me aceptaron y llegué a ser jefe proyectos.

¿Se realiza un estudio de factibilidad para verificar si el sistema contribuye a los objetivos del negocio? ¿Cómo se realiza este proceso?

Ninguno, no se trabaja tampoco en grandes proyectos. Otra cosa es que rara vez terminábamos los sistemas en el tiempo que se había establecido.

¿Qué acciones concretas realiza usted para extraer todo el conocimiento a los usuarios y a la organización para la cual esta diseñando un Sistema Informático?

Encuestas y Entrevistas, y tal vez una investigación previa, el analista se encarga de eso, aunque yo también jugaba ese rol por así decirlo.

Hay una tendencia, que cuando uno no tiene mucha experiencia, soluciona lo que quiere solucionar. Uno trata de analizar lo que quiere el cliente, pero uno trae como una idea previa. Con la experiencia uno se va dando cuenta lo quiere realmente el negocio. Hay que estudiar mucho, uno debe aprender acerca de los negocios a los cuales va a realizar un sistema.

¿Se realiza una división entre especificación de los requerimientos, es decir, se realiza una distinción de requerimientos en que se señalen servicios, requerimientos que detallen servicios y sirvan para contrato, y requerimientos que sirvan para el desarrollo?

¿O alguna otra división de requerimientos que ayude a entender a los diferentes tipos lectores de los requerimientos, a los cuales le corresponde intervenir en el desarrollo de este?

Todo depende del negocio del cliente, esto no se pone en práctica, nunca hay tiempo para esto. Generalmente se pregunta al cliente que quiere y se comienza a programar. Creo que falta gente que sepa trabajar con los tiempos, gente que logre eso va a ganar mucha plata. En la teoría se logra eso, pero en la práctica es muy diferente. Tal vez cuando uno es nuevo le complica este cambio. Hay muy poca gente que esta dispuesta a invertir en investigación.

¿Al cliente le importa la calidad, o solamente que cumpla el sistema con su objetivo?

Al cliente le gustan las pantallitas bonitas, los botoncitos. En la marcha blanca va todo bien con el sistema, pero con el tiempo cuando empiezan a requerir otras cosas, tal vez se dan cuenta que se debería haber invertido más tiempo en determinar todas las funcionalidades que se requerían del sistema.

¿Existe una buena interacción con el cliente o es la falta de tiempo?

El problema es que uno le dice si, si, si, a todo. No sabemos poner los límites, los contratos son mal hechos, existen muchos tratos de palabra. No se si falta una buena interacción, pero es como cuando el profesor está en la clase y uno esta si, si, si, todo el rato, y si el profesor pregunta lo mismo que había explicado recién uno no es capaz de responderle porque no proceso bien. Uno quiere ganar plata también, entonces si uno le pone muchas trabas, existe una competencia enorme a donde ir.

¿Cómo detallaban los documentos de requerimientos?

No existe una formalidad, no hay un sistema estándar, se usa casos de uso, UML, etc.

¿Qué pasa si existe ambigüedad en los documentos de requerimientos?

La gente no entiende, uno le muestra un diagrama y los pares no entiendes lo que quiere expresar, no se si esta mal hecho el diagrama o es que solo los clientes quieren ver una pantalla nada más. Separaba los requerimientos en funcionales, no funcionales, en módulos, y se los hacia llegar a los desarrolladores.

¿Usa alguna herramientas CASE para apoyarse en el trabajo de toma de requerimientos?

Power Designer, Process Analysis, Data Architect, sirve mucho sobre todo para hacer base de datos. La gente diagrama cualquier cosa, el que lleve el proyecto es el que decide como llevar a cabo este proyecto.

¿Cómo definiría su habilidad comunicativa, su inteligencia emocional y su capacidad de adaptación?

Tengo la habilidad pero tengo un defecto, conduzco a la gente a donde quiere, no soy objetiva. La habilidad comunicativa es vital, pero el informático no tiene esa habilidad.