Competencias del ICI en la Toma de Requisitos

Bienvenida

2007-11-19T00:04:00.000-03:00

Damos la bienvenida a todos aquellos compañeros que ingresen al Blog de nuestro proyecto del Ramo CHT del Departamento de Ingeniería en Informática de la USACH.

Atte.

Isaias González
Alejandro Truan

Visita nuestro Manual de Buenas Prácticas.

Deja tus comentarios y criticas.

Entrevista a Edgardo Sepulveda

2007-11-16T18:50:00.000-03:00

Edagardo Sepulveda es academico de la Universidad de Santiago de Chile y a desempeñado diversos roles en distintas empresas informaticas a lo largo de su carrera

¿Qué importancia le asigna usted a la forma en que se toman requerimientos?

en el desarrollo de proyectos informáticos no podría decir que hay una fase mas importante que otra, por ejemplo decir que la toma de requerimientos no es tan importante como el diseño, eso no es así, son todas etapas complementarias y que no pueden dejar de hacerse, siempre considerando que el nivel de profundidad al que puedo llegar dependerá del conocimiento que tenga del problema y de su envergadura, me explico, podría encontrarme ante un problema pequeño que no posea tantos requisitos y que ya domino, por lo tanto la toma de requisitos no es tan fundamental, por otro lado, existen situaciones muy complejas, por ejemplo transantiago, primero debemos interiorizarnos en este gran problema y afinar los requerimientos tomaría mucho tiempo, aquí la toma de requerimientos se hace fundamental, pero no disminuye la importancia de las otras fases.

Durante su experiencia ¿Que errores ha cometido durante la toma de requerimientos?

Buena pregunta, a veces uno subestima a los usuarios, uno cree que los usuario no saben del tema y saben, otro error que se comete es entrevistar a usuarios que no son los que toman realmente las decisiones o no saben realmente del tema, a veces el usuario que mas habla y que mas comenta en las reuniones y uno se reúne con el, pues piensa que es el que mas sabe, no es el que realmente entrega los requerimientos de mejor manera, quizás es el que mejor se “vende” pero no conoce tanto del tema.

Otra cosa que no se si es necesariamente una falla, pero a veces uno trata ante cualquier situación o sistema nuevo, asemejarlo a sistemas existente, esto esta mal, pues en el caso de los informáticos, los paradigmas son tan dinámicos que uno debe tener la capacidad de asumir nuevos escenarios, nuevas características.

A veces los artefactos que uno utiliza, como un modelo de datos o un diagrama de clases son muy técnicos, por ejemplo si le muestro a un usuario un diagrama de secuencia, que es muy “computin”, pues uno esta acostumbrado a hablar de los bits y los bytes y a lo mejor el usuario no entiende nada, la idea es acercarse mas al lenguaje del cliente y no producir esa barrera que se produce entre el usuario y el informático que va trabando la comunicación. Otro error que es muy común, que he tratado de evitarlo por las practicas que tengo en este tema es la documentación, es decir, he visto muchas veces que se va a entrevistas con los usuarios y no se documenta, me refiero a que durante las entrevistas se debe, anotar, anotar, anotar y anotar, terminada la entrevista realizar un resumen formalizado y consultar con el usuario de forma de crear un consenso, para no olvidar lo que se hablo y evitar que el producto final no sea lo que el usuario final esperaba.

Un error que cometo, o mas que un error, una característica no adecuada, es que soy, por llamarlo de una forma, muy “autista” para el desarrollo, me refiero a que voy a hablar con el usuario, recorro todas las vistas del negocio, pero no uso interlocutores para conversar las decisiones que tomo, esto podría significar una situación problemática, esto me pasa pues soy mas productivo trabajando solo que con un equipo de trabajo, pero esto es ya un problema de índole personal.

¿Qué recomendaciones daría a una persona que recién esta comenzando para tomar buenos requerimientos?

Primero, que no empiece sola, que parta con un equipo y ve como lo realiza el jefe de proyectos y su equipo, en primera instancia uno debe acompañar a los que saben del tema. Otra cosa que se podría recomendar es tener siempre una visión mental de lo que se quiere conseguir, por ejemplo, al realizar una entrevista pensar que espero de esa entrevista, plantearse ¿necesito la lista de requisitos? , no, primero debo establecer una comunicación con el cliente, hacerme “amigo” del usuario, dialogar cosas generales primero, para luego en una segunda o tercera entrevista, empezar a extraer los requisitos finamente, no deben esperar que en la primera reunión salga todo inmediatamente. Una recomendación general que le daría a todos los informáticos, es no pensar nunca en el programa computacional, en la plataforma, las comunicaciones, en la base de datos, piensen en los procesos de negocios, es lo primero que se debe captar, pues el usuario no habla en términos computacionales, como Web, cliente servidor, java, etc. El usuario habla de su proceso de negocio, donde el recibe los pedidos de los clientes, productos, servicios, etc. Y es eso lo que debo entender primero, luego recién puedo aterrizar eso, pero si parto pensando en la plataforma computacional, me olvido del problema real.

para descargar el audio de esta entrevista, presione el siguiente link: bajar entrevista

Entrevista Luis Berrios

2007-11-16T11:52:00.000-03:00

Entrevista Proporcionada por el Grupo de Castro - Nuñez, para ver el original presione aqui

1. Identificación del problema 1.1 ¿Cuáles son los principales problemas que posee el proceso y de dónde provienen dichos problemas?

Uno de los problemas que hay, propios del levantamiento de requerimientos, es que si bien existe un lenguaje estándar que es para hacer este proceso, UML, el usuario, por lo general, no sabe ocuparlo y aún así, aunque el analista pueda hacer un levantamiento de requerimientos y plasmar los requerimientos funcionales y no funcionales del usuario, al llevarlo a UML a veces se olvidan cosas o hay cosas que no son claras como para redactarlas en un párrafo o en una serie de puntos que describan el sistema que va a desarrollarse.

1.2 ¿De qué forma afectan a usted y al proceso de captura de requerimientos dichos problemas?

Uno de los grandes problemas, cuando se llevan los requerimientos a desarrollar el sistema, es saber si se está haciendo lo que quiere el cliente. Para evitar eso, se desarrollan prototipos funcionales y se muestran antes de mostrar la implementación al final. Si no que se muestran estos prototipos funcionales para saber con anticipación si se esta haciendo lo que el cliente quiere, o no.

2. Definición de actores sociales 2.1 ¿Cuáles son los actores (personas/unidad) fundamentales en el funcionamiento del proceso de captura de requerimientos?

El director de orquesta del proceso es el arquitecto de diseño o de dominio, quien es la persona que define los procesos para el levantamiento de requerimientos y después llevar esos requerimientos al equipo de desarrollo para plasmarlo en el sistema que se quiere desarrollar. Por otro lado el tiene que estar monitoreando cómo los analistas de negocios están interviniendo con los usuarios y si el levantamiento de requerimientos es el adecuado o no.

Los otros actores, los analistas de negocios, son las personas encargadas de interactuar con el cliente para recabar cuales son los aspectos que éste espera que contemple el sistema. Esto tiene que ver con la funcionalidad y lo que espera el cliente.

Por otro lado están los analistas funcionales, que son los que, entre comillas, dominan el módulo de la aplicación y que son los que interactúan con el desarrollador, para que el desarrollador, en vez de ir con el cliente, interactúe con ese analista para saber qué es lo que necesita el cliente.
2.2 ¿Quién o Quiénes regulan el proceso de captura de requerimientos y su actividad?

Como te decía en el punto anterior, el que regula realmente el proceso de levantamiento de requerimientos es el arquitecto de dominio o el arquitecto general del proyecto. No obstante, también hay un ente que regula el proyecto, que sería el jefe de proyecto. Y si el proyecto es lo suficientemente grande en tiempo y dinero, incluso existe hasta un gerente de proyecto. No obstante, cuando existe este gerente, éste no regula lo que es el proceso de levantamiento de requerimientos. Pero el jefe de proyectos sí lo puede hacer, ya que él es el que se encarga de revisar a nivel macro tanto lo que es el levantamiento de requerimientos, como el proceso de desarrollo y los procesos posteriores como es soporte o el paso del sistema a producción.
2.3 ¿Quién o Quienes son sus clientes?

