Trabajo Con Requerimientos

Trabajo con Requerimientos
Captulo nro 3
Calidad en el Desarrollo de Software Guillermo Pantaleo
Pgina 0
Tabla de contenido
IMPORTANCIA DE LOS REQUERIMIENTOS.................................................... 1 EL ROL DE ANALISTA ..........................................................................................1 Definicin .................................................................................................1 QU SON LOS REQUERIMIENTOS? .........................................................................2 PARA QU SIRVEN? ..........................................................................................2 CUL ES EL IMPACTO EN UN PROYECTO DE DESARROLLO DE SOFTWARE?.............................2 TAREAS ASOCIADAS A LOS REQUERIMIENTOS............................................. 6 FOCO............................................................................................................7 NIVEL ...........................................................................................................8 VISTA ...........................................................................................................8 ESTRATEGIA Y TCTICAS EN EL TRABAJO CON REQUERIMIENTOS ............ 10 ESTRATEGIA.................................................................................................. 10 TCTICAS..................................................................................................... 12 Especificacin de requerimientos de software y sus Atributos de calidad ......... 12 Especificacin de casos de uso .................................................................. 13 ANLISIS DE REQUERIMIENTOS ................................................................ 15 NO CONFUNDIR DOMINIO Y NEGOCIO CON DISEO ........................................ 15 Nota para desarrolladores giles................................................................ 21 Nota a los analistas de sistemas ................................................................ 21 PAQUETES .................................................................................................... 21 Alternativas de seleccin .......................................................................... 21 VALIDACIN Y VERIFICACIN ................................................................... 23
VALIDACIN .................................................................................................. 23
VERIFICACIN ............................................................................................... 23 ADMINISTRACIN DE CAMBIOS A LOS REQUERIMIENTOS......................... 26 PROBLEMA .................................................................................................... 26 ALTERNATIVAS DE SOLUCIN .............................................................................. 27 Nota para desarrolladores giles................................................................ 28 CONCLUSIN.............................................................................................. 29 REFERENCIAS............................................................................................. 30
Pgina 0
Importancia de los Requerimientos

En un captulo anterior hemos analizado cules son las causas del fracaso de los proyectos de desarrollo de sistemas. En ste, despus de haber establecido las condiciones apropiadas en el contexto de la organizacin y su rea de desarrollo, administrando las consecuencias generadas por los cambos, nos ocuparemos del trabajo con los requerimientos. Debo decir que en una gran cantidad de los proyectos que me toc revisar de las ms variadas empresas, el trabajo con los requerimientos estaba desprestigiado. Era visto como una actividad de segunda categora, siendo el diseo y programacin la actividad de primera. Esta visin de las actividades relacionadas a los requerimientos produca una realimentacin positiva en el sentido de que se le asignaban menos recursos para la adquisicin de herramientas y capacitaciones. Tambin, aunque parezca increble se asignaba menos tiempo a la concepcin de los sistemas ha desarrollar que a las otras tareas de los proyectos, con las consecuencias imaginables. Creo que los fabricantes y vendedores de tecnologa son en gran parte responsables de esta desvirtualizacin al promover la sensacin de que si se domina tal o cual framework o herramienta basta para convertir a los proyectos en exitosos. La confusin llega a tal nivel que tambin los analistas son vistos como desarrolladores de segunda clase. En algunos grupos que he conocido en los cuales se trabajaba utilizando alguna metodologa gil, ninguno de los desarrolladores desarrollaba el rol de analista, como si bastara con la cercana del cliente para que los requerimientos del sistema ha desarrollar se plasmaran solos, por generacin espontnea, en un listado o diagrama de casos de uso. Solo atinaban a analizar history bords en targetas con escenarios no siempre entendidos y casi nunca sistematizados. El trabajo con requerimientos necesita de un rol especializado que lo conduzca y ese es el analista.
EL ROL DE ANALISTA
Definicin
El analista es el rol que en un grupo de desarrollo de software posee una doble interfaz, una hacia el negocio y otra hacia el seno del gupo de desarrollo. Interfaz de negocio: para implementar esta interfaz el analista debe estar capacitado en tcnicas de relevamiento de requerimientos, UML (diagramas de actividad, estado y secuencia) y documentacin de procesos de negocio. Interfaz de Desarrollo: para implementar esta interfaz el analista debe estar capacitado para trasladar el producto de su trabajo con los usuarios y clientes al seno del grupo de desarrollo. Para esto debe saber UML(clases, casos de uso y paquetes), participar en la construccin de un modelo de dominio y debe tener conocimientos bsicos de arquitectura de sistemas. Como se desprende de esta definicin, necesitamos un profesional capaz y con muy buena formacin, ya que el rol en cuestin es muy abarcativo.
Calidad en el Desarrollo de Software Guillemo Pantaleo
Pgina 1
Existe en el mercado laboral de la informtica y por consiguiente en las empresas un concepto asociado a este rol que es viejo y obsoleto. Se piensa en l como aquel que releva requerimientos sin ninguna formacin tecnolgica. Esta visin est ligada a paradigmas superados y corresponde a la que se tena hace dos o tres dcadas. Debo decir que contribuyen a esta visin algunas carreras universitarias con planes no siempre debidamente actualizados. Para comenzar entonces a tratar el tema de trabajo con los requerimientos comenzaremos respondiendonos las siguientes preguntas bsicas:
QU SON LOS REQUERIMIENTOS?

o o o Definen lo que un sistema permite hacer desde el punto de vista del usuario (funcionales) Definen condiciones de funcionamiento del sistema en el ambiente operacional (no funcionales) Definen las condiciones a cumplir durante el desarrollo (de proceso)
PARA QU SIRVEN?
o o o Definir el sistema a desarrollar Comunicar y acordar el alcance y las prioridades Planear el proyecto de desarrollo
CUL ES EL IMPACTO EN UN PROYECTO DE DESARROLLO DE SOFTWARE?

