Metodologias agiles

3.3 El flujo de trabajo Requisitos

El desarrollo de software es caro. El proceso de desarrollo por lo general comienza cuando el cliente se acerca a una organización de desarrollo con respecto a un producto de software que, en la opinión del cliente, es bien esencial para la rentabilidad de su empresa o de alguna manera se puede justificar económicamente. El objetivo del flujo de trabajo de los requisitos es que la organización de desarrollo para determinar las necesidades del cliente. La primera tarea del equipo de desarrollo es adquirir una comprensión básica del dominio de aplicación (dominio para abreviar), es decir, el entorno específico en el que el producto de software objetivo es operar. El dominio podría ser la banca, la fabricación de automóviles, o la física nuclear. En cualquier etapa del proceso, si el cliente deja de creer que el software será rentable, desarrollo terminará inmediatamente. A lo largo de este capítulo se hace la suposición de que el cliente se siente que el costo se justifica. Por lo tanto, un aspecto vital de desarrollo de software es el caso de negocio, un documento que demuestra la rentabilidad del producto objetivo. (De hecho, el "costo" no siempre es financiera puramente fi. Por ejemplo, el software de militares a menudo se construye por razones estratégicas o tácticas. En este caso, el costo del software es el potencial daño que pudiera sufrir en ausencia del arma se están desarrollando.) En una reunión inicial entre el cliente y los desarrolladores, el cliente describe el producto como él o ella conceptualiza. Desde el punto de vista de los desarrolladores, la descripción que hace el cliente del producto deseado puede ser vago, no razonable, contradictoria, o simplemente imposible de lograr. La tarea de los desarrolladores en esta etapa es determinar exactamente lo que necesita el cliente y para hallar a cabo desde el cliente lo que existen limitaciones.

• Una limitación importante es casi siempre la fecha límite. Por ejemplo, el cliente puede estipular que el producto acabado debe ser completado dentro de los 14 meses. En casi todos los ámbitos de aplicación, ahora es común para un producto de software de destino sea de misión crítica. Es decir, el cliente necesita el producto de software para las actividades básicas de su organización, y cualquier retraso en la entrega del producto objetivo es perjudicial para la organización.

• Una variedad de otras limitaciones a menudo están presentes, como la fiabilidad (por ejemplo, el producto debe estar en funcionamiento el 99 por ciento del tiempo, o el tiempo medio entre fallos debe ser de al menos 4 meses). Otra limitación común es el tamaño de la imagen de carga ejecutable (por ejemplo, tiene que ejecutarse en el ordenador personal del cliente o en el hardware en el interior del satélite).