El trabajo anterior donde estaba yo, era ING. Ese era un caso particular en el desarrollo de software, pues el cliente era una persona miembro de ING, que se le llama sponsor. El sponsor es una persona que solicita una cantidad de dinero para desarrollar sistemas informáticos, para que funcionen de mejor forma o para apoyar procesos nuevos dentro de la compañía. Ese es un caso particular. Pero por lo general, los clientes son empresas o personas naturales externas. En este ultimo caso, en mi trabajo, nuestros clientes son empresas mineras y petroleras en general.
3. Rich Picture 3.1 ¿Cree que el proceso es burocrático o expedito?

Mientras más grande es la empresa de desarrollo de software, siempre es más burocrático. Por ejemplo en ING, como estaban con el modelo CMMI, estaba todo demasiado definido y estructurado. Por ejemplo, desde que tu terminas de producir un cierto componente o módulo del sistema hasta que los analistas de calidad, que son los QA (el analista de calidad es el que mediante una serie de pruebas revisa si lo que tu produjiste es lo que quería el cliente o no). Bueno, la iteración entre que tú desarrollas y pasas a QA, que es el ambiente donde se hacen las pruebas funcionales a tu sistema, a veces se hacía muy tedioso. Podían estar desde una semana hasta un mes.

Por otro lado, desde que tú tienes una duda como desarrollador, para pasársela al analista funcional y que este a su vez se la transmitiera el cliente y que retornara la respuesta, podía demorar hasta dos semanas, dentro de mi experiencia, por eso a veces es muy tedioso. Mientras que en empresas chicas, el desarrollador puede ser el mismo analista funcional e ir a preguntar directamente al cliente. El problema es que no hay una persona que se abstraiga de lo que es el desarrollo y otra del levantamiento de requerimientos.

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

Yo era analista de sistema y desarrollador. A nosotros nos llegaban los requerimientos a través del analista funcional, que era el encargado de desarrollar el caso de uso, para que tú lo desarrollaras. Entonces mi relación se basaba entre mi team líder, que es la persona que manejaba el equipo de desarrollo, y el analista funcional. Una vez al mes se hacían reuniones con el analista de planificación, que era la persona que básicamente se encargaba del cumplimiento de las cartas Gantt y cada tres meses, con el jefe de proyecto que era donde se ponían todas las cartas sobre la mesa y se comentaban los problemas que habían ocurrido en el pasado.

3.3 ¿Realiza labores no asociadas con el trabajo propio del proceso de captura de requerimientos?

Te voy a nombrar los roles que tuve en mi antiguo cargo:

Uno de ellos era analista de impacto, que cuando llegaban los requerimientos del cliente, en caso de realizar soporte a una aplicación o modificación a una aplicación, tenias que ver cómo iba a impactar lo que estaba pidiendo el cliente en lo que ya había hecho. Entonces tú tenías que ver en los modelos de datos, el código de las aplicaciones hechas, y ver si lo que estaba pidiendo era posible o no de hacerlo y cuanto iba a demorar. Entonces ahí también venia una especie de planificación donde tu tenias que dar una estimación de cuanto iba a demorar. Después, venía un tiempo de desarrollo y un tiempo de testing, que si bien ya había un equipo encargado de hacer testing, el equipo de QA, nosotros también hacíamos pruebas funcionales para tratar reducir los tiempos de iteración entre nosotros y el equipo de QA. Pero básicamente los roles que tenía siempre estaban dentro de mis funciones.

3.4 ¿Existen problemas que tengan que ver con contradicciones, poca claridad en los requerimientos o desconocimiento de los mismos?

Te voy a decir un caso bien puntual. El problema que hay ahora con las empresas informáticas es que como muchas están trabajando con recursos out sourcing, por ejemplo, si bien la persona de ese proyecto de ING, era sponsor de ese proyecto y era gerente del área comercial. Él debería saber todo lo que eran las condiciones de negocio o las reglas de negocio, por ejemplo cuando dar crédito a una persona. Pero como ella, supongo yo que no sabía, delegaba toda esa responsabilidad de sabiduría o conocimiento a personas externas que tampoco lo sabían. Entonces eso hacía que cuando llegaban los requerimientos al analista funcional, estos eran poco claros y aún así como algo natural, quizás, cuando se pasan las cosas de una persona a otra, se va perdiendo información.

