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.

...