Foro de Discusion Grupal para la Web

En esta entrada se publica enlace para el Foro y asi seguir la actividad de la Lectura del Capitulo 7 del Libro de Ingenieria del Software de Roger Pressman en su Sexta Edicion. Las Preguntas se recrean en el foro


Grupo PNF Informática

Conociendo los Requerimientos del Software

Antes de iniciar un proyecto cuya finalidad sea la de crear específicamente un software, sea cual fuere su  naturaleza, se deben determinar una serie de requisitos y/o requerimientos que nos permitan tener una visión más clara de la situación. Una vez que nos encontramos en esta fase del proyecto es muy importante establecer una metodología practica para la determinación de dichos requisitos debido a que por lo general el cliente cree saber todo lo que el software tiene que hacer y en su mente por lo general solo piensa: ‘debe haber un botón que al yo hacerle clic me muestre tal y cual cosa o haga esto o aquello’, o ‘yo quiero que al ingresar esto, me muestre esto y haga esto otro’. Es cierto que el cliente lo que realmente desea es realizar x proceso de una manera más eficiente y expedita, a menudo no le importa cómo, solo desea ver reflejado lo que él espera. Es en este momento que el analista debe poseer la destreza para detectar, corregir y proponer soluciones reales que fundamentados en la información que se le ha suministrado le permita presentar una propuesta o solución que satisfaga las necesidades que espera del cliente.  Es importante destacar que en esta fase lo que piensa el cliente generalmente es diametralmente opuesto a lo que piensa el analista-programador, debido a que ambos es piensan en función de sus experiencias y conocimientos. Mientras que el cliente piensa en lo que debe tener, como por ejemplo un resultado, reporte, etc., el analista-programador piensa en el posible diseño de la base de datos, como va a mantener la integridad y fidelidad de los datos, como adapta lógicamente cierto proceso manual de forma correcta de manera automatizada, y todo esto pensando siempre en no hacer un mal diseño que lo lleve a programar errores, que lógicamente no es lo que quiere el cliente.

Al realizar el estudio de los requerimientos es frecuente encontrarnos con situaciones confusas debido a que la información suministrada y esperada por el cliente no siempre es obvia, y tienen  muchas fuentes, por lo que un mismo problema es resuelto con dos o más formas diferentes por el cliente. En ocasiones podemos observar que el cliente no encuentras las palabras correctas para expresar lo que necesita para un caso especifico, por lo puede decirnos: ‘mira tengo esto y quisiera ver si pudiera obtener aquello’ o ‘no se como usted podría solucionar o mejorar esto’. Esta situación se complica un poco cuando hay varios interesados (llámese departamentos, sucursales, etc.), para los cuales la solución pudiese ser levemente diferente a otro departamento, pero al fin y al cabo los participantes desean lo mismo.

Los requisitos no son más que la determinación de las necesidades mismas que ayudarán a los ingenieros de software a entender mejor el problema en el cual están trabajando. Esto es importante debido a que se debe entender ampliamente lo que el cliente quiere antes de empezar a diseñar y construir un sistema, ya que esto repercutirá en el coste y tiempo necesarios para la culminación exitosa del software.

Podemos enunciar algunos de las especificaciones de los requerimientos:

-    Funcionales: son los que el usuario necesita que efectúe el software, capacidad de resolver un problema o alcanzar un objetivo (entrada, salida y excepciones). Ejemplo: el sistema debe emitir un comprobante al asentar la entrega de mercadería.

-    No funcionales: son los "recursos" para que trabaje el sistema de información (redes, tecnología).

-     Empresariales u Organizacionales: son el marco contextual en el cual se implantará el sistema para conseguir un objetivo macro. Ejemplo: Definir el costo de la industrialización del sistema, teniendo como objetivo disminuir costos de expedición y definir medio de entrega del sistema.

En entornos de software libre, muy frecuentemente el fundador (y gestor) del proyecto será también su primer usuario, pero esto no le exime de esta tarea, que determinará el alcance del proyecto al menos en sus primeras versiones, y permitirá a los desarrolladores que se vayan incorporando al proyecto, hacerse una idea de su progreso y objetivos, así como dónde prestar su ayuda.

