El Ingeniero informático en la captura de requisitos

Objetivos del Blog

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Wed, 29 Oct 2008 03:58:00 +0000

El objetivo de este blog es publicar un estudio de competencias y habilidades del ingeniero informático para la captura de requerimientos.

La importancia de su publicación recae en la gran posibilidad del enriquecimiento de las prácticas mediante los comentarios que otras personas pueden hacer entorno a este tema.

Consideramos este trabajo relevante ya que muchas veces al momento de realizar una captura de requerimientos, el ingeniero se enfrenta a clientes que no pueden dejar de utilizar el lenguaje propio del negocio, o que no muestran mayor interés en dar información relevante. Otras veces simplemente están estresados por su propia carga laboral y están de mal humor lo que entorpece el proceso. Adicionalmente el cliente es ambiguo, no sabe lo que desea (y no es su culpa, para eso están los ingenieros).

Siendo estos los problemas más frecuentes, hemos obtenido diversas recomendaciones, informaciones y detalles producto de las entrevistas que han servido como semilla para el desarrollo del trabajo que posteriormente ha utilizado la metodología de los sistemas blandos de Peter Checkland para el análisis de la información y obtención de resultados.

Entrevista, Cliente 2, Pilar Barra

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Thu, 15 Nov 2007 02:18:00 +0000

Pilar Barra, ingeniera en ejecución industrial, actualmente trabaja para la empresa Unilever Foods Chile Ltda como planificadora de producción en el área de planificación, hace ya 5 años. Los tipos de proyectos son referentes a optimización de recursos, medición de materias primas para elaborar productos como la mayonesa Hellmann’s.

1. ¿Qué valora del ingeniero informático entorno a este proceso (entrega de requerimientos)?

-Es destacable su dedicación
-Son respetuosos
-Los resultados de los proyectos son satisfactorios

2. ¿Qué crítica del ingeniero entorno a este proceso (entrega de requerimientos)?

-Entienden mal lo que se ha planteado
-Cuando se ven en problemas propios o no se satisface lo que piden, pierden fácilmente la paciencia
-No cumplen los tiempos asignados

3. ¿Reconoce usted, que a veces es ambiguo en especificar lo que desea, o no puede evitar utilizar un lenguaje propio de su ámbito el cual no es propio del ingeniero?

Es necesario que el ingeniero se informe y familiarice con el lenguaje que se utiliza en la empresa, es trabajo del ingeniero la buena interpretación de lo que se está exigiendo. Es en un principio donde los objetivos se plantean de forma general y se está más propenso a caer en ambigüedad, pero en las reuniones posteriores se van detallando más específicamente estos objetivos, de esta forma el ingeniero puede comprender de mejor forma lo que se desea.

4. ¿Nota una diferencia cuándo el ingeniero informático que lo entrevista tiene una amplia experiencia y cuándo no la tiene, cuál es esta?

Pienso que el ingeniero con experiencia es aquel que habla más, comunica sus dudas, plantea sus ideas. Por el otro lado el ingeniero sin experiencia es aquel que no habla se dedica a anotar lo que dice el cliente solamente y esta poco familiarizado con los términos específicos del rubro.

5. ¿Cómo se realiza el proceso, de manera formal o también influyen los estados de ánimo y las amistades para la voluntad que ud tenga para entregar los requerimiento?

Por lo general, trato de tener 2 tipos de reuniones. En un comienzo, la primera reunión es más formal y pautada, pero para reuniones posteriores, para dar soluciones a posibles problemas y responder consultas del ingeniero, se pueden dar de forma informal, con el fin de hacer un dialogo más agradable para ambos.
Con respecto a los estados de ánimo creo que me afectan a mí personalmente porque trato siempre de separar los problemas personales con el trabajo, pero si considero que al ser amigo del ingeniero se hace mucho más agradable trabajar con él.

Entrevista con el Cliente 1, Sr Daniel Astargo

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Tue, 13 Nov 2007 15:15:00 +0000

Entrevista con el Sr Daniel Astargo, Ingeniero comercial de la empresa Cintac S.A orientada al rubro de los metales. Debido a la comercialización de nuevos productos tales como el Metalcon, se necesita un apoyo informático para dar sustento a las diversas necesidades informáticas de esta empresa. El Sr Daniel Astargo, se ha encargo al menos 5 veces de dar diferentes requerimientos a ingenieros informáticos externos o internos.

1.- ¿De cuántos proyectos a estado a cargo en relación a la entrega de requerimientos a ingenieros informáticos?

Alrededor de 5

2.- ¿Cómo ha sido tu experiencia con los ingenieros?

No ha tenido mayores novedades, incluso con los ingenieros con los que ha trabajado ha formado lazos de amistad, ya que de esta forma dice: se desarrolla de mejor forma el desarrollo de la captura de información, siendo cómodo y agradable tanto para ellos como para el propio cliente. Al tener un lazo de amistad con ellos se hace más grata las conversaciones con ellos, donde en ocasiones se aceptan ideas que el propio ingeniero aporta ya que el cliente al tener un vinculo de amistad en él implica una confianza por el trabajo y experiencia de éste . Con los ingenieros que ha trabajado sigue hablando con ellos y no precisamente por un tema de trabajo.

3.- ¿Cómo es el formato para la obtención de requerimientos?

Ellos son los que imponen la estructura para la recaudación de información, donde entre los 2 se ponen de acuerdo para fijar las reuniones, los temas que se trataran y en caso de que surjan consultas antes de llegar una reunión, el cliente ofrece su mail en caso de posibles consultas de poco peso.

4.- ¿Tienes la disponibilidad para otorgar información al ingeniero informático, si este la requiere?

Como se dijo anteriormente, hace entrega del mail para consultas, el problema surge cuando quieren respuestas inmediatas.

5.- ¿Qué problemas son frecuentes en la captura de requerimientos?

El ingeniero no entiende lo que se necesita realmente y lo hace a su modo
El cliente no posee toda la información que desea saber el ingeniero (se necesita información de terceros)
Se alargan los plazos a los establecidos

Entrevista Cristián Gajardo

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Tue, 13 Nov 2007 00:13:00 +0000

Cristián Gajardo, ingeniero civil informático con más de 10 años de experiencia, actualmente trabaja en la empresa Taisa.

1. ¿Qué cargo tiene aquí?

Está a cargo de evaluaciones de proyecto.

2. ¿Cuánto tiempo lleva en esta empresa?

Lleva un año y medio más o menos en la empresa, trabajando con captura de requerimientos lleva alrededor de 5 años y como ingeniero informático más de 10 años.

3. ¿Cuántos proyectos con captura de requerimientos ha realizado?

En un año debe llevar unos 50 proyectos.

4. ¿Cuánto tiempo se toman en general para hacer la captura de requerimiento?

La captura de requerimiento se hace en 2 semanas generalmente, con reuniones con el cliente, reuniones de ida y vuelta (la típica reunión) y se llega a un acuerdo con un cierto documento donde queda especificado lo que se desea.

5. ¿Cómo es el proceso de captura de requerimientos?

Todo el proceso de captura de requerimientos va por etapas. La primera es la idea general que quiere el cliente, ésta se aborda, se toma, se redacta, se ve que es lo que quiere él, que es lo que uno cree que quiere él, luego se producen muchas reuniones con el cliente donde se fija otro documento que dice lo que se pidió y el acuerdo al cual se llego entre los desarrolladores y el cliente.

6. ¿Usted siempre se basa en un documento para establecer los requerimientos?

