MCPD 70-547: Requerimientos y Disenio de la Aplicacion

En cada tema que tratemos de la serie MCPD, iniciaremos con una pequeña frase o pregunta, que llame a la reflexión, claro siempre y cuando sea necesario :).

Cuando los requerimientos se terminan después que se termina la aplicación :S…” (f1)

Aunque para las metodologías ágiles, los requerimientos estáticos no son buenos, para eso están las iteraciones para contemplar los nuevos requerimientos o los cambios en algunos requerimientos. Y esto es normal y aceptable, y muchas veces el negocio necesita de estos cambios. Pero hombre, en algún momento tiene que acabar el proyecto, para poder liberar el software, y los nuevos requerimientos podrían pasar a una segunda versión del software. Como pueden ver hay distintos escensarios, y no hay una manera única de afrontar todos los escenarios.

Pero este cambio, en los requerimientos o los nuevos requerimientos, no son el problema, si es que son considerados dentro del ciclo desarrollo, como lo hacen las metodologías ágiles a través de las iteraciones, en lapsops de tiempo razonables. Cuando me refería a la frase f1, me refería más a los requerimientos ambiguos o incompletos, por ejemplo, te dicen: -Quiero una interfaz de usuario bonita. Y tu puedes hacer una interfaz de usuario bonita, para ti, pero no bonita para la persona que te lo pidió, y muchos de estos tipos de requerimientos son una de las cosas que afectan en retrasos en los tiempos de entrega del software.

Ojo, que tampoco se entienda que no se aceptan nuevos requerimientos una vez iniciado, a veces el negocio es el exige nuevos requerimientos, o cambios, imaginemos que el estado, o algún organismo dentro del estado, cambia el formato de la presentación de los registros de la contabilidad, no vas a decir, -no vamos hacer eso por que esta fuera de tiempo dentro de nuestro proyecto. Es que sin eso, puede que tu software le sea inútil a la persona que lo use, y simplemente tienes que hacerlo o hacerlo. Se nota la diferencia en los cambios de estos tipos de requerimientos porque el negocio lo pide, a los cambios por requerimientos ambiguos?, y claro tampoco es que nunca se acabarán los requerimientos, ya que en algún momento se tendrá que cerrar el proyecto, y los nuevos requerimientos deberán ir en una nueva versión del software.

Notar que los requerimientos, no son lo mismo que diagramas de casos de uso. Se pueden complementar, pero no son lo mismo, los requerimientos se pueden resumir como lo que quiere el usuario, y los casos de uso como puntos de vista del proceso que reflejan como cumpliremos con los requerimientos. Y por lo que he visto, puedes hacer proyectos sin casos de uso, pero no puedes hacer proyectos sin requerimientos, y si los haces, el software no será lo que el cliente quiso. Con esto no digo que los diagramas de casos de uso sean innecesarios, es más muchos veces estos podrían aclarar la forma de afrontar un proceso dentro de un escenario, pero con respecto a los diagramas UML pienso que se debería usar siempre y cuando sean necesarios, y no solamente por cumplir, salvo que dentro de tu contrato este contemplado hacer todos los diagramas, aunque algunos de estos no sean ni usados. Pero otro post, responderé al último comentario del último link :D.

Y lograr tener “los requerimientos”, es una tarea que implica empeño y cuidado. Si no me equivoco creo que dentro de la preguntita: “¿Por qué fallan los proyectos?”, un alto porcentaje lo tienen requerimientos incompletos. De lo contrario no se hablaría de la Ingeniería de Requerimientos o Análisis de Requerimientos, ni habrían métodologías para la Ingeniería de Requerimientos. Se clasifican diversos tipos de requerimientos, y me parece bueno, ya que te permite saber si al terminar el software has satisfecho todas las necesidades de la mayoría, no todos, de la organización:

Business Requirements, normalmente la visión del negocio, como por ejemplo, después de la implementación del sistema, quiero estar entre las principales organizaciones de mi rubro.

User Requirements, son los requerimientos que tiene que hacer el usuario final para cumplir su trabajo, como por ejemplo, quiero que cada vez que realice una venta, el stock de mi producto disminuya.

Functional Requirements, estos pueden derivarse de los requerimientos del negocio, y los requerimientos del usuario, y son básicamente los requerimientos que necesitas para el desarrollo, como por ejemplo, voy a necesitar crear controles de búsqueda.

