Sistemas 2

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II
INDICE
Investigacin Preliminar .................................................................................................................................... 2 Anlisis .............................................................................................................................................................. 6 Diseo................................................................................................................................................................ 12 Programacin .................................................................................................................................................... 24 Prueba ............................................................................................................................................................... 26 Implementacin ................................................................................................................................................. 32 Mantenimiento ................................................................................................................................................... 34 Otras Metodologas ........................................................................................................................................... 35 - OO................................................................................................................................................................. 35 - RUP............................................................................................................................................................... 45 - Metodologas giles ...................................................................................................................................... 53 Anexo: Patrones ................................................................................................................................................ 62 Lectura Adicional: Ha muerto el Diseo - Martin Fowler ................................................................................ 66
FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009
UNIDAD I: INVESTIGACIN PRELIMINAR

METODOLOGA DE DESARROLLO DE SOFTWARE
Es un conjunto de actividades, tcnicas, herramientas y/o procedimientos que deben utilizarse en el desarrollo de un sistema. Incluyen: Personas que participan en cada actividad. El papel que cumplen. Los recursos que necesitarn. La informacin que se obtiene como resultado de cada actividad (salida). La informacin que se requiere para iniciar cada actividad (entrada). El producto final es un sistema o software. Componentes bsicos de toda metodologa Una metodologa debe incluir: Ciclo de vida completo del desarrollo del sistema. Definicin de los productos (modelos) que se generan. Notacin: smbolos que se van a utilizar y qu significado tienen. Reglas que permitan verificar que cada modelo est siendo bien generado, y realizar validaciones que permitan detectar y corregir errores. Tipos de metodologas Convencional. Estructurada. Orientada a objetos. Orientada a datos. giles. De qu depende qu metodologa usar? No existen restricciones para elegir una metodologa. Hay que tener en cuenta las caractersticas de la empresa. Sus dimensiones y caractersticas del sistema en s. Sin aplicar una metodologa, los tiempos y costos se transforman en inconvenientes, aunque no sea rgidamente, conviene atarse a una metodologa.
CICLO DE VIDA DE UN SISTEMA

Es el perodo de tiempo que transcurre desde el momento en que se decide desarrollar un software hasta el momento en que se lo entrega al usuario como producto terminado. El ciclo de vida de un sistema es el conjunto de actividades que se deben desarrollar para llevar a cabo un sistema, desde que se toma la decisin de realizarlo hasta la entrega del sistema. Tipos o modelos de ciclos de vida 1. MODELO EN CASCADA: Plantea un enfoque secuencial de las distintas actividades del ciclo de vida o de todo el proceso. En general abarca las siguientes etapas: 1. Estudio Preliminar o Preproyecto: cuando se formula la solicitud comienza la primera actividad de sistemas. Muchas solicitudes que provienen de empleados y usuarios no estn formuladas de manera clara;
por consiguiente, antes de considerar cualquier investigacin de sistemas, la solicitud del proyecto debe examinarse para determinar con precisin lo que el solicitante desea. Un resultado importante es la determinacin de que el sistema sea factible. Despus de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario para terminarlo y las necesidades del personal. 2. Anlisis de Requerimientos: estudia un dominio de informacin ya establecido, sin tener en cuenta cuestiones de implementacin. Trata de encontrar QU se debe hacer, no CMO. Esta etapa implica determinar las necesidades del usuario. Diseo de Sistema: define cmo construir el sistema. Programacin y Documentacin: el diseo debe traducirse en forma tangible para la mquina. La documentacin es esencial para probar el programa y llevar a cabo el mantenimiento una vez que la aplicacin se encuentra instalada. Prueba: se centra en la lgica interna del software, asegurando que todas las sentencias se han probado, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Implementacin y Evaluacin del Sistema: proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicacin y construir todos los archivos necesarios para utilizarla. Dependiendo del tamao de la organizacin y el riesgo asociado al uso de la aplicacin, puede elegirse comenzar la operacin del sistema solo en una parte de la empresa o en forma paralela con la finalidad de comparar los resultados. Mantenimiento: aplica cada uno de los pasos precedentes del ciclo de vida a un programa existente en vez de a uno nuevo. Es cuando el usuario solicita modificaciones al sistema ya implementado, a partir de nuevos requerimientos.
3. 4.
5.
6.
7.
Inconvenientes del modelo en cascada: Antes de comenzar con una etapa, se debe haber terminado la anterior, con un alto grado de exactitud. Generalmente no se cumple la secuencialidad. El producto final requiere mucho tiempo de espera por parte del usuario. Dificultad del usuario en reconocer sus necesidades (requerimientos) por lo que se produce un retraso en el tiempo y aumentan los costos. Los cambios en la empresa, hacen que deban modificar el proyecto y el producto final va a ser diferente a lo que se requiere. Los cambios de la empresa se deben trasladar al ciclo de vida. 2. CONSTRUCCION POR PROTOTIPOS: intenta salvar el problema que se presenta en el momento en que el usuario y el informtico deben definir los requerimientos de la empresa. Se aplica en la etapa de Anlisis de Requerimientos. Un prototipo es un sistema incompleto, no operativo, hueco, en donde se visualizan las entradas y salidas que va a tener el sistema definitivo. Es la cscara del sistema; no tiene funcionalidad, ayuda a definir los requerimientos del usuario. El uso de prototipos est enfocado a mejorar la efectividad del proceso y no a mejorar la eficiencia. Las etapas del prototipo son: Definicin de requerimientos. Construccin de una versin del prototipo. Evaluacin del usuario. Modificacin del prototipo Fin: aceptacin del prototipo por parte del usuario. Luego de realizar la investigacin preliminar, el analista construye el prototipo, se lo muestra al usuario y a partir de ah ambos interactan, y el usuario realiza nuevas sugerencias. Luego, el analista construye un nuevo prototipo (o modifica el anterior) y as sucesivamente, hasta que se evala en forma satisfactoria (es decir, hasta
que el usuario est conforme). Luego de cumplir con esta funcin, es recomendable tirarlo, porque no sirve: nace y muere en la etapa de anlisis. 3. MODELOS EVOLUTIVOS: tienen en cuenta que los requerimientos varan a medida que se da el desarrollo del sistema. Estos modelos son iterativos. Se caracterizan por desarrollar versiones cada vez ms completas. Existen dos variaciones: Modelo incremental. Plantea ir entregando en distintas etapas, productos (versiones del soft) que cubran determinados requerimientos del usuario, con nuevas funcionalidades. El primer incremento a menudo es un producto esencial (ncleo). Como resultado de la utilizacin y evaluacin, se desarrolla un plan para el incremento siguiente. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo. Con ello, se logra que el usuario vaya teniendo algo para trabajar. Se basa en no modificar lo anterior, sino en agregar nuevas funciones. En cada una de las etapas se pueden utilizar ciclos de vida en cascada o prototipos. Ventajas: Es menor la posibilidad de error si el usuario cambia sus requerimientos sobre la marcha. Se acotan los tiempos por subproductos. El cliente est ms conforme, porque ve soluciones palpables. Modelo espiral. Es una combinacin de prototipos, con la secuencialidad de modelo en cascada. Posee 4 etapas: Planificacin: determinar objetivos, recursos disponibles, etc. Anlisis de riesgo: analizar las diferentes alternativas de solucin, y los riesgos tcnicos que conllevan cada una de las alternativas. Ingeniera: construccin del producto. Evaluacin: valoracin del producto obtenido. El producto evoluciona a travs de las distintas etapas, hasta que es aceptado. Es ms costoso, puede ser que lleve mayor tiempo y no es demasiado productivo.
INVESTIGACIN PRELIMINAR
Comienza cuando se formula la solicitud. Esta actividad consta de: Definicin de los objetivos: antes de considerar cualquier investigacin de sistemas, debe examinarse la solicitud de proyecto para determinar con precisin lo que el solicitante desea (definir los objetivos). Estudio de factibilidad: determina si un proyecto informtico es viable o no; en base a esto la organizacin determina si se contina o no. La decisin sobre la factibilidad del proyecto no es una decisin del analista de sistemas, sino por la administracin. Las decisiones estn basadas en los datos de factibilidad recolectados en las siguientes reas: Factibilidad tcnica: investigar si los recursos tcnicos actuales pueden ser mejorados o aadidos, en forma tal que satisfagan la peticin del cliente. Sin embargo, algunas veces las adiciones a los sistemas existentes son costosas y no valen la pena, debido simplemente a que satisfacen las necesidades en forma ineficiente. Si los sistemas existentes no pueden ser aadidos, la siguiente pregunta es si hay tecnologa existente para satisfacer las especificaciones. Factibilidad econmica: la factibilidad econmica es la segunda parte de la determinacin de recursos. Los recursos bsicos a considerar son: el tiempo propio y el del equipo de sistemas, el costo de hacer un estudio de sistema completo, el costo del tiempo de los empleados del negocio, el costo estimado de hardware y el costo estimado del software y/o desarrollos de software. Poder hacer la relacin Costo (hardware, software, personal, capacitacin, desarrollar o comprar sistemas) - Beneficio (tangibles: cuando puedo medir en funcin de pesos ($); intangibles: puedo medir la satisfaccin del cliente).
Factibilidad operacional: depende de los recursos humanos disponibles para el proyecto, e involucra proyectar si el sistema operar y ser usado una vez que est instalado. Si los usuarios estn conformes con el sistema presente y no estn involucrados con la peticin de un nuevo sistema, la resistencia ante la implementacin del nuevo sistema ser fuerte. En cambio, si los usuarios han expresado la necesidad de que un sistema que es operacional la mayor parte del tiempo tenga una forma ms eficiente y accesible, se tiene una mayor oportunidad de que el sistema sea utilizado. Hacer un propsito de la aceptacin o no que tiene el sistema una vez instalado. Aprobacin de la solicitud: los proyectos que son deseables y factibles deben incorporarse en los planes de la organizacin.
UNIDAD II: II: ANLISIS DE REQUERIMIENTOS

ANLISIS DE REQUISITOS
El anlisis de requisitos permite especificar la funcin y el rendimiento del software, indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software. Estudia un dominio de informacin ya establecido, sin tener en cuenta cuestiones de implementacin. Trata de encontrar QU se debe hacer, no CMO. Esta etapa implica determinar las necesidades del usuario y debe ser dirigido al que realiza las tareas (usuario, operario). El anlisis de los requisitos es una tarea de ingeniera del software que cubre el hueco entre la definicin del software a nivel sistema y el diseo del software. El anlisis de requisitos puede dividirse en cinco reas de esfuerzo: Reconocimiento del problema; Evaluacin y sntesis; Modelado; Especificacin; Revisin. Principios de Anlisis Cada mtodo de anlisis tiene su punto de vista. Sin embargo, todos los mtodos de anlisis se relacionan por un conjunto de principios operativos: Debe representarse y entenderse el dominio de informacin de un problema; Deben definirse las funciones que debe realizar el software; Debe representarse el comportamiento del software; Deben dividirse los modelos que representan informacin, funcin y comportamiento de manera que se descubran los detalles por capas; El proceso de anlisis debera ir desde la informacin esencial hasta el detalle de la implementacin. Directrices Entender el problema antes de empezar a crear el modelo de anlisis. Hay tendencia a precipitarse en busca de una solucin, incluso antes de entender el problema. Desarrollar prototipos que permitan al usuario entender cmo ser la interaccin hombre-mquina. Como el concepto de calidad del software se basa a menudo en la opinin sobre la amigabilidad de la interfaz, el desarrollo de prototipos (y la iteracin que se produce) es altamente recomendable. Registrar el origen y la razn de cada requisito. Este es el primer paso para establecer un seguimiento hasta el cliente. Usar mltiples planteamientos de requisitos. La construccin de modelos de datos, funcionales y de comportamiento, le proporcionan al ingeniero del software tres puntos de vista diferentes. Esto reduce la probabilidad de que se olvide algo y aumenta la probabilidad de reconocer la falta de consistencia. Dar prioridad a los requisitos. Las fechas ajustadas de entrega pueden impedir la implementacin de todos los requisitos del software. Si se aplica un modelo de proceso incremental, se deben identificar los requisitos que se van a entregar en la primera entrega. Trabajar para eliminar la ambigedad. Como la mayora de los requisitos estn descritos en un lenguaje natural, abunda la oportunidad de ambigedades. El empleo de revisiones tcnicas formales es una manera de descubrir y eliminar la ambigedad.
Modelos de Anlisis Se crean para entender mejor la entidad que se va a construir. Cuando la entidad es algo fsico, podemos construir un modelo a escala; pero cuando la entidad que se va a construir es un software, nuestro modelo debe ser capaz de modelar la informacin que transforma el software, las funciones y el comportamiento del sistema. El segundo y tercer principios operativos del anlisis requieren la construccin de modelos de funcin y comportamiento. Modelos Funcionales: El modelo funcional empieza con un sencillo modelo a nivel de contexto (por ejemplo, el nombre del software que se va a construir). Despus de una serie de iteraciones, se consiguen ms y ms detalles funcionales, hasta que se consigue representar una minuciosa definicin de toda la funcionalidad del sistema. Modelos de Comportamiento: La mayora del software responde a los acontecimientos del mundo exterior. La caracterstica estmulo respuesta es la base de este modelo, el cual crea una representacin de los estados del software y los acontecimientos que causan que cambie de estado. Los modelos creados durante el anlisis de requisitos desempean unos papeles muy importantes: El modelo ayuda al analista a entender la informacin, la funcin y el comportamiento del sistema, haciendo por tanto ms fcil y sistemtica la tarea de anlisis de requisitos. El modelo se convierte en el punto de mira para la revisin y por tanto la clave para determinar si se ha completado, su consistencia y la precisin de la especificacin. El modelo se convierte en el fundamento para el diseo, proporcionando al diseador una representacin esencial del software que pueda trasladarse al contexto de la implementacin.
PROTOTIPO
Es un modelo de lo que pensamos va a ser el sistema. Maqueta del sistema. Consiste en la elaboracin de un modelo o maqueta del sistema, que se construye para evaluar mejor los requisitos que se desea que cumpla el sistema. Estos modelos suelen consistir en versiones reducidas, demos o conjunto de pantallas que no son totalmente operativos. Permite intercambiar ideas con los usuarios y establecer los requerimientos. Existen tres razones principales para emplear prototipos: Prototipo de la Interfaz del Usuario: para asegurarse de que est bien diseada, que satisface las necesidades de quienes deben usarlo. Modelos de Rendimiento: para evaluar el posible rendimiento de un diseo tcnico, especialmente en aplicaciones crticas en este aspecto. Prototipo Funcional: supone una primera versin del sistema con funcionalidades limitadas. A medida que se comprueba si las funciones implementadas son las apropiadas, se corrigen, refinan o aaden otras nuevas hasta llegar al final del sistema. Proceso de Construccin En base a un primer relevamiento se construye un primer sistema con los datos de entrada salida que a nosotros nos parece. Se lo presenta al usuario y con sus comentarios y observaciones se le realizan modificaciones y se lo presenta nuevamente. As hasta que el usuario lo aprueba. El paradigma de construccin de prototipos comienza con la recoleccin de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las reas del esquema en donde es obligatoria ms definicin. Entonces aparece un diseo rpido. El diseo rpido se centra en una representacin de esos aspectos del software que sern visibles para el usuario/cliente (por ejemplo: enfoques de entrada y formatos de salida). El diseo rpido lleva a la construccin de un prototipo. El prototipo lo evala el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteracin ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer.
FIGURA: El paradigma de construccin de prototipos.
Ventajas Permite obtener las necesidades del usuario y representa un mecanismo muy til para identificar los requisitos del software. Podemos mostrarle el sistema al usuario, antes de terminar el trabajo; permite identificar las funciones del sistema. Desventajas El usuario ve el prototipo y quiere ya empezar a trabajar con el mismo, hay que hacerle entender que es un sistema vaco, que no es el definitivo. Cuando se informa de que el producto se debe construir otra vez para que se puedan mantener los niveles altos de calidad, el cliente no lo entiende y pide que se apliquen unos pequeos ajustes para que se pueda hacer del prototipo un producto final. El desarrollador, a menudo, hace compromisos de implementacin para hacer que el prototipo funcione rpidamente. Se puede utilizar un sistema operativo o lenguaje de programacin inadecuado simplemente porque est disponible y porque es conocido; un algoritmo eficiente se puede implementar simplemente para demostrar la capacidad. Despus de algn tiempo, el desarrollador debe familiarizarse con estas selecciones, y olvidarse de las razones por las que son inadecuadas. La seleccin menos ideal ahora es una parte integral del sistema.
NOTA
El prototipo no es una tcnica obligatoria, pero es recomendable utilizarla, para estar seguros, para validar, etc.
Seleccin del enfoque de creacin de prototipos El paradigma de creacin de prototipos puede ser cerrado o abierto. El enfoque cerrado se denomina a menudo prototipo desechable. Este prototipo sirve nicamente como una basta demostracin de los requisitos. Despus se desecha y se hace una ingeniera del software con un paradigma diferente. Un enfoque abierto, denominado prototipo evolutivo, emplea el prototipo como primera parte de una actividad de anlisis a la que seguir el diseo y la construccin. El prototipo del software es la primera evolucin del sistema terminado. Qu debemos mirar para determinar si un prototipo es o no una alternativa viable? Antes de poder elegir un enfoque abierto o cerrado, es necesario determinar si se puede crear un prototipo del sistema a construir. Se pueden definir varios factores candidatos a la creacin de prototipos: rea de aplicacin, complejidad, caractersticas del cliente y del proyecto. En general, cualquier aplicacin que cree pantallas visuales dinmicas, interacte intensamente con el ser humano, o demande algoritmos o procesamiento de combinaciones que deban crearse de manera progresiva, es un buen candidato para la creacin de un prototipo. Sin embargo, estas reas de aplicacin deben ponderarse con la complejidad de la aplicacin. Si una aplicacin candidata (una con las caractersticas reseadas anteriormente) va a requerir el desarrollo de decenas de miles de lneas de cdigo antes de poder realizar cualquier funcin demostrable, es muy probable que sea demasiado compleja para crear un prototipo. Si se puede hacer una particin a su complejidad, puede ser posible crear prototipos de porciones del software.
Como el cliente debe interactuar con el prototipo en fases posteriores, es esencial que 1. se destinen recursos del cliente a la evaluacin y refinamiento del prototipo, y 2. el cliente sea capaz de tomar decisiones inmediatas sobre los requisitos. Finalmente, la naturaleza del proyecto de desarrollo tendr una gran influencia en la capacidad de crear un prototipo. Desea y es capaz la gestin del proyecto de trabajar con el mtodo del prototipo? Tenemos disponibles herramientas para la creacin de prototipos? Tienen experiencia los desarrolladores con los mtodos de creacin de prototipos? Andriole sugiere un conjunto de seis preguntas e indica unos conjuntos bsicos de respuestas con su correspondiente tipo de prototipo sugerido, lo cual se muestra en la siguiente figura.
Trabajo preliminar adicional requerido No No
Pregunta Se entiende el dominio de la aplicacin? Se puede modelar el problema? Est el cliente suficientemente seguro de los requisitos bsicos del sistema? Estn establecidos los requisitos y son estables? Hay requisitos ambiguos? Hay contradicciones en los requisitos?
Prototipo desechable S S
Prototipo evolutivo S S
S / No
S / No
No
No S S
S No No
S S S
FIGURA: Seleccin del enfoque apropiado de creacin de prototipo.
Mtodos y herramientas para el desarrollo Para que la creacin del prototipo de software sea efectiva, debe desarrollarse rpidamente para que el cliente pueda valorar los resultados y recomendar los cambios oportunos. Para poder crear prototipos rpidos, hay disponibles tres clases genricas de mtodos y herramientas: Tcnicas de Cuarta Generacin. Las tcnicas de cuarta generacin (T4G) comprenden una amplia gama de lenguajes de consulta e informes de bases de datos, generadores de programas y aplicaciones y de otros lenguajes no procedimentales de muy alto nivel. Como las tcnicas T4G permiten al ingeniero del software generar cdigo ejecutable rpidamente, son ideales para la creacin rpida de prototipos. Componentes de software reutilizables. Otro enfoque para crear prototipos rpidos es ensamblar, ms que construir, el prototipo mediante un conjunto de componentes software existentes. La combinacin de prototipos con la reutilizacin de componentes de programa slo funcionar si se desarrolla un sistema bibliotecario de manera que los componentes existentes estn catalogados y puedan recogerse. Debera resaltarse que se puede usar un producto software existente como prototipo de un nuevo y mejorado producto competitivo. En cierta manera, sta es una forma de reutilizacin en la creacin de prototipos software. Especificaciones formales y entornos para prototipos. Durante las pasadas dos dcadas, se han desarrollado varios lenguajes formales de especificacin y herramientas como sustitutos de las tcnicas de especificacin con lenguaje natural. Hoy en da, los desarrolladores de estos lenguajes formales estn desarrollando entornos interactivos que 1. permitan al analista crear interactivamente una especificacin basada en lenguaje de un sistema o software, 2. invoquen herramientas automticas que traducen la especificacin basada en el lenguaje en cdigo ejecutable, y 3. permitan al cliente usar el cdigo ejecutable del prototipo para refinar los requisitos formales.
Herramientas Utilizadas en la Etapa de Anlisis Herramientas del Anlisis Estructurado Se deben realizar los flujos de datos a travs de los distintos procesos en base a las entradas y salidas. Diagrama de Flujo de Datos DFD Herramienta que permite en forma lgica representar un anlisis. Va de lo general a lo particular (Top Down). En un DFD, se ve al sistema como una funcin de transformacin. Es un diagrama en forma de red que representa el flujo de datos y las transformaciones que se aplican sobre ellos al moverse desde la entrada hasta la salida del sistema. a) ENTES EXTERNOS: representa un generador o consumidor de informacin del sistema y que no pertenece al mismo. Puede representar un subsistema, persona, departamento, organizacin, etc. que proporcione datos al sistema o que los reciba de l. Todo lo que del da informacin al sistema y lo que recibe informacin del sistema. b) PROCESOS O FUNCIONES DE TRANSFORMACIN: representa una funcin que transforma los flujos de datos de entrada en uno o varios flujos de salida. El trmino proceso hay que verlo como una funcin que tiene que realizar el sistema. c) ALMACENES: representa informacin del sistema almacenada en forma temporal. Si los flujos de datos representan datos en movimiento, los almacenes representan datos en reposo.
d) FLUJO DE DATOS: camino a travs del cual viajan datos de una parte del sistema a otra. Representan datos en movimiento. Objetivos de un sistema: lo que el sistema va a hacer para cumplir con los requerimientos de un usuario. Deben ser simples y nicos. No debe englobarse un objetivo en otro. Limites: determina qu est incluido y qu no lo est dentro del sistema. Hay que definirlos por comprensin. Desde la entrada (estmulo) hasta la salida ms importante. Se definen por ejes causales. Alcances: aclaracin sobre los objetivos, cosas que quedan dentro o afuera del sistema. Observaciones: Toda salida debe generarse mediante una entrada. Toda entrada debe tener una salida. No puede existir un almacn en el cual slo se escribe o slo se lee informacin, siempre la informacin es escrita para que otra funcin la examine. Los almacenes de datos deben aparecer en el ltimo nivel. No existen detalles fsicos ni de tiempo. No se refleja el orden de las tareas ni quin las ejecuta. No se reflejan reas o departamentos. Cmo se construye un DFD? Nivel 0 (diagrama de contexto): plantea la relacin del sistema con el exterior. Incluye una funcin (sistema) y los distintos externos. Nivel 1: dividimos el sistema en grandes funciones de transformacin. Se deben descomponer todas aquellas que se puedan descomponer, para tener el mismo nivel de detalle en cada nivel. Hay que evitar: funciones que slo tengan entradas (no transforman nada), funciones que slo tengan salidas (no hay forma de darle entradas para que produzca esas salidas). Narrativa Estructurada Nos permite describir procesos teniendo en cuenta las tareas que se realizan en un lenguaje sencillo; se trata de agrupar las tareas que hace el proceso. Una vez obtenidos los datos que describen la forma en que opera el sistema, el siguiente paso a seguir es identificar los requerimientos del nuevo sistema.
10
Herramientas de Anlisis de Decisin rbol de Decisin Es una representacin en forma de rbol que representa los valores de las variables y las acciones tomadas para cada valor de las mismas, as como el orden en que se realiza la decisin (n de condiciones no muy grande). Tabla de Decisin Modelo alternativo que muestra la funcin en forma tabular o matricial, donde en sus filas y columnas se indican condiciones y acciones. Est integrada por cuatro secciones. RESUMEN El anlisis de requisitos es la primera fase tcnica del proceso de ingeniera del software. En este punto se refina la declaracin general del mbito del software en una especificacin concreta que se convierte en el fundamento de todas las actividades siguientes de la ingeniera del software. El anlisis debe enfocarse en los dominios de la informacin, funcional y de comportamiento del problema. Para entender mejor lo que se requiere, se crean modelos, los problemas sufren una particin y se desarrollan representaciones que muestran la esencia de los requisitos y posteriormente los detalles de la implementacin. En muchos casos, no es posible especificar completamente un problema en una etapa tan temprana. La creacin de prototipos ofrece un enfoque alternativo que produce un modelo ejecutable del software en el que se pueden refinar los requisitos. Se necesitan herramientas especiales para poder realizar adecuadamente la creacin de prototipos. Como resultado del anlisis, se desarrolla la Especificacin de requisitos del software. La revisin es esencial para asegurarse que el cliente y el desarrollador tienen el mismo concepto del sistema. Desgraciadamente, incluso con los mejores mtodos, la cuestin es que el problema sigue cambiando.
11
UNIDAD III: III: DISEO