Si, en los contratos con los clientes.

7. ¿Cómo es el desempeño de los ingenieros jóvenes que llegan a la empresa?

Tienen problemas de planificación y valoración de proyecto.

8. ¿Nos podría dar más detalles sobre eso?

La valorización del proyecto (costo) es de acuerdo a lo planificado y la valorización no tiene nada que ver con planificar. Lo correcto es valorar y luego planificar, pero los ingenieros novatos entienden al revés. Todos planifican y dicen: yo planifico así y me demoro un año y les digo: no hay que aplicar una métrica para poder llegar a valorar. Uno debe valorar por servicios, se puede valorar, por pantalla, por página, por las validaciones, a esto es lo que se le pone precio.

9. ¿Usted le ha encomendado tareas que quizás que usted no se ha dado cuenta que no son aptas para una persona que no tiene experiencia?

Al principio no, al principio vienen súper suave, o sea en la toma de requerimientos se va orientando paso a paso al ingeniero novato por parte de todo el equipo.

10. ¿Todos se basan en las metodologías que tiene la empresa?

Generalmente sí, pero han habido casos de personas que siguen con la misma metodología, siguen con la carta Gantt y no valoran sino que planifican no más y lo hacen linealmente. Por ejemplo si yo voy a pasar algo a producción nunca es en un día, ya que habitualmente hay un rechazo porque puede existir una equivocación, y estos son los riesgos que no se consideran. Y esto se tiene que aprender necesariamente con ensayos y errores que surgen de la experiencia.

Nunca uno hace algo en un día, cuando una va hacer un trabajo se revisa y si esta malo se corrige. Entonces para yo planificar se debe tomar en cuenta estos factores y se estima cuando se va a terminar.

11. ¿Cuándo comienza la captura de requerimientos tiene frecuente contacto con el cliente o disposición para futuros cambios?

Después de la primera reunión con el cliente se revisa cuanto se va a demorar aproximadamente y se ve si el requerimiento es muy grande o chico y se planifican las reuniones. Luego de la 1ª reunión se revisa la minuta de que trato la reunión y se estiman cuantas reuniones se necesitan: 4, 5, 10, 15. Estas se estiman según la experiencia y el análisis de la complejidad de lo que se está pidiendo y cuando no se sabe de que se trata entonces se piden más reuniones para clarificar el objetivo.

12. ¿Cuál es el fin de las reuniones?

La idea es terminar la evaluación del proyecto, determinarla y no dejar algo propenso a que cambie, esto mediante un documento. Si no se llega a un acuerdo se levanta la alerta, diciendo que el cliente no tiene claro lo que quiere, el proyecto se congela hasta que el cliente revisa bien su documentación y pide lo que necesita. Muchas veces el cliente quiere algo, pero no sabe lo que es.

13. ¿Cuáles son otros principales problemas que el cliente tiene?

Uno era que no tienen claro que lo que piden. Otra es que no conocen las limitaciones que existen en el sitio, solo conocen lo que quieren. En las reuniones sucede que se cita gente que no corresponde para que respondan consultas que surgen del proyecto.

14. Usted que tiene más experiencia ¿cómo guía las reuniones con el cliente para establecer alguna estrategia para mejorar la captura de requisitos?

Los clientes envían un documento antes donde explican que es lo que quieren, ese documento se toma y se divide en preguntas o dudas, luego se envían estas consultas de vuelta al cliente donde se fija una reunión para contestarlas. Generalmente en la primera reunión se aclaran todas las dudas.

15. ¿Existe disposición de parte del cliente cuando ustedes tienen algún problema?

Si el problema es del ingeniero, no, lo debe solucionar el mismo, pero si el problema es netamente del negocio, se le explica al cliente que ese tema no había sido abordado y por esto se tiene que valorar de nuevo, planificar de nuevo o cambiar la planificación.

16. ¿Se logra un grado de afinidad con el cliente?

Siempre de amistad, porque les gusta lo que hacen los ingenieros, les gusta el producto y al final cuando se está en la etapa de producción ya se forman lazos de amistad, también ha surgido el caso contrario (rechazo), un caso es que el cliente no sabía lo que quería realmente, los ingenieros sin darse cuenta entendieron mal, pero el cliente afirmaba lo que ellos entendieron, y se comenzó mal el proyecto. El cliente siempre daba su aprobación sin entender lo que se hacía, pero al momento de pasar a producción surgieron problemas que no deberían pasar, lo que produjo un rechazo entre ese cliente y los ingenieros.

17. ¿Qué técnica tiene para clientes difíciles?

Ver que es lo que quiere y atacar por ahí. Se supone que es un cliente así que hay que ser profesional, o sea se ve que es lo que quiere el cliente, ver hacia donde quiere ir e ir con él.

Entrevista Alejandro Medel

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Mon, 12 Nov 2007 21:37:00 +0000

Alejandro Medel, ingeniero informático que trabaja para la empresa Taisa como consultor externo para diversos proyectos de distintas empresas

1. ¿Cuánto tiempo llevas trabajando como Ingeniero Informático?
Tiene 4 años como ingeniero informático y 3 realizando captura de requerimientos para la empresa Taisa.

2. ¿Alrededor de cuántos proyectos con toma de requisitos haz realizado?

Alrededor de 10 donde el Banco Santander es uno de los potenciales clientes.

3. ¿Cómo es tu participación en el proceso de captura de requerimientos?

Nunca ha tenido ningún problema, hay clientes que son más complicados, pero por lo general depende más que nada de los acuerdos que uno que tome con los clientes.

4. ¿Cómo es el proceso de captura de requisitos que realizas?

Al trabajar con el banco Santander hay una manera preestablecida de cómo se va a trabajar, documentación que se va a entregar, el tipo de documentación del banco Santander es CMMI5, lo que facilita la labor para la captura de requerimientos. CMMI5 se refiere a la calidad de la documentación, donde existen plantillas de documentación que hay que ir cumpliendo y entregando, ósea hay presentación en plantillas, las cartas Gantt son en plantilla, todo ya esta preestablecido en un formato de auditoría.

Existen también otros tipos de clientes que no tienen tantas normas, donde se hace más complejo el proceso de la captura de requisitos, en este caso depende más de los ingenieros informáticos la obtención de los requerimientos.

5. ¿Tu trabajo en qué consiste?

Empieza del momento en que el cliente (por lo general ingenieros comerciales) envía los requerimientos especificados (documento escrito), a partir de esto se empieza a analizar de que se trata, y se debe partir entregando una planificación de cuanto se demorara en evaluar ese proyecto, de este entonces se genera una documentación de análisis con todos los requerimientos, luego se produce un ‘pinponeo’ a través de distintas reuniones, se van entregando minutas (resumen de lo que se trato en la reunión) de esas reuniones porque a veces pueden haber acuerdos importantes o cambios de alcances de lo que se definió, hasta que los clientes dan su aceptación que queda guardada en un documento, en este momento se genera la carta Gantt y se pasa a la fase de desarrollo.

6. ¿En qué consiste el documento de aceptación?

El fin de este documento es que el cliente, en general ingeniero comercial, lo pueda leer y decir: Si, es esto lo que deseo.

7. ¿En qué consiste el equipo de trabajo?

Es un equipo de trabajo completo, donde existe un supervisor que revisa la documentación que genera el equipo de ingenieros, éste está compuesto por alrededor de 6 personas donde todos hacen lo mismo.

8. ¿Cómo es el trato a los ingenieros nuevos (con poca experiencia)?