4. Sistemas sociales y políticos 4.1 ¿Cuál es su rol dentro del proceso?

Se respondió en la pregunta N° 3.3

4.2 ¿Qué es lo que debe resaltarse positivamente del servicio que usted entrega?

Si bien, en ING había demasiada burocracia. La misma burocracia permitía ordenar el trabajo, otorgar responsabilidades cosa de que si una persona o proyecto “X” tenía alguna disfunción, tú ya sabías a quien recurrir. O si tenías algún problema de cualquier índole, estaba todo bien documentado, entonces tu ya sabes quien era el responsable y habían los mecanismos necesarios para reportar los errores o saber escalar y a quién escalar si es que esa persona no podía responder por cualquier motivo.

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

En el caso de ING, el reglamento lo daba directamente la casa matriz, que reside en estados unidos. Son las personas que envían todo lo que son los procedimientos básicos de la empresa y en caso de nosotros como informáticos, el departamento de arquitectura de ING en estados unidos, son los que envían los documentos a ING Chile para normar los roles y funciones de cada persona y acá en Chile lo que hace el arquitecto es velar por que esas normas se cumplan.
5. CATWOE, HAS 5.1 ¿Cuáles serían las mejoras que realizaría para mejorar el funcionamiento del proceso? y ¿Por qué éstas no se han realizado?

Yo creo que a veces, como en ING se estaba trabajando directamente con un cliente que esta dentro de la empresa, más que saltar como católicamente que yo tenía que transmitirle a una persona y esa a otra y así sucesivamente, podría haber...

Entrevistador: ¿Reuniones grupales?

Entrevistado: Claro, reuniones grupales o la posibilidad de consultar directamente a esa persona, porque son cosas tan pequeñas que te las pueden responder con una llamada telefónica o un email, pero que por la norma de la empresa, en este caso el modelo CMMI a veces no se puede, pues está contradiciendo a lo que te dice el modelo o la especificación de los roles.
5.2 ¿Quién o quienes poseen la atribución de modificar la operatividad del proceso de captura de requerimientos si lo desean?

En caso de ING, arquitectura, porque el jefe de proyecto no puede violar los procedimientos o políticas de una empresa. Pero el arquitecto sí lo puede hacer, o sea, mas que violarlo puede modificar el reglamento en forma excepcional para un proyecto si es requerido, pero ni el team líder ni el jefe de proyecto lo pueden hacer.

Descarga el Audio de la Entrevista

Extracto conversacion Sergio Astudillo

2007-11-13T04:10:00.000-03:00

Sergio Astudillo T.
Gerente general ATCOM
Sergio.astudillo@atcom-la.com

Desde su punto de vista, al hablar con ingenieros informáticos ¿Qué sensación le dejan sus capacidades de comunicación?

Que son insuficientes, en general, pero lo entiendo pues en la carrera nunca se nos enseña a los ingenieros en general a comunicar

¿Se nota demasiado la diferencia entre un recién egresado y una persona con experiencia?

no, no hay mucha diferencia entre una persona con mucha experiencia o con poca, mejora con el tiempo naturalmente pero no hay mucha diferencia, pese a eso los ingenieros informáticos se expresan muy bien, en términos de que expresan exactamente lo que están pensando y exactamente sus preguntas, pero eso, al resto de los seres humanos les es extraños pues los seres humanos son poco específicos, redundantes, la mayor parte de la gente no tiene claro exactamente lo que quiere, entonces enfrentados al tema de la ingeniería aplicada a las consultas obviamente hay un choque tremendo en que cuando no te especifican lo que quieren o la especificación es incompleta, o cuando se entra en los detalles de lo que la persona quiere le vas mostrando lo poco que sabe del tema y en ese sentido, las capacidades de comunicación de los ingenieros fallan, porque no importa que seas bueno o excelente, lo que importa es como el otro te percibe.

¿Cuál es su percepción de la habilidad del ingeniero para comprender el negocio?