o La calidad del trabajo con los Requerimeintos determinan la buena o mala evolucin y posterior terminacin del proceso de desarrollo del proyecto El costo del proyecto puede verse influenciado en forma determinante por la calidad del trabajo con los Requerimientos Las fallas ms graves en el desarrollo de sistemas se deben a las generadas por errores en el trabajo con los Requerimientos
o o
Para respaldar y justificar nuestras propuestas acerca de la importancia de los requerimientos en el desarrollo de software apelaremos a un par de publicaciones muy conocidas que nos ayudarn a fundamentar algunas de las aseveraciones anteriores. La primera es el informe del Standish Group [1] y el segundo es un artculo [2] publicado hace ya algn tiempo. Los resultados del primero se mostraron en una figura del captulo primero y se pueden ver las causas por la cuales los proyectos mostrados en dicho informe se comportaron de la forma mostrada. La tercera de las causas enumeradas en dicho informe fue un mal entendimiento de los Requerimientos. Qu significa un mal entendimiento? Significa lo siguiente: Calidad en el Desarrollo de Software Guillemo Pantaleo Pgina 2
Falta de conocimiento del negocio por parte del cliente y usuarios Falta de comunicacin del conocimiento que se tiene del negocio por parte del cliente y usuarios Falta de colaboracin con los desarrolladores en el relevamiento y anlisis por parte del cliente y usuarios Falta de planificacin de las tareas de trabajo con los requerimientos por parte de los desarrolladores Falta de conocimiento de la forma de construir modelos de requerimientos que faciliten el posterior diseo por parte de los desarrolladores Falta de comprensin, del concepto clave acerca de que el desarrollo debe siempre ser conducido por los requerimientos, por parte de los desarrolladores Falta de validacin y verificacin de los requerimientos por parte de los desarrolladores En resumen el no entendimiento de los requerimientos significa no conocer o reconocer alguno de los aspectos mencionados en el listado anterior. Respecto de la validacin y verificacin, en [2] se analizan sistemas famosos que han fallado y se clasifica a estos sistemas segn la fuente de error, es decir las falencias en la realizacin de dichas tareas. En las grficas que siguen, adaptadas de [2] se muestra esta clasificacin y el criterio de dicha clasificacin. Se desea fundamentar, con la referencia a este trabajo, el rol fundamental del relevamiento y anlisis por un lado; y de la validacin y verificacin de los requerimientos por otro. Los sistemas de la tabla que sigue fueron analizados en ste artculo y se concluy que tuvieron falencias en alguno de los siguientes aspectos1: RD: desarrollo de requerimientos (validacin de requerimientos) VER: verificacin (de requerimientos) VAL: validacin (de sistemas) Tareas mal realizadas en los sistemas famosos relevados Nombre del Sistema
HMS Titanic: transatlntico naufragado al chocar con un tmpano de hielo mientras navegaba. Tacoma Narrows Bridge: puente que se desplom entrando en resonancia al ser atravezado por un fuerte viento. Apollo 13: mdulo lunar que se qued sin sistema de ventilacin mientras orbitaba la luna. Concorde SST: aeronave de pasajeros pensada para volar por 40 aos y que se dej de utilizar mucho antes. IBM Pcjr: primera computadora portable que no sali nunca a la venta al mercado.
Ao
1912 1940
RD
NO SI
VER
NO SI
VAL
SI NO
1970 1976 2003 1983
SI SI
NO SI
SI NO
NO
SI
SI
Definiciones del modelo CMMi Pgina 3
Space Shuttle Challenger: transbordador espacial que explot al despegar. Chernobyl Nuclear Power Plant: plata atmica de generacin de energa que se descontrol y esparci material atmico al exterior de su estructura. A12 airplane: aeronave militar que nunca fue construida por falta de visin. Ariane 5 missile: cohete que explot al perder el control cuando despegaba. Mars Climate Orbiter: nave de exploracin interplanetaria que se extrell contra Marte cuando sobrebolaba el planeta. Space Shuttle Columbia: transbordador espacial que explot cuando reingresaba a la atmsfera de la tierra.
1986 1986
SI SI
NO SI
NO NO
1980s 1996 1999
NO SI NO
NO NO NO
NO NO NO
2002
SI
NO
NO
Con un NO en la tabla se indica que la tarea asociada no fue llevada delante de la forma correcta o ni siquiera fue realizada. Los sistemas de la tabla anterior son solo algunos de los presentados en [2]. Estos sistemas son conocidos por las consecuencias que gener su fracaso. En la figura que sigue se muestra la matriz de dos dimensiones que define el modelo SRCM (System Requirement Clasiffication Model) propuesto por los autores. La idea del modelo es clasificar a los sistemas segn alguna de las categoras expresadas por cada celda de la matriz, adaptada de [2]. Modelo de clasificacin de Requerimientos y Sistemas (SRCM) Sistema verificado y validado
A1 A2
Sistema no verificado y no validado

B1 B2
Sin sistema
C1 C2
Requerimientos vlidos Requerimientos incorrectos, incompletos o inconsistentes Sin requerimientos Requerimientos no factibles
A3
B3
C3 C4
Si hacemos el ejercicio de clasificar a los sistemas de la tabla anterior segn este modelo, obtendremos el resultado que se muestra en la figura que sigue.
Pgina 4
Distribucin SRCM
C2 8% 8% B2 8% 17% 59% B1 A2 C4
1 2 3 4 5
Claramente se observa que mayoritariamente los sistemas de tipo B1 con requerimientos vlidos pero no validados y no verificados son los que dominan. De este ejemplo podemos concluir que un factor determinante a la hora de planificar el desarrollo de sistemas es de primersima importancia invertir recursos en la ingeniera (relevamiento y modelado), en la validacin y en la verificacin de los requerimientos en los proyectos. Como muestra este ejemplo, el trabajo con los requerimientos no se agota en el relevamiento y el listado resultante, los sistemas necesitan validar reglas que el negocio impone y que deben ser analizadas por los involucrados, comprendidas y asignadas a las entidades indicadas de un modelo que represente el comportamiento del negocio. Los requerimientos deben expresar las condiciones de funcionamiento del sistema en desarrollo. Los requerimientos, como tantas veces se expresa deben describir el sistema que los clientes y usuarios necesitan para lo cual hay que validarlos. Los requerimientos deben ser verificados, para comprobar que cubren todos los requerimientos y el sistema que los implementa posee el comportamiento esperado en el ambiente operacional definido. Estos temas son desarrollados en las prximas secciones de este captulo.
Pgina 5
Tareas asociadas a los requerimientos