Los demás ingenieros lo van ayudando, por ejemplo no va a reuniones solo, hasta ver el momento que se encuentran capacitados y puedan hacerlo en forma independiente.

9. ¿Cuál es el marco donde se desenvuelven los proyectos?

Dentro de la empresa existen proyectos internos de investigación para mejorar los procesos dentro de la empresa, pero por lo general son proyectos externos para empresas como: Banco Santander, Banca, Codelco, Altec, el Mercurio y Casa de compensación los Héroes.

10. ¿Cómo es tu comunicación con el cliente?

Se trabaja siempre de la misma forma que es vía e-mail y teléfono y las reuniones donde se habla más en profundidad. Para el caso de las consultas, si se esta cambiando el alcance del proyecto es para generar una reunión y en casos más triviales se puede hacer llamando por teléfono o por mail, pero generalmente se usa el mail para que quede una constancia escrita de lo que comunico el cliente.

11. ¿A medida que avanzas en el proyecto cambian los requisitos?
Si, hay veces que esta todo analizado, estando en la etapa de desarrollo y surgen cambios de alcance que muchas veces tienen que ser solucionados dejando esos cambios que se quieren para una segunda fase del proyecto o en el peor de los casos reevaluar e incorporar el cambio que se requiere afectando a la estructura de todo el proyecto, para esto sirven los mails y documentación como respaldo de lo que se había fijado en un comienzo, y de esta forma no estar cambiando constantemente los requisitos, de ser así significan nuevos costos para el cliente.

12. ¿Cómo es la explicación de los clientes sobre los objetivos del proyecto?
Los clientes son bastante claros, siempre están dispuestos a entregar toda la información que nosotros podríamos requerir como de negocios por ejemplo. Lo que cuesta más es que en ocasiones los clientes exigen cosas bastante complicadas, quieren todo lo antes posible: “No es para hoy es para ayer”. Un problema que surge es que no comprenden la complejidad del proyecto, pero por lo general siempre ceden y se dejan orientar por la experiencia de los ingenieros.

13. ¿Cuánto tiempo tarda la captura de requerimientos?
La captura completa que involucra la generación del documento de aceptación (Banco Santander que Alejandro ve mayormente), son alrededor de 2 semana donde se genera toda la documentación y además hay reuniones de por medio. Hay proyectos también que son súper largos, Alejandro dice: “hace poco tuvo uno que duro alrededor de 2 meses solo para hacer un prototipo, por lo general depende del cliente”.

14. ¿Cuáles son las dificultades más frecuentes en la toma de requisitos?
Tratar de entender lo que los clientes piden, hay casos que los requerimientos son claros, pero también existen casos que son muy confusos. Cuando hay mucha gente de por medio el proceso se hace más lento, es decir que el cliente debe consultar con otra persona que también esta involucrada para obtener información que afecta a los requisitos.

15. ¿Cómo son los estándares con las distintas empresas?
Hay estándares que son impuestos por los clientes, como por ejemplo: Codelco y Altec que tienen estándares que señalan el tipo de formato para desarrollar el proyecto. Hay otros clientes que no tienen un formato específico, y se utilizan formatos creados acá mismo en la empresa, para esos clientes que no tienen estándares se realiza una documentación con plantillas que se ocupan al interior de Taisa, pero aún no se ha sacado oficialmente.

16. ¿Se han visto apurados en los plazos de entrega?
Si ha ocurrido y es básicamente por que los clientes quieren algo que es bastante rápido y esto conlleva a que los tiempos no sean reales. También se ha dado el caso que se depende de otra empresa u otro grupo para el desarrollo del proyecto y cuando estas no cumplen retrasan todo el proceso.

17. En un principio ¿fue difícil adaptarte?
No, ya que hay una etapa de inducción, donde nuestros clientes realizan capacitaciones sobre metodologías de desarrollo. Además existe un apoyo de todo el equipo que siempre está dispuesto a ayudar y enseñar.

En un principio uno no ve la parte humana se basa plenamente en lo teórico, ya que en la universidad uno no le da mayor relevancia a los ramos que fortalecen esta área.

18. ¿Tienes alguna estrategia más humana?
Si en este tiempo me hecho de muchos contactos, lo que es muy importante ya que al ser amigos es más fácil conseguir información.

No siempre hablar cosas de trabajo, por ejemplo: preguntar por la familia.

19. ¿Afecta la afinidad entre tú y el cliente?
No afecta en el desempeño, pero si afecta a las ganas con que uno realiza la toma de requerimientos. En el caso de haber ‘mala onda’ entre el cliente y el ingeniero informático hay que ser bastante profesional y tener mucha paciencia.

Entrevistas

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Mon, 12 Nov 2007 19:56:00 +0000

Entrevistas a Ingenieros

Entrevista 1: Rodrigo Gálvez y Juan Pablo Castro
Entrevista 2: Nelson Orellana
Entrevista 3: Gonzalo LLanquilef
Entrevista 4: Nelson Castillo
Entrevista 5: Alejandro Medel
Entrevista 6: Cristián Gajardo

Entrevistas a Clientes

Entrevista 1: Daniel Astargo
Entrevista 2: Pilar Barra

Entrevista a Rodrigo Gálvez y a Juan Pablo Castro

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Mon, 12 Nov 2007 19:52:00 +0000

Esta entrevista se realizó a Juan Pablo Castro y a Rodrigo Gálvez en un patio de la empresa D&S, donde la mayoría de las respuestas se complementaban entre ambos, en el caso de haber una respuesta personal de cada uno se distinguirá como “JP“para Juan Pablo y “G” para Gonzalo:

1. ¿Cuánto tiempo llevas trabajando como Ingeniero Informático?

G : Tiene 7 años de experiencia, donde los 7 años ha trabajado en la consultora Polo Sur, consultora externa que presta sus servicios a empresas, donde ha sido destinado a distintas empresas y actualmente se encuentra trabajando para la empresa Distribución y Servicio (D&S) en el área de Recursos Humanos, ya hace 3 años.

JP: Tiene 3 años de experiencia, en los cuales ha trabajado para la consultora Polo Sur. Actualmente trabaja a la empresa Distribución y Servicio (D&S) en el área de Recursos Humanos como consultor externo.

2. ¿Alrededor de cuántos proyectos con toma de requisitos haz realizado?

G: Alrededor de 50

JP: Alrededor de 20

3. ¿Tienen alguna particularidad los proyectos que sueles desarrollar?

Como el marco tecnológico de la empresa D&S se orienta en el desarrollo de módulos SAP, a la hora de realizar un proyecto la interfaz por lo general se mantiene y a lo que se debe enfocar el ingeniero es a las funcionalidades que se desean satisfacer.

4. ¿Cómo es el proceso de captura de requisitos que realizas?

En D&S el proceso para realizar la captura de requisitos, inicialmente se entrega una solicitud de requerimientos, donde se plantea en una primera instancia lo que se desea del proyecto nombrando limitaciones y los servicios (funcionalidades) que se desean satisfacer con la creación de éste, este documento está hecho en forma general y poco detallada. Luego el ingeniero debe revisar la solicitud, detectar posibles inconsistencias y aspectos que no fueron explicados, a continuación se fija una reunión con el cliente (generalmente se encuentra en la planta D&S) y se tratan los problemas detectados por el ingeniero, dándole solución a éstos, después de esta conversación se fija el contrato, dejando en claro en ésta que si las funcionalidades planteadas inicialmente pueden ser modificadas en el trayecto de éste. Una vez ya con una mayor certeza de lo que se pretende con el proyecto el ingeniero puede comenzar a identificar los requerimientos que estime necesarios para el desarrollo del proyecto.

5. ¿De qué forma complementas la toma de requisitos?

A través de diagramas de flujo de datos, ya que éstos ayudan a clarificar el ordenamiento y la secuencia de acciones de la aplicación del proyecto.

Por otro lado, la personalidad es muy importante para llegar al cliente, ya que una relación afectiva con el cliente condiciona en parte la aprobación o rechazo de las ideas de requisitos que el ingeniero elabore.

Hacer la labor de juntarse con el cliente a plantear los requisitos de forma más amena y cómodamente tanto para el cliente como para el ingeniero, por ejemplo juntarse en un parque, tomando un refresco y conversando acerca de los requerimientos que tendrá el proyecto.

6. ¿Tienes constante comunicación con el cliente, en las etapas del proyecto, (no, por qué)?

Si, se mantiene una constante comunicación, ya que como la empresa es grande (D&S), habitualmente los clientes son personas que se encuentran en la misma planta de la empresa, es por esto que se hace fácil y cómoda la ubicación del cliente para esclarecer consultas o para replantear los requerimientos en caso de que sea necesario, en otras oportunidades ha sucedido que el cliente es extranjero, en estos casos se hace difícil el diálogo con el cliente, a esto se le puede sumar la barrera del idioma, por ejemplo si el cliente es australiano se haría necesaria la presencia de un intermediario o que el mismo ingeniero se haga cargo de la interpretación del problema. Una mala interpretación de lo que desea el cliente, o por otro lado una mala explicación por parte del cliente generaran una captura de requisitos errónea.

7. A medida que avanzas en el proyecto, ¿cambian los requisitos?

Por lo general, en proyectos grandes (largo plazo), el proyecto esta propenso a cambios en los requerimientos. Estos cambios están ligados a distintos problemas que surgen en el camino, por ejemplo: debido a la disconformidad del cliente con respecto a los avances del proyecto, o bien por que el cliente desea agregar o modificar funcionalidades del proyecto o un cambio en la lógica de negocio, lo que implica agregar nuevos requerimientos o efectuar cambios en éstos, que en ocasiones puede ser el cambio de todos los requisitos que se habían planteado inicialmente.

En proyectos de corto plazo es usual fijar las peticiones de lo que se desea con el proyecto en el contrato, sin dar la posibilidad a cambios durante el trayecto de desarrollo, de suceder un cambio se fijaría un nuevo contrato lo que conlleva a un mayor cobro por parte del ingeniero.

8. ¿Los clientes son claros y precisos a la hora de explicar lo que quieren?

Los clientes, por lo general, explican de manera global lo que desean y no evalúan en profundidad lo que quieren, suelen creer que es trabajo del ingeniero informático elaborar la toma de requerimientos, sin mayor ayuda del ellos, sólo con la información general que entregan piensan que es suficiente para el desarrollo del proyecto solicitado. Es por esto que el ingeniero desarrollador trata de fijar reuniones con el cliente, para profundizar en los diversos temas que involucran los objetivos del proyecto.

9. ¿Influye la duración del proyecto para la toma de requerimientos?

En el caso de la empresa D&S por lo general se generan proyectos a largo plazo, o de plazo indefinido, los cuales están propensos a cambios en el trayecto de desarrollo, y existen proyectos a corto plazo que, generalmente, se fijan las condiciones en un comienzo y se mantienen durante todo su desarrollo.

10. ¿Las personas que la realizan captura de requerimientos han tenido alguna preparación especial?

Sólo la preparación teórica que se dictó durante la preparación que los llevo a ser ingenieros, las habilidades blandas van surgiendo con la experiencia y con la interacción con otros ingenieros.

11. ¿Qué técnicas de comunicación usan para lograr la captura?

· Proponer ideas que sean adecuadas e interesantes para el cliente.

· Analizar que tipo de cliente es (jefe. Operario, secretaria, intermediario, gerente) y según el rol actuar de una manera acorde al contexto.

· Tratar de que el diálogo sea en un lenguaje que ambos puedan entender.

· Usar bocetos de cómo será la interfaz (layout), sujeto a cambios por parte del cliente, si éste lo desea.

· Estar relajado, tratar de que sea amena la conversación.

12. ¿Cuáles son las dificultades más frecuentes en la toma de requisitos?

· El cliente es impreciso para explicar lo que quiere, explican lo que desean en forma general y no saben detallar específicamente lo que desean.

· El ingeniero no escucha lo que plantea el cliente y se basa en como el cree.

· El ingeniero no se siente cómodo con el entorno donde trabaja, como trabaja y con quienes trabaja.

· Los requerimientos establecidos involucran otras áreas.

Entrevista a Nelson Orellana

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Mon, 12 Nov 2007 19:39:00 +0000

Entrevista a Nelson Orellana, jefe del departamento de desarrollo de TI Internet en el Mercurio, egresado de la USACH el año 1997.

hol.1. ¿Cuánto tiempo llevas trabajando como Ingeniero Informático?

El Ingeniero Nelson Orellana tiene 10 años de experiencia trabajando con la captura de requisitos, y trabaja actualmente en el proceso de toma de requerimientos y desarrollo de aplicaciones interactivas para el diario El Mercurio.

2. ¿Alrededor de cuántos proyectos con toma de requisitos haz realizado?

El señor Nelson Orellana estima un número 75 o más proyectos en los que ha trabajado realizando esta labor.

3. En un comienzo ¿Cómo es la toma de requisitos? ¿Te guías por algún proceso?

Dependiendo del tipo de proyecto en que se involucre es la manera en como se realiza este proceso. Dijo. Actualmente el trabaja en procesos altamente interactivos dónde tiene contacto con el cliente y utiliza un esquema de desarrollo evolutivo dónde las tomas de requerimientos duran en promedio 2-3 semanas.

4. ¿De qué forma complementas la toma de requisitos?

Como las principales aplicaciones que son encargadas son de tipo gráfico, en el equipo se cuenta con una diseñadora, con ella se asiste a las reuniones con los clientes y se dibujan plantillas en photoshop que les son mostradas a los clientes y ellos pueden en dicho momento ir indicando lo que esperan de la aplicación.

También usa la técnica de ir modificando los prototipos anteriores con papel, o photoshop y crear las pantallas que definirán la aplicación.

5. ¿Tienes constante comunicación con el cliente, en las etapas del proyecto, (no, por qué)?

El Ingeniero Nelson Orellana responde que no, ya que la disposición de los clientes en el Mercurio es limitada, ellos generalmente no están dispuestos a entregar mucho tiempo para este proceso fuera de lo que entregaron en las primeras reuniones.

6. ¿A medida que avanzas en el proyecto cambian los requisitos?

El Ingeniero Nelson Orellana responde que si, que es utópico pensar que a lo largo del proyecto no cambien los requisitos, siempre existen cambios, y cuando el cliente ve avances tiene nuevas ideas que redefinen los aspectos iniciales.

7. ¿Los clientes son claros y precisos a la hora de explicar lo que quieren?

El Ingeniero Nelson Orellana responde que no, ya que ellos conocen muy bien la lógica de negocios pero en el ejercicio de esta no pueden desprenderse del lenguaje para explicar lo que necesitan, y si uno no entiende, ellos no explican todo, así que es obligación del ingeniero realizar las visitas al lugar de trabajo para comprender el vocabulario y el negocio del cliente. Citó un ejemplo cuando tuvo que realizar una aplicación para operarios que manejaban las impresiones del Diario, el Jefe del taller no podía darse a entender con un lenguaje común.