Analizando las estadísticas de por qué los proyectos de software fallan según la Quality Sistems & Software tenemos que el mayor índice corresponde a requerimientos incompletos con un 15.9%, seguido de la falta de requerimientos con un 12.4%. Esto nos da una idea de lo importante que es la ingeniería de requisitos y análisis en la práctica a la hora de realizar nuestro proyecto anual.

A fin de realizar un buen estudio de los requerimientos y tener un mejor porcentaje de éxito del software en proyecto, podemos clasificar los requerimientos por: entorno, ergonómicos, interface, funcionales, desempeño, disponibilidad, entrenamiento, restricciones de diseño y materiales.

Entre las técnicas que estamos estudiando para la determinación de los requisitos del software tenemos el Método JAD y el Método FPA.

El Método FPA mejora la definición de los requerimientos comunicando requerimientos funcionales. Estima esfuerzo, agenda y costos basado en requerimientos; al evaluar la factibilidad, de un proyecto se administran los cambios, optimizando el mantenimiento y soporte para así medir la productividad y verificar el desarrollo absoluto del sistema.

El Método JPA (Joint Application Development) es más costoso, depende de la unidad del grupo concerniente al tamaño del proyecto, convive de las metas comunes y de las ideas comunes, es peferida por las compañías por el gran desempeño en los nuevos sistemas para llevarlos a cabo, tanto desarrolladores como usuarios son participantes activos.

Los métodos antes descritos no son más que diferentes técnicas exploratorias para la organización de las etapas que implican la realización de un software. En el caso del método JAD, este se organiza en cinco roles

·         Patrocinador del proyecto: es quien presupuesta el proyecto y proporciona los recursos necesarios para apoyar el proyecto en cuanto a personal técnico, selección de casos de prueba, funcionalidad y evaluación del sistema.

·         Líder del proyecto: podría llamarse el experto que tiene un conocimiento a fondo del área comercial objeto de estudio y de los sistemas de información relacionados con el proyecto y encargado de que las reuniones del equipo de trabajo se reúnan de acuerdo a lo planificado, asegurarse de que se ejecuten las tareas pautadas y en la línea de tiempo estipulada. En otras palabras esta persona es el coordinador de cada uno de los integrantes del equipo que realizan el sistema.

·         Registrador: es quien realiza un resumen conciso de las discusiones y decisiones, en palabras coloquiales seria el cronista, ya que es él quien permite que en los momentos en que el sistema llega a un punto complejo revisar el cuándo y por qué se tomo cierta decisión, lo que contribuye a que el equipo puede reorientarse hacia los objetivos originalmente propuestos.

·         Time keeper: es el responsable de asegurar que se cumpla la agenda establecida a fin de optimizar el tiempo. También son los responsables de todos los materiales necesarios que se necesiten durante la sesión.

·         Clientes: estos son sumamente importante pues son ellos los que conocen como deberá funcionar el sistema y cómo se usa. Ellos ayudaran al equipo a comprender las tareas manipuladas por el sistema.

Sin duda alguna que el comprender este aspecto de la ingeniería de software nos permitirá aumentar las probabilidades de éxito del sistema en que estemos trabajando. La interacción por sí sola de los diferentes elementos que están involucrados en el análisis, diseño y desarrollo de un sistema no garantiza el éxito del mismo, sino más bien la aplicación correcta de un método práctico que garantice la organización y consecución de los objetivos planteados al momento de finalmente decidir realizar el diseño de un software.

Fuente Bibliográfica: 

Ginesta, M.G. y González, A.P. (2005). Ingeniería del Software en Entornos de SL. UOC Formación de Posgrado.

Pressman, R.S. (2002). Ingeniería del Software. Un enfoque práctico. Quinta Edición. México: Mc Graw Hill.

Quizhpe, C.A. y Ramírez S.L. (2009). Ingeniería de Requisitos2621. Universidad Técnica Particular de Loja. Escuela de Ciencias de la Computación.

Rodríguez, N. (2010). Ingeniería del Software: Levantamiento y Recolección de Requerimientos. Extraído el 06 de febrero de 2011 desde www.slideshare.net