Para modelar un negocio son súper buenos, pero para entenderlo, es distinto, pues los negocios tienen cosas que no están estructuradas y por lo tanto, no son capaces de ver otras cosas como emociones y sensaciones más que con la técnica.

¿Qué consejos le da como cliente a una persona que recién está empezando en la toma de requerimientos?

Yo le doy un consejo a mis alumnos que es que tomen un curso de teatro y para explicarles por que les pongo un ejemplo, les digo, muéstrenme que en la esquina hay un incendio pero sin decir nada, hazme saber que en la esquina se está quemando una casa, dímelo con señas, se les hace imposible o muy difícil, pues el lenguaje es la única manera que tenemos de comunicarnos y este lenguaje debe ser con expresión y tener vivo el sentimiento que es con el que funcionamos las personas, entonces el teatro te obliga primero a desinhibirte, pierdes la vergüenza a hablar y lo otro a lo que te obliga es a dominar el lenguaje, debes dominar el lenguaje pero en la expresión, les podría decir que tomaran un curso de oratoria, pero la idea es improvisar, pues normalmente las reuniones van de la mano con el desinhibirse

Usted se refiere al control de las emociones…

Claro, nunca hay que enojarse, entender que el hombre puede ser abogado y que para el todo es relativo, si es que estudio algo, el que no estudio nada quizás no tiene la noción suficiente y te dirá que se le olvido nomas, no tiene ninguna formación pero es tu usuario, entonces la emoción del enojo o mejor la idea de caerle bien para que te de mas información, es un tema que tiene que ver con la emoción más que con otra cosa. También es importante tu discurso, con la palabra que llegas, a la gente le gusta que la escuchen, pero también le gusta escucharte, ¿Qué hacen los ingenieros?, en general son callados, no les gusta hablar mucho, cualquier cosa que no sea números, le llaman cháchara, el problema es que casi todo el mundo le llama a eso expresión, por eso es bueno aprender a expresarte, por lo mismo te decía lo del teatro, pues te obliga a expresarte corporalmente a expresar un sentimiento que te dijeron que tenias que manejar y a perder la vergüenza que es una cosa muy importante

si desea descargar la entrevista en formato de audio, puede hacerlo desde el siguiente link: descargar entrevista Sergio Astudillo

Bienvenida

2007-11-12T01:56:00.001-03:00

Manual de Buenas Prácticas

2007-11-12T01:53:00.001-03:00

Desarrollando el problema con la metodología de Sistemas Blandos y estableciendo las relaciones entre los actores involucrados, proponemos el siguiente "Manual de Buenas Prácticas" que debe considerar todo Ingeniero Civil o Ejecución en Informático que se desenvuelva en la toma de requisitos en su lugar de trabajo.

1.- Siempre tener presente que la captura de requisitos es la etapa básica en el desarrollo de un proyecto, errores en ella pueden llevas a extensión en los plazos e incluso a cancelación del proyecto.

2.- Siempre escuchar al usuario, jamás imaginarse las soluciones o implementaciones mientras se conversa con el cliente.

3.- Hablar con el usuario en el idioma del negocio (si es necesario aprenderlo) y el idioma del cliente, evitar el uso de tecnicismos propios de los ingenieros.

4.- Evitar la confrontación con el clientes, "él siempre tiene la razón" dentro de los límites de aplicabilidad del proyecto.

5.- Documentar cada uno de los acuerdos que se logren en las reuniones con el cliente, ello permitirá tener respaldo sobre todo lo que el cliente pidió durante el proceso de captura.

6.- Considerando el punto anterior, ser capaz de visualizar el negocio más alla de lo que el cliente explique de él, muchos proyectos fracasan por la incapacidad del Ingeniero de visualizar los posibles problemas que puede presentar el proyecto.

7.- Si tus primeras experiencias capturando requisitos no son alentadoras, no decaigas, el aprendizaje y la experiencia hacen el mejor trabajo construyendo un buen capturado de requerimientos.

Esta es la v1.0 de nuestro Manual de las Buena Prácticas para un Ingeniero que se está iniciando en el mundo del desarrollo de proyectos informáticos.