8. ¿Haz tenido problemas por captura de requisitos mal elaborada?

El Ingeniero Nelson Orellana responde que si, al menos una vez al año ha tenido problemas serios que implican grandes cambios en lo que llevaba desarrollado y se ha perdido tiempo. Al principio con menos experiencia en los menos años, eran alrededor de 3 proyectos en los que tenía problemas serios, pero últimamente el y su equipo han disminuido esta cifra a 1 proyecto por año.

9. ¿Cuáles son las dificultades más frecuentes en la toma de requisitos?

El Ingeniero Nelson Orellana responde que si, siempre está el problema del estrés del cliente y la falta de tiempo. Adicionalmente la barrera del lenguaje del negocio, la cual en su caso debe ser resuelta por el o por otros ingenieros pertenecientes a su equipo. Otro problema es la falta de interés de un cliente, esto sucede cuando un gerente pide a un subalterno el desarrollo de alguna aplicación, éste le comunica a su subalterno rápidamente, y el con lo que entendió se encarga de contactar al departamento de IT Internet. En ese momento se da cuenta que el cliente final, el que requiere el producto es el gerente y casi siempre el nunca dará tiempo para realizar un correcto proceso de toma de requerimientos. Otro factor es la cultura del cliente, que le permite o no entregar su disposición y tiempo para realizar actividades que implique su participación (como los esquemas de photoshop).

10. ¿Crees que los demás ingenieros le dan la importancia necesaria a la captura de requisitos?

“Dependiendo del tipo de proyecto, en el Mercurio existe otro departamento que trabaja con SAP, ahí se toman 6 meses para realizar la captura de requerimientos”. Responde el Ingeniero.

11. ¿Los clientes tienen buena disposición para explicar claramente lo que desean de una aplicación?

El Ingeniero Nelson Orellana responde que No, como se ha dicho antes en la conversación, utilizan mucho su vocabulario del negocio, y es obligación de los ingenieros ponerse al tanto de ésta lógica.

Entrevista con Gonzalo Llanquilef

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Mon, 12 Nov 2007 19:29:00 +0000

Entrevista con Gonzalo Llanquilef, ingeniero civil informático egresado de la USACh. Actualmente trabaja en LAN liderando un equipo de trabajo que se constituye de 8 personas, otras veces el equipo ha llegado a contar con 5 personas.

¿Cuánto tiempo lleva trabajando como Ingeniero Informático?

Siete años de experiencia en el desarrollo de proyectos que se involucran con la captura de requerimientos.

¿Alrededor de cuántos proyectos con toma de requisitos haz realizado?

Alrededor de 70 proyectos, con un promedio de 15 a 20 proyectos por años.

3. En un comienzo ¿Cómo es la toma de requisitos? ¿Te guías por algún proceso?

La empresa se rige por la normativa CMMI, que normaliza la manera en como se hacen las comunicaciones con el cliente, define el formato de los documentos que respaldan el trabajo siguiendo un estándar que es adoptado y empleado por el equipo de trabajo. Este proceso también depende directamente de la envergadura del proyecto, en un proyecto pequeño el tiempo destinado a la captura de requerimientos es de 2 semanas aproximadamente, en el caso de un proyecto mediano (de 7 meses) se emplean alrededor de un mes a un mes y medio para la captura de requerimientos. Y finalmente cuando los proyectos son grandes (dos años), se destinan 3 meses al proceso de captura de requisitos

¿De qué forma complementas la toma de requisitos?

Para cada reunión con el cliente se toman apuntes y se registra a todo en las minutas, las que van construyendo un respaldo de las decisiones acordadas en cada fecha en que ocurrió una reunión.

¿Tienes constante comunicación con el cliente, en las etapas del proyecto, (no, por qué)?

Generalmente no, ya que para los clientes el trabajo de tener que recibir al ingeniero y explicarle lo que desea del sistema que se necesita construir siempre es un trabajo adicional para él.

¿A medida que avanzas en el proyecto cambian los requisitos?

Siempre existen cambios en los proyectos, no existen casos ideales en el ambiente laboral. Incluso existen situaciones en que el cliente no advierte que un cierto cambio o requerimiento adicional es necesario, y cuando el equipo de ingenieros le hace notar esta situación a veces el cliente lo ignora argumentando que es innecesario, sin embargo más tarde vuelve y se da cuenta de que efectivamente dicho requerimiento era necesario y lo manda a pedir. Por eso que es importante anticiparse a los cambios y preparar las cosas que uno como ingeniero sabe que van a ser necesitadas aún cuando éstas no sean explícitamente requeridas.

¿Los clientes son claros y precisos a la hora de explicar lo que quieren?

No, esto se manifiesta de diversas maneras, a veces piden aplicaciones para asuntos que no son necesarios, otras veces entregan requerimientos que no son adecuados para lo que se busca, el cliente tampoco tiene conciencia de lo que es requerido para llevar a cabo la construcción de un software específico. Incluso a veces solicita aplicaciones que ya han sido construidas en la empresa y que están siendo desaprovechadas.

¿Haz tenido problemas por captura de requisitos mal elaborada?

Sí hay proyectos que han fallado, sin embargo la responsabilidad ha recaído en el cliente que ha cometido errores en la entrega de los requerimientos y no se ha tenido problemas puesto que todo ésta registrado en las minutas y otros documentos.

¿Cuáles son las dificultades más frecuentes en la toma de requisitos?

Aparte de los problemas típicos existentes en la captura de requisitos tales como la falta de tiempo del cliente, el estrés, el lenguaje del negocio, también existen problemas por parte de algunos ingenieros que tienen carencia de habilidades blandas, en algunas reuniones que he asistido hay ingenieros hablan nada en el momento que es necesario y eso acarrea un sin número de problemas que se pagan en el proyecto, otras veces algunos ingenieros han sido fuertemente regañados por clientes debido a que dichos ingenieros no han tenido la capacidad de dialogar con el cliente.

¿Qué críticas efectúa usted a los ingenieros en el proceso de la toma de requisitos?

Muchos ingenieros tienen carencia de habilidades blandas, esto se refleja en variados aspectos, como el manejo de las presiones y las frustraciones. La manera en que reacciona el subordinado ante un fuerte llamado de atención del jefe. Muchos ingenieros han sentido fuertes deseos de abandonar el trabajo ante la primera reprimenda laboral, hay otros casos a quienes no les importa que constantemente los estén retando y siguen cometiendo los mismos errores. Otro problema mencionado antes, es la capacidad para dar opiniones ante un número importante de personas en una reunión, dónde se nota que tienen carencia de habilidades para enfrentar ese tipo de situaciones.

¿Qué valoran los clientes en el equipo de ingenieros?

Los clientes valoran la ayuda entregada por los ingenieros cuando ellos se encuentran en dificultades en el momento de la obtención de los recursos necesarios que se necesiten para un requisito, también aprecian la disponibilidad del ingeniero a cambiar los plazos de reuniones puesto que ellos producto de su trabajo se pueden ver con ese tipo de problemas.

¿Qué critican los clientes en el equipo de ingenieros?

Critican la poca flexibilidad del ingeniero para incorporar elementos adicionales si estos no se pagan. Las cosas deben estar bien definidas sobre que se hace y que no, no pueden existir ambigüedades.

Entrevista con Nelson Castillo

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Mon, 12 Nov 2007 19:26:00 +0000