• El costo es casi siempre una limitación importante. Sin embargo, el cliente rara vez se les dice a los desarrolladores de cuánto dinero está disponible para construir el producto. En su lugar, una práctica común es que, una vez que las especifi caciones han sido nalizado fi, el cliente pide a los desarrolladores para nombrar su precio para completar el proyecto. Los clientes siguen este procedimiento de licitación, con la esperanza de que la cantidad de la oferta de los desarrolladores es menor que la cantidad que el cliente ha presupuestado para el proyecto. La investigación preliminar de las necesidades del cliente a veces se llama el concepto de exploración. En reuniones posteriores entre los miembros del equipo de desarrollo y el equipo de cliente, la funcionalidad del producto propuesto es sucesivamente refi ned y analizado la viabilidad técnica y financiera justifi cación. Hasta ahora, todo parece ser sencillo. Por desgracia, los requisitos workfl OW menudo se realiza de forma inadecuada. Cuando el nalmente producto fi se entrega al usuario, tal vez un año o dos después de las especifi caciones se han firmado por el cliente, el cliente puede decir a los desarrolladores, "Yo sé que esto es lo que pedí, pero no es realmente lo que quería. "¿Qué le pidió al cliente para y, por lo tanto, lo que los desarrolladores pensaban que el cliente quería, no era lo que el cliente realmente necesita. Puede haber varias razones para esta situación. En primer lugar, el cliente no puede entender realmente lo que está pasando en su propia organización. Por ejemplo, no sirve de nada pedir a los desarrolladores de software para un sistema operativo más rápido si la causa de la corriente de respuesta lenta es una base de datos mal diseñado. O, si el cliente opera una cadena de mesa unprofi de tiendas al por menor, el cliente puede solicitar un sistema de información de gestión financiera que refl eja tales artículos como ventas, sueldos, cuentas por pagar y cuentas por cobrar. Dicho producto será de poca utilidad si la verdadera razón de la contracción lossesis (robo por empleados y hurtos). Si ese es el caso, se requiere entonces un sistema de control de existencias en lugar de un sistema de información de gestión financiera.

 Pero la razón principal por la que el cliente solicita con frecuencia para el producto equivocado es que el software es complejo. Si es difi culta para un profesional de visualizar una pieza de software y su funcionalidad del software, el problema es mucho peor para un cliente que es apenas conocimientos de informática. Como se verá en el capítulo 11, el Proceso ed Unifi puede ayudar en este sentido; los muchos diagramas UML del Proceso ed Unifi ayudar al cliente en la obtención de la comprensión detallada necesaria de lo que necesita ser desarrollado.

 3.4 El análisis de flujo de trabajo

 El objetivo del análisis de flujo workfl es analizar y refi ne los requisitos para alcanzar el conocimiento detallado de los requisitos esenciales para el desarrollo de un producto de software correctamente y mantener fácilmente. A primera vista, sin embargo, no hay necesidad de un análisis ow workfl. En su lugar, una manera aparentemente sencilla de proceder sería desarrollar un producto de software al continuar con nuevas iteraciones de los requisitos workfl ow hasta que se haya obtenido la necesaria comprensión del producto de software de destino.

 El punto clave es que la salida de los requisitos workfl flujo debe ser totalmente comprendidos por el cliente. En otras palabras, los artefactos de los requisitos workfl ujo deben expresarse en el idioma del cliente, es decir, en un lenguaje natural (humano), tales como Inglés, Armenio, o Zulu. Pero todas las lenguas naturales, sin excepción, son un tanto imprecisos y se prestan a confusión. Por ejemplo, considere el siguiente párrafo: Un registro parcial y un registro central se leen de la base de datos. Si contiene la letra A directamente seguido de la letra Q, a continuación, calcular el costo del transporte de esa parte de esa planta.

 A primera vista, este requisito parece perfectamente claro. Pero lo que lo hace (la segunda palabra en la segunda frase) se refieren: el récord parte, el registro de la planta, o la base de datos?

 Las ambigüedades de este tipo no pueden surgir si los requisitos se expresan (por ejemplo) en una notación matemática. Sin embargo, si una notación matemática se utiliza para los requisitos, entonces es poco probable que entender mucho de los requisitos del cliente. Como resultado, es muy posible que la falta de comunicación entre el cliente y los desarrolladores con respecto a los requisitos, y por lo tanto, el producto de software desarrollado para satisfacer esos requisitos puede no ser lo que necesita el cliente.

 La solución es tener dos ujos workfl separadas. Los requisitos workfl flujo se expresa en el lenguaje del cliente; el análisis workfl ay, en un lenguaje más preciso que asegura que el diseño e implementación ujos workfl se realizan correctamente. Además, se añaden más detalles durante el análisis workfl ay, no los detalles pertinentes a la comprensión del cliente del producto de software objetivo, pero esencial para los profesionales de software que van a desarrollar el producto de software. Por ejemplo, el estado inicial de un statechart (Sección 13.6) seguramente no afecta al cliente de cualquier manera, pero tiene que ser incluido en las especifi caciones si los desarrolladores son construir el producto de destino correctamente.

 Las especifi caciones del producto constituyen un contrato. Los desarrolladores de software se considera que han finalizado el contrato cuando entregan un producto que es satisfi los criterios de aceptación de las especifi caciones. Por esta razón, las especifi caciones no deben incluir términos imprecisos como términos adecuados, convenientes, amplias, o suficientes, o similares que suenan exacta pero en la práctica son igualmente imprecisas, como óptimo o 98 por ciento completo. Considerando que el desarrollo de software contrato puede dar lugar a una demanda, no hay ninguna posibilidad de las especifi caciones que forman la base para la acción legal cuando el cliente y los desarrolladores son de la misma organización. Sin embargo, incluso en el caso de desarrollo de software interno, las especificaciones siempre se deben escribir como si se van a utilizar como prueba en un juicio.

 Más importante aún, las especifi caciones son esenciales tanto para pruebas y mantenimiento. A menos que las especifi caciones son precisas, no hay manera de determinar si son correctos, y mucho menos si la implementación es satisfi las especifi caciones. Y es difícil cambiar las especifi caciones a menos que algún documento indica exactamente lo que las especifi caciones actualmente. Cuando se utiliza el Proceso ed Unifi, no existe ningún documento pliego de condiciones en el sentido habitual del término. En cambio, un conjunto de artefactos UML se muestra al cliente, como se describe en el Capítulo 13. Estos diagramas UML y sus descripciones pueden obviar muchos (pero no todos) de los problemas del documento pliego de condiciones clásica.

...