En la figura que sigue se muestran las tareas realizadas con los requerimientos. Algunas de ellas centradas en los mismos y otras para las cuales los requerimientos sirven como soporte, como lo son las estimaciones de alcance y esfuerzo y el establecimiento de prioridades en la planificacin de los proyectos. Estas tareas son llevadas adelante por los diferentes roles involucrados, poseen un nivel de granularidad distinto, son llevadas adelante en distintos momentos del ciclo de vida del proyecto y adems generan productos diferentes.
Es importante mencionar estas diferencias para ubicar a los productos generados como resultado del trabajo con los requerimientos en cada momento del ciclo de vida del proyecto y apreciar entonces el valor agregado por cada uno de ellos. Estos distintos aspectos del modelo de requerimientos es muy bien presentado en [5]. En la figura siguiente se muestra un esquema que muestra estos aspectos.
Pgina 6
FOCO
El enfoque desde el cual son modelados los Requerimientos es un factor determinante. A este enfoque contribuyen las respuestas a las siguientes preguntas, quin lo realiza, qu se trata, dnde, por qu y cmo. Este contexto abarcativo fue utilizado por Zachman [5] para ampliar el escenario en el cual se definen las arquitecturas de tipo enterprise y ha mostrado ser apropiado en otros campos de la tecnologa. En el caso de los Requerimientos son la gua para determinar: La Visin del Proyecto (por qu) La inclusin del vnculo de todos los involucrados en el negocio (quin) El alcance del sistema a desarrollar (qu) Las condiciones del ambiente operacional (dnde) El comportamiento funcional esperado (cmo) Los eventos del negocio (cundo)
Pgina 7
NIVEL
El nivel determina el grado de granularidad o detalle con que son tratados cada uno de los aspectos sobre los que se trabaja. Depende fuertemente del momento del ciclo de vida: Preventa (intencin) Inicio del Proyecto (alcance) Concepcin y Planificacin (alto nivel) Implementacin (detalle)
VISTA
Existen varias vistas de los requerimientos dependiendo de los modelos que se utilicen. Estructura (modelo de dominio) Dinmica (diagramas de secuencia) Comportamiento (diagramas de casos de uso) Control (reglas de negocio, modelo de anlisis) Cada uno de estos modelos implica un conocimiento menor o mayor del negocio a resolver con el sistema que se construir, por esta razn es tambin interesante vincular estas vistas con los niveles en que son de utilidad. En la figura que sigue, adaptada de [5], se muestra esta relacin siguiendo el modelo de Zachman. El contenido de cada una de las celdas de la matriz est constituida por los modelos de las Vistas presentadas anteriormente. Una ltima relacin que es interesante a tener en cuenta es la que existe entre las Vistas y el ciclo de vida del proyecto. Esta es muy similar a la que existe con los niveles, debido a que a medida que evoluciona el proyecto, es mayor la informacin con que se cuenta y por lo tanto son ms detallados los modelos que pueden construirse. Con la presentacin de esta matriz buscamos vincular todas las tareas que se desarrollan y los modelos que se construyen en el trabajo con los requerimientos y que iremos siguiendo a medida que avancemos en el desarrollo de los diferentes temas.
Pgina 8
Foco Qu Caractersticas Intencin Listado de Requerimientos Alcance Cmo Listado de Procesos de Negocio Diagramas de Actividad Dnde Diagramas de Contexto Ambiente Operativo, Rquerimientos No Funcionales Subsistema, Mdulo Actores Descripcin Quin Workflow (roles y actividades) Rol de Negocio Cundo Listado de eventos Cronograma de Negocio Por Qu Visin Objetivos Prioridades de Negocio Alcance Intencin
Nivel
Alto Nivel
Listado Casos Uso, Trazas
Especificacin de Casos de Uso principales Especificacin de Casos de Uso, Prototipo de Navegacin
Precedencia de Casos de Uso
Prioridades del Proyecto, Reglas de Negocio
Alto Nivel
Detalle
Diagrama Casos de Uso, Prototipos de Interfaces, Modelo de Dominio
Paquete
Actores Permisos Responsabilidades
Diagramas de Estados
Reglas de Negocio asignadas en el Modelo de Anlisis
Detalle
Pgina 9
Estrategia y tcticas en el trabajo con requerimientos

ESTRATEGIA
Como en casi todos los aspectos de un proyecto, el trabajo con los Requerimientos, depende de las caractersticas del proyecto y de la metodologa con que se trabaje. Proponemos un modelo de trabajo que presenta a las tareas que nos interesan como un mini proceso cuya formalidad ir decreciendo con el volmen del proyecto. Este modelo nos permitir cubrir proyectos grandes con una forma de trabajo con Requerimientos tipo workshop donde participarn varios involucrados que se ir simplificando a medida que encaremos sistemas ms simples terminando as con la participacin de un analista entrevistando a un usuario. Sin embargo, conservaremos algunas cuestiones esenciales que a nuestro entender deben ser tenidas en cuenta siempre y que hemos visto ausentes en muchos proyectos.
Planear
Pr en tra Defin da ir lug s ar, p roce prod uctos so y ep ara r
Prep arar Co el me Hacer nz lugar ar reu la ni n
Definir propsito y participantes