Entrevista con Nelson Castillo, ingeniero electrónico, Coordinador de negocios de de la empresa Taisa, con 20 años de experiencia. Trabaja en el proceso de toma de requerimientos y de las evaluaciones de éste.

¿Cuánto tiempo lleva trabajando como Ingeniero Informático?

20 años de experiencia, trabajando en el proceso de toma de requerimientos y de las evaluaciones de proyectos que se negocian con los clientes.

¿Qué concejos puede darnos para el proceso de captura de requerimientos basado en su experiencia?

Para ésto, es mi estilo comenzar siempre la reunión con preguntas totalmente ajenas al tema de la reunión, y que sean de carácter humano, preguntándole sobre sus familias, el trabajo, cómo han estado, etc. De esta manera la conversación se hace más agradable y ayuda a la construcción de un clima favorable y ameno.

Otra cosa importante es generar una conversación de ida y vuelta, mediante un ambiente de camaradería que permita romper el hielo entre las personas, haciendo que la conversación sea más dinámica.

. ¿Qué critica haría usted a los ingenieros con poca experiencia?

Muchos ingenieros con poca experiencia no tienen una visión de si mismos al mediano o largo plazo, están más orientados al área técnica, es decir se motivan por aprender nuevos lenguajes de programación y cosas por el estilo. Lo que los lleva a alejarse enfocarse a cosas netamente técnicas, no mostrando tanto interés por las habilidades blandas.

Metodología de los Sistemas blandos (SSM)

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Mon, 12 Nov 2007 04:18:00 +0000

¿Qué metodología usar y por qué?

La metodología de los sistemas blandos es más conocida por su nombre en inglés, soft system methodology (SSM), desarrollada por Peter Checkland.

Se ha decidido utilizar esta metodología al considerar que los factores principales ha analizar en este trabajo son de carácter cualitativo, en función de esto, se ha buscado una metodología que sustentase este requerimiento y como SSM cumple con ésta condición, en consecuencia fue elegida.

Otro aspecto importante para su elección es su enfoque organizacional que brinda para el modelado de procesos y puede ser usado para la resolución de problemas generales, sólo basta con adecuar algunas condiciones para poder aplicar la metodología. Como fue desarrollada pensando en la ingeniería de sistemas se puede tener el análisis de situaciones complejas dónde existen diversos puntos de vista sobre el mismo problema. Precisamente este tipo de análisis, es muy útil para los objetivos de este trabajo. (Ver Objetivos Generales).

La metodología de SSM se divide en 7 pasos.

Descubrir las situaciones problema, e sto involucra una investigación pequeña sobre el área del problema buscando identificar los principales involucrados, el funcionamiento del sistema actual, su entorno, etc.
Expresar la situación problema a través de Rich Pictures. Se utiliza esto ya que los diagramas visuales entregan mayor cantidad de información.
A partir del Rich Picticture, establecer las definiciones raíces.
Construir modelos conceptuales de lo que el sistema debe hacer para cada definición raíz.
Realizar una comparación de los modelos conceptuales con el mundo real. Buscar las similitudes y diferencias de los pasos 2 y 4.
Identificar cambios posibles y deseables. Es una manera de improvisar la situación.
Realizar recomendaciones para mejorar la situación problema.

A continuación se puede observar un diagrama dónde se encuentran los pasos.

Etapa 1: Se identifican los conflictos que conforman la situación problema, luego se hace una descripción de esta situación.

Etapa 2: Se busca identificar aquellos procesos que están dentro del sistema, y que tienen características de cambio constante. Registrar los problemas que son expresados por los miembros de las organizaciones, generalmente se obtienen a través de quejas, críticas, sugerencias, etc.

Ésto se logra mediante la creación de un Rich Picture

Un Rich Picture debe tener:

1. Identificación de los problemas que las personas tienen con otras.

2. Análisis social, identificando los roles que las personas tienen en la organización, revisando las normas de comportamiento de las personas tienen y el valor que es utilizado para juzgar su comportamiento.

3. Análisis de poder, dónde el tema central son problemas relacionados con los tópicos involucrados en una situación de poder.

Etapa 3: Nombrar a los sistemas importantes

Lo primero que se debe realizar es escoger un problema que se observe en el Rich Picture, para luego definir un sistema que no tenga ese problema al realizar una acción.

Se utiliza el CATWOE como el cuerpo como medio de análisis de las definiciones raíces. CATWOE, es una sigla que hace referencia a lo siguiente:

Customer: Cliente, representa a cualquier persona que se beneficie del sistema.

Actor: Actor, realizan las actividades definidas en el sistema.

Transformation process: Proceso de transformaciones, es la conversión de una entrada a una salida.

Weltabschauung: Visión de mundo, aporta el contexto dónde tiene sentido las transformaciones.

Owner: Propietario, tiene el poder de controlar el encendido y apagado del sistema

Enviromental constraints: Restricciones del ambiente, son restricciones externas al sistema que se incluyen en las normas de la organización.

Etapa 4:

Cuando se cuenta con una definición raíz es posible dibujar un modelo conceptual. El modelo corresponde a una actividad humana que estrictamente se apega a la definición raíz usando un conjunto mínimo de actividades. Se pueden aplicar modelos formales de sistemas al desarrollo de modelos conceptuales, éstos funcionan como una guía para revisar el modelo conceptual.

Etapa 5:

En esta etapa se comparan los modelos conceptuales con el mundo que describe el Rich Picture. Los modelos conceptuales pueden ser usados para crear una fuente de preguntas para hacerlas en una situación real.

Etapa 6 y 7:

Se identifican los posibles y deseables cambios. Es una buena práctica generar un debate acerca de los posibles cambios que se podrían llevar a cabo para afectar la situación problema. El resultado de estas dos etapas es la creación e implementación de un sistema. Cuando se tienen situaciones problemas confusas el producto de estas etapas es más un cambio que una implementación.

Normalmente existen tres tipos de cambios producidos que son los cambios de actitud, de procedimientos y de estructuras. En la etapa siete se toman los cambios para implementarlos y ponerlos a funcionar.

Manual de Buenas Prácticas

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Sun, 11 Nov 2007 01:26:00 +0000

Este manual surge como orientación y ayuda hacia los ingenieros informáticos para que puedan realizar una captura de requerimientos que cumpla con las características (atributos) que hacen que ésta esté bien elaborada.

Uso de diagramas de flujo de datos

Ayudan a clarificar el ordenamiento y la secuencia de acciones de la aplicación del proyecto, es decir, gracias a la visualización de éste se pueden detectar tempranamente requisitos que quedan expuestos al desarrollar un diagrama de flujo de datos del proyecto.

Afinidad con el cliente

Lograr una afinidad grata con el cliente, se hace de gran utilidad ya que así el cliente tendrá una mejor disposición y además la comunicación tendrá mayor fluidez otorgando mayor información y permitiendo interiorizar de mejor forma con lo que reamente desea con el proyecto deseado. En el caso contrario (no lograr una afinidad grata con éste), se puede dar una realización de ‘malas ganas’ del proyecto pudiendo ocasionar una deficiente toma de requerimientos y a largo plazo un resultado de proyecto que no es deseado por el cliente.

Realizar reuniones de manera informal

Entre las ventajas que trae encontrarse en una situación informal están: la conversación se daría en forma espontanea, se logra un ajuste a una situación formal (obtención de información más detallada), permite un desarrollo integral para ambos involucrados. Un ejemplo de algunos encuestados es: juntarse en un parque, tomando un refresco y conversando acerca de los requerimientos que tendrá el proyecto.