Entrevista Patricia Yañez

2007-11-11T16:38:00.000-03:00

Patricia Yañez
Ejecutiva Marketing
Atcom Telecomunicaciones
pyanez@atcom-la.com
Cliente

Los ingenieros informáticos parecieran estar diseñados para solo comunicarse con informáticos, su idioma es demasiado técnico, hablan de cosas que muchas veces uno no les entiende y creen que si lo es.

Pese a ello y que uno como cliente no los entiende, generalmente ellos si entienden lo que uno intenta decirles. Por lo tanto logran desarrollar lo que uno les pide.

Que utilicen un lenguaje más simple, sobretodo cuando hablen con personas que no son ingenieros.

Descarga la entrevista

Metodología de Sistemas Blandos (SSM)

2007-11-09T02:18:00.000-03:00

La Soft System Methodology (SSM) consiste en una técnica cualitativa que permite trabajar con sistemas o procesos con un alto contenido social, humano y político. No así las metodologías llamadas duras que de encargan de problemas asociados generalmente a la tecnología.

El origen de la SSM radica en la ineficacia de las técnicas de estudio de sistemas duros en problemas organizacionales de gran envergadura, fue concebida por Peter Chekland , quien descubrió los problemas que presentaban las metodologías para tratar problemas de gran alcance social, en los años 60 y publicada en el año 1981.

Los pasos de la SSM se describen a continuación

Definición de subprocesos.

Se establecen los distintos sistemas que participan del problema, identificándose los de mayor relevancia y además presentando las opiniones de cada uno de ellos respecto a la problemática.

a) Rich Picture.

Representación gráfica del problema, donde se aprecian los distintos actores sociales de él, sus acuerdos y desacuerdos.

b) Definiciones raíces.

Consiste en crear una nueva entidad o visión a partir de una existente, es decir, dada una premisa X transformarla en una premisa X’ donde esta ultima sea una versión mejorada de X.

c) Sistemas sociales.

Es un grupo de personas con un propósito común pertenecientes a un sistema o proceso. Estas personas comparten un rol, normas y valores sobre la problemática.

d) Sistemas políticos.

Si los sistemas sociales presentan conflictos entre ellos se habla de sistemas políticos.

e) CATWOE

Cliente: quien recibe la transformación (beneficio/perjuicio)
Actores: quien realiza la transformación.
Transformación: transformar X en X’
Weltanschauung: punto de vista bajo el cual tiene sentido T.
Owners: quien puede detener la transformación si es necesario (jefe o encargado)
Entorno: medio ambiente o contexto (a veces legal) que enmarca el desarrollo de T.

f) Definición de raíz elaborada.

Un proceso o sistema que hace X mediante Y para obtener Z, donde X es la transformación a realizar, Y es el método utilizado para obtener o alcanzar el objetivo Z.

g) HAS

Es un modelo sistémico que permite entrelazar un conjunto de actividades del desarrollo de un propósito, su objetivo es implementar la definición raíz elegida.

h) Tabla comparativa.

Comparación del HAS con la realidad, para ello se contratan los detalles del modelo con las realidades expresadas por la personas que participan de la problemática.

Muchos autores proponen que no existe una secuencia definitiva para la aplicación de la SSM pero se recomienda seguir la presentada anteriormente.

Algunas fortalezas de la metodología de sistemas blandos de Chekland son las siguientes:

• Otorga una estructura a problemas complejos y permite tratarlos organizadamente. Fuerza al usuario a buscar alternativas o soluciones más allá de las técnicas.

• Herramienta rigurosa para utilizar en problemas “sucios”.

• Posee una estructura específica.

Algunas debilidades de la metodología de sistemas blandos se presentan a continuación:

• Requiere que los participantes se adapten al concepto.

• Se debe tener cuidado con no acotar demasiado pronto la investigación.

• En la etapa de Rich Picture debemos evitar plasmar soluciones particulares a la problemática, lo cual muchas veces es complejo.

• Es complicado muchas veces visualizar el mundo de manera distendida y tendemos a aplicar acciones instintivamente.

La metodología de sistemas blandos se basa en ciertos supuestos que se presentan a continuación.