DISEO
Proceso de aplicar distintas tcnicas y principios con el propsito de definir un dispositivo, proceso o sistema con suficiente detalle como para permitir su realizacin fsica. Es la etapa ms importante dentro del ciclo de vida de un sistema. Junto con Codificacin y Prueba insumen el 75 % del tiempo. El diseo de un sistema de informacin produce los detalles que establece la forma en que el sistema cumplir con los requisitos identificados durante la fase de anlisis. Los especialistas en sistemas se refieren a esta etapa como diseo lgico (el proceso de transformacin que, partiendo de los requerimientos de los usuarios plasmados en el modelo lgico funcional, construye otro fcil de mantener, confiable, comprensible y con costos mnimos). Se aplica independientemente del paradigma de desarrollo utilizado. Otra definicin: Proceso iterativo de tomar un modelo lgico de un sistema junto con un conjunto de objetivos fuertemente establecidos para este sistema y producir las especificaciones de un sistema fsico que satisfaga estos objetivos. Tipos de Diseo Convencional: Usada en los inicios de la computacin. No segua pasos definidos, sino que se vala del sentido comn. Ligada a lenguajes de alto nivel. Estructurado: Plantea el sistema como un conjunto de funciones. El sistema est orientado a funciones, usando algn concepto de diseo descendente, desagregacin. Descomposicin del sistema o problema en pequeos subsistemas o subproblemas. Orientado a Objetos: Plantea el sistema como una coleccin de objetos que se envan mensajes entre ellos, que poseen responsabilidades y atributos. Orientado a datos: Plantea que en el sistema se deben representar los datos que se visualicen en la empresa, por ms que no se usen ahora; pero vislumbrando requerimientos posteriores. Trata de armar el sistema de acuerdo a las estructuras de datos que obtienen, es decir, analiza la entrada-salida. Caractersticas para que un sistema sea de calidad Que cumpla con los requerimientos. Que sea estable. Que sea fcilmente modificable. Que cumpla con los estndares.
DISEO ESTRUCTURADO
Diseo estructurado es el proceso de decidir qu componentes, y la interconexin entre los mismos, para solucionar un problema bien especificado. Debe ser de fcil mantenimiento. Consiste en la particin del problema en problemas ms simples. Facilita el mantenimiento en etapas posteriores. La etapa de anlisis da como resultado QU hace el sistema; la etapa de diseo es el CMO el sistema realiza el QU. La calidad de un sistema est dada fundamentalmente por el diseo del mismo. El diseo debe tener determinadas caractersticas:
12
1. Que me provea de una METODOLOGA, que yo la pueda aplicar a cualquier problema. 2. Que me d una serie de HERRAMIENTAS (grficas en lo posible) que me permitan trabajar con el problema y que me permitan documentarlo. 3. Que me d una serie de PAUTAS para evaluar la calidad del sistema que estoy produciendo. Complejidad del sistema Que siempre voy a lograr una nica solucin, que tal vez no sea la adecuada; se trata siempre de encontrar la mejor solucin. La diferencia entre los distintos sistemas; nos pueden llamar tanto como para un sistema administrativo, como para uno mdico, etc. Cmo hacer para lograr un equilibrio entre rapidez, estabilidad, seguridad, etc. (IMPORTANTE) Coordinacin, cuando hay mucha gente trabajando; cunto ms grande es el grupo de trabajo, ms complicado es. Trabajar con personas de otras profesiones (aumenta la complejidad). Conceptos y Principios para hacer un buen diseo: El sistema no debe tener agujeros. Ser abiertos a la hora de disear. Debe seguir los pasos desde el anlisis hasta el diseo. Nunca debe realizarse de nuevo algo que ya se hizo. El diseo debera estructurarse para admitir cambios. El diseo debera estructurarse para ser estables. Ir evaluando la calidad del diseo a medida que se lo va haciendo, y no al final (al final podra ser un poco tarde). Someterlo a un proceso de revisin permanente. Conceptos del diseo: 1. Abstraccin Es una modelizacin o representacin mental de un determinado problema. Permite centrarse en un problema desde su generalizacin sin considerar detalles irrelevantes. Se pueden plantear muchos niveles de abstraccin. A nivel superior de abstraccin, se establece una solucin en trminos amplios; a niveles ms bajos, se toma una orientacin ms procedimental. Finalmente al nivel inferior, la solucin se establece de manera que pueda implementarse directamente. 2. Refinamientos Sucesivos El refinamiento es un proceso de elaboracin, donde se empieza con un alto nivel de abstraccin. En el refinamiento el diseador va elaborando el enunciado original, proporcionando ms detalles con cada refinamiento sucesivo (se va mejorando el diseo que estamos realizando). En cada parte del refinamiento se descomponen una o varias instrucciones del programa en cuestin en instrucciones ms detalladas. Va de lo general a lo particular. 3. Modularidad Se divide al sistema en componentes identificables y tratables por separado llamados mdulos, que estn integrados para satisfacer los requisitos del programa. Ante un problema es ms fcil identificarlo; se busca por mdulos y no en todo el sistema. Deben tener independencia funcional. Los mdulos deben ser pequeos para que sean manejables, deben cumplir una sola tarea; que los mdulos estn poco relacionados, que sean independientes. 4. Ocultamiento de la Informacin La ocultacin implica un conjunto de mdulos independientes que se comunican entre ellos solo la informacin necesaria para conseguir la funcin del software. La ocultacin define y refuerza las restricciones.
13
Un mdulo no debe ocultar a otro (a la totalidad del otro). El acoplamiento debe ser de datos. El principio de ocultamiento de la informacin sugiere que los mdulos se han de caracterizar por decisiones de diseo que los oculten unos a otros. Los mdulos deben especificarse y disearse de forma que la informacin (procedimientos y datos) contenida dentro de un mdulo sea accesible a otros nicamente a travs de las interfaces formales establecidas para cada mdulo. Proporciona sus mayores beneficios cuando se requieren modificaciones durante las pruebas o el mantenimiento. 5. Arquitectura del Software La arquitectura es la estructura jerrquica de los componentes del programa (mdulos), la manera de interactuar de estos componentes, y la estructura de los datos usados por estos componentes. 6. Jerarqua de Control Representa la organizacin (frecuentemente jerrquica) de los componentes del programa (mdulos) e implica una jerarqua de control. No representa aspectos procedimentales del software, tales como secuencias de procesos, o la repeticin de operaciones. 7. Estructura de Datos Es una representacin de la relacin lgica entre los elementos individuales de datos. La estructura de datos es tan importante como la estructura del programa en la representacin de la arquitectura del software. La estructura de datos dicta las alternativas de organizacin, mtodos de acceso, capacidad de asociacin y procesamiento de la informacin. La organizacin y complejidad de la estructura de datos estn limitadas slo por el ingenio del diseador. Hay, sin embargo, unas pocas estructuras clsicas de datos que forman la base para construir estructuras ms sofisticadas. 8. Procedimiento del Software Define la jerarqua de control sin tener en cuenta la secuencia de procesamiento y las decisiones. El procedimiento del software se centra en los detalles de procesamiento de cada mdulo individualmente. Debe proporcionar una especificacin exacta del procesamiento, incluyendo la secuencia de acontecimientos, puntos exactos de decisin, operaciones repetitivas e incluso la organizacin de los datos. 9. Independencia Funcional Cada mdulo realiza una sola tarea y cada mdulo tiene que tener el menor nmero posible de comunicaciones con otros mdulos. Tiene una sencilla interfaz cuando se ve desde otras partes de la estructura del programa. Evita la propagacin de problemas. Qu debera tener un buen diseo? Debera presentar una organizacin jerrquica que haga un uso inteligente del control entre los componentes del software. Debe ser modular. Los mdulos deben ser funcionalmente independientes. Debe contener abstracciones de datos y procedimentales. Debe contener interfaces que reduzcan la complejidad de las conexiones entre los mdulos y con el entorno. Lo que se quiere lograr como diseo tendr cuatro partes o pautas: a) DISEO ARQUITECTNICO: define la relacin entre los principales elementos estructurales del programa. Especifica cual va a ser la arquitectura de mi sistema, como va a estar compuesto. El sistema va a estar compuesto por mdulos. Cmo se relacionan entre s. Se lo realiza basado en el D.F.D. b) DISEO DE DATOS: los objetos de datos, las relaciones definidas y el contenido detallado del diccionario de datos proporcionan la base para la actividad de diseo de datos. Los datos de la aplicacin, las claves primarias, secundarias. Bases de datos relacional.
14
c) DISEO DE INTERFAZ: describe como se comunica el software consigo mismo, con los sistemas que operan con l y con los operadores que lo emplean. Debe ser homognea, coherente, amigable, consistente, etc. Por ejemplo, si pongo un botn Aceptar en alguna parte, no poner OK en otra. d) DISEO PROCEDIMENTAL: descripcin procedimental de los elementos del software (qu es lo que hace cada uno de los mdulos). Por ejemplo, mediante pseudocdigo, diagrama de flujo, etc.
NOTA
El diseo debe ser flexible. Cuantos menos detalles de implementacin se dan, ms flexible es el sistema.
Independencia Funcional Lo que me dice es que tengo que tratar de lograr que todos mis mdulos sean funcionalmente independientes, para lo cual tengo dos medidas: la cohesin y el acoplamiento. Cohesin Concepto: es una medida de la fuerza relativa funcional de un mdulo. Medida que sirve para analizar un mdulo internamente; define el nivel de funcionalidad del mdulo. Estudia la relacin que existe entre los elementos de un mismo mdulo. Separa los elementos de mayor relacin de los no relacionados. Hay diferentes tipos de cohesin, a continuacin se los presentan ordenados de mejores a peores. a) COHESIN FUNCIONAL: el mdulo est formado por una nica funcin. Ejemplos: calcular hs. extras; bajas de clientes. Tipos de cohesin ms convenientes b) COHESIN COMUNICACIONAL: un mdulo realiza ms de una tarea y esas tareas estn relacionadas por los datos; las tareas trabajan sobre una misma estructura de datos, pero el orden no importa. Ejemplos: grabar promedio e imprimirlo; leer un registro, modificarlo y grabarlo (son tres tareas, comparten los datos). c) Lmite de Aceptable COHESIN SECUENCIAL: un mdulo realiza ms de una tarea y esas tareas estn relacionadas por los datos y deben ser ejecutadas en una determinada secuencia. Ejemplos: llamar a transaccin y actualizar el archivo; hacer un clculo y grabar un archivo.
d) COHESIN PROCEDIMENTAL: tenemos tareas relacionadas por el orden en que deben ejecutarse y poco relacionadas por los datos. No tienen relacin por los datos. Ejemplo: tenemos un programa y por x razones hay que dividirlo en mdulos, est definido el orden pero no hay relacin entre los datos. e) COHESIN LGICA: el mdulo est formado por funciones semejantes pero diferentes, no trabaja sobre la misma estructura de datos pero la funcin es la misma. Ejemplos: mdulo validar transaccin, depende del tiempo de transaccin para validar datos diferentes. Realizar estadsticas (las estadsticas pueden ser distintas, las tareas pueden ser diferentes). f) COHESIN TEMPORAL: un mdulo tiene varias tareas, que se realizan en un mismo momento. Ejemplo: cerrar archivo, inicializar variables.
g) COHESIN COINCIDENTAL: la serie de tareas que tiene el mdulo no tienen nada que ver, no tienen ninguna relacin. La cohesin coincidental es la peor. Qu es lo ideal? Que tengamos cohesin funcional; a lo sumo cohesin comunicacional o secuencial. Acoplamiento Concepto: se define como el grado de interdependencia entre los mdulos. Para que se produzca un buen diseo, se deben hacer los mdulos tan independientes como sea posible. El acoplamiento depende de la complejidad de la interfaz entre los mdulos. Se intenta conseguir el menor nivel de acoplamiento posible. Existen tres tipos de acoplamiento posibles:
15
a.
ACOPLAMIENTO DE DATOS: los mdulos se comunican mediante parmetros. En todas las entradas y salidas del mdulo se pasan como argumentos elementos de datos (o estructura de datos) y no de control.
b. ACOPLAMIENTO POR ESTAMPADO O PAQUETES: dos mdulos estn acoplados por estampado si ambos hacen referencia a la misma estructura de datos (sino es global). Es importante que la estructura sea utilizable slo por los dos mdulos y no por otros. c. ACOPLAMIENTO DE CONTROL O PATOLGICO: los mdulos se pasan como argumentos elementos de control (cdigo de funciones, flags, switches). No es un buen tipo de acoplamiento, ya que no permite que los mdulos sean totalmente independientes debido a que un mdulo controla a otro, influyendo en su ejecucin.
d. ACOPLAMIENTO GLOBAL: los mdulos comparten una estructura global de datos (entorno comn). Qu es lo ideal? Cuanto menos acoplamiento hay, mejor. Sin embargo, el acoplamiento debe existir, no debe ser nulo, pues no tendra sentido que no haya ninguna comunicacin.
IMPORTANTE El acoplamiento no debe ser nulo, debe ser mnimo.

