Impacto socioeconómico y cultural de un nuevo modelo basado en conocimientos para la identificación de requisitos de software a partir de información no estructurada.

...

Los ingenieros de software tienen significativas oportunidades de hacer el bien o causar daño, permitir que otros hagan el bien o causen daño o influir en otros para hacer el bien o causar daño (Sommerville, Ingenieria de Software, 2011). La responsabilidad que recae hacia los Ingenieros en Sistemas es muy grande y deben tener en claro muchos aspectos éticos en cuanto a la realización de su trabajo porque estos de no ser buenos pueden causar mucho daño a la sociedad, además de ellos depende que cada vez más personas decidan utilizar nuevos sistemas para realizar tareas cotidianas.

La captura de requisitos como problema crucial en el desarrollo del software.

Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, proceso o salida (Pressman, 2011). Los clientes por lo general no están familiarizados con la programación de sistemas asumiendo que los desarrolladores solo necesitan conocer ciertos detalles de la aplicación que necesitan y creen que especificar paso a paso el proceso no es necesario ya que el ingeniero debe saberlo, gracias a este problema a la hora de entregar los sistemas aparecen detalles que el cliente no cree correctos llegando a desconfiar de las capacidades del desarrollador sin darse cuenta de que la culpa fue suya por no haber detallado de manera clara todos los requerimientos de su sistema ya que este es de suma importancia para obtener un software de buena calidad y que cumpla con todas las peticiones realizadas por el cliente.

Aunque generalmente se piensa que la captura de requisitos resulta fácil para los ingenieros, esto no es así y cambia para cada cliente porque siempre son personalidades diferentes y siempre se pretende lograr una comunicación estable entre ambas partes; se podría decir que “La primera reunión entre un ingeniero de software (el analista) y el cliente puede compararse a la primera cita entre adolescentes. Ninguna persona sabe lo que decir o preguntar; ambos están preocupados por si lo que dicen es mal interpretado” (Pressman, 2011). “Nunca se tiene una segunda oportunidad para dar una primera impresión” resulta muy importante para el desarrollo del proyecto que el ingeniero logre dar una buena impresión en la primera cita ya que la comunicación es la clave para la captura de requisitos.

Los clientes y los ingenieros de software con frecuencia tienen establecido inconscientemente el pensamiento de «nosotros y ellos». En lugar de trabajar como un equipo para identificar y refinar los requisitos, cada uno define su propio «territorio» y se comunica por medio de memorandos, documentos formales de situación, sesiones de preguntas y respuestas e informes (Pressman, 2011). Muchos de los procesos de obtención de requerimientos se realizan bajo estos parámetro y se puede decir que los resultados obtenidos no son los mejores ya que la comunicación entre ambas partes no se da con claridad, lo ideal sería una comunicación fluida entre las partes intervinientes porque de esta manera se podrán despejar dudas y culminar procesos de manera rápida y sin complicaciones, evitando que al final surjan malentendidos o se omita información importante por no haber establecido una relación de trabajo con éxito.

Según Pressman con estos problemas en mente es por lo que algunos investigadores independientes han desarrollado un enfoque orientado al equipo para la reunión de requisitos que se aplica durante las primeras fases del análisis y especificación. Denominadas Técnicas para facilitar las especificaciones de la aplicación (TFEA), este enfoque es partidario de la creación de un equipo conjunto de clientes y desarrolladores que trabajan juntos para identificar el problema, proponer soluciones, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución. Esta sería la solución más acertada al momento de realizar la captura de requisitos ya que se mantienen involucradas ambas partes en el proceso e incluso se podría evitar reclamos de último minuto por parte de los clientes ya que si sus necesidades fueron entendidas correctamente no existirán problemas al momento de la puesta en marcha del sistema, ahorrando importantes cantidades de dinero en procesos de reacondicionamiento del software.

Los problemas más comunes que aparecen en la captura de requisitos según (Davey, 2008) son los siguientes:

• Requisitos incompletos, toma lugar cuando la necesidad del cliente no es entendida correctamente y esta no puede ser transmitida con claridad hacia el equipo desarrollador.

• Conocimiento incompleto del dominio, se refiere a que los usuarios generalmente brindan una pobre colaboración al momento de las reuniones.

• Ambigüedad de requisitos, surgen como resultado de las condiciones sinónimas y homónimas.

• Requisitos incoherentes, se refiere cuando el cliente no tiene bien definido lo que desea que el sistema realice en algún determinado proceso ocasionando que no se llegue a algo concreto.

• Requisitos excesivos, generalmente se dan cuando existen fuentes de información voluminosas de las cuales serán complicadas las abstracciones de los requisitos.

• Diferentes tipos de vista de la problemática, conlleva a que los conflictos no sean solucionados de manera clara generando inconformidad entre las partes involucradas.

Análisis Documental

Abad de R.J propuso que la idea que el texto del idioma natural puede usarse para identificar requisitos re sistemas orientado a abjetos, nombres de clases, objetos y métodos puede identificarse de los verbos en una frase. El objetivo mayor de análisis es identificar conceptos del Idioma Natural que puede planearse en el formulario de conceptos orientados a objeto. Marinos G. Georgiades recomendó una nueva herramienta del software por apoyar y automatizar los requisitos que diseñan el proceso con el uso de idioma natural. Carlos Mario Zapata usó las plantillas por recoger los requisitos. Syed Ahsan usó las encuestas, se mandaron por correo las preguntas a clientes para a través de los dispositivos móviles sacar los requisitos. (S. Murugesh, 2014)

El tratamiento documental significa extracción científico-informativa, una extracción que se propone ser un reflejo objetivo de la fuente original, pero que, soslaya los nuevos mensajes subyacentes en el documento.

El análisis documental es una forma de investigación técnica, un conjunto de operaciones intelectuales, que buscan describir y representar los documentos