• La mayoría de los problemas organizacionales y de gestión no deben ser considerados como problemas de sistemas porque los sistemas son iguales de difíciles de analizar.

• El acercamiento sistemático a una situación sistémica es siempre productivo.

Toma de requisitos

2007-11-08T19:15:00.001-03:00

A todo lo que engloba los principios, métodos, técnicas y herramientas que permiten mantener y documentar los requisitos para sistemas de software se le llama ingeniería de requisitos. Es importante detallar en que consiste esta área de la ingeniería de software para establecer la teoría del trabajo que realizaremos.

¿Qué son los requisitos?

Los requisitos son los efectos que se desean provocar en una maquina. Son las necesidades, las metas y objetivos de un programa o sistema. Estos requisitos se desprenden de las necesidades del cliente y del conocimiento del dominio (o negocio).

Como los requisitos son los objetivos o metas del software a crear, es de vital importancia que estos logren un estado óptimo antes de avanzar en las siguientes fases de desarrollo, los buenos requisitos se caracterizan por ser medibles, comprobables y libres de ambigüedades o contradicciones. Muchas personas consideran el hecho de establecer requisitos es un arte, entender las necesidades de una persona que muchas veces ni siquiera tiene claro lo que desea del sistema o programa es de gran dificultad y desarrollar metodologías estableciendo parámetros que ayuden al que realiza este rol se hace muy necesario.

Historia

Se reconoce esta área de la ingeniería de software como la parte borrosa del proceso pues consiste en formalizar ideas que en su inicio son informales. Antiguamente los requisitos no eran tomados demasiado en cuenta pues los sistemas y programas tenían bases estructuradas de lo que podían hacer y el cliente buscaba en el mercado la herramienta que se ajustara a sus necesidades, pues el desarrollo personalizado era extremadamente caro. Desde mediados de los 70 la ingeniería de requisitos adquirió relevancia pues los costos de desarrollo disminuyeron y las empresas entendieron la necesidad de sistemas a medida de sus necesidades, hasta llegar a nuestros días en que esta fase es considerada fundamental, sin embargo, no existe consenso entre los lenguajes, métodos y herramientas que se deben utilizar.

Importancia

Según Barry Bohem solo entre un 9% y un 12 % de la duración de un proyecto se utiliza en la ingeniería de requisitos, esto resulta a lo menos extraño pues es en esta fase donde ocurre la mayor cantidad de errores, los más costosos de reparar y que más tiempo consumen.

También afirma Bohem que el 10% de los errores ocurren en esta fase, estudios más actuales dicen que entre un 44% y un 80% ocurren durante la especificación de requisitos, estas cifras resultan alarmantes en el sentido del poco tiempo que se le dedica durante la creación de los proyectos. Otros datos que este autor entrega es son que reparar un error en la fase de codificación cuesta entre 5 y 10 veces más que si se hace durante la especificación de requisitos, esta cantidad aumenta mucho si ocurre durante la fase de mantenimiento llegando a ser entre 200 y 400 veces más costoso. Esto nos indica que mejorar la fase de requerimientos puede otorgar grandes beneficios.

Para una vision mas profunda de la toma de requerimientos, peude descargar el siguiente archivo: toma de requerimientos

Extracto conversacion con Isaías González

2007-11-08T18:43:00.001-03:00

Isaías Hernán González Berrios
Technology Project Manager
26 años de experiencia laboral

Isaías González lleva más de 26 años trabajando en desarrollo de software en distintas empresas, de la entrevista con el, destacamos las siguientes frases:

“Antiguamente, en mis tiempos, la injerencia del desarrollador o de las personas técnicas tenía más importancia, porque generalmente se le entregaba a los usuarios o clientes los requerimientos o ideas implícitos, pues el software estaba hecho, el cliente participaba muy poco de la funcionalidad, es decir, se vendían productos con todas sus funcionalidades hechas. Hoy día los usuarios participan mucho mas de las funcionalidades del sistema que requieren, los software son muncho mas personalizados, por lo tanto”

Con respecto a la importancia de la toma de requisitos:

“El desarrollo profesional es un proceso continuo, por lo tanto, uno siempre va a querer hacer las cosas mejor, con mayor empatía, intentando conocer mejor la problemática, mientras más se conoce el negocio y mas se conozca la empresa en la que uno trabaja va a tener mayor facilidad para poder entender cuál es la problemática que quiere solucionar el cliente.”

Con respecto al uso de metodologías:

“Porque si no es así, no tienes control, entonces el proyecto no sale nunca, lo que significa perdida de recursos humanos y monetarios saber si va mal estructurado y necesitas tomar acciones para poder corregir, por ejemplo, están los riesgos, todo proyecto los posee y tienen que esta explicados para todas las personas inmersas en el sistema, si se enferman los programadores, debes tener gente de backup para que pueda tomar la tarea inconclusa”

Descargar Entrevista Completa en formato *.doc

Descarga el audio de la entrevista

Extracto cuestionario Jorge Meynard

2007-11-08T11:14:00.000-03:00

Jorge Meynard Pontanilla
Jefe de Proyectos
ACB Ingeniería
4 años de experiencia
jmeynard@acbingenieria.cl

"La captura de requerimientos es importantisima, de su calidad depende el éxito o fracaso de un proyecto, permite establecer plazos, alcances y evaluar ecónomicamente el mismo"

Jorge indica que "prefiere clientes con conocimientos informáticos, ya que se logra el documento final de requisitos que debe ser firmado por todos los entes más rapidamente".

Además nos menciona que "la practica hace al maestro, considera tener una buena habilidad en la captura, pero cree que le falta mucho por aprender".

"Si un cliente, una vez firmado el documento de requisitos, desea agragar una funcionalidad, debe pagar por ello".

Jorge indica que siempre intenta colocarse en el lugar del cliente y pensando seimpre que este es "tonto".

"Como consejo, es necesario definir plazos y alcances en esta etapa, además verificar que el cliente posea tecnología necesaria para desarrollar el proyecto, ya que generalmente los clientes creen que se puede realizar todo frente a un computador".

Jorge cree que las instituciones deben enfatizar más en técnicas de interacción de personas, sobre todos los ingenieros informáticos ya que hasta el momento mucho de ellos se quedan conformes siendo buenos desarrolladores.

NOTA: Esta encuesta fue realizada mediante e-mail, ya que no fue posible juntarse a conversar con el encuestado.

Link de encuesta completa

Presione el ícono para descargar, el documento se encuentra comprimido.

Extracto conversación con Andrés Avila.

2007-11-07T00:44:00.001-03:00

Andrés Ávila
Gerente Informática ATCOM Telecomunicaciones.
Mas de 10 años de experiencia.
andres.avila@atcom-la.com

Durante la conversación con don Andrés Ávila, se pueden extraer las siguientes prémisas.

"el proceso de la toma de requisitos es básico en cualquier proyecto. Si el cliente rechaza el producto final, es porque el proceso se realizó de mala forma. Lo que finalmente se traduce en que el cliente no cancela y se producen pérdidas para la empresa".

"los errores siempre están presentes en el proceso de toma de requerimientos y si a ello se suman otros factores, los proyectos pueden fracasar".

"al egresar le costaba incluso llamar a los clientes, pero la experiencia logra borrar esas trabas, indica que muchas veces los encargados del area comercial temen que las ingenieros informáticos (más cercanos al area técnica) hablen con los clientes porque dicen cosas que no deberían"

"lo principal es reunirse con la persona que finalmente cancelará la creación del producto informático, el que finalmente paga".

"no se vuelve atrás cuando se logra una buena toma de requerimientos, ya que se documentan todos los acuerdos, don Andrés señala a modo de consejo, siempre documentar las conversaciones con los clientes".

"indica que es necesario visualizar más alla de los requerimientos, cosas que el cliente no toma en cuenta y sobre todo siempre escuchar al cliente, no imaginar la solución inmediatamente sino que llegar a acuerdos claros y documentados para recien comenzar a producir".

Algunas fotografías de ATCOM Telecomunicaciones y del lugar de trabajo del entrevistado.

NOTA: La fotos fueron tomadas con celular, debido a ello su calidad no es de las mejores.

Extracto de la conversación subido a sendspace.

Descargar Entervista