ETAPAS DEL DISEO Diseo Preliminar Abarca hasta plantear una estructura arquitectnica ms la definicin de los datos. Consiste en el refinamiento de funciones; o sea, llegar a funciones perceptibles y bien detalladas. El DFD se utiliza como herramienta para representar un modelo lgico. Consiste en analizar donde se justifica la incorporacin de almacenes y en el refinamiento de las funciones. La incorporacin de almacenes dentro de un nivel de DFD no significa refinamiento, significa detalle. Diseo Detallado Incluye un refinamiento de la estructura arquitectnica, una definicin detallada de la estructura de datos y una definicin algortmica de los procedimientos. Lo que se obtiene del diseo detallado es lo que entra en la etapa de codificacin. Est compuesto por:
a. Diseo de datos
Maneja como vamos a definir los datos del sistema. Tiene una asociacin directa con la calidad del sistema. El diseo de datos influye tanto en la estructura de los programas como en la complejidad de los procedimientos. Traduce los objetos de datos definidos en el modelo de anlisis a estructuras de datos que residen dentro del software. Consiste en identificar y definir las caractersticas de los almacenes y analizar cul es el contenido de la estructura de datos. Aqu se hace que el modelo lgico se transforme en modelo fsico. Se realiza un diccionario de datos (descripcin de los datos). Principios bsicos para el diseo de datos Tiempo y esfuerzo, metodologa sistemtica. Estructuras de datos y operaciones claramente identificados. Establecer un diccionario de datos y usarlo para definir el diseo de datos y el programa. Las decisiones de diseo de datos de bajo nivel deberan dejarse para el final del proceso de diseo. Ocultamiento de informacin. Desarrollar una biblioteca de estructuras de datos tiles y de operaciones que se les pueden aplicar. La estructura de datos debe estar soportada por el lenguaje de programacin utilizado.
16
Cules son los objetivos del diseo de datos? (Qu es lo que quiere lograr) 1. 2. 3. 4. 5. 6. Disponibilidad de los datos: los datos deben estar disponibles para el usuario en todo momento. Accesibilidad: los datos deben ser fcilmente accesibles. Integridad de datos: los datos deben ser precisos y deben ser consistentes. Ejemplo: que no se pueda borrar un cliente que tiene saldo en Cuenta Corriente. Almacenamiento eficiente: es ms inseguro cuando la informacin se guarda en cintas, etc. Recuperacin eficiente y actualizacin eficiente de la informacin Recuperacin dirigida de la informacin: Data Ware House Data Minning (minera de datos) -> se realiza en empresas grandes. - Data Minning (Minera de Datos): consiste en la extraccin no trivial de informacin que reside de manera implcita en los datos. Dicha informacin era previamente desconocida y podr resultar til para algn proceso. En otras palabras, la minera de datos prepara, sondea y explora los datos para sacar la informacin oculta en ellos. Para un experto, o para el responsable de un sistema, normalmente no son los datos en s lo ms relevante, sino la informacin que se encierra en sus relaciones, fluctuaciones y dependencias. Bajo el nombre de minera de datos se engloba todo un conjunto de tcnicas encaminadas a la extraccin de conocimiento procesable, implcito en las bases de datos. Las bases de la minera de datos se encuentran en la inteligencia artificial y en el anlisis estadstico. Mediante los modelos extrados utilizando tcnicas de minera de datos se aborda la solucin a problemas de prediccin, clasificacin y segmentacin. - Data warehouse (Almacn de Datos): en el contexto de la informtica, un almacn de datos es una coleccin de datos orientada a un determinado mbito (empresa, organizacin, etc.), integrado, no voltil y variable en el tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza. Se trata, sobre todo, de un expediente completo de una organizacin, ms all de la informacin transaccional y operacional, almacenado en una base de datos diseada para favorecer el anlisis y la divulgacin eficiente de datos (especialmente OLAP, procesamiento analtico en lnea). El almacenamiento de los datos no debe usarse con datos de uso actual. Los almacenes de datos contienen grandes cantidades de informacin que se subdividen a veces en unidades lgicas ms pequeas dependiendo del subsistema de la entidad del que procedan o para el que sean necesario. Qu se usa de la etapa de Anlisis? Los flujos de informacin (se encuentran en el Diccionario de Datos) y los objetos de datos, las relaciones (definidas en el Diagrama Entidad-Relacin).
b. Diseo Arquitectnico
Qu es? es la estructura modular que va tener mi sistema y cmo est organizado. Se extrae del D.F.D.; se parte del ltimo nivel del D.F.D. y se va armando la estructura modular, basndose en los procesos. El objetivo es definir una estructura modular y la relacin que existe entre cada uno de los mdulos. Combina la estructura del programa y la estructura de datos, definiendo interfaces que permiten el flujo de datos a travs del programa. El diseo estructurado suele caracterizarse como un mtodo de diseo orientado al flujo de datos porque permite una cmoda transicin desde el diagrama de flujo de datos (DFD) a la arquitectura de software. La transicin desde el flujo de informacin a una estructura se realiza en cinco pasos: 1. Se establece el tipo de flujo de informacin; 2. Se indican los lmites del flujo; 3. Se convierte el DFD en la estructura del programa; 4. Se define la jerarqua de control; 5. Se refina la estructura resultante usando medidas y heursticas de diseo. La conversin de DFD a una estructura modular depende del tipo de flujo de informacin que maneja el DFD.
17
Existen dos tipos de flujos de informacin: Centrado en TRANSFORMACIN La informacin entra al sistema a lo largo de caminos que transforman los datos externos a un formato interno. La informacin entrante se pasa a travs de un centro de transformacin y empieza a moverse a lo largo de caminos que ahora conducen hacia afuera del software (flujo de salida).
Entrada al sistema Transformada Salida del sistema
C G D E F H
Transformacin
Centrado en TRANSACCIN El flujo de informacin est caracterizado a menudo por un nico elemento de datos, denominado transaccin; que desencadena otros flujos de informacin a lo largo de los muchos caminos posibles (segn el valor que tenga). Se caracteriza por los datos que se mueven a lo largo de un camino de entrada que convierte la informacin del mundo exterior en una transaccin. La transaccin se evala y basndose en ese valor, se inicia el flujo a lo largo de uno de los muchos caminos de accin.
Qu se usa de la etapa de Anlisis? Se parte de un DFD en su ltimo nivel, bien detallado, y se trata de definir ese DFD en una estructura jerrquica de mdulos.
c. Diseo de Interfaz
Describe como se comunica el software consigo mismo, con los sistemas que operan con l y con los operadores que lo emplean (usuarios). La interfaz es la cara visible del sistema. El diseo de interfaz se concentra en tres reas importantes: Diseo de Interfaz entre Mdulos Lo que hay que planificar o definir es cmo se relacionan los mdulos considerando que entre ellos fluyen datos. Se debera tener definido el lenguaje en el que se va a desarrollar el sistema. Diseo de Interfaz Externa Trata de cmo se vinculan los entes externos al sistema, con el sistema. Se determinan los requisitos de datos y control de las entidades externas y se disean las apropiadas interfaces externas. Es conveniente tener almacenada la informacin para cuando se la necesite.
18
Ente Ext.
Precios
Precios
Mdulo de Interfaz Actualizacin de precios
Ambos diseos de interfaces deben acoplarse con algoritmos de validacin de datos y correccin de errores dentro del mdulo, para evitar la propagacin de efectos secundarios (que no sobrepasen los lmites establecidos). Diseo de Interfaz Hombre-Mquina Tiene ms que ver con la parte visual del sistema. Tiene como objetivo lograr un sistema amigable y fcil de manejar. El proceso general para disear la interfaz de usuario empieza con la creacin de diferentes modelos de funcin del sistema (tal y como se percibe desde afuera). Se definen las tareas orientadas al hombre y a la mquina, requeridas para conseguir la funcin del sistema. Criterios para Desarrollar una Interfaz Que sea fcil de usar; Que sea homognea; Que sea intuitiva; La carga de datos debe ser rpida; El sistema debe ser tolerante a errores; Se deben realizar las acciones del sistema de modo que sea encadenado; La informacin brindada no deja lugar a dudas; No hay que mostrar informacin excesiva (innecesaria). Cmo debe ser la interfaz? (qu es lo que reclaman los usuarios) Rpida en el tiempo de respuesta: En general, el tiempo de respuesta del sistema se mide desde el punto de vista que el usuario realiza la accin de control (por ejemplo, pulsar la tecla Enter o pulsar el botn del ratn) hasta que el software responde con la salida o accin deseada. El tiempo de respuesta del sistema tiene dos caractersticas importantes: la duracin y la variabilidad. Si la duracin de la respuesta del sistema es demasiado larga, es inevitable obtener como resultado la frustracin y el estrs del usuario. Sin embargo, si la interfaz va marcando el ritmo del usuario una duracin breve del tiempo de respuesta puede ser tambin perjudicial. Un tiempo de respuesta rpido puede obligar a que el usuario se precipite y cometa errores. La variabilidad se refiere a la desviacin del tiempo de respuesta promedio, y en muchos aspectos es la caracterstica ms importante del tiempo de respuesta. Una variabilidad baja posibilita al usuario establecer un ritmo de interaccin, aunque el tiempo de respuesta sea relativamente largo. Por ejemplo, es preferible obtener una segunda respuesta de una orden a una respuesta que vare de 0,l a 2,5 segundos. El usuario siempre estar desconcertado y preguntndose si ha ocurrido algo diferente detrs de la escena. Ayuda: Los dos tipos de funciones de ayuda ms comunes son: integradas y complementarias (aadibles). Se disea una funcin de ayuda integrada dentro del mismo software desde el principio. Suele ser sensible al contexto, lo que posibilita al usuario seleccionar entre los temas que sean relevantes para las acciones que est llevando a cabo en ese momento. Obviamente, esto reduce el tiempo que requiere para obtener ayuda, e incrementa su familiaridad con la interfaz. Una funcin de ayuda complementaria se aade al software una vez construido el sistema. En muchos aspectos es muy similar a un manual de usuario en lnea con una capacidad limitada de consulta. Es posible que el usuario tenga que buscar en una lista de miles de temas para encontrar la gua adecuada, entrando normalmente en las ayudas
19
incorrectas y recibiendo mucha informacin irrelevante. No hay ninguna duda de que es preferible el enfoque de funciones de ayuda integradas al enfoque de funciones complementarias. Cuando se va a considerar un servicio de ayuda hay una serie de temas de diseo que debern abordarse: Se necesitar disponer de todas las funciones del sistema en cualquier momento durante la interaccin del sistema? Opciones: ayuda solo para un subconjunto de todas las funciones y acciones; ayuda para todas las funciones. De qu forma solicitar ayuda el usuario? Opciones: un men de ayuda; una tecla de funcin especial; una orden de AYUDA. Cmo se representar la ayuda? Opciones: una ventana separada, una referencia a un documento impreso (no es lo ideal); una sugerencia de una o dos lneas que surge en una localizacin fija en la pantalla. Cmo regresar el usuario a la interaccin normal? Opciones: un botn de retorno visualizado en la pantalla; una tecla de funcin o una secuencia de control. Cmo se estructurar la informacin sobre la pantalla? Opciones: una estructura plana donde el acceso a la informacin se realiza mediante una contrasea; una jerarqua estratificada de informacin que va proporcionando ms datos a medida que el usuario va entrando por la estructura; la utilizacin de hipertexto. Manejo de errores (no debe ser alarmante): En general, todos los mensajes de error o sugerencias de un sistema interactivo debern tener las caractersticas siguientes: El mensaje deber describir el problema en una jerga que el usuario pueda entender. El mensaje deber proporcionar consejos constructivos para recuperarse de un error. El mensaje deber indicar cualquier consecuencia negativa del error (por ejemplo, los archivos de datos posiblemente deteriorados) para que el usuario pueda comprobar y garantizar que no hay ninguno (y corregirlos si existen). El mensaje deber ir seguido por una clave audible o visual. Esto es, para acompaar la visualizacin del mensaje se podra generar un pitido, o aparecer momentneamente una luz destellante o visualizarse en un color que se pueda reconocer fcilmente como el color del error. El mensaje no deber tener sentencias. Esto es, las palabras del mensaje nunca debern culpar al usuario. Estructura de rdenes: Cuando se proporcionan rdenes escritas como modo de interaccin surge una serie de temas de diseo: Se corresponden todas las opciones del men con sus rdenes? Qu formas adquirirn las rdenes? Opciones: una secuencia de control (por ejemplo, Alt-P); teclas de funcin; una palabra tecleada. Ser difcil aprender y recordar las rdenes? Qu se puede hacer si se olvida una orden? Podr personalizar o abreviar el usuario las rdenes? Criterios para evaluar si una interfaz es buena Longitud y complejidad de la tarea: indica la cantidad de aprendizaje necesario para los usuarios. El nmero de rdenes o acciones especificadas: esto nos indica que el tiempo de interaccin es la eficiencia general del sistema. El nmero de acciones y estados del sistema: indican la carga de memorizacin del usuario del sistema. El estilo de la interfaz, las ayudas y los protocolos de manipulacin de errores: indican la complejidad de la interfaz y el grado de aceptacin del usuario.
20
FIGURA: El ciclo de evaluacin de diseo de la interfaz.
Directrices o consejos Se dividen en tres categoras: Interaccin general. Visualizacin de la informacin. Entrada de datos. Interaccin general Ser consistente. Ofrecer respuestas significativas. Pedir verificacin de cualquier accin destructiva importante. Permitir deshacer la mayora de las acciones. Reducir la cantidad de informacin que se debe memorizar entre acciones. Buscar la eficiencia en el dilogo, el movimiento y el pensamiento. Perdonar los errores. Categorizar las actividades por funcin y organizar la pantalla de acuerdo a esto. Proporcionar ayuda sensible al contexto. Indicar las rdenes mediante verbos. Visualizacin de la informacin Mostrar slo la informacin que sea relevante en el contexto actual. No abrumar al usuario con datos. Utilizar un formato de visualizacin que permita una rpida asimilacin de la informacin. Usar etiquetas consistentes, abreviaciones estndar y colores predecibles. Producir mensajes de error significativos. Usar maysculas y minsculas, tabulaciones y agrupamientos de textos. Utilizar ventanas para dividir la informacin que se muestra y agruparla en un determinado sentido.
21
Estudiar la geografa de la pantalla y utilizarla lo mejor posible. Entrada de datos Minimizar el nmero de acciones. Mantener la consistencia entre la introduccin y la visualizacin de datos. Permitir al usuario personalizar la entrada de datos. La interaccin debe ser flexible y sintonizarse al modo preferido por el usuario. Desactivar las rdenes que son inapropiadas en el contexto actual. Dejar al usuario controlar el flujo interactivo. Proporcionar ayuda en todas las acciones de entrada. Eliminar todas las entradas innecesarias. Qu se usa de la etapa de Anlisis? Las entradas y salidas del DFD, sus funciones de comportamiento.
d. Diseo Procedimental
El diseo procedimental, llamado tambin diseo a nivel de componentes, tiene lugar despus de haber establecido los diseos de datos, de interfaces y de arquitectura. El objetivo es convertir el modelo de diseo en un software operacional. Consiste en detallar los procedimientos que forman el sistema, indicando qu se debe hacer con los datos, qu se obtiene, qu se valida, qu se verifica. Sin ambigedades. El diseo procedimental es la especificacin funcional de los mdulos y requiere definir los detalles algortmicos en un lenguaje natural. Esta especificacin es una especie de programa o pseudocdigo que especifica las entradas, salidas, etc. Existen varias tcnicas diferentes para representar un diseo procedimental. Entre ellas, la Notacin tabular de diseo y Notacin grfica del diseo. Se puede establecer una comparacin teniendo la premisa de que cualquier notacin para el diseo procedimental, si se utiliza correctamente, puede ser una ayuda incalculable para el proceso de diseo; por el contrario, aun con la mejor notacin, si sta se aplica mal, disminuye su entendimiento. Los criterios que se pueden aplicar para comparar las notaciones de diseo son: Modularidad. Una notacin de diseo deber soportar el desarrollo del software modular y proporcionar un medio para la especificacin de la interfaz. Simplicidad general. Una notacin de diseo deber ser relativamente simple de aprender, relativamente fcil de utilizar y en general fcil de leer. Facilidad de edicin. Es posible que el diseo procedimental requiera alguna modificacin a medida que el proceso de software avanza. La facilidad con la que un diseo se puede editar ayudar a simplificar todas y cada una de las tareas de la ingeniera del software. Legibilidad para la computadora. Una notacin que se puede introducir directamente en un sistema de desarrollo basado en computadora ofrece ventajas significativas. Capacidad de mantenimiento. El mantenimiento del software es la fase ms costosa del ciclo de vida del software. El mantenimiento de la configuracin del software casi siempre lleva al mantenimiento de la representacin del diseo procedimental. Cumplimiento de las estructuras. Ya se han descrito las ventajas de un enfoque de diseo que utiliza conceptos de programacin estructurada. Una notacin de diseo que hace cumplir slo la utilizacin de construcciones estructuradas conduce a la prctica de un buen diseo. Proceso automtico. Un diseo procedimental contiene la informacin que se puede procesar para que el diseador pueda observar otra vez y mejorar la correccin y calidad de un diseo. Dicha observacin puede mejorarse con informes que provengan de herramientas de diseo de software.
22
Representacin de datos. La habilidad de representar datos locales y globales es un elemento esencial del diseo detallado. Una notacin de diseo ideal sera la representacin directa de los datos. Verificacin de la lgica. La verificacin automtica de la lgica del diseo es el objetivo primordial durante las pruebas del software. Una notacin que mejora la habilidad de verificar la lgica mejora enormemente lo aceptable de las pruebas. Habilidad de codificar en. La tarea de ingeniera del software que va a continuacin del diseo a nivel de componentes es la generacin de cdigos. Una notacin que puede convertirse fcilmente en cdigo fuente reduce esfuerzos y errores. Qu es? El diseo procedimental consiste en convertir el diseo de datos, interfaces y arquitectura en un software operacional. Para poderlo llevar a cabo, el diseo se deber representar a un nivel de abstraccin cercano a un cdigo. El diseo a nivel de componentes establece los datos algortmicos que se requieren para manipular las estructuras de datos, efectuar la comunicacin entre los componentes del software por medio de las interfaces, e implementar los algoritmos asignados a cada componente Quin lo hace? Un ingeniero del software. Por qu es importante? Se tiene que tener la capacidad de determinar si el programa funcionar antes de construirlo. El diseo a nivel de componentes representa el software que permite revisar los datos del diseo para su correccin y consistencia con las representaciones de diseo anteriores (esto es, los diseo de datos, de interfaces y de arquitectura). Con este diseo se proporciona un medio de evaluar el funcionamiento de las estructuras de datos, interfaces y algoritmos. Cules son los pasos? Las representaciones de los diseos de datos, arquitectura e interfaces forman la base del diseo a nivel de componentes. La narrativa del proceso de cada componente se convierte en un modelo de diseo procedimental empleando un conjunto de construcciones de programacin estructurada. Para representar este diseo se utilizan las notaciones grficas, tabulares y basadas en texto. Cul es el producto obtenido? El diseo procedimental de cada componente representado en forma de notacin grfica, tabular o basada en texto es el primer producto de trabajo durante el diseo a nivel de componentes. Cmo puedo estar seguro de que lo he hecho correctamente? Mediante una revisin estructurada y una inspeccin. El examen del diseo se realiza para determinar si las estructuras de los datos, las secuencias del proceso y las condiciones lgicas son correctas, y para ver si producirn la transformacin de datos y control adecuados que se asign al componente durante los primeros pasos del diseo. Qu se usa de la etapa de Anlisis? La descripcin de lo que hace cada uno de los procesos. Narrativa estructurada.
23
UNIDAD IV: IV: PROGRAMACIN

PROGRAMACION
Consiste en transformar los distintos mdulos que componen el sistema en instrucciones que sean ejecutables por una computadora. El objetivo de esta etapa es producir programas confiables y de fcil mantenimiento. En esta etapa trabaja el programador, escribe instrucciones cdigo. Se le debe entregar la definicin de las estructuras de datos y la descripcin del proceso a programar, el diseo de interfaces y los datos de prueba de los cdigos. El analista aprueba o desaprueba el cdigo escrito, acompaa al programador de tal manera que vaya entendiendo lo que se le ha pedido. Esta etapa tambin se denomina diseo fsico del software y los archivos. Especificacin Funcional Es el detalle que los analistas les entregan a los programadores por cada proceso definido. En ella consta toda la informacin necesaria para desarrollar el software (diseo de pantallas y de archivos, lenguaje de programacin, nombres de los archivos y variables, lneas de mensajes de error, ayudas, etc.). Ocultacin de la Informacin A cada unidad de programa slo se le debe permitir el acceso a aquellos objetos de programas que necesite para realizar su funcin. El acceso a otros objetos que la unidad no necesita, debe ser negado. La ventaja de ocultar informacin innecesaria, es que no hay manera de que la informacin oculta sea corrompida por una unidad de programa que se supone no debe utilizarla. Estilo de Programacin Un programa bien escrito est bien organizado, emplea nombres significativos, incluye comentarios sensatos y utiliza construcciones del lenguaje que hacen ptimas la seguridad y legibilidad. La creacin de tales programas requiere cuidado, disciplina y profesionalidad en el trabajo por parte del programador. Instrumentos de Software Mejoran la productividad del programador, relevndolo de las tareas administrativas que antes realizaba. Algunos de ellos son: las bibliotecas de subrutinas generales, editores de lnea, traductores de programa (a cdigo mquina), instrumentos de anlisis de programas, instrumentos de administracin de configuracin, etc. Metodologas Alternativas de Programacin Si el programa se considera como una jerarqua de componentes: DESARROLLO DESCENDENTE: implica empezar en el tope de la jerarqua y trabajar hacia abajo; DESARROLLO ASCENDENTE: se empieza en el nivel ms bajo y se prosigue hacia arriba. El desarrollo descendente es una metodologa superior porque da como resultado la creacin de programas ms legibles y confiables que los aplicados con tcnicas descendentes. Cuestiones comunes a todos los Programas Productividad Es una medida de la cantidad de programacin o tiempo de trabajo que se realiza en un tiempo dado. Es importante porque sin una estimacin de productividad es imposible la asignacin de tiempo al proyecto. Eficiencia Resulta importante minimizar la cantidad de tiempo de CPU requerido por el programa, la utilizacin de la memoria, al igual que otros recursos como el disco. Mucho tiempo en el desarrollo de un programa eficiente, es probable que ste sea menos mantenible y menos transportable.
24
Correccin Si el programa no funciona correctamente, no importa que tan eficiente sea. Se requiere que el programador declare la naturaleza de las variables y as el lenguaje pueda revisar todo cuidadosamente para evitar referencias ilegales a los datos. Portabilidad Es muy importante escribir los programas de manera que se puedan aplicar a ms de una configuracin del sistema de cmputo y del Sistema Operativo. Mantenibilidad Debemos recordar que los sistemas viven durante mucho tiempo, por lo que el software debe mantenerse. El Papel del Analista Debe supervisar y coordinar todas las tareas de programacin que se van a realizar. Proporciona datos de prueba. Puede desarrollar manuales de usuario. Acta ante consulta de los programadores. Puede llegar a realizar tareas de programacin. Responde ante posibles cambios en los requerimientos de los usuarios. La eleccin del lenguaje de programacin depende: Del tamao del proyecto y el volumen de datos que maneja. De la organizacin, porque pueden tener un determinado software comprado. Del conocimiento de lenguajes que tienen los programadores. Transportabilidad del software.
25
UNIDAD V: PRUEBA
PRUEBA
Es un elemento crtico para la calidad del software y representa una revisin final de las especificaciones, del diseo y de la codificacin. Consiste en crear una serie de casos de prueba que intentan <<demoler>> el software construido. Debe probarlo una persona ajena al desarrollo. Conviene probar cada mdulo antes que probar el sistema completo. Objetivos de la Prueba La prueba es un proceso de ejecucin de un programa con la intencin de descubrir un error. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene xito si descubre un error no detectado hasta el momento.
NOTA
La prueba no puede asegurar la ausencia de defectos, slo puede demostrar que existen defectos en el software.
Principios de las Pruebas Antes de la aplicacin de mtodos para el diseo de casos de prueba efectivos, un ingeniero del software deber entender los principios bsicos que guan las pruebas del software. A todas las pruebas se les debera poder hacer un seguimiento hasta los requisitos del cliente. Como hemos visto, el objetivo de las pruebas del software es descubrir errores. Se entiende que los defectos ms graves (desde el punto de vista del cliente) son aquellos que impiden al programa cumplir sus requisitos. Las pruebas deberan planificarse mucho antes de que empiecen. La planificacin de las pueden empezar tan pronto como est completo el modelo de requisitos. La definicin detallada de los casos de prueba puede empezar tan pronto como el modelo de diseo se ha consolidado. Por tanto, se pueden planificar y disear todas las pruebas antes de generar ningn cdigo. El principio de Pareto es aplicable a la prueba del software. Dicho de manera sencilla, el principio de Pareto implica que al 80 por 100 de todos los errores descubiertos durante las pruebas se les puede hacer un seguimiento hasta un 20 por 100 de todos los mdulos del programa. El problema, por supuesto, es aislar estos mdulos sospechosos y probarlos concienzudamente. Las pruebas deberan empezar por lo pequeo y progresar hacia lo grande. Las primeras pruebas planeadas y ejecutadas se centran generalmente en mdulos individuales del programa. A medida que avanzan las pruebas, desplazan su punto de mira en un intento de encontrar errores en grupos integrados de mdulos y finalmente en el sistema entero. No son posibles las pruebas exhaustivas. El nmero de permutaciones de caminos para incluso un programa de tamao moderado es excepcionalmente grande. Por este motivo, es imposible ejecutar todas las combinaciones de caminos durante las pruebas. Es posible, sin embargo, cubrir adecuadamente la lgica del programa y asegurarse de que se han aplicado todas las condiciones en el diseo a nivel de componente. Para ser ms eficaces, las pruebas deberan ser realizadas por un equipo independiente. Si se quiere tener una mayor probabilidad de encontrar errores, el ingeniero del software que cre el sistema no es el ms adecuado para llevar a cabo las pruebas para el software. Datos de Prueba Reales Son aquellos que se extraen de los archivos de la organizacin. Son muy difciles de conseguir en cantidad suficiente como para desarrollar pruebas extensas. Estos datos mostrarn como funciona el sistema para los requerimientos tpicos de procesamiento (los datos reales generalmente no abarcan todas las combinaciones o formatos posibles). Artificiales
26
Se crean solamente a fines de efectuar las pruebas. Dado que se pueden manipular todas las combinaciones de formatos y valores, harn posible las pruebas de todas las rutas lgicas y de control en todo el programa. Los programas de pruebas ms exitosos utilizan lotes de prueba artificiales. Diseos de Casos de Prueba El principal objetivo del diseo de casos de prueba es obtener un conjunto de pruebas que tengan la mayor probabilidad de descubrir los defectos del software. Para llevar a cabo este objetivo, se usan dos categoras diferentes: Mtodo de Caja Blanca (enfoque estructural) La prueba de caja blanca, denominada a veces prueba de caja de cristal, es un mtodo de diseo de casos de prueba que usa la estructura de control del diseo procedimental para obtener los casos de prueba. Mediante los mtodos de prueba de caja blanca, el ingeniero del software puede obtener casos de prueba que (1) garanticen que se ejercita por lo menos una vez todos los caminos independientes de cada mdulo; (2) ejerciten todas las decisiones lgicas en sus vertientes verdadera y falsa; (3) ejecuten todos los bucles en sus lmites y con sus lmites operacionales; y (4) ejerciten las estructuras internas de datos para asegurar su validez. Consiste en centrarse en la estructura interna del programa para elegir los casos de prueba. La prueba ideal del software consistira en probar todos los posibles caminos de ejecucin, a travs de las instrucciones de cdigo, que puedan trazarse, esto es asegurar que por lo menos una vez, durante la prueba, se ejecutan todas las sentencias del programa y que se ejercitan todas las condiciones lgicas. Son tpicamente aplicadas a pequeos componentes de programas (mdulos o pequeos grupos de ellos). Prueba del camino bsico: obtiene un conjunto de pruebas linealmente independiente (usa matrices de grafos) que asegura que se ejecute por lo menos una vez cada sentencia del programa. Prueba de condicin: ejercita las cada una de las condiciones lgicas en el mdulo de un programa lo que amplia la cobertura de la prueba y mejora la calidad de la prueba de caja blanca. Prueba de flujo de datos: selecciona caminos de prueba de un programa de acuerdo con la ubicacin de las definiciones y los usos de las variables del programa. Prueba de bucles: se centra en la validez de las construcciones de bucles. Mtodo de Caja Negra (enfoque funcional) Consiste en estudiar la especificacin de las funciones, la entrada y la salida del sistema para derivar los casos. La prueba ideal consistira en probar todas las posibles entradas y salidas del programa. Se refiere a las pruebas que se llevan a cabo sobre la interfaz del software y no sobre el funcionamiento interno del mismo. O sea, los casos de prueba pretenden demostrar que las funciones de software son operativas, que la entrada se acepta en forma adecuada y que se produce un resultado correcto, as como que la integridad de la informacin externa se mantiene. Intenta encontrar errores en las siguientes categoras: Funciones incorrectas o ausentes; Errores de interfaz; Errores en estructuras de datos; Errores de rendimiento; Errores de inicializacin y de terminacin. A diferencia de la prueba de caja blanca, que se lleva a cabo previamente en el proceso de prueba, la prueba de caja negra tiende a aplicarse durante fases posteriores de la prueba. Ya que la prueba de caja negra ignora intencionadamente la estructura de control, centra su atencin en el campo de la informacin. Las pruebas se disean para responder a las siguientes preguntas: Cmo se prueba la validez funcional? Cmo se prueba el rendimiento y el comportamiento del sistema? Qu clases de entrada compondrn unos buenos casos de prueba?
27
Es el sistema particularmente sensible a ciertos valores de entrada? De qu forma estn aislados los lmites de una clase de datos? Qu volmenes y niveles de datos tolerar el sistema? Qu efectos sobre la operacin del sistema tendrn combinaciones especficas de datos? Tipos de Prueba Prueba de Unidad Centra el proceso de verificacin en la menor unidad del diseo del software: el mdulo (cada uno en forma independiente). Se prueban los caminos de control importantes, con el fin de descubrir errores dentro del lmite del mdulo. Este paso se puede llevar a cabo en paralelo para mltiples mdulos. Lleva la prueba si o si de la caja blanca y se puede complementar con la caja negra. Esta prueba se simplifica cuando existe un alto grado de cohesin. Cuando un mdulo slo realiza una funcin, se reduce el nmero de casos de prueba y los errores se pueden predecir y descubrir ms fcilmente.
FIGURA: Prueba de Unidad.
Prueba de Integracin La prueba de integracin es una tcnica sistemtica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interaccin. El objetivo es coger los mdulos probados mediante la prueba de unidad y construir una estructura de programa que est de acuerdo con lo que dicta el diseo. Est ligada a la forma prevista de integrar los distintos componentes del software hasta contar con el producto global que debe entregarse. Su objetivo fundamental es la prueba de interfaces (flujo de datos) entre los mdulos. Integracin Incremental: se combina el siguiente mdulo que se debe probar con el conjunto de mdulos ya probados. ASCENDENTE: empieza la construccin y la prueba con los mdulos atmicos (es decir, mdulos de los niveles ms bajos de la estructura del programa, mdulos hoja). Dado que los mdulos se integran de abajo hacia arriba, el proceso requerido de los mdulos subordinados siempre est disponible y se elimina la necesidad de resguardos. La principal desventaja de la integracin ascendente es que el programa como entidad no existe hasta que se ha aadido el ltimo mdulo. Este inconveniente se resuelve con la mayor facilidad de diseo de casos de prueba y con la falta de resguardos.
28
FIGURA: Integracin ascendente.
DESCENDENTE: se comienza por los mdulos raz. Es un planteamiento incremental a la construccin de la estructura de programas. Se integran los mdulos movindose hacia abajo por la jerarqua de control, comenzando por el mdulo de control principal (programa principal). Los mdulos subordinados (subordinados de cualquier modo) al mdulo de control principal se van incorporando en la estructura, bien de forma primero-en-profundidad, o bien de forma primero-en-anchura. La principal desventaja del enfoque descendente es la necesidad de resguardos y las dificultades de prueba que pueden estar asociados con ellos.
FIGURA: Integracin descendente.
Prueba de Validacin o Aceptacin El objetivo que se desea lograr consiste en comprobar si el producto est listo para ser implantado para el uso operativo en el entorno del usuario. Es la prueba para determinar si se cumplen los requisitos de aceptacin marcados por el cliente. La validacin del software se consigue mediante una serie de pruebas de caja negra que demuestran la conformidad con los requisitos. Un plan de prueba traza la clase de pruebas que se han de llevar a cabo, y un procedimiento de prueba define los casos de prueba especficos en un intento por descubrir errores de acuerdo con los requisitos. Tanto el plan como el procedimiento estarn diseados para asegurar que se satisfacen todos los requisitos funcionales, que se alcanzan todos los requisitos de rendimiento, que la documentacin es correcta e inteligible y que se alcanzan otros requisitos (por ejemplo, portabilidad, compatibilidad, recuperacin de errores, facilidad de mantenimiento). Una vez que se procede con cada caso de prueba de validacin, puede darse una de las dos condiciones siguientes: (1) las caractersticas de funcionamiento o de rendimiento estn de acuerdo con las especificaciones y son aceptables; o (2) se descubre una desviacin de las especificaciones y se crea una lista de deficiencias. Las
29
desviaciones o errores descubiertos en esta fase del proyecto raramente se pueden corregir antes de la terminacin planificada. A menudo es necesario negociar con el cliente un mtodo para resolver las deficiencias. La prueba alfa se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y los problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado. La prueba beta se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no est presente normalmente. As, la prueba beta es una aplicacin en vivo del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas (reales o imaginarios) que encuentra durante la prueba beta e informa a intervalos regulares al desarrollador. Como resultado de los problemas informados durante la prueba beta, el desarrollador del software lleva a cabo modificaciones y as prepara una versin del producto de software para toda la clase de clientes. Prueba del Sistema Es el proceso de prueba de un sistema integrado de hardware y software para comprobar si cumplen los requisitos especificados. La prueba del sistema est constituida por una serie de pruebas diferentes cuyo propsito es ejercitar profundamente el sistema basado en computadora. Aunque cada prueba tiene un propsito diferente, todas trabajan para verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas. Prueba de Recuperacin: es una prueba del sistema que fuerza al fallo del software de muchas formas y verifica que la recuperacin se lleva a cabo apropiadamente. Si la recuperacin es automtica (llevada a cabo por el propio sistema) hay que evaluar la correccin de la inicializacin, de los mecanismos de recuperacin del estado del sistema, de la recuperacin de datos y del proceso de rearranque. Si la recuperacin requiere la intervencin humana, hay que evaluar los tiempos medios de reparacin (TMR) para determinar si estn dentro de unos lmites aceptables. Prueba de Seguridad: intenta verificar que los mecanismos de proteccin incorporados en el sistema lo protegern de accesos impropios o ilegales. Durante la prueba de seguridad, el responsable de la prueba desempea el papel de un individuo que desea entrar en el sistema. Debe intentar conseguir las claves de acceso por cualquier medio, puede atacar al sistema con software a medida, diseado para romper cualquier defensa que se haya construido, debe bloquear el sistema, negando as el servicio a otras personas, debe producir a propsito errores del sistema, intentando acceder durante la recuperacin o debe curiosear en los datos sin proteccin, intentando encontrar la clave de acceso al sistema, etc. Prueba de Resistencia (Stress): estn diseadas para enfrentar a los programas con situaciones anormales. Ejecuta un sistema de forma que demande recursos en cantidad, frecuencia y volmenes no frecuentes. Tratar de sobrecargarlo para ver cmo responde. Ejemplos: incrementar la frecuencia de datos de entrada con el fin de comprobar cmo responden las funciones de entrada; ejecutar casos de prueba que requieran el mximo de memoria o de otros recursos; disear pruebas especiales que generen diez interrupciones por segundo, cuando las normales son una o dos; disear casos de prueba que puedan dar problemas en un sistema operativo virtual; disear casos de prueba que produzcan excesivas bsquedas de datos residentes en disco. Esencialmente, el responsable de la prueba intenta romper el programa. Prueba de rendimiento: est diseada para probar el rendimiento del software en tiempo de ejecucin dentro del contexto de un sistema integrado y se da durante todos los pasos del proceso de prueba. Se debe asegurar el rendimiento de los mdulos individuales a medida que se llevan a cabo las pruebas de caja blanca. Sin embargo, hasta que no estn completamente integrados todos los elementos del sistema no se puede asegurar realmente el rendimiento del sistema. Depuracin La depuracin ocurre como consecuencia de una prueba efectiva. Es decir, cuando un caso de prueba descubre un error, la depuracin es el proceso que provoca la eliminacin del error.
30
A diferencia de la prueba, la depuracin puede considerarse un arte que surge como consecuencia de la prueba. A partir de una indicacin sintomtica de un problema, la actividad de depuracin debe rastrear la causa del error. Se tienen siempre dos resultados: Se encuentra la causa, se corrige y se elimina o, No se encuentra la causa. Para el ltimo caso, la persona que realiza la depuracin debe sospechar la causa, disear un caso de prueba que ayude a confirmar sus sospechas y el trabajo vuelve hacia atrs a la correccin del error de una forma iterativa.
FIGURA: Proceso de depuracin.
31
UNIDAD VI: VI: IMPLEMENTACIN DEL SISTEMA