so roce
Proceso de trabajo con Requerimientos
Cerrar la reunin
Revi sar
r el p justa A
lor va l ir e do ed rega M g a
Actuar
Evaluar
Como se propone en [5], en la figura se muestra un ciclo de trabajo en el cual se nombran todas las actividades a llevar adelante. Este modelo propone planificar, ejecutar, evaluar y actuar. Es comn en proyectos medianos a chicos desarrollar el relevamiento de Requerimientos y su anlisis sin Calidad en el Desarrollo de Software Guillermo Pantaleo Pgina 10
planificacin ninguna, es comn establecer reuniones sin un claro propsito a las cuales los usuarios acuden a hablar de sus necesidades y las analistas a tomar notas sin ninguna planificacin previa. Esto impide a los usuarios preparar y ordenar sus conocimientos del negocio y a los analistas a definir una estrategia de avanzar sobre los diferentes aspectos del problema a investigar. Este modelo de trabajo [5], denominado workshop de colaboracin es ideal para proyectos grandes y formales y fcil de adaptar a proyectos menores. En su fortaleza radica tambin su debilidad. Su fortaleza consiste en que organizar el trabajo de esta forma requiere de la participacin de todos los involucrados; su debilidad en que para que esto sea posible se requiere una madurez importante por parte de todas las partes. Este modelo lo explicaremos enumerando algunos beneficios, ejemplificando cada uno de sus partes con los escenarios que comunmente se observan en los proyectos. Planear permite: conocer el propsito de la reunin, los temas a tratar, conocer de antemano quines participarn, planificar la agenda de los involucrados que debern asistir, preparar la documentacin por parte de los usuarios y clientes, ordenar y planificar el desarrollo de las preguntas a hacer por parte de los analistas. Planear evita: reuniones donde los asistentes se enteran del motivo de la misma cuando acuden a ellas, ausencias por falta de comunicacin sin el tiempo previo necesario, postergaciones para prximas reuniones por falta de informacin, falta de documentacin por desconocimiento de su necesidad, tertulias donde se tratan los ms diversos temas y ninguno relacionado con el sistema a desarrollar. Ejecutar permite: desarrollar la reunin de la manera planeada, en el lugar establecido, en los tiempos planificados, con las personas indicadas y definidas. Ejecutar evita: no contar con una sala para el desarrollo, demoras hasta que se nos asigna una, esperas a asistentes que acuden a horarios diferentes, tratar temas dispersos con escaso valor agregado. Evaluar permite: ordenar los resultados de las reuniones y publicarlas a todos los involucrados, dar consistencia a los productos generados, analizar y organizar el trabajo, contar con modelos relacionados y traceables, contar con modelos sobre los cuales basar los acuerdos. Evaluar evita: generar sensacin de que el esfuerzo anterior fue en bano, requerimeintos personalizados y solo conocidos por los interesados, proyectos con escaza visibilidad, falta de acuerdo por falta de visibilidad. Actuar permite: mejorar y aprender de la forma de trabajo, corregir y hacer ajustes en la direccin apropiada para el proyecto. Actuar evita: repetir errores de organizacin, repetir errores de desarrollo, desacuerdos, ausencia de conduccin y sensacin de falta de gestin. Deseamos hacer notar que no proponemos activos con formatos determinados para ayudarnos en estas tareas debido a que no queremos que el lector caiga en la tentacin de valorar el modelo anterior a partir de un documento. Dejamos que dicho documento lo elabore a medida de sus necesidades. Lo importante es rescatar el
Pgina 11
ejercicio de pensarlo, acordarlo y proponerlo al seno de la organizacin y el proyecto a partir de una forma de trabajo como la descripta. Tambin pensamos que la esencia de esta forma de trabajo trasciende la metodologa elegida para llevar adelante el proyecto.
TCTICAS
Especificacin de requerimientos de software y sus Atributos de calidad
Entendemos por especificacin de requerimeintos de software al listado de el sistema debe derivado a partir de relevar las necesidades de los usuarios. Estos requerimientos funcionales expresan la totalidad de la funcionalidad que el sistema brindar. Este listado de requerimientos fue dejado de lado, no utilizado por los seguidores de metodologas tipo UP (Unified Process Software Development) apoyndose en el uso de los casos de uso como mtodo no slo de modelar sino de relevar requerimientos en las diferentes herramientas de tipo CASE que implementan UML (Unified Modelling Lenguage). Hemos observado errores de los ms diversos cuando se trabaja de esa forma y con esos diagramas sin pasar previamente por un listado de requerimientos que cumplan con atributos tales como []: Completitud Correctitud No ambigedad
Nuestra experiencia nos indica que para elaborar un diagrama de casos de uso es necesario hacer un ejercicio de elaboracin en el cual se cometen los errores mencionados. Por esta razn recomendamos la utilizacin de un listado de requerimientos como paso previo a la elaboracin de los casos de uso. Otra razn por la que recomendamos dicho listado se debe a que los requerimientos deben ser acordados con todos los involucrados en un proyecto. A pesar de los esfuerzos marketineros de venta de los casos de uso por parte de los vendedores de herramientas, utilizando el argumento de que son muy fciles de entender, los usuarios y clientes no los entienden y no desean verlos. Por esta razn es necesario comunicarse y acordar con ellos a partir de un listado bien construido de requerimientos. En los apndices se presenta un ejemplo de una ERS(Especificacin de Requerimientos de Software) donde puede verse un listado bien escrito. Un listado de requerimientos bien escrito debe, entre otras cosas, no presentar ambigedad. Cunto ms detallado sea mejor escrito estar. Un error comn que hemos observado en gran cantidad de proyectos es la escritura o especificacin de los requerimientos expresando caractersticas del producto a construir ms que requerimientos. Esto es consecuencia, en la mayor parte de los casos, de falta de informacin detallada y expresiones concretas que describan a los requerimientos. Esa es la razn por la cual algunas ERS se parecen ms a un prospecto o folleto de
Pgina 12
publicidad de un producto que a un listado de requerimientos como se muestra en la tabla que sigue. Caractersticas de producto Requerimientos El sistema permitir la registracin de clientes El sistema permitir la administracin de clientes Los operadores y supervisores podrn modificar los datos de los clientes El sistema mantendr un registro histrico de clientes El sistema permitir generar solicitudes de reclamos El sistema permitir la administracin de reclamos El sistema permitir realizar el seguimiento de las solicitudes de reclamos segn sus estados Los supervisores podrn aceptar o rechazar las solicitudes de reclamos generando crditos en las cuentas de los clientes en los casos que corresponda
Especificacin de casos de uso

Todava despus de una dcada de la masificacin de la adopcin de los casos de uso como forma de modelar requerimientos se sigue sobreusando y usando mal estos diagramas. La tentacin creada por las herramientas CASE al facilitar la creacin de dichos artefactos hace que muchos desarrolladores slo construyan estos diagramas sin ninguna especificacin textual de los casos de uso participantes. Esta es la causa de la creacin de casos de uso que cuando se analizan en ms detalle no se sabe cul es su razn de ser. Por estos motivos aconsejamos la especificacin textual como medio de dar consistencia y precisin a estos diagramas. Otro abuso y mal uso se debe a la utilizacin de relaciones entre casos de uso. En nuestra experiencia las relaciones tiles son las de inclusin (include) y extensin (extend); no as la de generalizacin (herencia, extensin, especializacin). La razn es que si bien las herramientas facilitan su diagramacin, es muy confusa su especificacin textual. En nuestra experiencia ha sido de mucha utilidad complementar la especificacin con un prototipo de interfaces y un diseo lgico de las mismas que muestren los tipos de los campos manipulados, las condiciones de obligatoriedad, las condiciones de modificabilidad, reglas a validar y la relacin con el modelo de anlisis. En un apndice se presentan un ejemplo completo de especificacin de caso de uso donde pueden verse todos los aspectos mencionados. La figura que sigue muestra los artefactos propuestos que conforman la definicin de cada caso de uso.
Pgina 13
uc REQ
Definicin de Caso de Uso Especificacin textual de Caso de Uso
Diagrama de Caso de Uso Actor Prototipo de Interfaces
xml Diseo Conceptual de Interfaces
Aceptar
Cancelar
Cada vez que me toca desarrollar una capacitacin o presentacin en este tema apelo a la siguiente frase esto no compila . La razn es que muchos desarrolladores esperan de los diagramas de UML en general y de los de casos de uso en particular ms precisin de lo que deberan. Por esta razn es muy importante el acuerdo a nivel del grupo de desarrollo del significado de las palabras al momento de la construccin de estos diagramas. Por ejemplo es frecuente encontrar un caso de uso nombrado como Administrar xxx. Administrar puede significar diferentes cosas para las distintas personas de un grupo de desarrollo. Por ejemplo podra significar alta, baja y modificacin; o solo alta; o todo lo anterior ms procesar xxx. Es muy importante darle claridad y consistencia a los diagramas de este tipo definiendo al nivel del grupo el significado de las palabras claves. Tambin es importante hacerlo cuando se listaron los requerimientos, en aquel caso para todos los involucrados en el proyecto. Todas estas definiciones hacen a la organizacin del grupo de desarrollo.
Pgina 14
Anlisis de Requerimientos
NO CONFUNDIR DOMINIO Y NEGOCIO CON DISEO
En los ltimos tiempos, tres o cuatro aos, ha habido una oleada de propuestas acerca de cmo hacer para que el desarrollo de los sistemas est conducido por el negocio. Estas promociones van desde el excelente libro Domain Driven Design de Eric Evans [3] hasta el sustento de un nuevo paradigma tal como SOA (Service Oriented Architecture), cuya esencia se basa en cmo los servicios de IT (Information Technology) se funden con los del negocio para crear nuevos negocios. A gran parte de la comunidad informtica internacional le pareci una novedad, ya que en diferentes foros ambas fueron acogidas con gran atencin y hasta recibieron premios. Como algunos de mis colegas, con experiencia de tres dcadas en el desarrollo de software, me pregunto cul es la innovacin. Pensar las soluciones de software (programas) a los problemas de esta manera fue una de las primeras cosas que nos ensearon. Entonces uno se pregunta cul fue la razn para que esta estrategia se dejara de lado con las consecuencias que enseguida analizaremos? Yo he encontrado una respuesta que me satisface; la razn fue la complejidad de la tecnologa. Suena contradictorio pero no lo es. La complejidad de la tecnologa de las ltimas dos dcadas ha hecho que los desarrolladores estn muy ocupados aprendiendo a utilizar tal o cual herramienta, tal o cual ambiente de desarrollo, tal o cual lenguaje, tal o cual framework; que se olvidaron del negocio. Me ha tocado revisar muchos proyectos de desarrollo y me ha sorprendido encontrar lo que Martin Fowler llama objetos anmicos. Una capa de objetos que solo cuentan con atributos y gets y sets y ninguna otra operacin. Sin embargo dichos objetos estaban mapeados con precisin a la base de datos y contaban con capacidad transaccional y seguridad y etc., etc., etc. Los desarrolladores resuelven las cuestiones vinculadas a la infraestructura y dan poca importancia al negocio. La consecuencia de esta forma de trabajo son sistemas mal diseados, no extensibles desde el punto de vista del negocio, con un comportamiento que no es el esperado. Este es el resultado de resolver aspectos tan diferentes como el negocio y la infraestructura en la misma actividad de diseo. En este punto tenemos claro qu son los requerimientos y todos sabemos qu es el cdigo ejecutable, ahora bien cules son los artefactos que generamos al realizar las actividades que nos llevan de uno al otro?
Requerimientos
Cdigo
Pgina 15
Tambin es un concepto conocido el diagrama de clases conformando el diseo del cdigo. Sin embargo nos sigue quedando una brecha entre este diseo y los requerimientos.
Antes de continuar incorporaremos a este anlisis los conceptos ya vistos en secciones anteriores que hacen a la especificacin de los casos de uso como expresin de los requerimientos funcionales. An as, no hemos llenado esta brecha. Los casos de uso describen el comportamiento de nuestra aplicacin en desarrollo, es decir su dinmica. Pero en el diagrama de clases ligado al cdigo hay conceptos estticos adems de su dinmica. La pregunta es cmo surgieron estos conceptos. Deberamos haber partido de algn modelo tambin esttico para llegar a este diseo. As es, por lo tanto debemos haber recorrido un camino paralelo al que realizamos con el comportamiento, pero en este caso manipulando aspectos que aporten la estructura del diseo resultante. Nuestro punto de partida es pensar el problema a resolver en trminos de conceptos extrados del dominio del problema. Estos conceptos primarios, de los cuales la mayor parte terminar siendo objetos de nuestro cdigo los relacionaremos en un modelo de clases que llamamos Modelo de Dominio. Estamos funcionando, como Booch [8] describe, haciendo uso del mecanismo de particin. En este punto nuestros conceptos no tienen alcance preciso expresado en sus atributos. Este alcance lo obtendremos a partir de enriquecerlo con la informacin provista por el comportamiento (casos de uso, prototipo de interfaces y diseo conceptual de interfaces). Este ejercicio de refinamiento nos lleva del Modelo de Dominio a un Modelo de Negocio. Este ltimo es lo que Eric Evans llama lenguaje ubicuo y lo construimos a partir del dominio utilizando patrones de anlisis. Estos patrones de anlisis fueron catalogados de una forma didctica y precisa por Jill Nicola [4] y Martin Fowler [7]. El modelo de Negocio resultante no contiene ninguna informacin de la tecnologa, sino que describe el negocio en forma precisa y completa, incorporando las reglas de negocio a los objetos del modelo. Los objetos resultantes no son para nada anmicos, ellos a partir de su colaboracin modelan el negocio del sistema en construccin.
Pgina 16
Quiero ser claro y preciso al diferenciar el Modelo de Negocio del Diseo, ya que las preocupaciones de los desarrolladores al construirlos son distintas.
Modelo de Negocio Objetivo: entender en detalle el negocio y sus reglas Mecanismo utilizado: Patrones de Anlisis Diseo Objetivo: implementar una solucin al problema planteado en el anlisis ms las restricciones impuestas por los requerimientos no funcionales. Mecanismo utilizado: Patrones de Diseo El Modelo de Negocio resultante es la base sobre la cual trabajarn los desarrolladores para realizar su diseo, guiados ahora por otro objetivo y utilizando otros criterios tales como [9]: inversin en la cadena de dependencia, cdigo clausurado ante cambios, principio de substitucin de Liskov, segregacin de interfaces, dependencias no cclicas, etc. A partir de aqu los desarrolladores se valdrn de herramientas como los patrones de diseo [10] [11]. A partir de aqu adems llega el momento de tener en cuenta la tecnologa. El proceso comentado y la generacin de los artefactos resultante se muestran en las figuras que siguen.
Pgina 17
Pgina 18
Pgina 19
Pgina 20
Nota para desarrolladores giles

Deseo notar con nfasis que lo propuesto no significa hacer para cada uno y todos los proyectos los mismos diagramas, de la misma forma, como una receta preestablecida. Proponemos que los lectores se queden con la esencia de la forma de trabajo propuesta y la adapten de una manera inteligente a su mbito. Estoy convencido porque as me lo muestra la experiencia que la que acabamos de presentar es una estrategia de desarrollo que contribuir a quien la use a generar productos de muy buena calidad. Cuando nombramos algunas de las vistas de un proyecto como Modelo no nos referimos a un documento, nos referimos a los conceptos manipulados en ese momento del ciclo de vida y con el conocimiento que entonces tenemos de ellos, los cuales debern aprenderse, relacionarse y documentarse de la manera que ustedes encuentren ms apropiada.
Nota a los analistas de sistemas

Existe una gran tendencia a gastar casi todo del esfuerzo en el relevamiento, especificacin y prueba de los requerimientos funcionales en detrimento de los no funcionales. Estos ltimos caracterizan al ambiente operacional en el cual debe funcionar el sistema en desarrollo. Esta rasgo distintivo del trabajo con requerimientos por parte de los analistas lo hemos observado en muchos proyectos. Ambos son igualmente importantes y a ambos se le debe asignar el esfuerzo necesario.
PAQUETES
El trmino paquete es utilizado en diferentes mbitos del desarrollo de software con distintos significados, aqu lo usamos en un sentido lgico y amplio. Paquete es en principio un conjunto de casos de uso cohesivos desde algn criterio de negocio. Cuando el proyecto avance, estos paquetes se convertirn en fsicos, constituyendo los subsistemas que componen el sistema en desarrollo. La eleccin de estos paquetes primarios es una tarea sumamente importante, ya que constituyen el primer esbozo de la arquitectura del sistema en desarrollo. Durante el proceso de desarrollo del proyecto estos paquetes son la unidad de release de cada iteracin y cuando el proyecto est terminado e instalado constituyen la unidad de mantenimiento [7, 13].
Alternativas de seleccin
Cmo seleccionamos los paquetes de un sistema? La respuesta a esta pregunta es simple e importante. Una forma de eleccin es a partir de las clases ms representativas del modelo de dominio. La idea es centrar los paquetes en estas entidades y refinar el conjunto de paquetes resultante. Las relaciones entre estos paquetes estn dadas por la relacin entre los casos de uso empaquetados en cada uno. Cuando realizamos el diseo aparecen nuevos que alojan aspectos de la tecnologa.
Pgina 21
Otra posibilidad es elegir los paquetes a partir de las reas de negocio que el sistema en desarrollo resolver. Un posible inconveniente con esta alternativa es que resultan paquetes a veces muy grandes que deben a su vez ser particionados.
Pgina 22
Validacin y Verificacin
Adems de las tareas de relevamiento y especificacin, las tareas de validacin y verificacin fueron las que utilizamos para enfatizar la importancia del trabajo con los requerimientos en el inicio de este captulo. A continuacin presentamos nuestra propuesta de cmo llevarlas adelante a efectos de garantizar la calidad del software resultante.
VALIDACIN
Una forma directa de validacin del comportamiento del Modelo de Negocio es su programacin definitiva o prototipo y las pruebas sobre el mismo que muestren que el comportamiento es el esperado. El objetivo de esta validacin es mostrar la ejecucin de las validaciones de las reglas de negocio y asegurarse de que esta dinmica es la solicitada y es consistente visto desde las reglas. Esta programacin por las mismas razones que dimos en la seccin anterior no debe asentarse en clases de diseo que cumplan con criterios de buen diseo. Por esta razn puede tratarse de un prototipo o cdigo no optimo que con modoficaciones posteriores termine siendo el definitivo. La vadidacin de este comportamiento es clave en modelos complejos. Por otro lado, la validacin del comportamiento de la Aplicacin (funcionalidad) con los usuarios utilizando los prototipos de interfaces que forman parte de la especificacin de los casos de uso es una muy buena prctica que en nuestra experiencia nos ha dado muy buenos resultados. Ambas dos validaciones son necesarias, ya que a partir de lo presentado en secciones anteriores qued claro que Aplicacin (casos de uso) y Modelo de Negocio son cosas diferentes. Uno expresa el rea de negocio sobre la que nuestro sistema operar y la otra muestra qu y cmo usamos ese negocio desde el nuevo sistema en desarrollo. El resultado exitoso de estas validaciones nos da la certeza de que construiremos el sistema correcto.
VERIFICACIN
La verificacin de la correctitud de la construccin del sistema la llevaremos a cabo diseando y ejecutando pruebas (test) que nos darn la certeza de que hemos construido el sistema de manera correcta. Me referir aqu solamente a las pruebas funcionales, es decir a a quellas que prueban el comportamiento de la aplicacin en trminos de los casos de uso. El resto de las pruebas, otros tipos de pruebas, las trataremos en un prximo captulo. Si nuestros casos de uso fueron validados y son los que debamos construir, luego lleg el momento de probar que fueron construidos correctamente. Por lo tanto a partir de los casos de uso derivaremos los casos de prueba[12]. Nuestros procedimientos de pruebas estn expresados en la especificacin textual de los casos de uso. Adems para cada caso de uso contamos con los diferentes caminos bsico y alternativos, cuyas combinaciones constituyen los distintos escenarios de prueba. Debemos seleccionar el conjunto de datos con los cuales probar cada caso y tendremos as los casos de prueba definidos. En la figura que sigue se muestra un Calidad en el Desarrollo de Software Guillemo Pantaleo Pgina 23
diagrama que ejemplifica la constitucin de los casos de prueba incluyendo todas sus partes como se acaba de describir.
custom Nuestro Modelo de Test Funcional
Test de Funcionalidad
Test Unitario
Otros Test
Defectos
Caso de Test
1..*
Procedimiento de Test
1..* 1..*
Componente de Test
1..*
Activos de pruebas XXX_TestCase Alternativas Casos Uso Evaluacion Test ABM_TestCase UseCaseX_TestCase Plan de Test EMPRESA Application_TestCase JUnit JUnit JUnit Plan de Test
En la figura puede verse que por cada caso de uso se especializan tres diferentes tipos de caso de prueba. Las altas, bajas y modificaciones las generalizamos de forma tal que tanto la especificacin de los casos de uso como las pruebas resulten reusables. Por esta razn aparece un activo llamado ABM_TestCase, el cual constituye el caso de prueba para estos casos. Por cada interfaz de usuario de cada caso de uso, diseamos prueba orientadas a probar la presentacin. Se testean la presencia, disposicin y rden de los diferentes controles (layout), el paginado de datos, etc. Este caso de prueba los llamamos Application_TestCase y se ejecuta para todas las pantallas de los casos de uso de la aplicacin. Esta es otra muestra de la estrategia de reuso aplicada a los requerimientos, ya que la consistencia dada a la aplicacin nos permite plantear casos de prueba idnticos para todas sus vistas. Estos patrones de especificacin son fundamentales en la organizacin del ambiente de desarrollo a partir de acuerdos bsicos entre los desarrolladores y son los que facilitan el desarrollo y generan productos de mejor calidad. Para aquellos casos de uso diferentes, construimos el caso de prueba asociado y lo nombramos UseCaseX_TestCase. Los activos resultantes los implementamos en planillas electrnicas de las cuales en un apndice se presenta un ejemplo. Cada planilla posee lenguetas para las diferentes ejecuciones, columnas para registrar los resultados obtenidos y otros datos de inters.
Modelo construido con la Ingeniera Patricia Forradellas trabajando en it-Mentor. Pgina 24
Cuando en un prximo captulo tratemos otros temas relacionados a las pruebas de software en el contexto de xUnit e Integracin Continua, volveremos sobre el tema de la verificacin.
Pgina 25
Administracin de cambios a los requerimientos

PROBLEMA
Hace casi tres decadas trabajabamos en proyectos de desarrollo de software orientados a resolver problemas cientficos tecnolgicos en la universidad utilizando una computadora Digital PDP-11. En esos tiempos me toc trabajar en proyectos de investigacin y desarrollo en reas como ingeniera biomdica, exploracin petrolera y telefona. Los programas que construimos en su mayora no eran interactivos, ms bien procesaban datos y solo se les provean algunos parmetros y a partir de sus salidas se elaboraban reportes. Los proyectos comenzaban y terminaban casi con los mismos requerimientos. Con la irrupcin de la PC en el mercado, la variedad de reas a las cuales fue posible proveer una solucin de software creci casi exponencialmente y con esa misma velocidad decreci el tiempo en que los requerimientos permanecan estables, sin cambios. La posibilidad de contar con interfaces de ususario de gran variedad contribuy a que los clientes tuvieran aproximaciones ms tempranas a los productos en construccin y a partir de estas vistas solicitar cambiar sobre la marcha. Lo que hoy era vlido, maana ya no lo era. Tuvo que pasar mucho tiempo antes de que los procesos de desarrollo resolvieran con algo de coherencia la administracin de estos cambios. Es ms, an hoy da me toca en algn proceso de mejoras trabajar con proyectos de desarrollo donde no se administran los cambios a los requerimientos y peor an, demanda toda una explicacin detallada la fundamentacin de la necesidad de este proceso a los mismos responsables de los proyectos que sufren las consecuencias de no hacerlo. Este proceso es muy simple, se trata de acordar qu cambios se aceptan realizar, cules se postergarn y por qu razn y cules se rechazarn y por qu razn. Cada cambio propuesto o pedido en el proyecto pasa por diferentes estados de acuerdo a su ciclo de vida. Esta administracin es en general llevada adelante con alguna herramienta de soporte que facilita entre otras cosas realizar el seguimiento de cada cambio segn su estado, evaluacin de su impacto y asignacin de las tareas asociadas al mismo. En la figura que sigue se muestra un posible ciclo de vida de cambios a los requerimientos de un proyecto. Se muestran los diferentes estados por los que pasa una solicitud de cambio, las transiciones posibles y los involucrados en el proceso.
Pgina 26
Cliente Usuario
Desarrollador
Analista / Lider En anlisis de impacto Cambio importante Cambio Menor Marketing Aceptado pendiente Pendiente de aprobacin
En CCB Asignado Desarrollador En desarrollo Rechazado Tester
CCB
Pendiente de prueba
Probado Implementado
Probado con falla
Un error comn que me ha tocado observar es la implementacin de este proceso sin tener en cuenta el tamao del proyecto, del grupo de desarrollo y de la cultura de la organizacin. Todas estas caractersticas influyen en este proceso y deben respetarse con mayor rigor en proyectos grandes y organizaciones corporativas.
ALTERNATIVAS DE SOLUCIN
En organizaciones pequeas y medianas el CCB(Change Control Board) estar integrado solo por el responsable del proyecto, el referente de parte del cliente y la persona a la cual se le asign el rol de analista en el proyecto. La frecuencia de reuniones y anlisis de los cambios ser adaptada a la velocidad con que se generen los cambios. La idea es agrupar cambios para su tratamiento. En organizaciones corporativas con proyectos grandes y numerosos en involucrados, el CCB estar constituido por un referentes de cada parte, el responsable del proyecto, analistas, lider tcnico y gerentes. La frecuencia ser prefijada de antemano en quince a 20 das. En todos los casos es necesario e imprescindible: Calidad en el Desarrollo de Software Guillemo Pantaleo Pgina 27
1. Documentar todos y cada uno de los anlisis de impacto y los acuerdos de las reuniones del CCB 2. La asistencia de involucrados con poder de decisin en la planificacin del proyecto (tiempos, presupuesto, caractersticas del producto en desarrollo)
Nota para desarrolladores giles

Cuando mencionamos controlar los cambios no nos referimos a definir sistemas cuyos requerimientos permanecern frezados y limitados del valor que proporciona la adaptacin de las especificaciones a la evolucin del negocio. De ninguna manera. Nos referimos a instrumentar un mecanismo que permita balancear los esfuerzos de desarrollo con las actividades necesarias para implementar los cambios surgidos. Lo hacemos convencidos de que los proyectos aparentemente flexibles, en los cuales se dan cabida a todos los cambios solicitados, terminan desestabilizados y como consecuencia de esto no aportan ningn valor al negocio.
Pgina 28
Conclusin
De lo expuesto se concluye que el trabajo con los requerimientos es mucho ms que relevar y listar los el sistema debe de todo proyecto de desarrollo. Es necesario que este listado cuente con determinadas propiedades para no ser solo un listado de caractersticas. Se debe, a partir de la especificacin del comportamiento de la aplicacin a desarrollar (casos de uso), definir cmo se implementarn estos requerimientos. Tambin es necesario contar con un modelo de dominio que siente las bases para un posterior diseo y que esencialmente decriba al negocio. En todos los casos administrar los cambios surgidos durante el proceso de desarrollo. Por ltimo debemos validar y verificar todo este trabajo con los requerimientos.
Pgina 29
Referencias
1. Standish Group, http://www.standishgroup.com/. 2. Requirements Development, Verification, and Validation Exhibited in Famous Failures, A. Terry Bahill1, Steven J. Henderson, Systems Engineering, Vol. 8, No. 1, 2005, Wiley Periodicals, Inc. 3. Domain Driven Design, Eric Evans, Addison-Wesley, 2004. 4. Streamlined Object Modeling Patterns, rules and implementations, Jill Nicola et. al., PHPTR, 2002. 5. Requirements by Collaboration: Workshops for Defining Needs, Ellen Gottesdiener, Addison Wesley Professional, 2002. 6. A framework for information systems architecture, J. A. Zachman, IBM System Journal, vol. 26, 1987. 7. Analysis Patterns: Reusable Object Models, Martin Fowler, Addison-Wesley Object Technology Series, 1997. 8. Object-Oriented Analysis and Design with Applications (2nd Edition), Grady Booch, 1994. 9. Agile Software Development: Principles, Patterns, and Practices, Robert C. Martin, Prentice Hall, 2002. 10. Design Patterns: Elements of Reusable Object-Oriented Software, Gamma et al, AddisonWesley Professional Computing Series, 1994. 11. Patterns of Enterprise Application Architecture, Martin Fowler, Addison-Wesley Signature Series, 2002. 12. Generating Test Cases from Use Case, Jim Heumann, Rational Software, 2001. 13. Agile Software Development: Principles, Patterns, and Practices, Robert C. Martin, Winner of the 2002
Pgina 30

Trabajo Con Requerimientos

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Trabajo Con Requerimientos

Încărcat de

Drepturi de autor:

Formate disponibile

Trabajo con Requerimientos