Saber decir que no

Muchas veces el cliente va a desear muchas cosas para la aplicación, pero como generalmente no tiene conciencia de lo que está pidiendo, el ingeniero debe ser capaz de poder evaluar estas peticiones y decir que no cuando es necesario, también debe considerar factores de tiempo, económicos, etc.

Anticiparse a los problemas

En el momento en que el cliente efectúa una petición, el ingeniero debe explicarle lo que es necesario para en el futuro poder implementar dicho requerimiento. Existen veces que el cliente no admite que ciertos asuntos son necesarios y no quiere incluirlo en las listas de problemas. Es buena idea efectuar ese trabajo igual, ya que tarde o temprano el cliente va a requerirlo de todas maneras, y en el caso de que no sea requerido, el equipo ya estaba preparado para el contratiempo.

Comenzar la reunión con preguntas humanas ajenas al tema de la reunión

Es muy importante recordar que el cliente es una persona antes que un cliente. Por ésto es muy buena práctica, comenzar las reuniones con preguntas sobre su estado, su familia, su trabajo, etc. Ésto ayuda a crear un clima más favorable para el desarrollo de toda la reunión, haciendo que las personas se sientan más a gusto.

Que el cliente sienta que el ingeniero es una ayuda

Es cierto, el cliente es ambiguo al hacer sus requerimientos, pero esa es la manera en que debe ser, para eso están los ingenieros que tienen que ser capaces de poder ayuduar al cliente cuando éste no puede obtener lo necesario para implementar un requisito. Cómo el ingeniero conoce mejor lo que sirve o no sirve, debe brindar ayuda al usuario a encontrar lo necesario y no dejarlo sin guía, argumentando que su trabajo es simplemente escucharlo.

Comunicarse apropiadamente con el cliente en las reuniones

En las reuniones, aunque parezca obvio es necesario hablar. Existen ingenieros que acuden a las reuniones y no dicen nada en gran parte de ella. Como consecuencia de ésto, indirectamente están aceptando problemas, o más trabajo, sólo por el hecho de no establecer su punto de vista. Ésto ocurre con las personas que son muy introvertidas, o que son tímidas para exponer ante un gran número de personas. Es necesario que el ingeniero se prepare a si mismo para éste tipo de situaciones y exponga adecuada y claramente.

Respaldar en algún tipo de registro los acuerdos tomados en cada reunión

Cuándo existan los típicos problemas de responsabilidades, de quien iba a quedar cargo de hacer que tarea, se puede recurrir a un respaldo de lo acordado en cada reunión, ésto es aplicable tanto para la relación entre ingeniero y cliente o entre el equipo de ingenieros.

Saber cuándo es conveniente aplazar o suspender una reunión.

Para el cliente es un trabajo extra el hecho de tener que explicar al ingeniero lo necesario para implementar el sistema. Esto genera un estrés y acumulación de carga de trabajo. Además considerando de que se está tratando con personas, es probable que llegado el día una reunión, él tenga problemas personales, estrés y carga de trabajo. el ingeniero debe ser capaz de darse cuenta de esta situación, ser flexible, y ofrecer un horario conveniente al usuario para la siguiente reunión, eso es ponerse en el lugar del otro.

Atributos de la Captura de Requisitos

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Sun, 11 Nov 2007 01:18:00 +0000

1. Abstractos: Evita detalles no esenciales que no afectan al sistema.
2. Completos: Contiene todos lo elementos necesarios para construir la solución.
3. Correctos: Conducen a implementaciones que son aceptables.
4. Consistentes: No contradicen a otros requisitos o a si mismos.
5. Factibles: Son realizables por el quipo de trabajo
6. Modificables: En caso de errores, deben ser flexibles al cambio.
7. Precisos: Evitar la ambigüedad en el establecimiento de requisitos.
8. Legibles: Deben ser fáciles de leer y entender.
9. Verificables: Es sencillo verificar que una cierta implementación cumplo los requisitos.

Objetivos Generales

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Sun, 11 Nov 2007 01:14:00 +0000

Identificar que habilidades y competencias posee un ingeniero informático para la toma de requisitos

Al hablar de habilidades y competencias, no nos referimos a lo mismo, ya que al decir que una persona es competente en algún aspecto específico, se quiere decir que esa persona es idónea para lograr algo en ese aspecto. Una persona competente en el ámbito de la captura de requisitos sería aquella que posee los conocimientos de la teoría que ésta implica para su desarrollo, además de una serie de habilidades blandas usadas a la hora de relacionarse tanto con clientes, como compañeros de trabajo. Por otro lado, al decir habilidades, se refiere (en el aspecto de la captura de requisitos) a la capacidad que posee el ingeniero para realizar la captura de requisitos, generalmente lograda por conocimientos teóricos con los cuenta el ingeniero informático.
Este fin pretende determinar las habilidades y competencias de relevancia, y para lograrlo se hará según el número de coincidencias que se pudieron deducir de las encuestas hechas, es por esto que el resultado del objetivo es basado plenamente en la muestra que se utilizo para el desarrollo del trabajo, además se usará como orientación el análisis del Rich Picture y en general del análisis obtenido al utilizar la metodología SSM.

Establecer la importancia de las habilidades blandas para el proceso de captura de requerimientos

Las habilidades blandas son muy necesarias e importantes a la hora de realizar una buena captura de requerimientos, ya que las habilidades blandas ayudan a flexibilizar y sirven de ajuste a un proceso rígido y formal (estructura formal), es decir, con ayuda de éstas se logra obtener puntos o información que no hubiera sido posible implementando solo la teoría. Es por esto que se desea dejar en claro la importancia de estas habilidades, que llegan a formar a la persona idónea, mediante la reflexión a las vivencias y experiencias de los ingenieros encuestados.

Video, Captura de requerimientos tradicional. ¿Se puede cambiar?

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Thu, 08 Nov 2007 23:08:00 +0000

A pesar de las barreras idiomáticas que el video impone para nosotros, podemos darnos cuenta observando las imágenes que éste proceso de captura de requerimiento es muy tradicional.

Dos personas se entrevistan con un cliente y obtienen los requerimientos, luego estos ingenieros informáticos (supuestamente), llegan e interactúan con su equipo de trabajo. Lo que se puede deducir de esto, es que cualquier solución que emerja de los diseñadores, será una solución originada sin una participación presencial activa del cliente en dicha interacción.

La solución no nace en el cerebro del o los diseñadores, sino nace en la interacción de los diseñadores con el cliente. Ésta es una buena práctica que queremos potenciar.

Sin embargo, no siempre debido a las diferentes naturalezas del negocio, las empresas, las magnitudes del proyecto o el marco tecnológico existente, esta práctica podría ser inaplicable.

Uno de los principales inconveniente es justamente requerir de la disposición del cliente a involucrarse en trabajos o actividades que no son propias de su trabajo para que los ingenieros puedan desarrollar mejor el suyo. Se necesitaría una mentalidad abierta para que los clientes aceptaran involucrar su tiempo en una interacción así, dejando la comodidad del sillón de la sala de reuniones que tradicionalmente utiliza.

Sabiendo éstas dificultades, aún queremos establecerlo cómo una buena práctica siempre y cuándo las condiciones de entorno lo permitan, ya que una buena captura de requerimientos bien realizada disminuye los errores consecuentemente los retrasos en el desarrollo de un software.

¿Qué es más conveniente, que el cliente pierda algunas horas por cada día de interacción o que pierda meses de atrasos por tener que rehacer módulos o funciones debido a fallas en la captura de requisitos?

Descripción del Problema

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Thu, 08 Nov 2007 21:55:00 +0000

Un ingeniero puede conocer toda la teoría de la toma de requerimientos, puede haber estudiado lo que es, lo que se debe obtener de ella, etc. De esta manera adquiere la capacidad para entender qué hacer y cómo hacerlo, pero hay otros factores que no son teóricos que influyen y generalmente éstos no son explicados en la teoría de la ingeniería del software por ser de carácter más humano, y cuándo en la práctica llega el momento de tomar los requerimientos, el ingeniero se da cuenta de lo que está escrito en los libros no es toda la verdad. Precisamente, la variedad de habilidades blandas que no ha cultivado son las que le dan el carácter de competente al ingeniero que posee la capacidad de hacer la captura de requisitos.

Es decir el ingeniero idóneo para realizar esta labor es aquel que por un lado conoce la teoría y por otro lado posee habilidades blandas para saber relacionarse con los clientes de los cuales debe obtener los requisitos.

Sin embargo, ese caso es el ideal, en la práctica se encuentran personas que conocen bien la teoría y que tienen distintos grados desarrollo de habilidades blandas lo que los lleva a no encajar en algún tipo de empresa pero si en otro.

Los problemas que acarrea la actividad de la toma de requerimiento son variados, están los que se involucran con el cómo se realiza la actividad y esos son los que dependen de las habilidades blandas, e implican todo lo que se debe enfrentar a la hora juntarse con un cliente. El estrés que depende de la actividad que desarrolle el cliente, está ligado directamente con la carga de trabajo y la presión que el tiene para resolver sus problemas que son ajenos al software, en muchos casos considerando que la captura de requerimientos es algo que está fuera de su labor cuando el no está necesitado de dicho software, es decir cuando lo mandan a responder la captura de requisitos y esa actividad no forma parte de su punto de interés. Ese es un gran problema que enfrentan los ingenieros a la hora de entrevistarse con alguien.

La falta de tiempo, que muchas veces se escucha en el ambiente laboral es una realidad, no existen las condiciones ideales dónde el ingeniero puede tomarse el tiempo que quisiera para complementar su entrevista con otros métodos, el tiempo siempre apremia y cuesta que el cliente lo entregue, otro gran problema.

La barrera del lenguaje de negocio. En muchas ocasiones ocurre que debido a la naturaleza de las actividades desarrolladas por el cliente, éste no puede dejar de lado el lenguaje específico propio del negocio utilizado para describir su actividad ante el ingeniero, y aunque intente dar a entenderse en el lenguaje natural siempre estarán los términos propios de la actividad que no son fáciles de dejar. Por esta razón, el ingeniero debe aprender lo necesario para poder entender al cliente.

Es muy importante que el ingeniero sepa definir bien los tiempos de desarrollo para comprometerse con el cliente, y para esto es crucial contar con un proceso de captura de requisitos bien realizado. Por esta razón es crucial los problemas que son enfrentados ayudará a crear los esquemas mentales necesarios para enfrentarlos y poder anticiparse a ellos.

¿Quiénes somos?

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Thu, 08 Nov 2007 16:57:00 +0000

Somos alumnos de la carrera Ingeniería Civil Informática de la Universidad de Santiago de Chile que se nos ha encomendado, en paralelo con otros compañeros, desarrollar un proyecto para la asignatura Comportamiento Humano en el Trabajo. El proyecto se orienta a las habilidades y competencias de los ingenieros informáticos de hoy en día para realizar la captura de requerimientos para el desarrollo de software.

Blog orientado a alumnos

Uno de los fines del blog es lograr la colaboración e interacción para obtener retroalimentación entre los distintos blogs creados por los alumnos de la asignatura, para así entre todos generar un manual de buenas prácticas para la captura de requerimientos.

Blog orientado a los entrevistados e ingenieros informáticos en general

Por otro lado, el blog también pretende que los ingenieros informáticos (novatos) puedan usarlo como una ayuda. También se le da la función de recibir opiniones y aportes para el proyecto.

Para mayores antecedentes acerca del proyecto dirigirse a Descripción del Problema

En la foto se puede apreciar a los creadores del blog: Felipe Bustamante Villarroel (izquierda) y Francisco Pavez Cornejo (derecha). Dos alumnos aventureros e intrépidos que para lograr las entrevistas recorrieron la capital de extremo a extremo, y gracias a esto comenzaron a desarrollar el proyecto a partir de las entrevistas obtenidas.

Agradecimiento

noreply@blogger.com (Felipe Bustamante y Francisco Pavez.) — Mon, 29 Oct 2007 01:30:00 +0000

Antes de comenzar a desarrollar el contenido de este Blog, nos gustaría agradecer a todos las personas que entrevistamos por su disponibilidad y voluntad brindada en un día laboral.

Ellos son:

Sr. Rodrigo Galvez,

Ingeniero Civil Informático que se desempeña en la empresa D&S. Tiene Actualmente 7 años de experiencia en torno a la captura de requisitos. Participa en proyectos para la misma empresa relacionados con SAP y otros.

Sr. Juan Pablo Castro,

Ingeniero Civil Informático que trabaja en la empresa D&S. Actualmente posee 3 años de experiencia en la captura de requerimientos. También participa en proyectos para la misma empresa relacionados con SAP y otros.

Sr. Nelson Orellana,

Ingeniero Civil Informático con 10 años de experiencia, Trabaja en el Mercurio como jefe del departamento de TI Internet. Los proyectos en los que está involucrado tienen como cliente al Mercurio u otros diarios pertenecientes al Holding de empresas.

Sr. Alejandro Medel,

Ingeniero Civil Informático con 3 años de experiencia en el proceso de la captura de requerimientos, actualmente trabaja en la empresa Taisa. Los proyectos en los que participa tienen a importantes clientes tales como: CODELCO, Banco Estado, Banco Santander.

Sr. Gonzalo Llanquilef,

Ingeniero Civil Informático con 7 años de experiencia en la captura de requisitos, actualmente lidera a otros jefes de proyectos. trabaja en la empresa Lan. Sus clientes pertenecen a la misma empresa, ha participado en una notable cantidad de proyectos.

Sr. Cristían Gajardo,
Ingeniero civil informático con más de 10 años de experiencia en el área de la captura de requisitos. Trabaja en la empresa Taisa, en la cual tiene a otros ingenieros a su cargo. Realizan evaluaciones de proyectos en función de los requisitos recabados. La forma de trabajo de Taisa opera bajo el estándar CMMI5 para el desarrollo de software, lo que normaliza el proceso y documentos en la captura de requerimientos efectuada.

Sr. Nelson Castillo,
Ingeniero electrónico con más de 20 años de experiencia, trabajando en el proceso de toma de requerimientos y de las evaluaciones de proyectos que se negocian con los clientes.Trabaja en la empresa Taisa desempeñando el cargo de Coodinador de negocios.

Sr. Daniel Astargo
Ingeniero comercial de la empresa Cintac S.A orientada al rubro de los metales. Debido a la comercialización de nuevos productos tales como el Metalcon, se necesita un apoyo informático para dar sustento a las diversas necesidades informáticas de esta empresa.

Srta. Pilar Barra
Ingeniera en ejecución industrial, actualmente trabaja para la empresa Unilever Foods Chile Ltda como planificadora de producción en el área de planificación, hace ya 5 años.