IMPLEMENTACIN
Consiste en la puesta en marcha del sistema o proyecto en el lugar donde va a funcionar el sistema. A partir de aqu el usuario podr hacer uso de la informacin que el sistema le brinda. En toda etapa de implementacin deben desarrollarse las siguientes etapas: Capacitacin del Usuario OBJETIVOS: 1 Que el usuario conozca lo que el sistema le proporciona (qu informacin brinda). 2 Que cada uno de los usuarios conozca las responsabilidades que les toca. La capacitacin tomar distintos perfiles de acuerdo al tipo de usuario a capacitar: Permitir al usuario final o gerencial conocer cul es la informacin que brinda el sistema. Capacitacin operativa: al personal de operaciones, cmo recuperar el sistema si se cae o si se produce un fallo de hardware o software. Usuario de nivel jerrquico: la informacin que el sistema necesita y cul le brinda. Todas las personas que tendrn uso primario o secundario debern ser capacitadas. Conversin del Sistema Cambio del sistema viejo por el sistema nuevo. Hay diferentes formas de proceder a la conversin: Cambio Directo A partir de tal fecha se deja de usar el sistema viejo y se empieza a usar el sistema nuevo. Se realiza cuando el sistema nuevo es sencillo, completamente distinto al viejo o el rendimiento no es crtico. Ventaja: menor costo, el usuario se ve obligado a usar el sistema nuevo aunque no le guste. Desventaja: si existen problemas con el sistema nuevo no se puede volver al viejo. No permite comparar resultados. Puede haber resentimiento por parte de los usuarios. Conversin en Paralelo Por un tiempo se corren simultneamente el sistema viejo y el nuevo, y se examinan los resultados; cuando se obtienen los mismos resultados se pone en uso el sistema nuevo y al antiguo se lo desecha. Ventaja: permite comparar resultados y rescatar errores del sistema nuevo. Proporciona un sentido de seguridad a los usuarios. Desventaja: mayor costo de funcionamiento, las salidas de uno y otro pueden diferir. Usuario resistente al cambio. Conversin Gradual o por Fases Trata de combinar las mejores caractersticas de los dos mtodos anteriores sin incurrir en todos los riesgos. En este plan el nmero de transacciones es aumentado gradualmente conforme el sistema avanza en sus fases. Ventaja: involucracin gradual de los usuarios. Posibilidad de deteccin y recuperacin de errores sin perder mucho tiempo. Desventaja: lleva demasiado tiempo poner al sistema nuevo en su lugar. Inadecuado para la conversin de sistemas pequeos no complicados. Ejemplo: lo implemento en sucursales; lo implemento todo, pero no en toda la empresa, slo en una o varias sucursales. Enfoque Piloto (Modular) Se instala el sistema nuevo en una parte de la organizacin, si funciona se extiende a otra parte. Se usa la construccin de prototipos operacionales modulares para cambiar del sistema antiguo al nuevo en forma gradual. Ventaja: errores localizados. Los usuarios se familiarizan con cada mdulo.
32
Desventaja: puede llevar mucho tiempo. No siempre es posible la construccin de prototipos. Es ms costoso. Migracin de Datos Se deben convertir los datos del sistema viejo para colocarlos en el sistema nuevo. Estos pueden cambiar: formato de datos, medios de almacenamiento, contenido. Si el sistema viejo no es computarizado, se puede planificar una carga masiva o individual. Evaluacin o Seguimiento Se ha estado evaluando la evolucin del sistema de informacin para dar retroalimentacin para su mejora eventual. La evaluacin tambin es llamada para dar continuidad a la implementacin del sistema. Consiste en el control o seguimiento sobre todas las etapas de la implementacin, se ve como va funcionando el sistema y se va acomodando. TCNICAS DE EVALUACIN: Anlisis costo-beneficio; Evaluacin de decisiones revisadas; Involucramiento del usuario; Enfoque de utilidad del sistema. Respaldo y Recuperacin de Archivos Para protegerse contra la prdida de datos, los analistas disean procedimientos de respaldo. Se hacen copias duplicadas de los datos para garantizar que siempre existir una copia de los registros, an cuando el original se dae o se destruya. Auditoria: Los analistas deben tener capacidad de validar los reportes y salidas, y de probar la autenticidad y precisin de los datos e informacin que arroja el sistema. Entre los procesos de auditoria y control tenemos: Rastreo de transacciones y de anlisis de valores intermedios producidos durante el procesamiento. Impresin de registros seleccionados que cumplan ciertos criterios para validar la autenticidad de los datos. Mantenimiento constante de las situaciones financieras cuando el sistema maneje este tipo de informacin. Controles suficientes de las entradas de datos, dado que un sistema para ser confiable debe asegurar datos confiables, precisos y crebles. Seguridad La seguridad es una necesidad ya que la informacin es un recurso organizacional fundamental. Aunque no existe un sistema totalmente seguro, el analista pretende disminuir la vulnerabilidad del sistema. Seguridad Fsica: Seguridad de las instalaciones de computacin (Hardware y Software). Seguridad Lgica: Controles lgicos (contraseas y cdigos de autorizacin) dentro del mismo software. Seguridad de Comportamiento: Se debe investigar a los empleados que eventualmente tendrn acceso a las computadoras, datos e informacin, para asegurarse que sus intereses sean consistentes con los de la organizacin y que comprendan completamente la importancia de llevar a cabo procedimientos de seguridad.
33
UNIDAD VII: VII: MANTENIMIENTO

MANTENIMIENTO
Proceso de modificar un sistema o componente software despus de su entrega para corregir defectos, mejorar el rendimiento u otros atributos o adaptarlos a un entorno cambiante. En qu consiste? En mantener operativo el sistema que hemos implementado. Consideremos el mantenimiento en funcin de todas las actividades que se realizan una vez entregado el producto y aceptado por el cliente. Correccin de defectos en el software. Creacin de nuevas funcionalidades por nuevos requisitos de usuario. Mejora de la funcionalidad y del rendimiento. Tipos de Mantenimiento Mantenimiento Perfectivo Modificaciones para mejorar mi sistema. Actividades para mejorar funcionalidades requeridas por el usuario y/o el analista. Ejemplos: mejorar listados o grficos; a una estadstica de ventas, agregarle un grfico, ya sea por iniciativa nuestra o por el usuario. Suele estar vinculado a las versiones del sistema. Mantenimiento Adaptativo Actividades que se realizan para adaptar el sistema a los cambios en su entorno. No se realizan mantenimientos por cambios de datos como porcentajes aplicados, ya que stos son considerados como pautas. Ejemplos: bono federal legislacin; cambios en las leyes, por ejemplo en la forma de calcular las asignaciones familiares. Los cambios pueden ocurrir en: Entorno de datos: Ejemplo: pasar de un sistema de archivos a uno relacional (base de datos). Entorno de proceso: nueva plataforma de explotacin o nuevo sistema operativo. Mantenimiento Correctivo Actividades dedicadas a corregir defectos en el hardware o en el software detectados por el usuario durante la explotacin del sistema. Corregir lo que est fallando. Ejemplo: clculo que se est haciendo mal. Procesamiento: Ejemplo: salidas incorrectas. Rendimiento: Ejemplo: tiempos de respuesta debajo de lo estimado. Implementacin: Ejemplo: inconsistencia en el diseo. Mantenimiento Preventivo Actividades para facilitar el mantenimiento futuro del sistema. Realizar modificaciones para prevenir posibles errores o mal funcionamiento del sistema. Ejemplos: incluir validacin de los datos de entrada. Depuracin de la base de datos. Una modificacin sobre la base de datos para que la bsqueda sea ms rpida. Ejemplo general: El problema del ao 2000, qu tipo de mantenimiento sera? Preventivo Correctivo Depende de cuando se lo haga. Adaptativo Mantenimiento de la Documentacin A medida que se va modificando un sistema de programacin, la documentacin asociada tambin se debe modificar para que refleje los cambios en el sistema. Si el cambio es transparente a los usuarios, slo es necesario modificar aquellos documentos que describen la aplicacin del sistema.
34
UNIDAD VIII: VIII: OTRAS METODOLOGAS

ORIENTACIN A OBJETOS
Sirve para solucionar las falencias del diseo estructurado y para hacer una aproximacin a la realidad. En el mundo real no se ven funciones, se ven objetos. Objeto: Un objeto es la instancia de una clase. Es cualquier cosa distinguible o identificable, con determinados atributos y determinado comportamiento. Abstraccin: Examen selectivo de ciertos aspectos del problema, eliminando los aspectos que no son importantes. La abstraccin debe servir para un propsito que nos determina lo que no es importante, delimitando nuestro universo. Es posible obtener mltiples abstracciones de la misma cosa. Un buen modelo captura los aspectos cruciales del problema y omite el resto. Herencia: Es la capacidad de una clase para definir el comportamiento y las estructuras de datos de sus ejemplos como un sper conjunto de la definicin de otra clase o clases. Permite concebir una nueva clase de objetos como un refinamiento de otra, para abstraer las similitudes entre las clases, y para disear y especificar nicamente las diferencias para la clase nueva. nicamente las diferencias para la clase nueva. Las clases pueden heredar comportamiento. Polimorfismo: Es la capacidad de dos o ms clases de objetos para responder al mismo mensaje, cada una de su manera propia. Esto significa que un objeto no necesita saber a quin enva un mensaje. Slo necesita saber que muchos tipos diferentes de objetos se han definido para responder a ese mensaje en particular. Por ejemplo, la accin abrir realizar operaciones diferentes en el caso que sea enviado este mensaje a un objeto ventana, puerta, peridico, un regalo, etc. Cada clase sabe como realizar tal operacin. Encapsulamiento: La esencia del encapsulamiento es que cuando un objeto trae consigo una funcionalidad, esta ltima se oculta. Esto permite reducir el potencial de errores que pudieran ocurrir. Pblicamente se conoce de un objeto sus capacidades: Yo puedo hacer estas cosas, y sus salidas: Yo puedo decir estas cosas. Pero no se conoce cmo sabe o cmo lo hace. El objeto que requiere informacin, especifica el trabajo o pide la informacin y lo deja. Luego de decidir qu funcionalidad e informacin utilizarn los otros objetos se oculta el resto. Se disea una interface pblica (la parte de afuera de la cpsula) que permite a otros objetos acceder a lo que ellos requieren. La representacin privada (lo de adentro de la cpsula) se protege del acceso de otros objetos. Asociaciones: Cuando las clases se conectan entre s de forma conceptual, esta conexin se conoce como asociacin. Por ejemplo: la asociacin entre un jugador y un equipo. Podr caracterizar tal asociacin con la frase: un jugador participa en un equipo. La asociacin puede funcionar en direccin inversa: un equipo emplea a jugadores.
Las asociaciones pueden ser ms complejas que tan slo una clase asociada a otra. Varias clases se pueden conectar a una.
35
RESTRICCIONES: Puede establecerse una restriccin en las asociaciones. En el ejemplo siguiente: la asociacin atiende est restringida para que el cajero atienda al cliente en turno.
CLASES DE ASOCIACIN: Una asociacin, al igual que una clase, puede contener atributos y operaciones. De hecho cuando ste sea el caso, tendremos una clase de asociacin. Una clase de asociacin modela los atributos y operaciones de una asociacin. Se conecta a una asociacin mediante una lnea discontinua, y puede asociarse a otra clase. Un vnculo es la instancia de asociacin. Conecta a los objetos en lugar de las clases.
MULTIPLICIDAD: La multiplicidad seala la cantidad de objetos de una clase asociada. Cuando la multiplicidad de una asociacin es de uno a muchos, con frecuencia se presenta un reto muy particular: la bsqueda. Cuando un objeto de una clase tiene que seleccionar un objeto particular de otro tipo para cumplir con un papel en la asociacin, la primera clase deber atenerse a un atributo en particular para localizar al objeto adecuado. En ocasiones, una clase es una asociacin consigo misma (asociacin reflexiva). Esto puede ocurrir cuando una clase tiene objetos que pueden jugar diversos papeles. Por ejemplo: un ocupante de automvil puede ser un conductor o un pasajero. Agregacin: En ocasiones una clase consta de otras clases. ste es un tipo especial de relacin conocida como agregacin. Puede establecerse una restriccin a una agregacin para mostrar que un componente u otro es parte del todo.
Composicin: Una composicin es un tipo muy representativo de una agregacin. Cada componente dentro de una composicin puede pertenecer tan slo a un todo. Los componentes de una mesa de caf (la superficie de la mesa y las patas) establecen una composicin.
36
Clases: Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto es una instancia de una clase). A travs de ella podemos modelar el entorno en estudio. Los objetos que comparten el mismo comportamiento se dice que pertenecen a la misma clase. Una clase es una especificacin genrica para un nmero arbitrario de objetos similares. Un rectngulo es el smbolo que representa una clase. El nombre de la clase es, por convencin, una palabra con la primera letra en mayscula y normalmente se coloca en la parte superior del rectngulo. Si el nombre de la clase consta de dos palabras entonces, debemos unirlas e iniciar cada una con maysculas. Grficamente:
ATRIBUTO: Un atributo es una propiedad o caracterstica de una clase y describe un rango de valores que la propiedad podr contener en los objetos de la clase. Describen de alguna manera la clase o el objeto. Estn asociados a clases y objetos; puede tomar un valor definido por un dominio enumerado. Una clase podr contener varios o ningn atributo. Por convencin, si el atributo consta de una sola palabra se escribe en minsculas; por otro lado, si el nombre contiene ms de una palabra, cada palabra ser unida a la anterior y comenzar con una letra mayscula, a excepcin de la primera palabra que comenzar en minscula. Grficamente:
El UML da la opcin de indicar informacin adicional de los atributos. En el smbolo de la clase, se podr especificar un tipo para cada valor del atributo, as como tambin un valor predeterminado. Por ejemplo: marca: string = Philips capacidad: integer OPERACIONES: En UML no se hace referencia a mtodos sino a operaciones. Una operacin es algo que la clase puede realizar u otra clase puede hacer a una clase. De la misma manera que el nombre de un atributo, el nombre de una operacin se escribe en minsculas si consta de una sola palabra. Grficamente:
As como es posible establecer informacin adicional de los atributos, tambin lo es en lo concerniente a las operaciones. En los parntesis que preceden al nombre de la operacin se podr mostrar el parmetro con el que funcionar la operacin junto con su tipo de dato. RESPONSABILIDADES Y RESTRICCIONES: La responsabilidad es una descripcin de lo que har la clase, es decir, lo que sus atributos y operaciones intentan realizar en conjunto. Una lavadora, por ejemplo, tiene la responsabilidad de recibir ropa sucia y dar por resultado ropa limpia. En el smbolo, indicar las
37
responsabilidades en un rea inferior a la que contiene las operaciones. Una manera ms formal es agregar una restriccin, un texto libre bordeado por llaves. Por ejemplo, supongamos que en la clase Lavadora deseamos establecer la capacidad de una lavadora ser de 7, 8 o 9 (y as restringir el atributo capacidad de la clase Lavadora)
MENSAJE: Un objeto accede a otro objeto envindole un mensaje. Un mensaje consiste del nombre de una operacin y cualquier argumento requeridos. El conjunto de mensajes al que un objeto puede responder es conocido como el comportamiento del objeto. Un objeto puede enviar mensajes privados a s mismo para implementar operaciones pblicamente accesibles. INSTANCIA: Los objetos que se comportan en una manera especificada por una clase se llaman las instancias de esa clase. Todos los objetos son las instancias de alguna clase. Una vez que una instancia de una clase se crea, se comporta como todas las otras instancias de su clase, y es capaz de recibir un mensaje para desempear cualquier operacin para la que tiene mtodos. SUBCLASE: Es una clase que hereda el comportamiento desde otra clase. Una subclase comnmente agrega su comportamiento propio para definir su tipo nico de objeto. SUPERCLASE: Una superclase es una clase cuyo comportamiento especfico se hereda. Una clase podra tener una nica superclase, o podra tener varias combinando comportamiento desde varias fuentes y agregar solo un poco de s misma para producir su nico tipo de objeto. CLASE ABSTRACTA: No son destinadas para producir instancias de s mismas. Existen para que el comportamiento comn a una variedad de clases pueda factorizarse en una ubicacin comn, donde puede definirse una vez y reutilizarlo nuevamente y nuevamente. Especifican totalmente su comportamiento, pero no necesitan implementarse completamente.
38
UML
Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Se usa para entender, disear, configurar, mantener y controlar la informacin sobre los sistemas a construir. El Lenguaje Unificado de Modelado determina un conjunto de notaciones y diagramas estndar para modelar sistemas orientados a objetos, y describe la semntica esencial de lo que estos diagramas y smbolos significan. Mientras que ha habido muchas notaciones y mtodos usados para el diseo orientado a objetos, ahora los modeladores slo tienen que aprender una nica notacin. Concepto: Es una serie de diagramas que permiten representar una visin de mi sistema (una parte de mi sistema). Permite reflejar un determinado modelo de objetos. No es una metodologa, es un estndar. Es una serie de diagramas que permiten documentar todo.
IMPORTANTE UML no es una metodologa, es un estndar.

Diagramas UML Diagrama de Clases Est formado por varios rectngulos conectados por lneas que muestran la manera en que las clases se relacionan entre s. Un rectngulo es el smbolo que representa a la clase, y se divide en tres reas: El rea superior contiene el nombre; El rea central contiene los atributos; El rea inferior contiene las acciones u operaciones. El diagrama de clases se utiliza para modelar la estructura esttica de las clases del sistema.
Diagrama de Casos de Uso Se utiliza para especificar requerimientos. Describe la forma en que un sistema lucir para los usuarios potenciales. Son todas las funciones que va a realizar el sistema. Es una coleccin de escenarios iniciados por una entidad llamada actor (persona, componente, sistema). Un caso de uso en una interaccin tpica entre el usuario y el sistema, con el fin de lograr cierto objetivo. Un caso de uso es una descripcin de las acciones de un sistema desde el punto de vista del usuario. Para los desarrolladores de sistema sta es una herramienta valiosa, ya que es una tcnica de aciertos y errores para obtener los requerimientos del sistema desde el punto de vista del usuario. Se utiliza para modelar los procesos que realiza el sistema.
39
IMPORTANTE: Para que un caso de uso me sirva, tiene que ser simple, claro y conciso. Debo definir pocos actores para cada caso de uso. Identificar preguntas claves. Ver como interacta el actor con el sistema. DIAGRAMAS DE INTERACCIN Los diagramas de interaccin son modelos que describen la manera en que colaboran grupos de objetos para cierto comportamiento. Habitualmente, un diagrama de interaccin capta el comportamiento de un solo caso de uso. El diagrama muestra cierto nmero de ejemplos de objetos y los mensajes que se pasan entre estos objetos dentro del caso de uso. Hay dos tipos de diagramas de interaccin: diagramas de secuencia y diagramas de colaboracin. Diagramas de Secuencia Los diagramas de secuencia muestran el intercambio de mensajes (es decir la forma en que se invocan) en un momento dado. Los diagramas de secuencia ponen especial nfasis en el orden y el momento en que se envan los mensajes a los objetos. Tiene dos dimensiones. La horizontal es la disposicin de los objetos, y la dimensin vertical muestra el paso del tiempo. El diagrama de secuencia se utiliza para modelar el paso de mensajes entre objetos. Un mensaje simple es la transferencia de control de un objeto a otro. Sincrnico, esperar la respuesta a tal mensaje antes de continuar. Asincrnico, no esperar respuesta para continuar.
Diagramas de Colaboracin Los diagramas de colaboracin muestran las interacciones que ocurren entre los objetos que participan en una situacin determinada. Esta es ms o menos la misma informacin que la mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el tiempo, mientras que los diagramas de colaboracin fijan el inters en las relaciones entre los objetos y su topologa. Adems de las relaciones entre objetos, el diagrama de colaboraciones muestra los mensajes que se envan los objetos entre s. Por lo general, evitar la multiplicidad dado que podra ser fuente de confusin. Para representar un mensaje, se dibuja una flecha cerca de la lnea de asociacin entre dos objetos; esta flecha apunta al objeto receptor. El tipo de mensaje se mostrar en una etiqueta cerca de la flecha; por lo general, el mensaje le indicar al objeto receptor que ejecute una de sus operaciones, el mensaje finalizar con un par de parntesis, dentro de los cuales colocar los parmetros (en caso de haber alguno) con los que funcionar la operacin.
40
Se puede convertir cualquier diagrama de secuencias en diagrama de colaboracin y viceversa.
Cundo utilizar diagramas de interaccin? Se deben usar los diagramas de interaccin cuando se desee ver el comportamiento de varios objetos en un caso de uso. Son buenos para mostrar la colaboracin entre los objetos; sin embargo, no sirven bien para la definicin precisa del comportamiento. Si se desea ver el comportamiento de un solo objeto a travs de muchos casos de uso, se debe usar un diagrama de estado de transicin; si se quiere ver el comportamiento a travs de muchos casos de uso o muchos procesos, se debe considerar un diagrama de actividad. Diagramas de paquete Un diagrama de paquetes muestra como un sistema est dividido en agrupaciones lgicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un paquete est pensado como un directorio, los diagramas de paquetes suministran una descomposicin de la jerarqua lgica de un sistema. Los Paquetes estn normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas lneas maestras sobre la mesa, los paquetes son buenos elementos de gestin. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido.
41
Cundo utilizar diagramas de paquetes? Los paquetes son una herramienta vital para los proyectos grandes. Debe usarse siempre que un diagrama de clases que abarque todo el sistema ya no sea legible en una hoja de papel tamao carta (o A4). Los paquetes son especialmente tiles para pruebas. Se pueden realizar pruebas unitarias en el nivel de paquete por paquete. Cada paquete deber tener una o ms clases de pruebas que verifiquen su comportamiento. Diagramas de estado Los diagramas de estados son una tcnica conocida para describir el comportamiento de un sistema. Describen todos los estados posibles en los que puede entrar un objeto particular y la manera en que cambia el estado del objeto, como resultado de los eventos que llegan a l. En la mayor parte de las tcnicas OO, los diagramas de estados se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo su ciclo de vida. Los diagramas de estado muestran los diferentes estados de un objeto durante su vida, y los estmulos que provocan los cambios de estado en un objeto. Los diagramas de estado ven a los objetos como mquinas de estado o autmatas finitos que pueden estar en un conjunto de estados finitos y que pueden cambiar su estado a travs de un estmulo perteneciente a un conjunto finito.
Cundo utilizar diagramas de estados? Los diagramas de estados son buenos para describir el comportamiento de un objeto a travs de varios casos de uso. No son tan buenos para describir un comportamiento que involucra cierto nmero de objetos que colaboran entre ellos. Es til combinar los diagramas de estados con otras tcnicas. Diagramas de actividades Los diagramas de actividad describen la secuencia de las actividades en un sistema. Los diagramas de actividad son una forma especial de los diagramas de estado, que nicamente (o mayormente) contienen actividades. Los diagramas de actividad son similares a los diagramas de flujo procesales, con la diferencia de que todas las actividades estn claramente unidas a objetos. Los diagramas de actividad siempre estn asociados a una clase, a una operacin o a un caso de uso. Soportan actividades tanto secuenciales como paralelas. La ejecucin paralela se representa por medio de iconos de fork/espera, y en el caso de las actividades paralelas, no importa en qu orden sean invocadas (pueden ser ejecutadas simultneamente o una detrs de otra).
42
Cundo utilizar diagramas de actividades? La gran virtud de los diagramas de actividades reside en que manejan y promueven el comportamiento en paralelo. Esta cualidad hace de ellos una excelente herramienta para el modelado de flujo de trabajo y, en principio, para la programacin multihilos. Su gran desventaja es que no dejan muy claros los vnculos entre acciones y objetos. Pueden ser muy tiles en los siguientes casos: En el anlisis de un caso de uso. En la comprensin del flujo de trabajo, a travs de numerosos casos de uso. Cuando se trata de aplicaciones multihilo. En cambio, en general no deberan usarse: Para tratar de ver cmo colaboran los objetos. Para tratar de ver cmo se comporta un objeto durante su perodo de vida. Diagramas de emplazamiento El diagrama de emplazamiento (deployment diagram) es aquel que muestra las relaciones fsicas entre los componentes de software y de hardware en el sistema entregado. As, el diagrama de emplazamiento es un buen sitio para mostrar cmo se enrutan y se mueven los componentes y los objetos, dentro de un sistema distribuido. Cada nodo de un diagrama de emplazamiento representa alguna clase de unidad de cmputo; en la mayora de los casos se trata de una pieza de hardware. El hardware puede ser un dispositivo o un sensor simple, o puede tratarse de un mainframe. Los componentes en un diagrama de emplazamiento representan mdulos fsicos de cdigo. Las dependencias entre los componentes deben ser las mismas que las dependencias de paquetes. Estas dependencias muestran cmo se comunican los componentes con otros componentes. La direccin de una dependencia dada indica el conocimiento en la comunicacin.
43
Cundo utilizar diagramas de emplazamiento? En la prctica, no se ha usado mucho este tipo de diagramas hasta el momento. Cada sistema tiene sus propias caractersticas fsicas que se querrn subrayar.
44
RUP [Proceso Unificado de Racional]

El Proceso Unificado de Rational (Rational Unified Process, habitualmente resumido como RUP) es un proceso de desarrollo de software y, junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Tambin se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye informacin entrelazada de diversos artefactos y descripciones de las diversas actividades. Est incluido en el Rational Method Composer (RMC), que permite la personalizacin de acuerdo a necesidades. Originalmente se dise un proceso genrico y de dominio pblico, el Proceso Unificado, y una especificacin ms detallada, el Rational Unified Process, que se vendiera como producto independiente. La metodologa RUP es ms apropiada para proyectos grandes (aunque tambin pequeos), dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeos, es posible que no se puedan cubrir los costos de dedicacin del equipo de profesionales necesarios. Principios de desarrollo El RUP est basado en 5 principios clave que son: Adaptar el proceso: el proceso deber adaptarse a las caractersticas propias del proyecto u organizacin. El tamao del mismo, as como su tipo o las regulaciones que lo condicionen, influirn en su diseo especfico. Tambin se deber tener en cuenta el alcance del proyecto. Balancear prioridades: los requerimientos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos. Debido a este balanceo se podrn corregir desacuerdos que surjan en el futuro. Demostrar valor interactivamente: los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteracin se analiza la opinin de los inversores, la estabilidad y calidad del producto, y se refina la direccin del proyecto as como tambin los riesgos involucrados. Elevar el nivel de abstraccin: este principio dominante motiva el uso de conceptos reutilizables tales como patrn del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificacin de software a la medida del cliente, sin saber con certeza qu codificar para satisfacer de la mejor manera los requerimientos y sin comenzar desde un principio pensando en la reutilizacin del cdigo. Un alto nivel de abstraccin tambin permite discusiones sobre diversos niveles y soluciones arquitectnicas. Enfocarse en la calidad: el control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de la produccin. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente. Principales caractersticas (Nota: Leer Caract. esenciales en la pgina siguiente, es ms importante) Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo). Pretende implementar las mejores prcticas en Ingeniera de Software. Desarrollo iterativo. Administracin de requisitos. Uso de arquitectura basada en componentes. Control de cambios. Modelado visual del software. Verificacin de la calidad del software.
45
Caractersticas esenciales de RUP (IMPORTANTE) Proceso dirigido por los casos de uso. Proceso iterativo e incremental. Proceso centrado en la arquitectura. El RUP se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el cdigo fuente, etc.) y roles (papel que desempea una persona en un determinado momento). Proceso dirigido por los casos de uso
Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se debe conocer qu es lo que quieren y necesitan los usuarios prospectos. El trmino usuario representa algo o alguien que interacta con el sistema por desarrollar.
46
Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso, el cual describe la funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificacin funcional del sistema. Una especificacin funcional tradicional se concentra en responder la pregunta: Qu se supone que el sistema debe hacer? La estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: por cada usuario? Estas tres palabras tienen una implicacin importante, nos fuerzan a pensar en trminos del valor a los usuarios y no solamente en trminos de las funciones que sera bueno que tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, tambin dirigen su diseo, implementacin y pruebas, esto es, dirigen el proceso de desarrollo. An y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la eleccin de los casos de uso. Por lo tanto, la arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida. Proceso iterativo e incremental. El ciclo de vida iterativo se basa en la evolucin de prototipos ejecutables que se muestran a los usuarios y clientes. En el ciclo de vida iterativo a cada iteracin se reproduce el ciclo de vida en cascada a menor escala. Los objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedentes. Las actividades se encadenan en una minicascada con un alcance limitado por los objetivos de la iteracin. Cada iteracin comprende: Planificar la iteracin (estudio de riesgos). Anlisis de los Casos de Uso y escenarios. Diseo de opciones arquitectnicas. Codificacin y pruebas. La integracin del nuevo cdigo con el existente de iteraciones anteriores se hace gradualmente durante la construccin. Evaluacin de la entrega ejecutable. Preparacin de la entrega (documentacin e instalacin del prototipo)
Proceso centrado en la arquitectura. Arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes. Una arquitectura ejecutable es una implementacin parcial del sistema, construida para demostrar algunas funciones y propiedades.
47
RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo.
CICLO DE VIDA
FIGURA: Esfuerzo en actividades segn fase del proyecto.
El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en los distintas actividades. Fases del Ciclo de Vida El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versin del producto.
48
Cada ciclo est compuesto por fases y cada una de estas fases est compuesta por un nmero de iteraciones. Las fases son: Inicio o Estudio de oportunidad (tambin llamado Concepcin). Elaboracin Construccin Transicin En cada fase participan todas las disciplinas, pero dependiendo de la fase el esfuerzo dedicado a una disciplina vara.
Inicio o Estudio de oportunidad (concepcin) Define el mbito y objetivos del proyecto. Se define la funcionalidad y capacidades del Producto. Durante la fase de inicio las iteraciones hacen mayor nfasis en actividades de modelado del negocio y de requerimientos. Es como un relevamiento (ms acotado). Bsicamente, durante la etapa de Concepcin, se definir la situacin econmica del proyecto: cunto costar aproximadamente y cunto redituar. Tambin se necesitar tener una idea del alcance del proyecto. Tal vez haga falta cierto trabajo de anlisis inicial para tener una idea de la magnitud del proyecto. Qu artefactos se utilizan en la concepcin? Documento Visin. Especificacin de Requerimientos. Elaboracin Tanto la funcionalidad como el dominio del problema se estudian en profundidad. Se define una arquitectura bsica. Se planifica el proyecto considerando recursos disponibles. En otras palabras, Qu es lo que se va a construir en realidad? Cmo se va a construir? Qu tecnologa va a usar?
49
Lo primero y ms importante que se debe considerar en esta etapa son los riesgos del proyecto. Los riesgos pueden clasificarse, desde un punto de vista prctico, en cuatro categoras: Riegos de requerimientos: cules con los requerimientos del sistema? El gran peligro es construir un sistema errneo, que no haga lo que quiere el cliente. No entender lo que requiere el usuario. Para el manejo de los riesgos de requerimientos, lo ms importante es detectar los casos de uso potenciales del sistema en construccin. Se deben encontrar la mayor cantidad posible, en especial los ms importantes. Es por esto que durante la etapa de elaboracin se deben programar entrevistas con los usuarios, con el fin de recopilar los casos de uso. Otra tarea importante es elaborar el esqueleto del modelo conceptual del dominio. Se debe avanzar con el modelo de diseo. El modelo de diseo agrega clases que se encargan de llevar a cabo el trabajo y que proporcionan adems una arquitectura reutilizable, que servir de ayuda para extensiones futuras. Para la construccin de modelos de dominio, resultan valiosas dos tcnicas UML: los diagramas de clases, que cuando se dibujan desde una perspectiva conceptual son excelentes para capturar el lenguaje del negocio, y los diagramas de actividades, que complementan los diagramas de clases describiendo los pasos que siguen los empleados parara llevar a cabo sus labores. Tambin pueden usarse los diagramas de interaccin. El modelado de dominio es dirigido por los casos de uso, a medida que se descubren. Otra buena tcnica para entender las partes intrincadas de los casos de uso, es la utilizacin de prototipos, que permite apreciar adecuadamente ciertas situaciones. Riesgos tecnolgicos: cules son los riesgos que habr de enfrentar? Por ejemplo, si va a usar objetos, tiene ya la suficiente experiencia en el trabajo de diseo orientado a objetos? Para abordar los riesgos tecnolgicos, lo ms importante es construir prototipos que prueben las partes tecnolgicas con las que uno piensa trabajar. Es importante probar las herramientas. Los riesgos tecnolgicos mayores son inherentes la manera en la que se integran (acoplan) los componentes de un diseo, en lugar de hallarse en los componentes mismos. Por ejemplo, se puede tener el mejor lenguaje de programacin, pero no se acopla bien con la Base de datos. Por eso es tan importante obtener todos los componentes con los que se pretende trabajar e integrarlos en esta etapa temprana del proceso. Adems, en esta etapa se debe ocupar de cualquier decisin de diseo arquitectnico, es decir, tener idea de lo que son los componentes y cmo se construirn, fundamentalmente en un sistema distribuido. Durante este proceso, se utilizan algunas tcnicas UML, como diagramas de paquetes, diagramas de clase y diagramas de emplazamiento. Riesgos de habilidades: Puede conseguir la asesora y los expertos que necesita? No encontrar la gente capacitada para llevar adelante el proyecto. Para manejar estos riesgos, se debe realizar la capacitacin del personal. Por ejemplo, para adquirir las habilidades de la OO lo mejor es hacerlo a travs del mtodo de tutora, mediante el cual un desarrollador experimentado colabora con el desarrollador en su proyecto durante un extenso perodo. Tambin se pueden complementar las habilidades mediante la lectura y la realizacin de cursos de entrenamiento formales. Riesgos polticos: Existen fuerzas polticas que se puedan interponer en su camino y afectar seriamente el proyecto? Polticas de la empresa. Qu es lo que debemos tener al finalizar la segunda etapa? Bsicamente, debemos tener una Base arquitectnica para el sistema y una planificacin. Base arquitectnica: es el cimiento del desarrollo y funciona como anteproyecto de las etapas posteriores. Se compone de: La lista de los casos de uso, que me dice cules son los requerimientos. El modelo del dominio, donde tengo las claves de mi sistema. La plataforma tecnolgica, que describe las partes clave de la tecnologa de implementacin y la manera como se acoplan. Planificacin: la esencia del plan es establecer una serie de iteraciones para la construccin y asignar los casos de uso a las iteraciones. El plan se termina cuando todos los casos de uso han sido asignados a una
50
iteracin y cuando se ha identificado la fecha de inicio de todas las iteraciones. El plan no entra en mayores detalles. El primer paso de la planificacin es clasificar los casos de uso por categora; los usuarios debern clasificar el nivel de prioridad de cada caso de uso. Luego, los desarrolladores debern considerar los dos nuevos riesgos que aparecen en esta etapa: Riesgo arquitectnico: est asociado a cada caso de uso, el cual consiste en que, si el caso de uso se deja de lado hasta muy avanzado el proyecto, el trabajo anterior se ver muy comprometido, lo que resultar en una gran cantidad de retrabajo. Se dan tres categoras de clasificacin: alto riego, riesgo posible pero no probable y poco riesgo. Riesgo del calendario: est relacionado con la seguridad que tengan los desarrolladores en la estimacin del esfuerzo requerido para cada caso de uso. Realizado lo anterior, habr que estimar el tiempo de duracin que tomar cada caso de uso, hasta la semana-persona ms prxima. Una vez efectuadas las estimaciones, se puede decidir si se est listo para hacer el plan. El siguiente paso es la determinacin de la longitud de la iteracin. Se busca una iteracin de longitud fija para todo el proyecto, de modo que se pueda lograr un ritmo regular de entrega de iteraciones. Cada iteracin debe ser lo suficientemente larga para realizar varios casos de uso. Ahora se puede considerar el esfuerzo para cada iteracin. El siguiente paso es la asignacin de los casos de uso a las iteraciones. Los casos de uso de alta prioridad, riego arquitectnico y/o riegos de calendarizacin deben tratarse antes que los dems. Para la transicin, se debe signar del 10% al 35% del tiempo de construccin a la afinacin y el empaquetado para entrega. Despus, hay que agregar un factor de contingencia: del 10% al 20% del tiempo de construccin, dependiendo de lo arriesgada que parezca ser la situacin; este factor se debe agregar al final de la etapa de transicin. Si se realizaron estos pasos, se debera contar con un plan que muestre los casos de uso que se realizarn durante cada iteracin. Este plan simboliza el compromiso entre los desarrolladores y los usuarios; un buen nombre para este plan es el de calendario de compromisos. Este itinerario no es inflexible, pero es importante que los cambios se realicen en conjunto (entre desarrolladores y usuarios).
NOTA
Los casos de uso son el fundamento de la planificacin del proyecto, razn por la cual UML pone tanto nfasis en ellos.
Qu artefactos se utilizan en la elaboracin? Diagramas de caso de uso. Construccin El producto se desarrolla a travs de iteraciones, donde cada iteracin involucra tareas de anlisis, diseo e implementacin. Las fases de estudio y anlisis slo dieron una arquitectura bsica que es aqu refinada de manera incremental conforme se construye (se permiten cambios en la estructura). Gran parte del trabajo es programacin y pruebas. Se documenta tanto el sistema construido como el manejo del mismo. Esta fase proporciona un producto construido junto con la documentacin. En la fase de construccin, se lleva a cabo la construccin del producto por medio de una serie de iteraciones. Cada iteracin es un miniproyecto. Para cada iteracin se seleccionan algunos casos de uso, se refina su anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementacin de la nueva versin del producto. El propsito de este proceso es reducir el riesgo. Los riesgos surgen con frecuencia debido a que las cuestiones difciles se posponen para el final del proyecto. Las iteraciones dentro de la construccin son tanto incrementales como iterativas.
51
Funcionalmente, las iteraciones son incrementales. Cada iteracin se construye sobre los casos de uso desarrollados en las iteraciones anteriores. Son iterativas en trminos del cdigo base. Cada iteracin implica la reescritura de algn cdigo ya existente con el fin de hacerlo ms flexible. La reestructuracin de factores es una tcnica muy til para la iteracin del cdigo. Cuando se reestructuran los factores, no cambia la funcionalidad del programa; lo que se hace es cambiar su estructura interna, a fin de simplificar su lectura y su modificacin. Qu artefactos se utilizan en la construccin? Documento Arquitectura que trabaja con las siguientes vistas: Vista Lgica: Diagrama de clases. Modelo E-R (si el sistema as lo requiere). Vista de Implementacin: Diagrama de secuencia. Diagrama de estados. Diagrama de colaboracin. Vista Conceptual: Modelo de dominio. Vista fsica: Mapa de comportamiento a nivel de hardware. Transicin Se libera el producto y se entrega al usuario para un uso real. Se incluyen tareas de marketing, empaquetado atractivo, instalacin, configuracin, entrenamiento, soporte, mantenimiento, etc. Los manuales de usuario se completan y refinan con la informacin anterior. Estas tareas se realizan tambin en iteraciones. En la fase de transicin se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.
52
METODOLOGAS GILES
[Bibliografa: Metodologas giles en el Desarrollo de Software, Jos H. Cans, Patricio Letelier y M. Carmen Penads]
INTRODUCCIN Hasta hace poco, el proceso de desarrollo de software llevaba asociado un marcado nfasis en el control del proceso mediante una rigurosa definicin de roles, actividades y artefactos, incluyendo modelado y documentacin detallada. Este esquema tradicional para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamao (respecto a tiempo y recursos), donde por lo general se exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el ms adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. En este escenario, las metodologas giles emergen como una posible respuesta para llenar ese vaco metodolgico. Por estar especialmente orientadas para proyectos pequeos, las metodologas giles constituyen una solucin a medida para este entorno, aportando una elevada simplificacin que a pesar de ello no renuncia a las prcticas esenciales para asegurar la calidad del producto. Se entiende como Desarrollo gil de software a un paradigma de Desarrollo de Software basado en procesos giles. Los procesos giles de desarrollo de software, conocidos anteriormente como metodologas livianas, intentan evitar los tortuosos y burocrticos caminos de las metodologas tradicionales enfocndose en la gente y los resultados. Es un marco de trabajo conceptual de la ingeniera de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos mtodos de desarrollo gil; la mayora minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteracin, la cual debe durar de una a cuatro semanas. Cada iteracin del ciclo de vida incluye: planificacin, anlisis de requerimientos, diseo, codificacin, revisin y documentacin. Una iteracin no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener un demo (sin errores) al final de cada iteracin. Al final de cada iteracin el equipo vuelve a evaluar las prioridades del proyecto. Los mtodos giles enfatizan las comunicaciones cara a cara en vez de la documentacin. La mayora de los equipos giles estn localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en ingls). La oficina debe incluir revisores, diseadores de iteracin, escritores de documentacin y ayuda y directores de proyecto. Los mtodos giles tambin enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los mtodos giles son criticados y tratados como "indisciplinados" por la falta de documentacin tcnica. METODOLOGAS GILES En febrero de 2001, tras una reunin celebrada en Utah EE.UU., nace el trmino gil aplicado al desarrollo de software. En esta reunin participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologas de software. Su objetivo fue esbozar los valores y principios que deberan permitir a los equipos desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las actividades desarrolladas. Tras esta reunin se cre el The Agile Alliance, una organizacin, sin nimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo gil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida es el Manifiesto gil, un documento que resume la filosofa gil. El Manifiesto gil Segn el Manifiesto se valora: Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de xito de un proyecto de software. Es ms importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo
53
de adapte automticamente. Es mejor crear el equipo y que ste configure su propio entorno de desarrollo en base a sus necesidades. Desarrollar software que funciona ms que conseguir una buena documentacin. La regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar una decisin importante. Estos documentos deben ser cortos y centrarse en lo fundamental. La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su xito. Responder a los cambios ms que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a lo largo del proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible y abierta. Los valores anteriores inspiran los doce principios del manifiesto. Son caractersticas que diferencian un proceso gil de uno tradicional. Los dos primeros principios son generales y resumen gran parte del espritu gil. El resto tiene que ver con el proceso a seguir y con el equipo de desarrollo, en cuanto metas a seguir y organizacin del mismo. Los principios son: I. II. III. IV. V. VI. VII. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo. El software que funciona es la medida principal de progreso.
VIII. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante. IX. X. XI. XII. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. La simplicidad es esencial. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento.
PROGRAMACIN EXTREMA (EXTREME PROGRAMMING, XP)

XP es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico.
54
Metodologas giles
Basadas en heursticas provenientes de prcticas de produccin de cdigo. Especialmente preparados para cambios durante el proyecto. Impuestas internamente (por el equipo). Proceso menos controlado, con pocos principios. No existe contrato tradicional o al menos en bastante flexible. El cliente es parte del equipo de desarrollo. Grupos pequeos (< 10 integrantes) y trabajando en el mismo sitio. Pocos artefactos. Pocos roles. Menos nfasis en la arquitectura del software.
Metodologas Tradicionales
Basadas en normas provenientes de estndares seguidos por el entorno de desarrollo. Cierta resistencia a los cambios. Impuestas externamente. Proceso mucho ms controlado, con numerosas polticas/normas. Existe un contrato prefijado. El cliente interacta con el equipo de desarrollo mediante reuniones. Grupos grandes y posiblemente distribuidos. Ms artefactos. Ms roles. La arquitectura del software es esencial y se expresa mediante modelos.
Los principios y prcticas son de sentido comn pero llevadas al extremo, de ah proviene su nombre. El padre de la filosofa XP es Kent Beck. A continuacin se muestran las caractersticas esenciales de XP organizadas en los cuatro apartados siguientes: historias de usuario, roles, proceso y prcticas. Las historias de Usuario Son la tcnica utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las caractersticas que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinmico y flexible. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas. Beck presenta un ejemplo de ficha (customer store and task card) en la cual pueden reconocerse los siguientes contenidos: fecha, tipo de actividad (nueva, correccin, mejora), prueba funcional, nmero de historia, prioridad tcnica y del cliente, referencia a otra historia previa, riesgo, estimacin tcnica, descripcin, notas y una lista de seguimiento con la fecha, estado cosas por terminar y comentarios. A efectos de planificacin, las historias pueden ser de una a tres semanas de tiempo de programacin (para no superar el tamao de una iteracin). Las historias de usuario son descompuestas en tareas de programacin (task card) y asignadas a los programadores para ser implementadas. Roles XP Los roles de acuerdo con la propuesta original de Beck son: Programador. El programador escribe las pruebas unitarias y produce el cdigo del sistema. Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar mayor valor al negocio. Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. Encargado de seguimiento (Tracker). Proporciona realimentacin al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteracin. Entrenador (Coach). Es responsable del proceso global. Debe proveer guas al equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente.
55
Consultor. Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto, en el que puedan surgir problemas. Gestor (Big boss). Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin. Proceso XP El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos: 1. El cliente define el valor de negocio a implementar. 2. El programador estima el esfuerzo necesario para su implementacin. 3. El cliente selecciona qu construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4. El programador construye ese valor de negocio. 5. Vuelve al paso 1. En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar ms trabajo que el estimado, ya que se perder calidad en el software o no se cumplirn los plazos. De la misma forma el cliente tiene la obligacin de manejar el mbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteracin. El ciclo de vida ideal de XP consiste de seis fases: Exploracin, Planificacin de la Entrega (Release), Iteraciones, Produccin, Mantenimiento y Muerte del Proyecto. Prcticas XP La principal suposicin que se realiza en XP es la posibilidad de disminuir la mtica curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseo evolutivo funcione. Esto se consigue gracias a las tecnologas disponibles para ayudar en el desarrollo y la aplicacin disciplinada de las siguientes prcticas: El juego de la planificacin. Hay una comunicacin frecuente entre el cliente y los programadores. El equipo tcnico realiza una estimacin del esfuerzo requerido para la implementacin de las historias de usuario y los clientes deciden sobre el mbito y tiempo de las entregas y de cada iteracin. Entregas pequeas. Producir rpidamente versiones del sistema que sean operativas, aunque no cuenten con toda la funcionalidad del sistema. Esta versin ya constituye un resultado de valor para el negocio. Metfora. El sistema es definido mediante una metfora o un conjunto de metforas compartidas por el cliente y el equipo de desarrollo. Una metfora es una historia compartida que describe cmo debera funcionar el sistema (conjunto de nombres que acten como vocabulario para hablar sobre el dominio del problema, ayudando a la nomenclatura de clases y mtodos del sistema). Diseo simple. Se debe disear la solucin ms simple que pueda funcionar y ser implementada en un momento determinado del proyecto. Pruebas. La produccin de cdigo est dirigida por las pruebas unitarias. stas son establecidas por el cliente antes de escribirse el cdigo y son ejecutadas constantemente ante cada modificacin del sistema. Refactorizacin (Refactoring). Es una actividad constante de reestructuracin del cdigo con el objetivo de remover duplicacin de cdigo, mejorar su legibilidad, simplificarlo y hacerlo lo ms flexible para facilitar los posteriores cambios. Se mejora la estructura interna del cdigo sin alterar su comportamiento externo. Programacin en parejas. Toda la produccin de cdigo debe realizarse con trabajo en parejas de programadores. Esto conlleva ventajas implcitas (menor tasa de errores, mejor diseo, mayor satisfaccin de los programadores,). Propiedad colectiva del cdigo. Cualquier programador puede cambiar cualquier parte del cdigo en cualquier momento. Integracin continua. Cada pieza de cdigo es integrada en el sistema una vez que est lista. As, el sistema puede llegar a ser integrado y construido varias veces en un mismo da. 40 horas por semana. Se debe trabajar un mximo de 40 horas por semana. No se trabajan horas extras en dos semanas seguidas. Si esto ocurre, probablemente est ocurriendo un problema que debe corregirse. El trabajo extra desmotiva al equipo.
56
Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Este es uno de los principales factores de xito del proyecto XP. El cliente conduce constantemente el trabajo hacia lo que aportar mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. La comunicacin oral es ms efectiva que la escrita. Estndares de programacin. XP enfatiza que la comunicacin de los programadores es a travs del cdigo, con lo cual es indispensable que se sigan ciertos estndares de programacin para mantener el cdigo legible.
SCRUM
Es un proceso de desarrollo de software iterativo e incremental utilizado comnmente en entornos basado en la Metodologa gil de desarrollo de software. Ha sido desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para la gestin de proyectos, que se ha utilizado con xito durante los ltimos 10 aos. Est especialmente indicada para proyectos con un rpido cambio de requisitos. Aunque Scrum estaba enfocado a la gestin de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximacin de gestin de programas: Scrum de Scrums. Caractersticas de Scrum Scrum es un modelo de referencia que define un conjunto de prcticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutar durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (clientes externos o internos), y el Team que incluye a los desarrolladores. Sus principales caractersticas se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duracin de entre 15 y 30 das (la magnitud es definida por el equipo). El resultado de cada sprint es un incremento ejecutable (incremento de software potencialmente entregable o utilizable) que se muestra al cliente. El conjunto de caractersticas que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunin de Sprint Planning. Durante esta reunin, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos estn congelados durante el sprint. La segunda caracterstica importante son las reuniones a lo largo del proyecto, entre las que se destaca la reunin diaria de 15 minutos del equipo de desarrollo para coordinacin e integracin Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fcil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar. Roles en Scrum En Scrum se definen varios roles, stos estn divididos en dos grupos: cerdos y gallinas. Los nombres de los grupos estn inspirados en el chiste sobre un cerdo y una gallina que se relata a continuacin. Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice: "Hey, por qu no abrimos un restaurante?" El cerdo mira a la gallina y le dice: "Buena idea, cmo se llamara el restaurante?" La gallina piensa un poco y contesta: "Por qu no lo llamamos "Huevos con jamn?" "Lo siento pero no", dice el cerdo, "Yo estara comprometido pero t solamente estaras involucrada". De esta forma, los cerdos estn comprometidos a construir software de manera regular y frecuente, mientras que el resto son gallinas: interesados en el proyecto pero realmente irrelevantes porque, si ste falla, no son un cerdo, es decir, no son los que se haban comprometido a sacarlo adelante. Las necesidades, deseos, ideas e influencias
57
de los roles gallina se tienen en cuenta, pero no de forma que pueda afectar, distorsionar o entorpecer el proyecto Scrum. Roles "Cerdo" Los Cerdos son los que estn comprometidos con el proyecto y el proceso Scrum; ellos son los que "ponen el jamn en el plato". Product Owner: El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog. ScrumMaster (o Facilitador): El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el lder del equipo (porque ellos se auto-organizan), sino que acta como una proteccin entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan. Equipo: El equipo tiene la responsabilidad de entregar el producto. Un pequeo equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseador, desarrollador, etc.). Roles "Gallina" Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse en cuenta. Un aspecto importante de una aproximacin gil es la prctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentacin con respecto a la salida del proceso a fin de revisar y planear de cada sprint. Usuarios: El software es construido para alguien! Si el software no es usado - como la paradoja del rbol que cae en el bosque cuando no hay nadie hace ruido? - fue alguna vez escrito?. Stakeholders (Clientes, Proveedores): Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producir el beneficio acordado que lo justifica. Slo participan directamente durante las revisiones del sprint. Managers: Es la gente que establece el ambiente para el desarrollo del producto. Reuniones en Scrum Cada da de un sprint, se realiza la reunin sobre el estado de un proyecto. Esto se llama un scrum o la "daily standup". El scrum tiene unas guas especficas: La reunin comienza puntualmente a su hora. A menudo hay castigos -decididos por el equipo- para quin llega tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plstico del cuello) Todos son bienvenidos, pero solo los "cerdos" pueden hablar La reunin tiene una duracin fija de 15 minutos, de forma independiente del tamao del equipo. Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunin corta) La reunin debe ocurrir en la misma ubicacin y a la misma hora todos los das. Durante la reunin, cada miembro del equipo contesta a tres preguntas: Qu has hecho desde ayer? Qu es lo que ests planeando hacer maana? Has tenido algn problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos). Despus de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recin superado. El propsito de la retrospectiva es realizar una mejora continua del proceso. Esta reunin tiene un tiempo fijo de cuatro horas. Scrum permite la creacin de equipos autoorganizados impulsando la co-localizacin de todos los miembros del equipo, y la comunicacin verbal entre todos los miembros y disciplinas involucrados en el proyecto.
58
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafos impredecibles no pueden ser fcilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximacin pragmtica, aceptando que el problema no puede ser completamente entendido o definido, y centrndose en maximizar la capacidad del equipo de entregar rpidamente y responder a requisitos emergentes. Documentos Product backlog: Es un documento de alto nivel para todo el proyecto. Contiene amplias descripciones de todas las caractersticas requeridas, funcionalidades en la wish-list, etctera. Es el "qu" va a ser construido. Es abierto y editable por todo el mundo. Contienen estimaciones burdas, normalmente en das. Esta estimacin ayuda al Product Owner a ajustar la lnea temporal y, de manera limitada, la prioridad (por ejemplo, si "aadir corrector ortogrfico" est estimada en 3 das frente a 3 meses, eso podra afectar a los deseos del Product Owner. Sprint backlog: Es un documento detallado donde se describe el cmo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duracin superior a 16 horas. Si una tarea es mayor de 16 horas, deber ser rota en mayor detalle. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno. Burn down: La burn down chart es una grfica mostrada pblicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una lnea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta lnea sea descendente (en casos en que todo va bien en el sentido de que los requisitos estn bien definidos desde el principio y no varan nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay ms requisitos pendientes de ser completados en el Backlog). Si durante el proceso se aaden nuevos requisitos la recta tendr pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variar o incluso valdr cero en algunos tramos.
FIGURA: Ficha Scrum. FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009
59
La ficha adjunta incluye una descripcin sinptica del proceso y sus elementos que son: Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados. Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog), Incremento. Reuniones: Planificacin del sprint, Revisin diaria, Revisin del sprint. Sprint
OTRAS METODOLOGAS GILES

Aunque los creadores e impulsores de las metodologas giles ms populares han suscrito el manifiesto gil y coinciden con los principios enunciados anteriormente, cada metodologa tiene caractersticas propias y hace hincapi en algunos aspectos ms especficos. Estos son algunas de ellas: CRYSTAL METHODOLOGIES: Se trata de un conjunto de metodologas para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reduccin al mximo del nmero de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo de invencin y comunicacin, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, as como tener polticas de trabajo en equipo definidas. Estas polticas dependern del tamao del equipo, establecindose una clasificacin por colores, por ejemplo Cristal Clear (3 a 8 miembros) y Cristal Orange (25 a 50 miembros). DYNAMIC SYSTEM DEVELOPMENT METHOD (DSDM): Define el marco para desarrollar un proceso de produccin de software. Nace en 1994 con el objetivo de crear una metodologa RAD unificada. Sus principales caractersticas son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseo y construccin, y finalmente implementacin. Las tres ltimas son iterativas, adems de existir realimentacin a todas las fases. ADAPTIVE SOFTWARE DEVELOPMENT (ASD): Su impulsor es Jim Highsmith. Sus principales caractersticas son: iterativo, orientado a los componentes software ms que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulacin, colaboracin y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las caractersticas del software; en la segunda desarrollan las caractersticas y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisin de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo. FEATURE-DRIVEN DEVELOPMENT (FDD): Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseo e implementacin del sistema partiendo de una lista de caractersticas que debe reunir el software. Sus impulsores son Jeff De Luca y Meter Coad. LEAN DEVELOPMENT (LD): Definida por Bob Charettes a partir de sus experiencias en proyectos con la industria japonesa del automvil en los aos 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal caracterstica es introducir un mecanismo para implementar dichos cambios. CONCLUSIONES No existe una metodologa universal para hacer frente con xito a cualquier proyecto de desarrollo de software. Toda metodologa debe ser adaptada al contexto del proyecto (recursos tcnicos y humanos, tiempo de desarrollo, tipo de sistema, etc.). Histricamente, las metodologas tradicionales han intentado abordar la mayor cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeos y con requisitos muy cambiantes. Las metodologas giles ofrecen una solucin casi a medida para una gran cantidad de proyectos que tienen estas caractersticas. Una de las cualidades ms
60
destacables en una metodologa gil es su sencillez, tanto en su aprendizaje como en su aplicacin, reducindose as los costos de implantacin en un equipo de desarrollo. Esto ha llevado hacia un inters creciente en las metodologas giles. Sin embargo, hay que tener presente una serie de inconvenientes y restricciones para su aplicacin, tales como: estn dirigidas a equipos pequeos o medianos (Beck sugiere que el tamao de los equipos se limite de 3 a 20 como mximo, otros dicen no ms de 10 participantes), el entorno fsico debe ser un ambiente que permita la comunicacin y colaboracin entre los miembros del equipo durante todo el tiempo, cualquier resistencia del cliente o del equipo de desarrollo hacia las prcticas y principios puede llevar al proceso al fracaso (el clima de trabajo, la colaboracin y la relacin contractual son claves), el uso de tecnologas que no tengan un ciclo rpido de realimentacin o que no soporten fcilmente el cambio, etc. Falta aun un cuerpo de conocimiento consensuado respecto de los aspectos tericos y prcticos de la utilizacin de metodologas giles, as como una mayor consolidacin de los resultados de aplicacin. La actividad de investigacin est orientada hacia lneas tales como: mtricas y valuacin del proceso, herramientas especficas para apoyar prcticas giles, aspectos humanos y de trabajo en equipo. Aunque en la actualidad ya existen libros asociados a cada una de las metodologas giles existentes y tambin abundante informacin en Internet, es XP la metodologa que resalta por contar con la mayor cantidad de informacin disponible y es con diferencia la ms popular.
61
ANEXO: ANEXO: PATRONES

PATRONES Los patrones describen maneras comunes de hacer las cosas. Un patrn es mucho ms que un modelo. El patrn debe incluir la razn por la cual es como es. Se dice con frecuencia que un patrn es una solucin a un problema. El patrn debe dejar claro el problema, explicar por qu lo resuelve y adems explicar las circunstancias bajo las que funciona y bajo las que no. Los patrones son importantes porque son la siguiente etapa tras el dominio de los elementos bsicos de un lenguaje o tcnica para modelar. Los patrones ofrecen una serie de soluciones y ensean lo que constituye un buen modelo y cmo se construye. Ensean con el ejemplo. Otra Definicin: un patrn es un par problema/solucin con nombre que se puede aplicar en nuevos contextos. Cuando utilizar patrones? Se deben usar patrones todo el tiempo. Siempre que se pretenda desarrollar algo relacionado con anlisis, diseo, codificacin o administracin de proyectos, se debern buscar patrones que puedan ser de utilidad. Los patrones existen tanto a nivel de arquitectura como de componentes. Patrn de diseo Los patrones de diseo (design patterns) son la base para la bsqueda de soluciones a problemas comunes en el desarrollo de software y otros mbitos referentes al diseo de interaccin o interfaces. Un patrn de diseo es una solucin a un problema de diseo. Para que una solucin sea considerada un patrn debe poseer ciertas caractersticas. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseo en distintas circunstancias. Breve Resea Histrica En 1979 el arquitecto Christopher Alexander aport al mundo de la arquitectura el libro The Timeless Way of Building; en l propona el aprendizaje y uso de una serie de patrones para la construccin de edificios de una mayor calidad. En palabras de este autor, "Cada patrn describe un problema que ocurre infinidad de veces en nuestro entorno, as como la solucin al mismo, de tal modo que podemos utilizar esta solucin un milln de veces ms adelante sin tener que volver a pensarla otra vez." Los patrones que Christopher Alexander y sus colegas definieron, publicados en un volumen denominado A Pattern Language, son un intento de formalizar y plasmar de una forma prctica generaciones de conocimiento arquitectnico. Los patrones no son principios abstractos que requieran su redescubrimiento para obtener una aplicacin satisfactoria, ni son especficos a una situacin particular o cultural, son algo intermedio. Un patrn define una posible solucin correcta para un problema de diseo dentro de un contexto dado, describiendo las cualidades invariantes de todas las soluciones. Ms tarde, en 1987, Ward Cunningham y Kent Beck usaron varias ideas de Alexander para desarrollar cinco patrones de interaccin hombre-ordenador (HCI) y publicaron un artculo en OOPSLA-87 titulado Using Pattern Languages for OO Programs. No obstante, no fue hasta principios de los 90's cuando los patrones de diseo tuvieron un gran xito en el mundo de la informtica a partir de la publicacin del libro Design Patterns escrito por el grupo Gang of Four (GoF) compuesto por Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides, en el que se recogan 23 patrones diseo comunes. Objetivos de los patrones Los patrones de diseo pretenden: Proporcionar catlogos de elementos reusables en el diseo de sistemas software. Evitar la reiteracin en la bsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
62
Formalizar un vocabulario comn entre diseadores. Estandarizar el modo en que se realiza el diseo. Facilitar el aprendizaje de las nuevas generaciones de diseadores condensando conocimiento ya existente. Asimismo, no pretenden: Imponer ciertas alternativas de diseo frente a otras. Eliminar la creatividad inherente al proceso de diseo. No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrn, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. Abusar o forzar el uso de los patrones puede ser un error. Categoras de patrones Segn la escala o nivel de abstraccin: Patrones de arquitectura: Aqullos que expresan un esquema organizativo estructural fundamental para sistemas software. Patrones de diseo: Aqullos que expresan esquemas para definir estructuras de diseo (o sus relaciones) con las que construir sistemas software. Idiomas: Patrones de bajo nivel especficos para un lenguaje de programacin o entorno concreto. Adems, tambin es importante resear el concepto de Antipatrn de Diseo, que con forma semejante a la de un patrn, intenta prevenir contra errores comunes de diseo en el software. La idea de los antipatrones es dar a conocer los problemas que acarrean ciertos diseos muy frecuentes, para intentar evitar que diferentes sistemas acaben una y otra vez en el mismo callejn sin salida por haber cometido los mismos errores. Estructuras o plantillas de patrones Para describir un patrn se utilizan plantillas ms o menos estandarizadas, de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicacin uniforme entre diseadores. Varios autores eminentes en esta rea han propuesto plantillas ligeramente distintas. Si bien la mayora definen los mismos conceptos bsicos. La plantilla ms comn es la utilizada precisamente por el GoF y consta de los siguientes apartados: Nombre del patrn: nombre estndar del patrn por el cual ser reconocido en la comunidad (normalmente se expresan en ingls). Clasificacin del patrn: creacional, estructural o de comportamiento. Intencin: Qu problema pretende resolver el patrn? Tambin conocido como: Otros nombres de uso comn para el patrn. Motivacin: Escenario de ejemplo para la aplicacin del patrn. Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrn. Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrn. Participantes: Enumeracin y descripcin de las entidades abstractas (y sus roles) que participan en el patrn. Colaboraciones: Explicacin de las interrelaciones que se dan entre los participantes. Consecuencias: Consecuencias positivas y negativas en el diseo derivadas de la aplicacin del patrn. Implementacin: Tcnicas o comentarios oportunos de cara a la implementacin del patrn. Cdigo de ejemplo: Cdigo fuente ejemplo de implementacin del patrn. Usos conocidos: Ejemplos de sistemas reales que usan el patrn. Patrones relacionados: Referencias cruzadas con otros patrones.
63
Relacin de principales patrones GoF PATRONES CREACIONALES Abstract Factory (Fbrica abstracta): Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre s y haciendo transparente el tipo de familia concreta que se est usando. Builder (Constructor virtual): Abstrae el proceso de creacin de un objeto complejo, centralizando dicho proceso en un nico punto. Factory Method (Mtodo de fabricacin): Centraliza en una clase constructora la creacin de objetos de un subtipo de un tipo determinado, ocultando al usuario la casustica para elegir el subtipo que crear. Prototype (Prototipo): Crea nuevos objetos clonndolos de una instancia ya existente. Singleton (Instancia nica): Garantiza la existencia de una nica instancia para una clase y la creacin de un mecanismo de acceso global a dicha instancia. Ejemplo: se usa para implementar la abstraccin a la base de datos.
FIGURA: Estructura del patrn Singleton.
PATRONES ESTRUCTURALES Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podra utilizarla. Permite hacer polimorfismo. Bridge (Puente): Desacopla una abstraccin de su implementacin. Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase. Decorator (Envoltorio): Aade funcionalidad a una clase dinmicamente. Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema. Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idntica informacin. Proxy: Mantiene un representante de un objeto. PATRONES DE COMPORTAMIENTO Chain of Responsibility (Cadena de responsabilidad): Permite establecer la lnea que deben llevar los mensajes para que los objetos realicen la tarea indicada. Command (Orden): Encapsula una operacin en un objeto, permitiendo ejecutar dicha operacin sin necesidad de conocer el contenido de la misma. Interpreter (Intrprete): Dado un lenguaje, define una gramtica para dicho lenguaje, as como las herramientas necesarias para interpretarlo. Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementacin de estos. Mediator (Mediador): Define un objeto que coordine la comunicacin entre objetos de distintas clases, pero que funcionan como un conjunto.
64
Memento (Recuerdo): Permite volver a estados anteriores del sistema. Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automticamente todos los objetos que dependen de l. State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno. Strategy (Estrategia): Permite disponer de varios mtodos para resolver un problema y elegir cul utilizar en tiempo de ejecucin. Template Method (Mtodo plantilla): Define en una operacin el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura. Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarqua de clases sin modificar las clases sobre las que opera. PATRONES DE SISTEMA MVC (Modelo Vista Controlador): Divide un componente o un subsistema en tres partes lgicas: modelo, vista y controlador, facilitando la modificacin o personalizacin de cada parte. Session (Sesin): Ofrece una forma de que los servidores de sistemas distribuidos sean capaces de distinguir los clientes, permitiendo que las aplicaciones asocien el estado con la comunicacin entre el cliente y el servidor. Worker Thread (Thread trabajador): Mejor la productividad y minimiza la latencia media. Callback (Retrollamada): Permite que un cliente se registre en un servidor para ciertas operaciones. De esta forma, el servidor puede notificar al cliente cuando la operacin ha finalizado. Succesive Update (Actualizacin Sucesiva): Ofrece a los clientes una forma de recibir actualizaciones continuas. Router (Encaminador): Desacopla mltiples fuentes de informacin de los objetos de esa informacin. Transaction (Transaccin): Agrupa una coleccin de mtodos de forma que todos ellos finalicen correctamente o fallen de forma colectiva. Aplicacin en mbitos concretos Adems de su aplicacin directa en la construccin de software en general, y derivado precisamente del gran xito que han tenido, los patrones de diseo han sido aplicados a mltiples mbitos concretos producindose lenguajes de patrones y completos catlogos de mano de diversos autores. En particular son notorios los esfuerzos en los siguientes mbitos: Patrones de interfaces de usuario; esto es, aquellos que intentan definir las mejores formas de construir interfaces hombre-mquina (HCI, GUI). Patrones para la construccin de sistemas empresariales, en donde se requieren especiales esfuerzos en infraestructuras software y un nivel de abstraccin importante para maximizar factores como la escalabilidad o el mantenimiento del sistema. Patrones para la integracin de sistemas (EAI), es decir, para la intercomunicacin y coordinacin de sistemas heterogneos. Patrones de workflow, esto es para la definicin, construccin e integracin de sistemas abstractos de gestin de flujos de trabajo y procesos con sistemas empresariales.
65
LECTURA ADICIONAL
HA MUERTO EL DISEO? Para algunas personas que slo han tenido un contacto breve con la Programacin Extrema, pareciera que la XP convoca a la muerte del diseo de software. No solamente se ridiculiza a la actividad de diseo como "Big Up Front Design", sino que tcnicas como UML, marcos flexibles e incluso patrones son menospreciados o simplemente ignorados. De hecho la XP involucra mucho diseo, pero lo hace de una manera diferente a la de los procesos de software establecidos. La XP ha rejuvenecido la nocin de diseo evolutivo con prcticas que permiten a la evolucin ser una estrategia de diseo viable. Tambin brinda nuevos retos y habilidades pues los diseadores necesitan aprender cmo hacer diseo simple, cmo usar refactoracin para mantener el diseo limpio y cmo usar patrones en un estilo evolutivo. La Programacin Extrema (XP por sus siglas en ingls) desafa muchos de los presupuestos comunes acerca del desarrollo de software. La ms controversial es el rechazo a un esfuerzo significativo en el diseo previo, en favor de un estilo ms evolutivo. Para sus detractores, esto es un retorno al desarrollo "codificar y corregir" usualmente denostado como hackear. Para sus fans esto es frecuentemente visto como un rechazo a tcnicas de diseo (tal como el UML), principios y patrones. No preocuparse por el diseo, si escuchas tu cdigo un buen diseo aparecer. Me encuentro en el centro de este debate. Gran parte de mi carrera ha involucrado lenguajes grficos de diseo el Unified Modeling Language (UML) y sus seguidores- y patrones. Realmente he escrito libros tanto sobre UML como sobre patrones. Significa mi adhesin a la XP una renuncia a todo lo que he escrito sobre esos temas, limpiando mi mente de todas esas nociones contrarrevolucionarias? Bueno, no puedo prolongar ms el suspenso. La respuesta corta es no. La larga es el resto de este artculo. Diseo planeado y evolutivo Voy a describir dos estilos de cmo se disea en desarrollo de software. Quiz el ms comn es el diseo evolutivo. Esencialmente, evolutivo significa que el diseo del sistema crece conforme se implanta el sistema. El diseo es parte del proceso de programacin y conforme el programa evoluciona el diseo cambia. En su uso comn, el diseo evolutivo es un desastre. El diseo acaba siendo la agregacin de una sarta de decisiones tcticas ad-hoc, cada una de las cuales hace el cdigo ms difcil de modificar. Se podra alegar que eso no es diseo, ciertamente suele llevar a un diseo pobre. Como indica Kent, el diseo est para permitir cambiar el software fcilmente a largo plazo. Conforme el diseo se deteriora, igualmente se deteriora la capacidad de cambio. Se tiene el estado de entropa de software, conforme pasa el tiempo el diseo empeora y empeora. Esto no solo hace el software ms difcil de cambiar, tambin facilita la generacin de bugs y dificulta el encontrarlos y eliminarlos con seguridad. Esta es la pesadilla de "codifica y corrige", donde los bugs devienen exponencialmente ms costosos de arreglar conforme el proyecto avanza. El diseo planeado es todo lo contrario, y contiene nociones nacidas de otras ramas de la ingeniera. Si usted quiere construir la casa de su perro, puede simplemente tomar unas tablas y construir una forma ruda. Si quiere construir un rascacielos, no puede hacerlo de la misma manera - se caera antes de terminar siquiera la mitad. As que empieza con dibujos ingenieriles, hechos en un estudio ingenieril como en el que trabaja mi esposa en el centro de Boston. Conforme hace el diseo ella se figura todo el asunto, en parte por anlisis matemtico pero principalmente usando cdigos de construccin. Los cdigos de construccin son reglas acerca de cmo disear estructuras con base en la experiencia de qu es lo que funciona bien (y algo de matemticas). Una vez hecho el diseo, su compaa ingenieril puede pasar el diseo a otra empresa que lo construya. El diseo planeado en software debera funcionar de la misma manera. Los diseadores piensan los grandes problemas con anticipacin. No necesitan programar porque no estn construyendo el software, slo lo estn planeando. As que pueden usar tcnicas de diseo como el UML que deja de lado algunos de los detalles de la programacin y permite a los diseadores trabajar a un nivel ms abstracto. Una vez hecho el diseo, pueden pasarlo a otro grupo (o a otra compaa) que lo construya. Ya que los diseadores estn pensando en una escala mayor, pueden evitar las series de decisiones tcticas que llevan a la entropa del software. Los programadores pueden seguir la direccin del diseo y, dado que siguen el diseo al pie de la letra, tener un sistema bien construido.
66
Ahora bien, el diseo planeado ha estado all desde los 70s, y mucha gente lo ha usado. Es mejor en muchas formas que el diseo evolutivo de codificar y corregir. Pero tiene algunas fallas. La primera es que es imposible pensar en todos los problemas que se necesitan tratar cuando se programa. Es inevitable que al programar se encuentren cosas que ponen en entredicho el diseo. Si los diseadores ya acabaron y ya estn en otro proyecto, qu pasa? Los programadores empiezan a codificar en torno al diseo y la entropa aparece. An si el diseador no se ha ido, lleva tiempo organizar los problemas de diseo, cambiar los dibujos y alterar el cdigo. Usualmente se hace una correccin rpida por la presin de tiempo. Entropa (otra vez). Adems frecuentemente hay un problema cultural. Los diseadores se han formado por su habilidad y experiencia, pero estn tan ocupados trabajando en diseos que ya no tienen tiempo para programar. Sin embargo las herramientas y materiales de desarrollo de software cambian rpidamente. Cuando dejas de programar no solo pierdes los cambios que ocurren en este flujo tecnolgico, tambin pierdes el respeto de los que s programan. Esta tensin entre constructores y diseadores tambin existe en la construccin, pero es ms intensa en el software. Es intensa porque hay una diferencia clave. En construccin hay una divisin clara de habilidades entre los que disean y los que construyen, pero en software no es tanto as. Cualquier programador trabajando en ambientes de alto diseo necesita ser muy hbil. Lo suficientemente hbil para cuestionar los diseos del diseador, especialmente cuando el diseador sabe menos acerca de las realidades diarias de la plataforma de desarrollo. Ahora bien, estos problemas pueden corregirse. Podramos manejar la tensin humana. Quiz podemos conseguir diseadores tan hbiles para tratar con la mayora de los problemas y tener un proceso suficientemente disciplinado para cambiar los dibujos. An hay otro problema: los requerimientos cambiantes. Ese es el problema nmero uno, causante de dolores de cabeza en los proyectos de software en que he participado. Una manera de controlar los requerimientos cambiantes es aadir flexibilidad en el diseo de modo que se pueda cambiar fcilmente conforme cambian los requerimientos. Esto requiere perspicacia en la clase de cambios esperados. Un diseo puede planearse para tratar con reas de volatilidad, pero mientras eso ayuda con cambios de requerimientos previstos, no ayuda (y puede daar) con cambios imprevistos. As que los requerimientos tienen que entenderse lo suficientemente bien para separar las reas voltiles, y en mi experiencia eso es muy difcil. Algunos de estos problemas de requerimientos se deben a la falta de un entendimiento claro de los mismos. Mucha gente se enfoca en los procesos de ingeniera de requerimientos con la esperanza de que esto prevendr la necesidad de cambiar el diseo ms tarde. Pero an esta receta puede no llevar a la cura. Muchos requerimientos cambiantes imprevistos ocurren debido a cambios en el negocio. Esos no pueden prevenirse, no importa cuan cuidadoso sea el proceso de ingeniera de requerimientos. Esto hace sonar imposible al diseo planeado. Ciertamente estos son grandes retos. Pero no me inclino a afirmar que el diseo planeado es peor que el evolutivo, bajo el estilo "codifica y corrige". De hecho prefiero el diseo planeado. No obstante estoy consciente de los problemas del diseo planeado y busco una direccin nueva. Las Prcticas Habilitadoras de la XP La XP es controversial por muchas razones, pero una de las banderas rojas clave de la XP es que aboga por el diseo evolutivo en lugar del diseo planeado. Como sabemos, el diseo evolutivo no puede funcionar debido a decisiones ad hoc y la entropa de software. El meollo para entender este argumento es la curva de cambio del software. La curva del cambio dice que mientras ms avanza el proyecto, es exponencialmente ms caro hacer cambios. La curva del cambio se expresa usualmente en trminos de las fases "un cambio hecho en el anlisis por $1 cuesta miles en produccin". Esto es irnico ya que la mayora de los proyectos an trabajan en un proceso ad-hoc que no tiene una fase de anlisis, pero las exponenciaciones an estn all. La curva exponencial del cambio significa que el diseo evolutivo no puede funcionar. Tambin explica por qu el diseo planeado debe ser hecho cuidadosamente porque cualquier error encara la misma exponenciacin. La suposicin fundamental de la XP es que es posible aplanar la curva del cambio lo suficiente como para hacer que funcione el diseo evolutivo. Este aplanamiento es a la vez permitido y explotado por la XP. Esto es parte del enganche de prcticas en XP: especficamente no puedes hacer todas las cosas que explotan la curva aplanada sin hacer las cosas que permiten aplanarla. Esta es una fuente comn de controversia sobre la XP. Mucha gente
67
critica la explotacin sin entender la habilitacin. Frecuentemente las crticas surgen de la propia experiencia de los crticos que no hicieron las prcticas habilitadoras que permiten funcionar a las prcticas explotadoras. Como resultado se quemaron y cuando ven la XP recuerdan el fuego. En el centro de las prcticas habilitadoras estn las de Pruebas e Integracin Continua. Sin la seguridad dada por las pruebas el resto de la XP sera imposible. La integracin continua es necesaria para mantener al equipo en sincrona, de modo que puedas hacer un cambio sin preocuparte de integrarla con otra gente. Juntas, estas prcticas pueden tener un gran efecto en la curva del cambio. Me acord de esto otra vez aqu en ThoughtWorks. La introduccin de Pruebas e Integracin Continua ha marcado un mejoramiento en el esfuerzo de desarrollo. Ciertamente suficiente para cuestionar seriamente la afirmacin de la XP de que necesitas todas las prcticas para lograr una gran mejora. La refactoracin tuvo un efecto similar. La gente que refactora su cdigo de la manera disciplinada sugerida por la XP encuentra una diferencia significativa en la efectividad comparada a hacer una reestructuracin relajada ms ad-hoc. Esa fue ciertamente mi experiencia una vez que Kent me ense a refactorar propiamente. Despus de todo, slo un cambio as de fuerte me habra motivado a escribir un libro entero sobre el tema. Jim Highsmith, en su excelente resumen de la XP, usa la analoga de un conjunto de escalas. En una bandeja est el diseo planeado, en la otra la refactoracin. En propuestas ms tradicionales el diseo planeado domina porque se supone que no puedes cambiar de idea ms tarde. Conforme baja el costo del cambio puedes hacer ms con tu diseo ms tarde como refactoracin. El diseo planeado no se esfuma, solo que ahora hay un balance entre los dos acercamientos. Para m, siento que antes de la refactoracin estaba diseando con una sola mano. Estas prcticas habilitadoras de integracin continua, pruebas y refactoracin, crean un nuevo ambiente que hace plausible el diseo evolutivo. Sin embargo algo que an no imaginamos es el lugar del punto de equilibrio. Estoy seguro de que, a pesar de la impresin externa, XP no es slo prueba, codifica y refactora. Hay espacio para el diseo antes de codificar. Algo de esto ocurre antes de que se haya cdigo, la mayor parte ocurre en las iteraciones antes de codificar una tarea particular. Pero hay un nuevo balance entre diseo up-front y refactoracin. El valor de la Simplicidad Dos de los ms grandes gritos de batalla de la XP son los eslogans "Haz la cosa ms simple que pueda funcionar" y "No lo vas a necesitar" (conocido como YAGNI por sus siglas en ingls). Ambos son manifestaciones de la prctica XP del diseo simple. La manera en que usualmente se describe YAGNI, es que no deberas aadir hoy cdigo que slo ser usado por alguna caracterstica que ser necesaria maana. En principio esto suena simple. El problema viene con cosas tales como marcos (frameworks), componentes reusables, y diseo flexible. Tales cosas son complicadas de construir. Se paga un costo up-front extra para construirlas, en la expectativa de que recuperars ese costo ms tarde. Esta idea de construir flexibilidad up-front es vista como la parte clave del diseo de software efectivo. Sin embargo el consejo de la XP es que no construyas componentes flexibles y frameworks para el primer caso que necesite esa funcionalidad. Deja crecer esas estructuras como se necesiten. Si quiero una clase Money hoy que maneje adicin pero no multiplicacin entonces solo construyo adicin en la clase Money. An si estoy seguro de que necesitar multiplicacin en la iteracin siguiente, y entiendo cmo hacerlo fcilmente, y creo que sera realmente rpido hacerlo, an as lo dejar para la siguiente iteracin. Una razn de esto es econmica. Si tengo que trabajar por una caracterstica que slo se necesitar maana, estoy comprometiendo esfuerzo de caractersticas que necesitan hacerse para la iteracin actual. El plan de entrega dice qu es lo que necesita trabajarse ahora, trabajar en cosas del futuro es contrario a los acuerdos de los desarrolladores con el cliente. Hay un riesgo de que las historias de la iteracin pudieran no hacerse. An si estas historias de la iteracin no estn en riesgo depende del cliente decidir que trabajo extra debe hacerse -y que podra no incluir an la multiplicacin. Este contraincentivo econmico es reforzado por la posibilidad de que pudiramos no hacerlo bien. Como sea que estemos seguros de que esta funcin trabaja, an podramos equivocarnos -especialmente si an no tenemos requerimientos detallados. Trabajar en la solucin errnea anticipadamente es an peor despilfarro que trabajar en la funcin correcta con anticipacin. Y los XPertos generalmente creen que es ms probable que nos equivoquemos (y yo concuerdo con esa opinin).
68
La segunda razn por el diseo simple es que un diseo complejo es ms difcil de entender que un diseo simple. Por lo tanto cualquier modificacin al sistema se hace ms difcil por la complejidad aadida. Esto agrega un costo en el periodo que va de cuando el diseo ms complicado se aadi a cuando se necesit. Ahora bien, para mucha gente este consejo no tiene sentido, y tienen razn. Tienen razn si te imaginas en el mundo de desarrollo convencional donde las prcticas habilitadoras de la XP no existen. No obstante, cuando el balance entre diseo planeado y evolutivo cambia, entonces YAGNI se convierte en una buena prctica (y slo entonces). Para resumir, no debes gastar esfuerzo aadiendo cosas que no sern necesarias hasta una iteracin futura. Aun si el costo es cero, no debes porque eso incrementa el costo de modificacin. De cualquier manera slo puedes comportarte as si ests usando XP o alguna prctica similar que baje el costo del cambio. Finalmente Qu Demonios es Simplicidad As que queremos nuestro cdigo tan simple como sea posible. Eso no suena difcil de sostener, despus de todo quin quiere ser complicado? Pero desde luego esto trae la pregunta "qu es simple?" En XPE Kent da cuatro criterios para un diseo simple, en orden de importancia: Correr todas las pruebas Revelar toda la intencin Evitar duplicacin El menor nmero de clases y mtodos El que corran todas las pruebas es un criterio muy simple. No duplicacin tambin es muy directo, aunque muchos de los desarrolladores necesitan gua para lograrlo. El truco tiene que ver con revelar la intencin. Qu significa eso exactamente? El valor bsico aqu es claridad de cdigo. XP pone en alto el cdigo fcil de leer. En XP "cdigo astuto" es un trmino de abuso. Pero para algunas personas, el cdigo que revela la intencin es otra astucia. En su artculo en XP 2000, Josh Kerievsky seala un buen ejemplo de esto. El atiende al que posiblemente es el cdigo XP ms pblico - JUnit. JUnit usa decoradores para aadir funcionalidad opcional a los casos de prueba, tales como sincronizacin concurrente y cdigo batch set up. Separando este cdigo en decoradores permite al cdigo general ser ms claro de lo que podra ser. Pero uno se pregunta si el cdigo resultante es realmente simple. Para m lo es, pero estoy familiarizado con el patrn Decorator. Pero para muchos que no lo estn esto es muy complicado. Similarmente JUnit usa mtodos enchufables los cuales, he notado, la mayora de la gente los encuentra cualquier cosa menos claros. As que debemos concluir que el diseo de JUnit es simple para diseadores experimentados pero complicado para los menos experimentados? Yo creo que el meollo en eliminar la duplicacin, tanto el "Una vez y slo una vez" de la XP y el DRY (Don't Repeat Yourself) del Programador Pragmtico es uno de esos obvios y maravillosamente poderosos buenos consejos. El solo seguirlo puede llevar muy lejos. Pero no es todo, y la simplicidad es an algo complicado de hallar. Recientemente me vi envuelto en hacer algo que bien podra estar sobrediseado. Lo arreglamos refactorando y removiendo algo de su flexibilidad. Pero como uno de los desarrolladores dijo "es ms fcil refactorar sobrediseo que refactorar sin diseo". Es mejor ser un poco ms simple de lo que necesitas ser, pero no es un desastre ser un poco ms complejo. El mejor consejo que he escuchado sobe todo esto vino del to Bob (Robert Martin). Su consejo fue no demorarse mucho sobre cual es el diseo ms simple. Despus de todo se puede, se debe y se refactorar ms tarde. Al final la disposicin a refactorar es ms importante que saber que la cosa ms simple ya est. La refactoracin viola YAGNI Este asunto surgi recientemente en la lista de correo XP, y vale la pena traerlo a colacin, ya que estamos viendo el rol del diseo en la XP. Bsicamente la cuestin empieza con el punto de que la refactoracin toma tiempo pero no aade funcionalidad. Como el punto del YAGNI es que se supone que se debe disear para el presente y no para el futuro, es esto una violacin?
69
El punto de YAGNI es no aadir complejidad innecesaria para las historias actuales. Esto es parte de la prctica del diseo simple. Refactorar es necesario para mantener el diseo tan simple como puedas, as que debes refactorar cuando notes que puedes simplificar las cosas. El diseo simple explota las prcticas de la XP y es tambin una prctica habilitadora. Slo si has hecho pruebas, integrado continuamente y refactorado puedes practicar el diseo simple efectivamente. Pero al mismo tiempo, mantener el diseo simple es esencial para mantener la curva del cambio plana. Cualquier complejidad innecesaria hace al sistema difcil de cambiar en toda direccin excepto la que anticipaste con la complicada flexibilidad aadida. Sin embargo la gente no es buena anticipando, as que es mejor esforzarse por la simplicidad. No se obtiene la cosa ms simple la primera vez, as que necesitas refactorar para acercarte a la meta. Patrones y XP El ejemplo JUnit me lleva inevitablemente a los patrones. La relacin entre patrones y la XP es interesante y es una cuestin comn. Joshua Kerievsky arguye que los patrones son subestimados en la XP y lo sustenta elocuentemente, as que no lo repetir. Pero vale la pena tomar en cuenta que para mucha gente los patrones parecen estar en conflicto con la XP. La esencia de este argumento es que los patrones frecuentemente se sobreutilizan. El mundo esta lleno del legendario buen programador, fresco de su primera lectura del GOF que incluye 16 patrones en 32 lneas de cdigo. Recuerdo una tarde, alimentada por una muy buena cerveza, trabajando con Kent en un artculo que sera llamado "Patrones de No Diseo: 23 trucos baratos". Estbamos pensando en cosas como usar una declaracin if en lugar de una estrategia. La broma tena una razn, los patrones son frecuentemente sobreutilizados, pero eso no los hace tan mala idea. La cuestin es cmo los usas. Una teora es que las fuerzas del diseo simple te llevarn a los patrones. Muchas refactoraciones hacen esto explcitamente, pero an sin ellas siguiendo las reglas del diseo simple llegars a los patrones aun si no los conoces previamente. Esto puede ser cierto pero, es la mejor forma de hacerlo? Seguramente es mejor si sabes toscamente a dnde vas y tienes un libro que te gue en lugar de tener que inventarlo t mismo. Yo ciertamente an uso el GOF cuando siento que surge un patrn. Para m el diseo efectivo implica que necesitamos saber si vale la pena pagar el precio de un patrn -eso es su propia habilidad. Similarmente, como sugiere Joshua, necesitamos estar ms familiarizados acerca de cmo llegar a un patrn gradualmente. En este respecto, la XP trata la manera en que usamos patrones diferente a la manera en que algunas personas los usan, pero ciertamente no elimina su valor. Leyendo algunas de las listas de correo tengo la sensacin de que mucha gente ve a la XP como desalentadora de patrones, a pesar de la irona de que la mayora de los proponentes de la XP tambin han sido lderes del movimiento de los patrones. Ser que ellos han visto ms all de los patrones, o tienen a los patrones tan embebidos en su pensamiento que ellos ya no lo notan? No s la respuesta para otros, pero para m los patrones an son vitalmente importantes. XP puede ser un proceso de desarrollo, pero los patrones son una columna vertebral del conocimiento de diseo, conocimiento que es valioso cualquiera que sea el proceso. Procesos diferentes pueden usar patrones de diferente manera. XP enfatiza no usar patrones hasta que sea necesario y evolucionar el camino hacia un patrn va una implementacin simple. Pero los patrones son todava una pieza clave de conocimiento a adquirir. Mi consejo a los XPeros en el uso de patrones es: Invertir tiempo en aprender sobre patrones. Concentrarse en cundo aplicarlos (no muy pronto). Concentrarse en cmo implementar el patrn en su forma ms simple primero, y aadir complejidad luego. No temer eliminar un patrn si no est valiendo su peso. Pienso que la XP debera enfatizar aprender ms sobre patrones. No estoy seguro de cmo encajara esto en las prcticas de la XP, pero estoy seguro que Kent puede encontrar la manera.
70
Creciendo una arquitectura Qu queremos decir con arquitectura de software? Para m el trmino arquitectura conlleva una nocin de los elementos centrales del sistema, las piezas que son difciles de cambiar. Un fundamento sobre el cual debe construirse el resto. Qu rol juega la arquitectura cuando usamos diseo evolutivo? De nuevo los crticos de la XP afirman que la XP ignora la arquitectura, que la ruta de la XP es ir hacia la codificacin rpida y confiar en que la refactoracin resolver todos los problemas de diseo. Interesantemente tienen razn, y eso bien puede ser una debilidad. Ciertamente los ms agresivos XPeros - Kent Beck, Ron Jeffries y Bob Martin - estn poniendo ms y ms energa en evitar cualquier diseo arquitectnico. No pongas una base de datos hasta que realmente sepas que la necesitas. Trabaja con archivos primero y refactora a la base de datos en una iteracin posterior. Yo soy conocido por ser un XPero cobarde, y como tal tengo que discordar. Yo creo que hay lugar para una amplia arquitectura inicial. Cosas tales como establecer temprano cmo separaremos la aplicacin, como interaccionaremos con la base de datos (si hace falta una), qu estrategia usar para manejar el servidor web. Esencialmente creo que muchas de estas reas son patrones que hemos aprendido a travs de los aos. Conforme crece el conocimiento de patrones, se debe tener una idea razonable de cmo usarlos. De cualquier modo la diferencia clave es que no se espera poner en piedra estas decisiones arquitectnicas tempranas, o bien el equipo sabe que ellas pueden errar sus decisiones tempranas y debern tener el valor de arreglarlas. Otros cuentan la historia de un proyecto en que, cerca de la implantacin, deciden que no necesitaban ms EJB y lo quitaron del sistema. Fue una refactoracin considerable, se hizo tarde, pero las prcticas habilitadoras lo hicieron no slo posible, sino valioso. Cmo habra funcionado esto de la otra manera. Si decides no usar EJB, habra sido ms difcil aadirlo luego? No debes pues empezar con EJB hasta que hayas tratado cosas sin l y encontrado su falta? Es una pregunta que implica varios factores. Ciertamente trabajar sin un componente complejo incrementa la simplicidad y hace las cosas ir ms rpido. Sin embargo algunas veces es ms fcil sacar algo que meterlo. Mi consejo es empezar estimando la arquitectura probable. Si ves un gran montn de datos con mltiples usuarios, adelante, usa una base de datos desde el primer da. Si ves lgica de negocio compleja, pon un modelo del dominio. De cualquier modo en deferencia a los dioses del YAGNI, cuando dudes ve al lado de la simplicidad. Tambin preprate para simplificar tu arquitectura tan pronto veas que parte de la misma no est dando nada. UML y XP De todas las preguntas que me hacen sobre mi compromiso con la XP una de las ms grandes es respecto a mi asociacin con el UML. No son los dos incompatibles? Hay un nmero de puntos de incompatibilidad. Ciertamente la XP menosprecia los diagramas en gran medida. Aunque la posicin oficial es en la lnea de "salos si son tiles", se puede leer entre lneas "los verdaderos XPeros no diagraman". Esto se refuerza con el hecho de que gente como Kent no se sienten cmodos con los diagramas, de hecho nunca he visto a Kent dibujar voluntariamente un diagrama de software en ninguna notacin fija. Yo creo que el asunto viene de dos causas separadas. Una es el hecho de que algunas personas encuentran los diagramas tiles y otras no. El peligro est en los que piensan que quienes no los usan deberan usarlos y viceversa. En lugar de eso deberamos aceptar que algunos usen diagramas y otros no. El otro problema es que los diagramas tienden a asociarse con procesos pesados. Tales procesos gastan mucho tiempo en dibujar diagramas que no ayudan y pueden daar. De manera que pienso que la gente debe ser guiada en cmo usar bien los diagramas y evitar las trampas, en lugar del mensaje "solo si tienes que" de los XPertos. Aqu esta mi consejo para usar bien los diagramas. Primero piensa para qu los ests dibujando. El principal valor es la comunicacin. Comunicacin efectiva significa seleccionar las cosas ms importantes y descuidar las menos. Esta selectividad es la clave para usar bien el UML. No dibujes cada clase -slo las importantes. Para cada clase, no muestres cada atributo y operacin -slo los importantes. No dibujes diagramas de secuencia para todos los casos de uso y escenarios -slo... ya lo entiendes. Un problema comn con el uso de los diagramas es que la gente intenta hacerlos extensos. El cdigo es la mejor fuente de informacin extensa ya que el cdigo es lo ms fcil de mantener en sincrona con el cdigo. La exhaustibilidad de los diagramas es la enemiga de su comprensin.
71
Un uso comn de los diagramas es explorar un diseo antes de empezar a programarlo. Frecuentemente se tiene la impresin de que tal actividad es ilegal en XP, pero eso no es cierto. Mucha gente dice que cuando se tiene una tarea difcil vale la pena juntarse para tener una sesin de diseo rpido. De cualquier manera cuando hagan tales sesiones: mantnganlas cortas no traten de concentrarse en todos los detalles (slo los importantes) traten el diseo resultante como un esbozo, no como el diseo final El ltimo punto merece extenderse. Cuando se hace un diseo up-front, inevitablemente encontrars que algunos aspectos del diseo estn mal, y eso slo se descubre cuando lo programas. Eso no es un problema dado que entonces cambias el diseo. El problema viene cuando la gente piensa que el diseo est hecho y entonces no aprovechan la oportunidad de devolver al diseo el conocimiento adquirido al programar. Cambiar el diseo no necesariamente implica cambiar los diagramas. Es perfectamente razonable dibujar diagramas que te ayuden a entender el diseo y entonces hacerlos a un lado. El dibujarlos ayud y eso es suficiente para que valga la pena hacerlos. Pero no tienen que ser artefactos permanentes. Los mejores diagramas UML no son artefactos. Muchos XPeros usan tarjetas CRC. Eso no entra en conflicto con el UML. Yo uso una mezcla de CRC y UML todo el tiempo, usando la tcnica que sea ms til para el trabajo en mano. Toma mucho tiempo mantener los diagramas actualizados, as que pierden sincrona con el cdigo. Estn ocultos en una herramienta CASE, as que nadie los mira. El consejo de documentacin sobre la marcha viene de estos problemas observados: Slo usa diagramas que puedas mantener actualizados sin esfuerzo notable. Pon los diagramas donde todos puedan verlos fcilmente. Me gusta pegarlos en la pared. Alienta a la gente a editar la copia en la pared para cambios simples. Presta atencin a si alguien usa los diagramas. Si nadie lo hace, tralos. El ltimo aspecto de usar UML es para documentacin en una situacin de relevo, tal como cuando un grupo ocupa el lugar de otro. Aqu el punto XP es que producir documentacin es una historia como cualquier otra, y as su valor de negocio es determinado por el cliente. Otra vez la UML es til aqu, los diagramas son selectivos para ayudar a la comunicacin. Recuerda que el cdigo es el repositorio de informacin detallada, el diagrama acta para resumir y resaltar asuntos importantes. Sobre la Metfora Bueno, podra decirlo pblicamente -no he captado el punto de esta cosa, metfora. La he visto funcionar, y funcion bien en el proyecto C3, pero eso no significa que yo tenga una idea de cmo hacerla, ni menos cmo explicar cmo hacerla. La prctica XP de la metfora se origin a partir de la propuesta de Ward Cunningham de un sistema de nombres. El punto es que vienes con un bien conocido conjunto de nombres que actan como vocabulario para hablar acerca del dominio. Este sistema de nombres juega en el modo en que nombras las clases y mtodos en el sistema. He construido un sistema de nombres construyendo un modelo conceptual del dominio. Lo he hecho con los expertos del dominio usando UML o sus predecesores. He encontrado que hay que ser cuidadoso al hacerlo. Se necesita mantener un conjunto de notacin mnimo y tienes que guardarte de dejar que cualquier asunto tcnico se cuele en el modelo. Pero si lo haces, he encontrado que puedes usarlo para construir un vocabulario del dominio que los expertos del dominio puedan entender y usarlo para comunicarse con los desarrolladores. El modelo no empareja con el diseo de clases perfectamente, pero es suficiente para dar un vocabulario comn de todo el dominio. Ahora, no veo ninguna razn por la que este vocabulario no pueda ser metafrico, tal como la metfora C3 en que la nmina se convirti en una lnea de ensamblaje de fbrica. Pero tampoco veo por qu el basar tu sistema de nombres en el vocabulario del dominio sea tan mala idea. Ni me inclino a abandonar una tcnica que funciona bien para m obteniendo los nombres del sistema. Frecuentemente se critica a la XP sobre la base de que se necesita al menos algn esbozo de diseo de un sistema. Los XPeros frecuentemente responden con la respuesta "esa es la metfora". Pero yo an no creo haber visto una explicacin convincente de la metfora. Este es un hoyo real en la XP, y uno que el XPero necesita sortear.
72
Quieres ser arquitecto cuando seas grande? En la ltima dcada, el trmino "arquitecto de software" se ha vuelto popular. Es un trmino que me resulta difcil de usar. Mi esposa es ingeniero estructural. La relacin entre ingenieros y arquitectos es... interesante. Mi favorito es "los arquitectos son buenos para las tres B's: bulbos, bushes [arbustos], birds [pjaros]". La idea es que los arquitectos salen con todos esos dibujos bonitos, pero son los ingenieros quienes tienen que asegurarse de que realmente puedan ponerse en pie. Como resultado he evitado el trmino arquitecto de software; despus de todo si mi esposa no puede tratarme con respeto profesional quin puede hacerlo. En software, el trmino arquitecto significa muchas cosas. (En software cualquier trmino significa muchas cosas.) En general, sin embargo conlleva ciertos problemas, como "no soy un mero programador -soy un arquitecto". Esto puede traducirse como "ahora soy un arquitecto -soy demasiado importante como para programar". La cuestin es si separarte del mundano esfuerzo de programar es algo que debes hacer si quieres ejercer liderazgo tcnico. Esta cuestin genera demasiada emocin. He visto gente enojarse mucho al pensar que no tienen ms el rol de arquitectos. "No hay lugar en XP para arquitectos experimentados" es el grito que frecuentemente escucho. Tanto como en el rol del diseo en s, no creo que sea el caso que la XP no valore la experiencia de o las buenas habilidades de diseo. En realidad muchos de los proponentes de la XP - Kent Beck, Bob Martin, y desde luego Ward Cunningham - estn entre de quienes he aprendido mucho acerca de lo que es el diseo. De cualquier manera esto significa que sus roles difieren de lo que mucha gente ve como un rol de liderazgo tcnico. Como ejemplo, citar a uno de nuestros lderes tcnicos en ThoughtWorks: Dave Rice. Dave ha estado en varios ciclos de vida y se ha puesto el sombrero extraoficial de lder tcnico en un proyecto de 50 personas. Su rol como lder significa gastar mucho tiempo con los programadores. El trabaja con un programador cuando ste necesita ayuda, siempre anda merodeando para ver quin necesita ayuda. Una seal significativa es cuando se sienta. Como un trabajador de mucho tiempo en ThoughtWorks, l podra muy bien tener la oficina que quisiera. Comparti una por un tiempo con Cara, la gerente de entregas. Sin embargo en los ltimos meses se mud a las bahas abiertas donde trabajan los programadores (usando el estilo abierto "war room" que la XP favorece). Esto es importante para l porque de este modo ve lo que est pasando y est disponible para dar la mano donde se necesite. Aquellos que saben XP se darn cuenta de que estoy describiendo el rol explcito de Coach. En verdad uno de los varios juegos de palabras que hace la XP es que llama a la figura de primer tcnico el "Coach". El significado es claro: en XP el liderazgo tcnico se muestra enseando a los programadores y ayudndolos a tomar decisiones. Es uno que requiere buena habilidad de gentes tanto como buenas habilidades tcnicas. Jack Bolles en XP 2000 coment que hay poco espacio ahora para el maestro solitario. Colaboracin y enseanza son las claves del xito. En una cena en una conferencia, Dave y yo hablbamos con un oponente a la XP. Conforme discutamos lo que hacamos, las similaridades de nuestro enfoque eran marcadas. Todos nosotros gustbamos del desarrollo adaptativo e iterativo. Las pruebas eran importantes. As que nos tena perplejos su oposicin. Entonces vino esta declaracin en la lnea de "lo ltimo que quiero es que mis programadores refactoren y manoseen el diseo". Ahora todo estaba claro. La laguna conceptual me la explic Dave "si l no confa en sus programadores por qu los contrata?". En XP la cosa ms importante que puede hacer el desarrollador experimentado es pasar cuantas habilidades pueda a los desarrolladores junior. En lugar de un arquitecto que toma todas las decisiones importantes, tienes un coach que ensea a los desarrolladores a tomar decisiones importantes. Como Ward Cunningham seal, as l ampla sus habilidades y aade ms a un proyecto de lo que cualquier hroe solitario podra. Reversibilidad En la XP 2000 Enrico Zaninotto di una pltica fascinante en la que discuti la relacin entre los mtodos giles y la manufactura esbelta (lean manufacturing). Segn l, uno de los aspectos clave de ambos enfoques es que atajan la complejidad al reducir la irreversibilidad del proceso. Desde esta vista una de las principales fuentes de complejidad es la irreversibilidad de las decisiones. Si puedes cambiar tus decisiones, no es tan importante que sean correctas - lo que hace tu vida mucho ms sencilla. La consecuencia para el diseo evolutivo es que los diseadores deben pensar en cmo evitar la irreversibilidad en sus decisiones. Ms que tratar de tomar la decisin correcta ahora, busca una manera de posponerla (hasta que
73
tengas ms informacin) o toma la decisin de tal modo que seas capaz de revertirla despus sin demasiada dificultad. Esta determinacin de mantener la reversibilidad es una de las razones de que los mtodos giles pongan tanto nfasis en sistemas de control de cdigo fuente y de ponerlo todo en esos sistemas. Mientras que esto no garantiza la reversibilidad, particularmente para decisiones de vida larga, proporciona un fundamento que da confianza al equipo, aun si rara vez se usa. Disear para la irreversibilidad tambin implica un proceso que hace que los errores se muestren pronto. Uno de los valores del desarrollo iterativo es que las iteraciones rpidas permiten a los clientes ver el sistema conforme crece, y si se comete un error en los requerimientos, puede ser localizado y corregido antes de que el costo de la correccin sea prohibitivo. Esta misma localizacin rpida es importante para el diseo. Esto significa que tienes que poner las cosas de modo que las reas potencialmente problemticas sean rpidamente verificadas para ver qu problema sale. Tambin significa que hay que hacer experimentos para ver qu tan difciles pueden ser los cambios futuros, aun si no haces el cambio ahora - efectivamente desechando un prototipo de una rama del sistema. Varios equipos han reportado tratar un cambio futuro en modo prototipo temprano para ver qu tan difcil sera. El Deseo de Disear Aunque me he concentrado mucho en las prcticas tcnicas en este artculo, una cosa que es muy fcil de pasar por alto es el aspecto humano. Para funcionar, el diseo evolutivo necesita una fuerza que lo lleve a converger. Esta fuerza slo puede venir de la gente -alguien en el equipo tiene que tener la determinacin para asegurar que la calidad del diseo permanezca alta. Este deseo no tiene que venir de todos (aunque es bueno si as pasa), usualmente slo una o dos personas en el equipo toman la responsabilidad de mantener el diseo ntegro. Esta es una de las tareas que usualmente caen bajo el trmino 'arquitecto'. Esta responsabilidad significa vigilar el cdigo base, por si cualquier rea del mismo se est enredando, y entonces actuar de inmediato para corregir el problema antes de que se salga de control. El encargado del diseo no tiene que ser el mismo que lo arregla - pero tiene que asegurarse de que alguien lo arregle. La falta del deseo de disear parece ser una razn importante por la que el diseo evolutivo falla. Aun si la gente est familiarizada con las cosas de las que he hablado en este artculo, sin ese deseo no habr diseo. Cosas que son difciles de refactorar Podemos usar la refactoracin para tratar todas las decisiones de diseo, o hay algunos asuntos tan diseminosos que son difciles de aadir despus? Actualmente, la XP ortodoxa dice que todas las cosas son fciles de aadir cuando las necesitas, asi que YAGNI siempre se aplica. Me pregunto si hay excepciones. Un buen ejemplo de algo que es controversial de aadir es la internacionalizacin. Cuesta tanto aadirla despus que deberas empezar con ella desde un principio? Podra fcilmente imaginar que hay algunas cosas que caeran en esta categora. Sin embargo la realidad es que an tenemos muy pocos datos. Si tienes algo que aadir ms tarde, como internacionalizacin, eres muy consciente del esfuerzo que tomar hacerlo. Eres menos consciente del esfuerzo que realmente habra tomado, semana tras semana, ponerlo y mantenerlo antes de que fuera necesario. Tambin ests menos consciente del hecho de que bien podras haberlo puesto mal, y as de todos modos tendras que hacer algo de refactoracin. Parte de la justificacin del YAGNI es que muchas de estas necesidades potenciales terminan no siendo necesarias, o al menos no en el modo que esperabas. El esfuerzo que ahorras no haciendo ninguna de ellas es menor al esfuerzo requerido para refactorar las que realmente necesitas. Otra cuestin a tener en cuenta es si realmente sabes cmo hacerlo. Si has hecho internacionalizacin varias veces, sabes los patrones que necesitas emplear. Como tal es ms probable que lo hagas bien. Aadir estructuras anticipatorias es probablemente mejor si ests en esa posicin, que si eres nuevo en el problema. Mi consejo sera que si sabes cmo hacerlo, ests en la posicin de juzgar el costo de hacerlo o no hacerlo despus. No obstante si no lo has hecho antes, no slo no eres capaz de calcular el costo lo suficientemente bien, es menos probable que lo hagas bien. En ese caso deberas dejarlo para despus. Si lo aades entonces, y lo encuentras doloroso, probablemente an as estars mejor de lo que estaras si lo hubieras instalado antes. Tu equipo es ms
74
experimentado, conoces mejor el dominio y entiendes mejor los requerimientos. A menudo en esta posicin ves lo fcil que hubiera sido con una retrospectiva 20/20. Aadirlo antes puede ser mucho ms difcil de lo que crees. Esto trae a colacin la cuestin del orden de las historias. En Planning, Kent y yo abiertamente manifestamos nuestro desacuerdo. Kent est a favor de dejar que los valores de negocio sean el nico factor de orden de las historias. Despus de un desacuerdo inicial, Ron Jeffries ahora coincide. Yo todava no estoy seguro. Yo creo que hay un balance entre valores de negocio y riesgo tcnico. Esto me llevara a proveer al menos algo de internacionalizacin pronto para mitigar este riesgo. No obstante esto slo es cierto si la internacionalizacin fuera necesaria para la primera entrega. Llegar a la entrega tan rpido como sea posible es vitalmente importante. Cualquier complejidad adicional debe hacerse despus de la primera entrega si no se necesita para la primera entrega. El poder del cdigo empacado y funcionando es enorme. Esto enfoca la atencin del cliente, aumenta la credibilidad y es una fuente masiva de aprendizaje. Haz todo lo que puedas para adelantar esa fecha. An si es ms esfuerzo aadir algo despus de la primera entrega, es mejor entregar antes. Est ocurriendo el diseo? Una de las dificultades del diseo evolutivo es que es muy difcil decir si el diseo est realmente ocurriendo. El peligro de entremezclar diseo con programacin es que puede haber programacin sin diseo - esta es la situacin donde el Diseo Evolutivo diverge y falla. Si ests en el equipo de desarrollo, entonces sabes si el diseo est ocurriendo por la calidad del cdigo base. Si el cdigo base se vuelve ms complejo y difcil de trabajar, no se est haciendo suficiente diseo. Pero este es tristemente un punto de vista subjetivo. No tenemos mtricas confiables que nos permitan medir objetivamente la calidad del diseo. Si esta falta de visibilidad es dura para personas tcnicas, es ms alarmante para miembros del equipo no tcnicos. Si usted es un gerente o cliente cmo puede decir si el software est bien diseado? A usted le interesa porque un software pobremente diseado ser ms caro de modificar en el futuro. No hay una respuesta fcil para esto, pero aqu van unas pocas sugerencias: Escuche a la gente tcnica. Si se quejan de la dificultad de hacer cambios, tome esas quejas seriamente y dles tiempo de arreglar las cosas. Vigile cuanto cdigo se desecha. Un proyecto que hace refactoracin saludable estar constantemente eliminando cdigo malo. Si no se elimina nada, entonces es casi seguro que no se est refactorando lo suficiente - lo cual llevar a la degradacin del diseo. Sin embargo, como cualquier mtrica esta puede ser abusada, la opinin de gente tcnica buena, por subjetiva que sea, triunfa sobre cualquier mtrica. As que ha muerto el diseo? De ninguna manera, pero la naturaleza del diseo ha cambiado. El diseo XP busca las siguientes habilidades: Un deseo constante de mantener el cdigo tan claro y simple como sea posible. Habilidades de refactoracin, de modo que puedas confiadamente hacer mejoras cuando veas la necesidad. Un buen conocimiento de patrones: no slo las soluciones sino tambin apreciar cuando usarlos y cuando evolucionar hacia ellos. Saber cmo comunicar el diseo a la gente que necesita entenderlo, usando cdigo, diagramas y sobre todo conversacin. Esta es una seleccin pusilnime de habilidades, pero siempre ha sido difcil ser un buen diseador. La XP no lo hace realmente ms fcil, al menos para m. Pero creo que la XP nos da una nueva forma de pensar acerca del diseo efectivo porque ha hecho el diseo evolutivo una estrategia plausible otra vez. Y yo soy un gran fan de la evolucin -de otro modo quin sabe qu podra ser yo? Copyright Martin Fowler, all rights reserved
75

Sistemas 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sistemas 2

Uploaded by

Copyright:

Available Formats

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

UNIDAD I: INVESTIGACIN PRELIMINAR

CICLO DE VIDA DE UN SISTEMA

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

UNIDAD II: II: ANLISIS DE REQUERIMIENTOS

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FIGURA: El paradigma de construccin de prototipos.

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FIGURA: Seleccin del enfoque apropiado de creacin de prototipo.

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

UNIDAD III: III: DISEO

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

IMPORTANTE El acoplamiento no debe ser nulo, debe ser mnimo.

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

Mdulo de Interfaz Actualizacin de precios

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FIGURA: El ciclo de evaluacin de diseo de la interfaz.

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

UNIDAD IV: IV: PROGRAMACIN

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FIGURA: Prueba de Unidad.

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FIGURA: Integracin ascendente.

FIGURA: Integracin descendente.

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FACULTAD DE CIENCIA Y TECNOLOGIA - ORO VERDE - 2009

DIEGO SCHUMACHER - RESUMEN TEORIA - SISTEMAS DE INFORMACION II

FIGURA: Proceso de depuracin.