Quality-of-Service Requirements, o antes llamados requerimientos no funcionales, como dice el nombre, estos son los que darán la calidad a tu servicio, y estos giran alrededor de la performance, escalabilidad, estándares, y otros. -No quiero que mis transacciones demoren más de 60 segundos. Sobre este termino se está enfatizando bastante, y muchas guías de implementación de soluciónes, ahondan sobre ellos: Sun Java Enterprise System Deployment Planning Guide, ahi podemos encontrar otros términos como seguridad, disponibilidad entre otros.

Ya tienes los requerimientos completos?, eso es lo que crees, y viene el siguiente paso, el diseño mi aplicación. Para los que tiene amplia experiencia, esta no debe ser una tarea difícil, claro dependiendo del escenario. Pero que pasa si es tu primera aplicación?, una recomendación que me gusto del libro, y que siempre recomiendo, es revisar aplicaciones Web ya existentes. Es obvio, que pocas veces encontrarás a algún buen amigo que te comparta su aplicación. Pero hasta que llegue el amigo, que nos comparta sus aplicaciones, nosotros tenemos Starter Kits, y otras aplicaciones que hay de MS, y otros modelos que encontremos en la web.

No siempre nuestro primer diseño, será el mejor, pero hay que tratar de que sea el menos peor, y leer las recomendaciones de gente que haya hecho algunos diseños, y tratar por lo menos que nuestro diseño sea flexible a los cambios, como un modelo en capas.

Para comprobar el correcto diseño de una aplicación, podemos realizar prototipos y hacer pruebas de concepto (POC), y verificar la validez de nuestro diseño. Ojo, tampoco van a tomar todos los requerimientos para hacer el prototipo *-), si no, ya no fuera prototipo. Como comentario, en muchas empresas (casa de software), apuestan por la realización de prototipos para implementar nuevas tecnologías o vender algunos productos, muchas veces estos prototipos son hasta gratis para las empresas que acepta la implementación, obvio que el beneficio viene después tanto para la empresa donde se implementa el prototipo, y para la casa de software.

En el libro, hablan sobre dos tipos de prototipos Mock-up y POC, digamos que Mock-up es como sólo el diseño de la aplicación, y POC es la funcionalidad que debe cumplir con los requerimientos, y al final los dos hacen el prototipo.

A ver resumiendo:

  • Tener claro los requerimientos, no pasar requerimientos ambiguos o incompletos. Hay algunas características para saber que tenemos un buen requerimiento, que no se ambiguo, que este completo, que sea necesario, que sea fiable, entro otros.
  • Si aparecen cambios en los requerimientos, dejarlos para la siguiente iteración, y si los cambios son grandes e impiden que se cierre un proyecto, dejarlos para la siguiente versión.
  • Tener cuidado al hacer el diseño de la aplicación, y realizar un pequeño prototipo para verificar la validez de nuestro modelo.

Y algo que me olvidaba, siempre tratar de que los requerimientos estén escritos y aprobados. Ya que muchas veces esta es nuestra carta de defensa, y es que a veces se proyecta una duración de dos meses para un grupo de N requerimientos, pero en el primer mes se cambian requerimientos ambiguos o incompletos, y ahora son N^ requerimientos, y si no tenemos documentado los requerimientos iniciales, al final la culpa de no terminar en los dos meses, adivinen de quién es?, y es ahí cuando el programador deja de tener vida, se debería considerar que si hubo requerimientos ambiguos, el trabajo ya se avanzo, y si se hizo mal o bien (por que fue con requerimientos ambiguos), ya esta hecho, y se invirtió tiempo en el, se debe ser consciente que ya no se terminará, en dos meses, quizá se necesita de un par de semanas más. Tampoco se debe cerrar a que no se termina en dos meses y punto, si necesita para ese tiempo, simplemente por que se necesita, se podría contar con otro recurso, que ayude a corregir la implantación de los cambios en los requerimientos, para que así los demás recursos puedan continuar con su trabajo normal, y se termine en el tiempo requerido. Revisar la Tabla 2, de este PDF, y ver como afecta requerimientos incompletos en el ciclo de vida desarrollo de software, diseño y codificación.

Otros Links que encontré por ahi:

P.D.: Esto es la parte teoría de lo que he visto que ha pasado, y que yo mismo he pasado, en los proyectos, aunque en los proyectos es más emocionante y más presionante, full adrenalina :).

Saludos,

Post cruzado

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *