RESUMEN INFORMATICA IV

PUDS FASES: Inicio Elaboracin Construccin Transicin

Flujos de trabajo

Modelado de Negocio Requerimientos Anlisis AyDS

Diseo Implementacin Prueba

Info IV

Cada Flujo se trabajo se describe enunciando: Actividades Artefactos Trabajadores

UNIDAD N 1 MODELO DE DISEO

Modelo de Anlisis: Terminado el modelo se tiene una descripcin detallada de todos los requisitos del sistema. Modelo de Diseo: Constituye una formalizacin y refinamiento adicional al modelo de anlisis. Modelo de objetos representando la realizacin fsica de los casos de uso. Permite conocer especificaciones muy detalladas de todos los objetos, incluyendo operaciones y atributos. Se definirn explcitamente las interfaces de los objetos y la semntica de las operaciones. Se compondr de bloques que constituirn los objetos de diseo, que luego sern implementados como cdigo fuente, abstrayendo la implementacin real. Inicialmente cada objeto de anlisis se transformar en un bloque, teniendo rastreabilidad en los modelos. Es una abstraccin de cmo el sistema se construye realmente y nos permite reducir la complejidad del mismo. Es la ltima parte de la iteracin de elaboracin y comienza la de construccin. Se deben tener definidas las herramientas que se utilizarn en el desarrollo de la aplicacin, ya que muchas cosas se pueden dejar listas y autogenerarlas para el modelo de implementacin. Para desarrollar el modelo de diseo debemos: Identificar el ambiente de implementacin: Identificar e investigar las consecuencias que el ambiente de implementacin tendr sobre el diseo. Incorporar estas conclusiones y desarrollar un primer enfoque del modelo de diseo: Usamos el modelo de anlisis como base y traducimos los objetos de anlisis a objetos de diseo, de acuerdo al ambiente actual de implementacin. 1

 Describir cmo interactan los objetos en cada caso de uso especfico: El modelo de diseo se focaliza en describir todos los estmulos enviados entre objetos y qu operacin har cada uno. Este proceso nos dar las interfases de cada objeto. Rastreabilidad: Se puede rastrear una clase desde el cdigo fuente al anlisis y viceversa. Es importante porque a medida que el sistema tiene cambios a lo largo de su ciclo de vida se necesita saber siempre dnde se deben hacer los cambios en el cdigo fuente.

Artefactos
1.-Clases de diseo: Son abstracciones de clases de implementacin. Muchas caractersticas de las clases tienen relacin directa con el lenguaje de programacin, por eso es necesario tenerlo elegido en esta instancia. Se deben definir para cada clase sus mtodos, atributos, parmetros, tipos, visibilidad de los atributos (pblicos, protegidos, privados, amigos). 2.-Realizacin de casos de uso de diseo: Se vinculan directamente con las realizaciones de casos de uso de anlisis, los cuales se relacionan con casos de uso de modelos de casos de uso (as se traza rastreabilidad a travs de los distintos modelos). Se tienen en cuenta los distintos requerimientos no funcionales que se fueron recolectando. Las realizaciones poseen: descripcin textual del flujo de eventos, diagramas de clases, diagramas de interaccin. Diagramas de clases: Las clases y subsistemas pueden intervenir en ms de un caso de una realizacin de casos de uso. A travs de ellos se pueden tener registrado qu clases intervienen en las realizaciones de los distintos casos de uso.
Interfaz Entrada Botones de Com ando Cuadros de Texto Etiquetas Opciones() Gesto r de person al Entidad de control de pers onal Obtener datos de us uarios () Actualizar datos de us uarios () Im prim ir res ultados () Generar cons ulta de us uarios()

Us uario Nom bre Apellido Direccin Telefono Id Em pleado Ingresar() Borrar() Modificar()

Adm inis trador de s istem a

Interfaz Salida Botones de Comando Etiquetas vis ualizacin() Confirm acin()

Diagramas de interaccin: o Se utilizan Diagramas de secuencia. o En ellos las interacciones entre objetos se representan mediante la transferencia de mensajes entre dichos objetos. o Muestra las interacciones entre objetos ordenadas en secuencia temporal. o Se utilizan para validar casos de uso. o Documentan el diseo desde el punto de vista de los casos de uso observando qu mensajes se envan a los objetos, componentes o casos de uso y viendo grosso modo cunto tiempo consume el mtodo invocado. o Ayudan a comprender los cuellos de botella potenciales para poder eliminarlos. o Conceptos relacionados: Lnea de vida de un objeto (lifeline): Representa la vida del objeto durante la interaccin. Un objeto se representa como una lnea vertical punteada con un rectngulo de encabezado y con rectngulos a travs de la lnea principal que denotan la ejecucin de mtodos (activacin). El rectngulo de encabezado contiene el nombre del objeto y el de su clase en un formato nombreObjeto:nombreClase. Activacin: Muestra el perodo de tiempo en el cual el objeto se encuentra desarrollando alguna operacin. Se denota como un rectngulo delgado sobre la lnea de vida del objeto. Mensaje: Se denota mediante una lnea slida dirigida desde el objeto que emite el mensaje hacia el objeto que lo ejecuta. Tiempos de transicin: En un entorno de objetos concurrentes o de demoras en la recepcin de mensajes es til agregar nombres a los tiempos de salida y de llegada de mensajes.

: Administrador de Interfaz entrada sistema Ingresa opcion Solicita Ingreso Datos Ingresa Datos

Gestor Personal

Usuarios

Interfaz Salida

Datos a chequear Solicita busqueda de Datos Devuelv Datos e Chequea consistencia

Solicita visualizacin de la transaccin Visualiza Transaccin

3.-Subsistema de diseo: Permite organizar y agrupar las clases de diseo de acuerdo a su funcionalidad (har mas manejable el modelo). Debe existir independencia entre los subsistemas para lograr su reutilizacin y a la hora de las modificaciones, ya que los cambios en unos no afectarn a los otros. Subsistema de servicio: prepara al sistema para cambios de servicios individuales.

4.-Interfaz: A travs de ellas se especifican las distintas operaciones que pueden ser realizadas por una clase o los subsistemas. Representan la cara visible de la funcionalidad de una clase. Dentro de una clase, sus atributos y mtodos conformarn la interfaz. Si se cambia el cdigo de un mtodo pero no se cambia ni su nombre, tipo y parmetros, slo se habr cambiado funcionalidad y no su interfaz, por lo cual las clases relacionadas a sta no deberan sufrir ninguna modificacin. Si se agregan parmetros o se cambian tipos, s se debe cambiar la forma en que estas clases se relacionaban. 5.-Descripcin de la arquitectura: Debe estar constituida por: definicin de subsistemas que conforman el modelo de diseo, con sus interfaces, clases de diseo relacionadas directamente con clases de anlisis que conformaban la vista del la arquitectura del modelo de anlisis, 4

 realizaciones de casos de uso relevantes, los cuales tienen una relacin con las realizaciones del modelo de anlisis y con los casos de uso del modelo de casos de uso. 6.-Modelo de despliegue: Permite representar cmo ser la distribucin fsica del sistema, o sea dnde residir fsicamente cada uno de los componentes (clases de interfaz, de control, de entidad). Las ubicaciones fsicas se denominan nodos. Existen relacionen entre ellos representadas por medios de comunicacin: Internet, extranet, intranet. Hay nodos que contienen los componentes asociados a interfaces entre el sistema y los actores (por ejemplo donde residen las distintas pantallas de aplicacin). Otros nodos contienen las clases de control, que residen en los servidores de aplicacin. Hay nodos donde estarn las clases de entidad que luego constituirn los repositorios de datos (BASES DE DATOS).

S e rvid o r d e B a s e d e D a to s

T e rm in a l d e ve n ta s

Te rm in a l d e a d m in is tra c i n

Trabajadores Arquitecto: Responsable de asegurar que el modelo de diseo y de despliegue se correspondan con el modelo de casos de uso y de anlisis. Cuida que sea consistente y que est todo lo significativo para la arquitectura del modelo. Ingeniero de Casos de Uso: Es el encargado de asegurar las realizaciones de casos de uso del modelo de casos de uso y del modelo de anlisis. Cuida los detalles para que cada caso de uso sea comprendido perfectamente y que las relaciones con los casos de uso de los modelos anteriores estn totalmente claras. Ingeniero de componentes: Es el encargado de definir todo lo referido a las clases del diseo y tambin de los subsistemas de diseo. Para las clases define sus mtodos, atributos (interfaz) y las relaciones que existen con otras clases, que relaciones existen con otros subsistemas y de qu forma se relacionan con los otros subsistemas (interfaces). 5

Flujo de Trabajo

Diseo de la arquitectura: Comenzamos en esta etapa a definir los modelos de diseo y de despliegue, utilizamos para ello los siguientes elementos: a. Nodos y sus configuraciones de comunicacin. b. Subsistemas y sus interfaces. c. Clases de diseo relevantes para la arquitectura. d. Mecanismos genricos de diseo. a) Nodos y sus configuraciones de comunicacin: Toda aplicacin est compuesta por tres capas, una encargada de la interfaz con el usuario, otra de almacenamiento de la informacin y una capa intermedia encargada de procesar las reglas y lgica del negocio. Estas capas pueden tener tanto una divisin lgica como fsica: divisin lgica: en la aplicacin se encuentran muy bien divididas las tres funcionalidades de estas capas, divisin fsica: estas capas pueden residir en nodos diferentes. Las primeras aplicaciones, manejaban estas tres capas todas juntas, tanto fsica como lgicamente. El procesamiento se realizaba en las mainframes y los usuarios accedan a l a travs de terminales bobas. Luego aparecieron aplicaciones partidas lgicamente en dos capas: una reside en el servidor y la otra se ejecuta en los clientes.(Modelo cliente- servidor). Existen dos variantes de este modelo: Servidor inteligente: tanto la capa de datos como la de reglas de negocio residen en un servidor llamado DBMS (DataBase Management System). Los clientes cumplen slo la funcin de capa de interfaz, tomando la informacin que los usuarios ingresan al sistema, enviando esto hacia el servidor y mostrando lo que dicho servidor enva hacia el puesto. Cliente inteligente: en este caso el cliente no cumple nicamente la funcin de interfaz con el usuario sino tambin las funciones de la capa intermedia, realizando todos los chequeos y controles necesarios antes de hacer llamadas a la capa de datos. Por ltimo, estn aquellas aplicaciones partidas lgicamente en tres capas (podran estar o no divididas tambin fsicamente.): En estas aplicaciones estn aisladas las tres funcionalidades de una aplicacin: interfaz, control y datos. 6

 Entre las distintas ventajas est la posibilidad de aumentar el rendimiento de la aplicacin a medida que existan ms requerimientos con la misma, ya que la capa intermedia al estar independizada de las otras dos, puede ir residiendo en tantos servidores como vaya siendo necesario y es posible agregar servidores a medida que vaya haciendo falta. Lo mismo sucedera con los servidores de base de batos, donde hay dos variantes de este modelo: Aplicaciones que se ejecutan en cada estacin de trabajo, generalmente realizadas en lenguajes de programacin, como Visual Basic. Aplicaciones que se ejecutan en un servidor web y son accedidas desde las estaciones de trabajo por algn explorador de internet, como Internet Explorer. En el caso de aplicaciones Windows, stas residen en cada equipo y deben estar instaladas en cada equipo. Las aplicaciones Web estn instaladas en servidores web, stos pueden ir creciendo y agregando nuevos servidores a medida que la aplicacin aumente sus requerimientos de rendimiento. En este punto del flujo se analizan los distintos nodos que se utilizarn, con sus caractersticas tcnicas, como las conexiones que existirn entre stos. b) Subsistemas y sus interfaces: Objetivo de subsistema: organizar el modelo de diseo en piezas manejables. A partir de los paquetes de anlisis y de servicios definidos se deben identificar los subsistemas que existen. Si la clase de un subsistema interacta con una clase de otro sistema, se definir una relacin entre estos. Debemos definir la manera en que estas clases se relacionan, es decir las interfaces que permiten que una clase sea accedida.(Ej.: los mtodos que esta expone hacia fuera para que sean invocados por otras clases). c) Clases de diseo relevantes para la arquitectura: Es importante detallar las clases que hay que tener en cuenta para la arquitectura. No debemos analizar un gran nmero de clases ni bajar en un nivel de detalle extremo en ese momento, slo analizar las relevantes para la arquitectura. El anlisis ms fino se har en el diseo de clases y en el de casos de uso. d) Mecanismos genricos de diseo: Se trata de todos aquellos requisitos especiales que fuimos detectando en modelos anteriores y pospusimos hasta tener mejor definidas las caractersticas ms tcnicas del proyecto (plataforma de cada capa, lenguajes, bases de datos). Suelen relacionarse con: Persistencia. Distribucin transparente de objetos locales y remotos. Seguridad. Mono o multiusuario. Manejo de errores. Transacciones. Arquitectura de la aplicacin (una, dos o ms capas lgicas). Tipos de interfaz de usuario (Windows o Web).

Diseo de un caso de uso: 7

ste tiene como objetivos: a) Identificacin de clases de diseo. b) Interacciones entre objetos. c) Identificacin de subsistemas de diseo. d) Interacciones entre subsistemas. a) Identificacin de clases de diseo. Para cada realizacin de caso de uso se recogen todas las clases del diseo que intervienen a travs de un diagrama de clases de diseo. Tomaremos el caso de uso - anlisis con sus clases de anlisis correspondientes y en base a esto y al resto de la informacin recabada hasta el momento para dicho caso detectaremos todas las clases con sus respectivas relaciones. Para cada clase de diseo asignaremos un ingeniero de componentes como responsable de la misma. b) Interacciones entre objetos. Se definen cmo interactan las clases que intervienen en cada realizacin de caso de uso. Se utiliza un diagrama de secuencia que contiene instancias de actores, los objetos de diseo y las transmisiones de mensajes entre estos. Se transforma el diagrama de colaboracin de la realizacin de caso de uso- anlisis en un esbozo inicial del correspondiente diagrama de secuencia. A medida que bajemos en detalle en cada caso podemos encontrar cursos alternativos para los casos como: nodos o conexiones que dejan de funcionar, ingresos errneos de informacin por parte de actores, errores generados por la misma aplicacin o por hardware. c) Identificacin de subsistemas de diseo. Se tomarn los paquetes de anlisis detectados en el modelo de anlisis y adems aquellos requisitos que dejamos para esta etapa de diseo y con esto se delinearn los distintos subsistemas de diseo que intervendrn en el sistema. Se utilizar un diagrama de clases. d) Interacciones entre subsistemas. Para detectar las interacciones que existen entre los distintos subsistemas se utilizarn los diagramas de secuencia. Se reflejan las relaciones entre los actores y subsistemas a travs del envo de mensajes entre los mismos Diseo de una clase: Ya se tiene claro cul ser el rol exacto de cada clase dentro de las distintas realizaciones de casos de uso. Ya se traz la relacin con las clases detectadas en el modelo de anlisis. Pasemos a analizar para cada una de ellas: o operaciones, o atributos, o relaciones, o mtodos, o estados. En el caso de las clases de entidad el anlisis depende de la base de datos a utilizar y en este punto se est en condiciones de normalizar la BD y generar la estructura que se utilizar en la aplicacin. En las clases de interfaz el diseo de las mismas est muy ligado al lenguaje de programacin que se utilizar. a) Operaciones 8

 Las responsabilidades detectadas en las clases de anlisis implican una o varias operaciones para las clases de diseo. Deben cubrir todas las operaciones que sean necesarias en todas las realizaciones de casos de uso - diseo en los que las mismas participen. Es necesario describir, utilizando la sintaxis del lenguaje de programacin, la visibilidad de cada operacin (publica, privada, protegida). b) Atributos Debemos identificar en detalle los distintos atributos o propiedades de cada clase en la sintaxis del lenguaje de programacin. Se deben identificar los tipos de cada atributo, que dependern del lenguaje elegido. c) Relaciones Se deben dejar muy bien reflejados los distintos tipos de relaciones que existan entre las clases de diseo. Una entrada para esto son los diagramas de interaccin (colaboracin y secuencia) ya que en stos se manifiestan las relaciones y los envos de mensajes entre las distintas clases. En cuanto a las generalizaciones (o herencia) depender si el lenguaje que estemos utilizando la soporte o no, en este ltimo caso tendremos que reemplazar esto por la duplicidad de funcionalidades y caractersticas en aquellos objetos comunes. d) Mtodos stos especifican cmo se realizan las distintas operaciones, es recomendable utilizar lenguaje en pseudo cdigo y siempre teniendo en cuenta el lenguaje de programacin que utilicemos. e) Estados Con el objeto de agregar mayor detalle para la implementacin de la clase podemos reflejar los estados por los que puede pasar una clase. En muchos casos suele ser importante utilizar diagramas de estados a travs de los cuales podemos reflejar su comportamiento cuando reciben un mensaje. Diagrama de estados Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicacin junto con los cambios que permiten pasar de un estado a otro. Estado: Identifica un periodo de tiempo del objeto -no instantneo- en el cual l est esperando alguna operacin, tiene cierto estado caracterstico o puede recibir determinado tipo de estmulos. Se representa mediante un rectngulo con los bordes redondeados que puede tener tres compartimientos: uno para el nombre, otro para el valor caracterstico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry, exit o do respectivamente).

Eventos Es una ocurrencia que puede causar la transicin de un objeto de un estado a otro. El nombre de un evento tiene alcance dentro del paquete en el cual est definido, no es local a la clase que lo nombre. Envo de mensajes Puede representarse el momento en el cual se envan mensajes a otros objetos. Esto se realiza mediante una lnea punteada dirigida al diagrama de estados del objeto receptor del mensaje. 9

Diseo de un subsistema: Los puntos clave a tener en cuenta son: independencia entre subsistemas, mantener interfaces y sus operaciones, asegurar que el subsistema cumple con su objetivo en las distintas realizaciones en las que est involucrado.

Caso Prctico
1.- Diagrama de casos de uso Los casos de uso especifican una interaccin entre un usuario y el sistema en el que ste puede lograr un objetivo. Casos de uso para agencia de alquiler de autos: El cliente reserva el vehculo Antes de disponer del vehculo el cliente debe hacer la reserva. Para ello se pone en contacto con la agencia de alquiler y realiza una solicitud. La agencia la acepta o la rechaza basndose en una serie de criterios, como por ejemplo la disponibilidad de los vehculos o el historial de alquiler del solicitante. Si se acepta la reserva el comercio llena un formulario con los detalles del cliente y el pago del depsito completa el proceso de reserva. El cliente acude por el vehculo Cuando el cliente llega a la agencia de vehculos sta le asigna el modelo de vehculo solicitado segn los niveles de stock disponibles. Una vez abonado el importe total el cliente recibe el automvil. El cliente devuelve el vehculo El cliente devuelve el vehculo a la agencia el da especificado en el acuerdo de alquiler.

2.-Diagrama de clases de estructura esttica La siguiente tarea consiste en clasificar los objetos y sus relaciones. Examinar los casos de uso ayuda a identificar las clases. Las clases de objetos se modelan utilizando diagramas de estructura esttica o de clases que muestran la estructura general del sistema, as como las propiedades relacionales y de comportamiento.

10

3.- Diagrama de secuencia Proporcionan una vista detallada de un caso de uso. Muestran una interaccin organizada en una secuencia de tiempo y ayuda a documentar el flujo de lgica dentro de la aplicacin. Los participantes se muestran en el contexto de los mensajes que se transfieren entre ellos.

4.-Diagrama de colaboracin Los diagramas de colaboracin constituyen otro tipo de diagrama de interaccin. Muestran cmo operan los objetos de un grupo entre s en un caso de uso. A cada mensaje se le asigna un nmero para documentar el orden en el que tiene lugar.

11

5.-Diagrama de estados El estado de un objeto se define como sus atributos en un momento determinado. Los objetos van pasando por distintos estados a medida que se ven influenciados por estmulos externos. El diagrama de estados asigna estos estados, as como los eventos de activacin que hacen que un objeto se encuentre en un estado determinado.

6.-Diagrama de actividades Los diagramas de actividades muestran la lgica que tiene lugar como respuesta a las acciones generadas internamente. Est relacionado con una clase o caso de uso especfico y muestra los pasos que se deben realizar para llevar a cabo una operacin determinada.

12

7.-Diagrama de despliegue Muestran cmo estn configurados el hardware y el software del sistema.

8.-Diagrama de componentes Corresponden al modelo de implementacin. Muestran cmo distintos subsistemas de software conforman la estructura general del sistema que se crea en una base de datos centralizada que contiene registros de alquileres anteriores, detalles del vehculo, registros de servicios y detalles del cliente y del empleado. Resulta esencial que estos datos se centralicen en una base de datos porque los niveles de stock varan con las horas y todas las partes deben disponer de informacin de ltima hora. El mantenimiento de los datos actualizados requiere actualizaciones de la informacin en tiempo real de todas las partes.

13

UNIDAD N2 MODELO DE IMPLEMENTACION

Modelo de Implementacin: Busca implementar cada objeto especfico en trminos de componentes (scripts, archivos
de cdigo binario ejecutables-,etc.). Son herramientas fundamentales los lenguajes de programacin y las libreras. Se toman los resultados del diseo para convertirlos en un software ejecutable; un sistema que integra componentes expresados en archivos fuentes, ejecutables, cdigo binario y similares dndole comportamiento concreto al modelo. La implementacin es el proceso protagonista durante las iteraciones de la fase de construccin. Observe que tambin se desarrolla trabajo de implementacin durante las fases de elaboracin y transicin. Generalmente en estos casos, las actividades de implementacin dan soporte a los flujos de anlisis y diseo mediante prototipos; y la correccin de errores empotrados en el cdigo, respectivamente. Los propsitos de este flujo de trabajo son los siguientes: Planificar en pasos pequeos y manejables (enfoque incremental) las integraciones de sistema necesarias en cada iteracin. Definir la organizacin que tendr el cdigo en trminos de subsistemas y capas de proceso, mostrando la asignacin de componentes ejecutables a nodos del diagrama de despliegue. Implementar clases y objetos en trminos de componentes (archivos de cdigo fuente, archivos binarios, archivos ejecutables, etc.), mostrando la asignacin y distribucin de los mismos en un diagrama de componentes. Probar los componentes individuales implementados, compilando e integrndolos en uno o ms ejecutables libres de errores. Integrar los resultados producidos por desarrolladores individuales o equipos en un sistema ejecutable. Relacin con otros flujos de trabajo Algunas vinculaciones entre el flujo de trabajo implementacin y los dems flujos de trabajo: Todo el proceso de desarrollo propuesto por el PUD est conducido por casos de uso. En este flujo de trabajo se producen modelos que realizan y tienen una traza definida hacia el modelo de casos de uso obtenido en el flujo requerimientos. Los artefactos producidos durante los flujos de trabajo anlisis y diseo son una entrada primaria para el proceso desarrollado durante este flujo de trabajo. En el flujo de trabajo pruebas se definen los casos de prueba que sern incluidos durante cada una de las integraciones de subsistemas y sistemas que acontecen durante este flujo de trabajo. 2.1. Implementar el diseo Cada clase del diseo es implementada codificando en un lenguaje de programacin, o utilizando un componente preexistente. Por eso la manera en que una clase del diseo ser concretamente implementada depende del lenguaje utilizado. El modelo de diseo puede ser ms o menos ajustado al modelo de implementacin dependiendo de cmo haga corresponder las clases o construcciones similares en el lenguaje de implementacin elegido. Es necesario disponer antes de que el diseo comience, la forma en que las clases en el modelo de diseo se relacionan con las clases de implementacin asentando esta decisin en la Gua de Diseo. 2.2. Las pruebas de desarrollo La frase Prueba de Desarrollo es utilizada para categorizar las actividades de prueba ejecutadas por los arquitectos, ingenieros de componentes, programadores o desarrolladores de software. En muchos de los mtodos tradicionales se consideran los siguientes tipos de pruebas: Pruebas de unidad: prueba de cada componente individual

14

 Pruebas de integracin: prueba de funcionamiento de subsistemas Pruebas de Sistema: prueba de funcionamiento del sistema como un todo. Esta categorizacin es correcta, sin embargo el problema surge cuando se decide integrar los subsistemas y el sistema total cuando casi se ha concluido la codificacin de los componentes y se definen equipos de pruebas que actuarn por etapas. Puede ser muy tarde, los errores podran propagarse sin ser detectados por los diferentes equipos de prueba. Las fallas descubiertas podran develar graves problemas de diseo y generar un alto grado de retrabajo no deseable para los costos y oportunidad de entrega del producto final. No espere terminar todos los componentes para integrar subsistemas y el sistema final. Lo que sera peor an, no deje las pruebas de componentes para el final de la fase de construccin. En cada iteracin, de la fase construccin, en cada construccin, an en la fase de elaboracin, haga pruebas de integracin y pruebas de sistema. 2.3. Entornos de desarrollo e integracin Un sistema generalmente es implementado por equipos de desarrolladores o programadores individuales que trabajan juntos y en paralelo. Para que esto sea posible son necesarios los siguientes espacios o entornos de trabajo: Un entorno de desarrollo individual para cada programador: A los efectos de editar, compilar, ejecutar y probar todos los componentes y el subsistema asignado, cada programador tendr un entorno de trabajo individual. No es necesario que en este espacio el desarrollador disponga de los dems subsistemas sobre los cuales no tiene responsabilidad. Es recomendable por otra parte que cada programador tenga acceso mediante un repositorio comn desde donde acceder a otros subsistemas y libreras de uso compartido. o Un entorno de integracin de subsistemas para el grupo de desarrollo: A veces equipos de implementadores desarrollan simultneamente sobre el mismo subsistema. En este caso los primeros necesitan integrar sus componentes en un subsistema antes de que el mismo pueda ser liberado para su integracin al sistema total. Un miembro del equipo de desarrollo acta como integrador, siendo su responsabilidad tambin su mantenimiento y rendimiento. o Un entorno de integracin del sistema total: Quin o quines cumplan con el rol de integrador debern contar con un entorno de integracin del sistema total en el que puedan agregar los componentes individuales y/o subsistemas que resultaran al cabo de cada iteracin en una Construccin.

Flujo de trabajo de implementacin

Estructurar el Modelo de Implementacin es la primera actividad desarrollada en el marco de la Implementacin.

15

Los flujos: requerimientos, anlisis y diseo ocurren con preeminencia en la Fase de Elaboracin. En esa etapa comenzamos a dar forma al Modelo de Implementacin. En cada iteracin, y en la medida en que avanzamos hacia la fase de Construccin donde subsisten declinando su incidencia actividades de requerimientos, anlisis y diseo- toman mayor protagonismo las de: Estructuracin del Modelo de Implementacin, Planeamiento de la Integracin, Implementacin de Componentes, Integracin de los Subsistemas y el Sistema como un todo.

Actividades

3.1. Estructurar el modelo de implementacin

El propsito del flujo de trabajo Estructurar el Modelo de Implementacin es: Identificar los componentes significativos arquitectnicamente (ejecutables). Asignar componentes a los nodos de red. El propsito de esta actividad desarrollada por el arquitecto de software es establecer la arquitectura en la que se apoyar la implementacin y la asignacin de responsabilidades para subsistemas de implementacin y sus respectivos componentes. Un modelo de implementacin bien organizado resulta en la ocurrencia de un nmero menor de conflictos durante el desarrollo de componentes y el proceso de construccin; tambin previene problemas de configuracin y facilita las sucesivas integraciones de componentes y subsistemas. Trabajadores Quien cumpla con el rol de arquitecto de software es quien tiene la principal responsabilidad en la definicin de Modelo de Implementacin. La naturaleza del trabajo a desarrollar sugiere que la o las personas que administran esta actividad posean experiencia en la construccin, administracin de la configuracin y el lenguaje de programacin que se utilizar para implementar el sistema.

16

Lineamientos de Trabajo

Estructurar el modelo de implementacin es algo que debemos hacer en paralelo con la evolucin de otros aspectos de la arquitectura.

pasos:

La actividad Estructurar el Modelo de Implementacin a su vez contempla los siguientes Crear el modelo de implementacin inicial Ajustar los subsistemas de implementacin Definir los imports referencias a otros componentes - necesarios para cada subsistema. Decidir cmo tratar los ejecutables. Decidir cmo tratar los elementos de prueba. Actualizar la vista de implementacin.

Crear el modelo de implementacin inicial

La primera versin del modelo de implementacin se obtiene como una copia espejada de
la ltima versin del Modelo de Diseo. Los paquetes de diseo se expresan como subsistemas compuestos a su vez de componentes y todos los archivos relacionados necesarios para implementarlos. Considere que cada clase del diseo ser un componente implementado codificando en un lenguaje de programacin o empleando un componente preexistente. La manera en que una clase del diseo ser concretamente implementada depender del lenguaje utilizado.
Ajustar los subsistemas de implementacin

El propsito de este paso es adaptar la estructura del modelo de implementacin a cuestiones tcticas relacionadas con el entorno de trabajo. Estas adaptaciones facilitan la organizacin del equipo de trabajo y debe expresar, si hubiera, las restricciones del lenguaje de programacin a utilizar.

Definir imports necesarios para cada subsistema

El objeto aqu es definir las dependencias y visibilidad de componentes entre subsistemas o mdulos. Generalmente, las dependencias en el modelo de implementacin son heredadas del modelo de Diseo, excepto cuando la estructura del modelo de implementacin ha sido ajustada. Se presenta la estructura de capas de los subsistemas en diagramas de componentes.

Decidir cmo tratar ejecutables

Los ejecutables y otros objetos derivados son el resultado de aplicar un proceso de construccin sobre un subsistema de implementacin, y pertenecen lgicamente a dicho subsistema. En el caso ms simple, para cada subsistema de implementacin habr un tem de configuracin (nodo de la red) para cada ejecutable, y un tem de configuracin para contener los fuentes y otros elementos utilizados para producirlo. Desde el punto de vista del modelado, un conjunto de ejecutables producidos en un proceso de construccin puede ser representado como un artefacto: el artefacto Construccin asociado a un subsistema de implementacin dado.

Decidir cmo tratar los elementos de prueba

En general los componentes y subsistemas de prueba no son tratados en forma muy diferente al del resto del software desarrollado. Sin embargo, los componentes y subsistemas de prueba no forman parte del sistema implantado, y por lo general no se entregan al cliente. Por lo tanto la recomendacin es aislar estos componentes en una estructura de directorio o paquete, garantizando su visibilidad; pero facilitando su eliminacin al momento de construir la versin operativa del software.

Actualizar la vista de implementacin

Este paso consiste bsicamente en la actualizacin del documento de Arquitectura de Software y los diagramas correspondientes al modelo de implementacin. 3.2. Planear la integracin En la planificacin de la integracin se consideran los subsistemas que sern implementados as como otros subsistemas existentes que sern integrados en la iteracin corriente.

17


Trabajadores

El propsito del flujo de trabajo Planear la Integracin es por lo tanto: Planear la integracin del sistema para la actual iteracin. La integracin es hecha habitualmente por una persona o un pequeo equipo. Los integradores necesitan experiencia en la gestin de construcciones y configuraciones de software; pero fundamentalmente se requiere que los mismos posean un fluido manejo del lenguaje de programacin sobre el cual se desarrollaran los componentes. Debido a que a menudo la integracin se desarrolla con un alto grado de automatizacin, se requiere tambin conocimientos en sistemas operativos, interpretes de comandos y herramientas.

Lineamientos de Trabajo

Identificar Subsistemas

La planificacin de la integracin debe ser hecha tempranamente, al menos de modo rudimentario cuando se define la arquitectura. Con el objeto de evitar que el plan de construccin quede obsoleto, este debe ser actualizado cada vez que sucedan modificaciones en la arquitectura y el diseo. Al menos una vez por cada iteracin en las fases de construccin y transicin, quien cumple con el rol de integrador, desarrolla esta actividad que tiene como objetivo principal el de planear el modo en que han integrarse cada componente y cada subsistema en el sistema que se construye. Los siguientes son los pasos que comprenden esta actividad: Identificar subsistemas Definir conjuntos de construccin Definir series de construccin.

El plan de la iteracin identifica y especifica los subsistemas con sus respectivos casos de
usos y escenarios a ser implementados. En el plan se analizan tambin las realizaciones de casos de uso, diagramas de secuencia y colaboracin. Se identifican tambin otros subsistemas necesarios para facilitar la compilacin y crear una versin ejecutable del software.
Definir conjuntos de construccin

Para facilitar las cosas y manejar la complejidad se reduce el nmero de cosas sobre las que es necesario pensar. En esta situacin es recomendable definir conjuntos significativos de subsistemas que funcionan juntos y pueden considerarse como una unidad desde el punto de vista de una integracin.

Definir series de construccin

Se define una serie de construcciones para integrar el sistema incrementalmente. Esto es hecho de abajo hacia arriba en la estructura de capas del sistema que compone el modelo de implementacin. Por cada construccin, se definen cuales subsistemas deben ir en el y que otros subsistemas deben estar disponibles en calidad de stubs componentes de utilidad para facilitar su implementacin -. 3.3. Implementar componentes Los implementadores escriben cdigo fuente, adaptan cdigo existente, compilan y ejecutan pruebas de unidad de componentes, generando re trabajo para el diseador en caso de detectarse errores atribuibles al mismo. Los implementadores tambin corrigen defectos y vuelven a ejecutar pruebas de unidad para verificar cambios. Finalmente el cdigo es revisado para evaluar calidad y cumplimiento de las reglas que podran estar previstas en una gua de programacin. El objeto principal del flujo de trabajo Implementar Componentes consiste en Producir componentes de software ajustado a los requerimientos y libre de errores.

Trabajadores

La actividad de programacin normalmente es desarrollada por una persona, sin embargo propuestas metodolgicas actuales como XP Xtreme Programming- estn proponiendo que la codificacin de cada componente sea realizada de a pares de programadores.

18

Recordar que las personas que cumplan este rol deben manejar fluidamente el lenguaje de programacin adoptado.

Lineamientos de trabajo

La actividad de revisin es recomendable que la lleven a cabo pequeos equipos de dos o tres personas que podran incluir miembros del rea usuaria y programadores experimentados. Este trabajo tiene mejores resultados si se realiza en varias etapas, cada una enfocada en pequeas secciones del cdigo. Son ms productivas las revisiones frecuentes con un alcance acotado. En estas sesiones se identifican los problemas especficos que necesitan ser resueltos. Las correcciones se implementan al terminar la revisin. El propsito principal de esta actividad es producir nuevo cdigo fuente o modificar el existente de acuerdo a las especificaciones del modelo de diseo. La actividad implementar componente a su vez contempla los siguientes pasos: Implementar operaciones Implementar Estados Delegar para reutilizar Implementar asociaciones Implementar atributos Hacer la revisin preliminar del cdigo.

Implementar operaciones

Para implementar operaciones hacemos lo siguiente: Elegimos un algoritmo Elegimos una estructura de datos apropiada para el algoritmo Definimos nuevas clases y operaciones de ser necesario Codificamos la operacin Eleccin de un algoritmo: muchas operaciones son lo suficientemente simples para ser implementadas directamente desde la especificacin de las mismas. En otros casos podra requerir un algoritmo no trivial por alguna de las siguientes razones: o Intentamos implementar operaciones complejas o Queremos optimizar operaciones simples pero resueltas de modo ineficiente. Por ejemplo, un componente que debe ordenar los elementos de una lista; por razones de perfomance, podramos optar entre escribir nuestro propio algoritmo (burbuja, shell, dicotmicos, etc.) o el provisto por el lenguaje de implementacin. Eleccin de una estructura de datos apropiada para el algoritmo: la implementacin de la estructura de datos para implementar el algoritmo va a depender del lenguaje elegido y podra recaer en alguna de las siguientes: arrays, lists, queues, stacks, bags o variaciones de estas. La mayora de los lenguajes orientados a objetos proveen libreras de componentes reusables con estos tipos. Definicin de nuevas clases y operaciones: esto sucede cuando necesitamos nuevas clases que mantengan resultados intermedios. Por ejemplo, al descomponer una operacin compleja en dos operaciones ms simples. Estas operaciones sern privadas y visibles por lo tanto solo en el contexto de la misma y no fuera de ella. Codificar la operacin: escribimos el cdigo para la operacin empezando por las sentencias que definen su interfase. Por ejemplo, la declaracin de funcin miembro en C++, especificacin de subprogramas en Ada, mtodos en Visual Basic o Java.
Implementar estados

La manera ms sencilla de implementar el estado de un objeto es por referencia a los valores de sus atributos sin ninguna representacin especial. La transicin de estados para un objeto estar implcita en los cambios de valor de los atributos y las variaciones de comportamiento que sern programadas a travs de sentencias condicionales. Esta solucin no ser satisfactoria para comportamientos complejos debido a la dificultad implicada en una eventual modificacin del comportamiento la necesidad de nuevos estados. Si el comportamiento de los componentes es estado dependiente, podran ser necesarios diagramas de transicin de estados que describan su comportamiento, faciliten su interpretacin y posterior codificacin.

Delegar para reutilizar

19

Si una clase o parte de una clase puede ser implementada reutilizando una clase existente, se usa el mecanismo de delegacin en lugar de la herencia. Delegacin significa que la clase es implementada con la ayuda de otra clase. La clase referencia un objeto de otra clase utilizando una variable. Cuando una operacin es llamada, la operacin llama una operacin del objeto referenciado -de la clase reutilizada-. Recuerde que en un buen diseo de objetos, estos son bastante haraganes. Estn buscando todo el tiempo delegar la responsabilidad a un especialista para que haga lo que a l se le ha pedido.

Implementar asociaciones

Una asociacin unidireccional es implementada como un puntero -un atributo que contiene una referencia a un objeto-. Si la cardinalidad destino fuera uno, entonces esta puede ser definida como un puntero simple. En cambio si la cardinalidad destino es muchos, entonces debe ser tratada como un conjunto de punteros. Una asociacin bidireccional es materializada como atributos en ambas clases procediendo del mismo modo que se indic para asociaciones unidireccionales. En cada lenguaje de programacin en particular podr descubrir mecanismos de asociacin propios del entorno que se utiliza.

Implementar atributos

Existen tres maneras de implementar atributos: A travs de variables primitivas incluidas en el lenguaje Reutilizando una clase o componente existente Por medio de una nueva clase. Definir una nueva clase es a menudo ms flexible, pero tenga en cuenta que introduce una indireccin innecesaria. Por ejemplo, el nmero de seguridad social de un empleado podra ser implementado como un atributo de tipo String o como una nueva clase. Podra darse tambin el caso que grupos de atributos se combinen en dos nuevas clases tal como se muestra en el ejemplo siguiente donde ambas implementaciones son correctas:

Hacer la revisin preliminar del cdigo

Siempre se compila el cdigo, y se fija al mximo nivel de detalle los avisos del compilador. Se controla mentalmente las operaciones, recorriendo el cdigo tratando de encontrar todos los caminos e identificando todas las condiciones de excepcin. Esto se lleva a cabo tan pronto como se pueda despus de implementar algo nuevo. Si fuera posible, se utiliza herramientas automticas de revisin. 3.4. Integrar cada Subsistema Si ms de un implementador trabaja en la construccin del mismo subsistema, es necesario crear regularmente una nueva versin consistente del subsistema para que en la misma se integren los cambios producidos por cada desarrollador individual. El resultado de estas integraciones es alojado en el entorno de integracin de subsistemas referido en el punto 2.3. Una vez en este entorno de integracin cada construccin es probada, luego de lo cual, y habiendo superado los requerimientos de calidad preestablecidos, la nueva versin del subsistema pasa al entorno de integracin del sistema total. Entonces el propsito de este flujo de trabajo es: Integrar los cambios producidos por mltiples desarrolladores, creando una nueva versin de un subsistema de implementacin. Trabajadores La integracin de cada subsistema es hecha habitualmente por una persona o un pequeo equipo. Los integradores necesitan experiencia en la gestin de construcciones y configuraciones de software; pero fundamentalmente se requiere que los mismos posean un fluido manejo del lenguaje de programacin sobre el cual se desarrollaran los componentes. Debido a que a menudo la

20

integracin se desarrolla con un alto grado de automatizacin, se requiere tambin conocimientos en sistemas operativos, interpretes de comandos y herramientas. Lineamientos de Trabajo El trabajo de integracin tiene habitualmente un alto grado de automatizacin con esfuerzo manual requerido solo cuando la construccin falla por alguna circunstancia. Una estrategia frecuente es programar construcciones y pruebas de unidad mediante procesos automticos que se ejecuten durante la noche. 3.5. Integrar el sistema Siguiendo el plan de integracin de construcciones se agrega e integra cada subsistema en el entorno de trabajo del sistema. De este modo se obtiene una nueva versin del software que es sometida al flujo de trabajo de pruebas. El propsito entonces de este flujo de trabajo es: o Integrar subsistemas de implementacin para crear una nueva versin consistente del sistema total.
Trabajadores

Rige lo mismo que en el item anterior. Rige lo mismo que en el item anterior.

Lineamientos de Trabajo

4.4 Ejecucin de pruebas unitarias El propsito principal de esta actividad es verificar la especificacin y la estructura interna de una clase o del componente que lo implementa. Los pasos principales de esta actividad son los siguientes: Ejecutar pruebas unitarias Evaluar la ejecucin de pruebas Verificar resultados de pruebas Recuperar a partir de pruebas suspendidas
Ejecutar pruebas unitarias

Este paso consiste en la ejecucin de procedimientos de prueba o scripts si las pruebas son automatizadas. El procedimiento mencionado consiste bsicamente en: Establecer el entorno de prueba para asegurar que todos los elementos necesarios tales como hardware, software, herramientas, datos, libreras, etc. han sido previstos. Inicializar el entorno de prueba para asegurar que todos los componentes estn en el estado inicial correcto para el inicio de la prueba. Ejecutar los procedimientos de pruebas. La ejecucin de los procedimientos de prueba varan, lo cual depende tanto de si el mismo es automtico, manual como de la necesidad de componentes Stubs y drivers especficos. Pruebas automatizadas: se ejecutan los scripts creados durante el paso Implementar Pruebas del Subflujo Implementar Componentes. Pruebas Manuales: se utilizan los procedimientos desarrollados durante la actividad Estructurar Procedimientos de Pruebas que son usados para ejecutar manualmente la prueba.

Evaluar la ejecucin de pruebas

Este paso tiene el propsito de determinar si las pruebas concluyeron con xito, y tener una visin clara de la accin correctiva requerida. La ejecucin de las pruebas termina en alguna de las siguientes condiciones. Normal: todos los procedimientos de pruebas (o scripts) se ejecutaron como se proyect. Si la prueba termina en condicin normal, entonces se debe continuar con la Verificacin de Resultados de Pruebas. Anormal o prematuro: los procedimientos de pruebas o scripts no se ejecutaron completamente como se haba previsto. Cuando la prueba termina de modo anormal los resultados de la prueba pueden ser poco fiables. Hay que identificar la causa del error, corregirlo y re ejecutar el test.

21

Si la prueba termina de modo anormal, se debe retomar en el paso Recuperacin a partir de pruebas suspendidas.
Verificar resultados de pruebas

El propsito de este paso es determinar si el resultado de la prueba es confiable e identificar las acciones correctivas si los resultados indican fallas. Cuando la prueba termina, se revisan los resultados para asegurar que los mismos son confiables, que las advertencias de compilacin (warnings), o resultados inesperados, no han sido ocasionados por influencias externas tales como una inicializacin o datos incorrectos. Si las fallas reportadas se deben a errores identificados en artefactos de prueba o debido a problemas con el entorno de prueba, se toman las acciones correctivas apropiadas y se ejecuta la prueba nuevamente. Si los resultados indican que las fallas son genuinamente atribuibles a los artefactos probados entonces se contina con la actividad Corregir Errores.

Recuperar a partir de parada de pruebas

En este caso la meta ser determinar las acciones correctivas apropiadas para reiniciar una prueba detenida, corregir el problema, recuperar y ejecutar la prueba nuevamente. Esta parada puede deberse a fallas en los scripts utilizados para lanzar pruebas, en fallas del sistema tales como cadas de red, cadas de hardware, etc. En todos estos casos los sntomas son parecidos: acciones inesperadas, ventanas emergentes y eventos no previstos. El entorno de prueba parece no responder y hasta podra colgarse el sistema. Para recuperar a partir de una situacin como sta debera: Determinar la causa real del problema. Corregir el problema. Inicializar el entorno de pruebas nuevamente. Ejecutar las pruebas nuevamente. 4.5 Corregir defectos El propsito principal de esta actividad es implementar las correcciones al cdigo documentadas en el documento de requerimientos de cambios durante las actividades de pruebas unitarias de componentes y revisiones de cdigo. Los pasos principales de esta actividad son: Estabilizar el defecto. Localizar la falla. Corregir la falla. Estabilizar el defecto Este es el primer paso, exteriorizado como un sntoma del programa, forzando su ocurrencia en forma efectiva. Si no se puede lograr que el error suceda efectivamente, estamos ante complicaciones y ser mucho ms difcil localizarlo. Luego se limita el caso de prueba identificando cul de los factores del caso de prueba hacen que el error ocurra, y cuales factores son irrelevantes al mismo. Para determinar si un factor es irrelevante, se cambia el factor en cuestin y ejecuta el caso de prueba; si el error an as ocurre, este factor puede ser probablemente eliminado. Si se logr, se finaliza con al menos un caso de prueba que reproduce el error y tambin con alguna idea sobre que factores estn relacionados con la ocurrencia del error. Localizar la falla El prximo paso es ejecutar los casos de prueba que originan la falla e intentar identificar el lugar concreto del cdigo donde se produce el fallo. Ejemplos de cmo localizar una falla son: Ponga atencin a la regin sospechosa del cdigo. Pruebe una pequea parte de l, comente para que no se ejecute la o las sentencias que supone producen el error y corra nuevamente el caso de prueba. Contine comentando pedazos del programa mientras el error persista. Como resultado se podr identificar el lugar preciso donde se produce la falla. Utilice un debugger herramienta provista por un entorno de desarrollo de un lenguaje de programacin para localizar un error para revisar el cdigo lnea por lnea y monitorear los valores de variables significativas del programa. Corregir la falla

22

 Cuando la falla ha sido localizada es momento de corregir el cdigo. Esta debiera ser la parte ms fcil del proceso. Las siguientes son algunas recomendaciones para hacer efectiva la correccin:
Asegrese de comprender el problema y el programa antes de efectuar la correccin. Corrija el problema, no el sntoma. Haga un cambio a la vez. Corregir errores es en si misma una actividad propensa a incluir nuevos errores. Introduzca los cambios incrementalmente para facilitar la localizacin de nuevas fallas. Cuando la falla ha sido corregida agregue un caso de prueba especial que verifique particularmente el error. 5. Artefactos 5.1 Modelo de implementacin El modelo de implementacin describe la forma en que los elementos del modelo de diseo, como las clases, se implementan en trminos de componentes, como archivos de cdigo fuente, ejecutables, etc. Describe tambin cmo se organizan los componentes de acuerdo con los mecanismos de estructuracin y arquitectura de mdulos disponibles en el entorno de implementacin y en el leguaje lenguajes de programacin utilizados, y cmo dependen los componentes unos de otros. 5.2 Construccin Una Construccin es una versin operativa de parte o de un sistema completo que demuestra un subconjunto de capacidades o funcionalidades propias del producto final. Es una expresin concreta y resultante del ciclo de vida iterativo. Representa y demuestran la funcionalidad desarrollada a la fecha. Cada Construccin es puesta bajo el mecanismo de control de configuracin con el objeto de retornar eventualmente a versiones previas cuando el agregado de funcionalidad ocasiona problemas de funcionamiento o compromete la integridad y estabilidad del sistema. Durante el desarrollo iterativo del software podr haber numerosas construcciones. Cada una proveer puntos de revisin y ayudar a descubrir problemas de integracin en la medida que los mismos han sido introducidos. 5.3 Componente Un componente es el empaquetamiento fsico de los elementos de un modelo, como son las clases en el modelo de diseo. Algunos estereotipos estndar de componentes son los siguientes: <<Ejecutable>>: es un programa que puede ser ejecutado en un nodo. <<File>>: es un archivo que contiene cdigo fuente o datos. <<Library>>: es una librera esttica o dinmica. (dlls) <<Tabla>>: es una tabla de base de datos. <<Documento>>: es un documento. Durante la creacin de componentes en un entorno de implementacin particular estos estereotipos pueden ser modificados para reflejar el significado real de estos. Los componentes tienen las siguientes caractersticas: Relacin de traza con los elementos del modelo que implementan. Implementacin de varios elementos. Por ejemplo, un componente podra implementar varias clases, sin embargo, la forma exacta en que se crea esta traza depende de cmo van a ser estructurados y armados en mdulos los archivos de cdigo fuente, dado el lenguaje de programacin que se est utilizando. 5.4 Stubs Un componente es probado remitiendo mensajes a su interfase, esperando que este lo procese y revisando el resultado. En el transcurso de este proceso, muy habitualmente, se utilizan otros componentes enviando tambin mensajes y utilizando sus resultados. Estos ltimos componentes pueden ocasionar problemas a la prueba: Por no haber sido an implementados. Por tener errores de funcionamiento, ocasionando confusin sobre el origen de los problemas.

23

Porque uno o ms componentes de hardware podran no estar disponibles para el programador. Piense por ejemplo en un sistema de control de accesos en el que los dispositivos de lectura de las tarjetas magnticas o mecanismos de apertura de puertas podran no disponerse por los programadores. Debido a que la prueba podra tornarse muy lenta cuando por ejemplo necesita inicializar una base de datos. Ya que es muy difcil provocar ciertos resultados. Piense por ejemplo que todos los mtodos de sus clases que escriben en disco validan previamente el espacio disponible. Ocasionar la situacin Sin espacio en disco podra ser una tarea bastante engorrosa. Para evitar estos problemas utilizamos los componentes Stubs, los cuales se comportan como si fueran los componentes reales, al menos para los valores o mensajes que su componente enva al momento de la prueba. Con una perspectiva ms amplia podramos considerar en esta categora a emuladores que simulan el comportamiento real de otros componentes no disponibles. 5.5. Subsistema de implementacin Los subsistemas de implementacin proporcionan una forma de organizar los artefactos del modelo de implementacin en trozos ms manejables. Un subsistema puede estar formado por componentes, interfaces y otros subsistemas, inclusive en forma recursiva. Adems, un subsistema puede implementar -y as proporcionar- las interfases que representan la funcionalidad que exportan en forma de operaciones. Los subsistemas de implementacin estn muy relacionados con los subsistemas de diseo en el modelo de diseo visto anteriormente. De hecho, los subsistemas de implementacin deberan seguir la traza uno a uno de sus subsistemas de diseo correspondientes.

5.6 Interfases Las interfases, ya definidas como artefactos en el Flujo de Trabajo Diseo, pueden ser utilizadas en el modelo de implementacin para especificar las operaciones realizadas por componentes y subsistemas. Adems como se mencion anteriormente los componentes y los subsistemas pueden tener dependencias de uso sobre interfases. En este caso las interfases no son necesariamente pantallas sino que podramos entenderlas como conectores o facilitadores de acceso a los elementos de un modelo. La definicin de estos conectores puntos de enlace se implementan de acuerdo al lenguaje utilizado. La firma (visibilidad, nombre, argumentos de entrada / salida) de una clase en c++ o en java son la interfase de acceso a las mismas. 5.7. La vista del modelo implementacin La vista de implementacin es una de las cinco vistas arquitectnicas de un sistema. Las otras son la vista lgica, vista de casos de uso, vista de procesos y vista de despliegue. El propsito de la primera es capturar las decisiones de arquitectura hechas para la implementacin. Tpicamente la vista de implementacin contiene: Una enumeracin de todos los subsistemas del modelo de implementacin. Diagramas de componentes ilustrando cmo los subsistemas estn organizados en capas y sus jerarquas. Ilustraciones de las dependencias de importacin entre subsistemas. La vista de implementacin es utilizada para: Asignar trabajo de implementacin a programadores individuales, equipos de programadores subcontratistas. Evaluar la cantidad de cdigo a ser desarrollado, modificado o eliminado. Analizar la reutilizacin a gran escala. Considerar estrategias del la versin en desarrollo.

24

Tanto la vista de implementacin como las otras vistas de arquitectura son documentadas en el Documento de Arquitectura del Software. 6. Trabajadores 6.1 Arquitecto de Software El arquitecto de software tiene por sobre todo y principalmente la responsabilidad de manejar las decisiones tcnicas respecto de la arquitectura del software. Tpicamente el arquitecto identifica y documenta los aspectos significativos de la estructura del sistema, incluyendo las vistas de requerimientos, diseo, implementacin y puesta en marcha del mismo. El arquitecto es responsable de tomar decisiones razonables, atenuando los conflictos que pudieran plantearse a partir de los intereses particulares de cada apostador - stakeholder - del sistema. Es tambin su obligacin manejar adecuadamente los riesgos tcnicos y asegurar que las decisiones de ste tipo son convenientemente comunicadas, validadas y compartidas por los miembros del equipo de trabajo. 6.2 Implementador El rol del implementador o programador consiste fundamentalmente en el desarrollo y prueba de componentes en concordancia con los estndares adoptados en el proyecto para su posterior integracin en un subsistema mayor. Cuando son necesarios componentes de prueba tales como drivers stubs es el mismo programador el responsable de su desarrollo y prueba para incorporarlos en los subsistemas de apoyo. 6.3 Integrador de Sistemas Los integradores son responsables de planificar y realizar la integracin de elementos de implementacin para producir construcciones o versiones ejecutables del sistema. Tal como se dijo en el punto 2.3 los implementadores liberan sus programas probados en un espacio de integracin de subsistemas donde el integrador los combina para producir una construccin de un mdulo o paquete del sistema. El integrador es responsable tambin de planear la integracin que tiene lugar una vez finalizada la del nivel de subsistemas. Efectivamente, los subsistemas o mdulos obtenidos son agregados e integrados posteriormente en otro espacio de trabajo correspondiente al sistema total.

UNIDAD N3 MODELO DE PRUEBAS

Propsito de las pruebas Planificar las pruebas necesarias en cada iteracin, incluyendo las pruebas de integracin y las pruebas de sistema. Las pruebas de integracin son necesarias para cada construccin dentro de la iteracin; mientras que las pruebas de sistema son necesarias slo al final de la iteracin. Disear e implementar las pruebas creando los casos de prueba que especifican qu probar, los procedimientos de prueba que detallan cmo realizar las pruebas y si es posible, componentes de prueba ejecutables para automatizar las pruebas. Realizar las diferentes pruebas y manejar los resultados de cada una de ellas sistemticamente. Las construcciones en las que se detectan defectos son probadas de nuevo y posiblemente devueltas a otro flujo de trabajo, como diseo o implementacin, de forma que los defectos importantes puedan ser arreglados. Relacin con otros flujos de trabajo El flujo de trabajo requerimientos captura los requisitos para los productos de software. Estos requerimientos son el punto de partida y entrada principal de la actividad de identificacin de las pruebas a realizar. El flujo de trabajo anlisis y diseo determina el diseo apropiado para el producto de software; esta es otra entrada importante del proceso de identificacin de las pruebas a realizar. El flujo de trabajo implementacin produce construcciones del producto de software que son validadas por el flujo de trabajo pruebas. Dentro de una iteracin varias construcciones podran ser testeadas. habitualmente una por ciclo de pruebas.

25

2.1. Psicologa y economa de las pruebas Cuando se prueba un programa se desea agregarle algn valor -es decir, puesto que la prueba es una actividad costosa, se desea un incremento del valor del programa. Agregar valor significa aumentar su calidad o su confiabilidad, lo que, a su vez, significa encontrar y eliminar errores. De aqu que no se deba probar un programa para mostrar que funciona; ms bien es conveniente comenzar con la suposicin de que el programa contiene errores y luego probar el programa para encontrar tantos como sea posible. Puesto que los seres humanos tendemos a estar fuertemente orientados hacia la obtencin de metas, el establecimiento de una de ellas en forma apropiada tiene gran importancia desde el punto de vista psicolgico. Si la nuestra es demostrar que el programa no tiene errores, estaremos entonces subconscientemente dirigidos hacia este fin, es decir, tenderemos a seleccionar datos de prueba con baja probabilidad de hacer que el programa falle. Si nos proponemos demostrar que el programa tiene errores, nuestros datos de prueba tendrn una mayor probabilidad de lograrlo. Esta ltima manera de enfocar el problema agrega al programa mayor valor que la primera. Un caso de prueba que descubre un error difcilmente pueda ser considerado como no exitoso; mas bien, ha demostrado ser una valiosa inversin. 2.2. Conceptos bsicos Testing de software Realizar testing de software no es debuggear un cdigo, ya que el objetivo es encontrar los
problemas, pero no el origen de los mismos, aunque puede ocurrir que en algunas ocasiones los encuentre (luego de encontrar el problema se buscar el origen). Tampoco es la demostracin de que en dicho software no hay errores. Testear o probar un software es someterlo a ciertas condiciones a fin de demostrar si es vlido o no a partir de los requerimientos que le dieron origen, es decir, si satisface los requerimientos definidos (validacin), ya que podra ocurrir que un software no tuviera defectos pero que tampoco realizara la funcionalidad especificada y acordada con el usuario. Implica la verificacin de que dichas funcionalidades se implementan correctamente. Testing es una actividad destructiva, y el mismo es exitoso en la medida que descubre defectos en el software. Esta actividad, definitivamente agrega valor (calidad) al producto, y an ms, si se analizan los resultados, tambin al proceso de desarrollo utilizado. Podra decirse que un software no tiene calidad por ejemplo cuando el sistema se cancela inesperadamente, no cumple las funcionalidades requeridas por los usuarios, implementa dichas funcionalidades en forma incorrecta, sus respuestas son lentas, es difcil de utilizar (no es amigable), permite cometer errores, es difcil entender el cdigo fuente, slo quien lo construy puede modificarlo, es ms complejo de lo necesario, no se sabe bien cmo probarlo, entre otros. La calidad es un resultado del esfuerzo hecho durante todo el desarrollo, aumentar la cantidad de las pruebas no aumenta necesariamente la calidad del sistema software. Testing es una de las barreras para evitar que productos software de baja calidad lleguen a clientes. En un cdigo que estamos probando se pueden encontrar errores que causan defectos, los cuales muestran fallas.
Falla (failure)

Es una diferencia entre los resultados (comportamientos) reales y los esperados. Se da por ejemplo cuando un programa no se comporta como se esperaba que lo hiciera. Puede ser interna o externa. Una falla interna aparece antes de liberar el producto al cliente (considrese aqu el concepto de cliente externo y cliente interno). Una falla externa aparece luego de entregar el producto al cliente (externo o interno). Las fallas aparecen a partir de los casos de prueba.

26

Las fallas pueden ser: Catastrficas: no se logra la salida esperada porque el software se cancela sin producirla o sin haberla completado. Funcional: los valores obtenidos como resultado difieren de los esperados. Propiedad: hace referencia al incumplimiento de una propiedad que se haba definido como importante, por ejemplo, un tiempo de respuesta mayor al definido es una falla de propiedad de desempeo. Formato: la salida puede mostrar los resultados esperados, pero la forma de la misma no es correcta. La tipificacin de la falla siempre se hace en la mayor categora que esta pueda alcanzar, por ejemplo, si la falla es de propiedad y funcional (tal es el caso de un conjunto de datos que se obtienen en un tiempo mayor al esperado y con datos errneos), la misma ser catalogada como funcional (ya que un conjunto de datos errneos puede obtenerse a la velocidad que se desea y an as la falla no se habr solucionado). A pesar de esto la falla debe describirse completamente.
Defecto (fault)

Error (mistake)

Se presenta en el cdigo y puede mostrar o causar una falla. Si el sistema no falla no hay defectos. Un defecto ocasiona de 0..n fallas.

Es cualquier equivocacin humana en un sistema software que genera defecto/s. El mismo ser encontrado por el desarrollador

2.3. Tipos de prueba Para encarar el proceso de pruebas de cada componente, subsistema o sistema es necesario
determinar la estrategia que ha de aplicarse. Se presenta a continuacin dos maneras de focalizar el anlisis del software en busca de defectos de construccin.

Pruebas tipo caja negra Una forma de examinar el funcionamiento de un programa consiste en tomar solamente los
datos de entrada y salida obtenidos con los primeros. La persona que efecta la prueba considera el programa como una caja negra, es decir, se desentiende completamente del comportamiento y estructura internos. Su inters se dirige nicamente a encontrar circunstancias en las cuales el programa no se comporta de acuerdo con sus especificaciones, es decir sin aprovechar el conocimiento de la estructura interna del programa. Si el objetivo es hallar todos los errores en un programa, el criterio ser probar la entrada de datos exhaustivamente. Esto implica emplear toda posible condicin de entrada como un caso de prueba.

Pruebas tipo caja blanca Las pruebas de caja blanca o lgicas, permiten examinar la estructura interna de los
programas. Usndola el operador de la prueba obtiene datos de prueba a partir del examen de la lgica del programa. Una prueba exhaustiva de secuencia no garantiza de ninguna manera que el programa cumpla con su especificacin. Por ejemplo, si se pide hacer una rutina para ordenar valores numricos en orden creciente y en forma inadvertida se escribe la rutina para trabajar en forma decreciente, entonces una prueba exhaustiva de secuencia podr ser de muy escasa ayuda para descubrir el error. Un programa puede ser incorrecto por causa de secuencias faltantes. Por supuesto, una prueba exhaustiva de secuencias no detectar la falta de secuencias lgicas necesarias. Una prueba de este tipo podr no detectar errores de sensitividad de los datos. Existen muchos ejemplos de estos errores, pero bastar con presentar uno simple.

27

Suponga que en un programa se deben comparar dos nmeros para detectar una convergencia, es decir determinar si la diferencia entre los dos nmeros es menor que un valor predeterminado.

Se podra escribir la sentencia en la forma siguiente: Por supuesto, esta sentencia contiene un error porque deberamos comparar EPSILON con el valor absoluto de A-B y no se lo detectar necesariamente ejecutando cada secuencia lgica posible dentro del programa. En conclusin, aunque la prueba exhaustiva de entrada (caja negra) es superior a la prueba exhaustiva de secuencia (caja blanca), ninguna de ellas resulta ser una estrategia til porque ambas son impracticables. Existen, sin embargo, modos de combinar elementos de ambos mtodos para llegar a una estrategia razonable, aunque no sea perfecta. Esto es lo que esperamos aportar con el contenido metodolgico planteado en esta unidad.

2.4. Etapas de Prueba Las pruebas se aplican con distintos niveles de esfuerzo y enfoques en el ciclo de vida de desarrollo del software. Es muy importante tener un enfoque adecuado en cada un de los momentos del proyecto. Pruebas de desarrollo Las pruebas de desarrollo se focaliza sobre los aspectos de test ms apropiados para ser encarados por los propios desarrolladores del proyecto. En contraste, las pruebas de sistema mencionadas ms adelante, pueden ser encaradas por un grupo independiente de pruebas. Tradicionalmente, las pruebas de desarrollo han sido concebidas como pruebas de unidad con foco ocasional en aspectos de integracin e infrecuentemente otros aspectos de prueba. Seguir con este criterio tradicional presenta riesgos en la calidad del software. A menudo aspectos que corresponden a los lmites de esta categorizacin son ignorados. En particular las pruebas de desarrollo han sido tratadas en la unidad 3 en el flujo de trabajo implementacin. La mejor estrategia es dividir el esfuerzo de trabajo de pruebas a los fines de tener cierta superposicin natural cuya magnitud depende de cada proyecto en particular. Lo que resulta insoslayable y recomendable siempre es que tanto los desarrolladores como el grupo independiente de pruebas del sistema compartan una misma visin de calidad. Pruebas de unidad Las pruebas de unidad de una iteracin se enfocan en la verificacin de los ms pequeos elementos del software. Se aplica a componentes del modelo de implementacin para comprobar que el flujo de control y de datos esperados han sido contemplados y funcionan como se espera. Estas expectativas se basan en como el componente participa en la ejecucin de un caso de uso. Recuerde que tanto los diagramas de secuencia como los de colaboracin, construidos a partir de los casos de uso permiten visualizar el desempeo (colaboracin) de cada componente. Los detalles de las pruebas de unidad son abordados en el flujo de trabajo Implementacin. Pruebas de integracin Las pruebas de integracin son hechas para asegurar que los componentes del Modelo de Implementacin funcionan armnicamente cuando son combinados para ejecutar un caso de uso. El alcance de la prueba es tpicamente un paquete o un grupo de paquetes del modelo de implementacin. Estos paquetes podran originarse en distintos grupos de desarrollo. Las pruebas de integracin exponen las omisiones o errores de especificacin de sus respectivas interfaces. Pruebas de sistema Las pruebas de sistema indican los aspectos del esfuerzo de prueba a ser abordados preferentemente por un grupo independiente de desarrollo que no particip en la implementacin del cdigo. Normalmente estas pruebas son realizadas cuando el sistema ya funciona como un todo. El ciclo de vida iterativo permite que estas pruebas se desarrollen tan pronto como sea posible con un conjunto estabilizado de casos de usos. Pruebas de aceptacin

28

Las pruebas de aceptacin son la prueba final que antecede a la entrega del software. El objetivo aqu es verificar que el software est listo y puede ser utilizado por los usuarios finales en el desarrollo de esas funciones y tareas para las que el fue construido. Habitualmente las pruebas de aceptacin adoptan alguna de estas tres modalidades: Aceptacin formal. Aceptacin informal o test alfa. Aceptacin beta o test beta. La eleccin de la estrategia habitualmente obedece a los requerimientos contractuales, el dominio de la aplicacin y los estandares organizacionales. Aceptacin formal La prueba de aceptacin formal es un proceso cuidadosamente administrado. Los tests son planeados y diseados con el mismo nivel de detalle que las pruebas del sistema. Los casos de prueba elegidos deben ser un subconjunto de los utilizados para la prueba del sistema. Es importante no desviarse de ninguna manera de los casos de prueba elegidos, y la presencia indispensable, en este caso, de los usuarios finales. Las actividades y artefactos producidos en la prueba de aceptacin formal son los mismos que se emplearon en la prueba del sistema. Los beneficios de este tipo de pruebas de aceptacin son: Las funciones y caractersticas a ser probadas son conocidas. Los detalles de las pruebas son conocidos y pueden ser medidos. Los tests pueden ser automatizados. El progreso de la prueba puede ser medido y monitoreado. El criterio de aceptacin es conocido. Las desventajas: Requiere importante cantidad de recursos y planeamiento. La prueba se puede convertir en una re implementacin de la prueba del sistema. Podra no descubrir defectos subjetivos del software, ya que solo se buscan defectos esperados. Aceptacin informal En las pruebas de aceptacin informal los procedimientos de test no son tan rigurosamente definidos como en las pruebas de aceptacin formal. Las funciones y aspectos de negocio a ser evaluadas se identifican y documentan pero no tienen los casos de prueba particular a seguir como en el caso anterior. Quien est probando determina no solo que hacer sino tambin la aprobacin cuando se encuentra satisfecho. Los beneficios de esta forma de prueba de aceptacin son: las funciones y caractersticas a ser probadas son conocidas. El progreso de la prueba puede ser medido y monitoreado. El criterio de aceptacin es conocido. Podra descubrir defectos subjetivos del software, ya que la eleccin de los casos de prueba es aleatorio y podrn aparecer defectos no esperados. Las desventajas se requieren recursos, planeamiento y administracin. No se tiene control sobre los casos de prueba a ser utilizados. Los usuarios finales podran dar su conformidad sin detectar defectos. Los usuarios finales tienden a focalizarse en la comparacin del nuevo sistema con uno anterior perdiendo prioridad la bsqueda de defectos. Aceptacin Beta De las tres modalidades de pruebas de aceptacin la denominada Test Beta es la menos controlada. El nivel de detalle, los datos y forma de encarar la prueba es determinada por cada probador individual. Cada probador es responsable de la creacin del entorno, seleccin de datos, determinacin de funciones y caractersticas a explorar. Adems determina su propio criterio de aceptacin. Esta modalidad es enteramente implementada por los usuarios finales y como podr apreciar es la forma ms subjetiva de aceptacin.

Los beneficios de esta forma de prueba de aceptacin son:

29

La prueba es enteramente implementada por los Usuarios Finales. Hay disponibilidad de potenciales probadores. Se incrementa la satisfaccin de los usuarios que participan. Se descubren ms defectos de aparicin subjetiva que las dos modalidades anteriores. Las desventajas: No todas las funciones y/o caractersticas pueden ser probadas. El progreso de la prueba es difcil de ser medido. Los usuarios finales pueden conformarse con el funcionamiento del sistema sin ver ni reportar defectos. Los usuarios finales tienden a focalizarse en la comparacin del nuevo sistema con uno anterior en lugar de buscar defectos. Los recursos necesarios para la prueba podran escapar al control del proyecto. El criterio de aceptacin no es conocido. 3. Flujo de trabajo de prueba El principal objetivo de ste flujo de trabajo es realizar y evaluar el resultado de las pruebas. Esta tarea consiste fundamentalmente en planificar el esfuerzo de cada iteracin, luego se describen los casos y procedimientos necesarios para llevar a cabo las comprobaciones, hecho esto, los desarrolladores implementan los componentes y stubs necesarios para dar la mayor automatizacin posible al proceso.

Todo esto se hace para cada construccin entregada como resultado del flujo de trabajo de
implementacin. Finalmente, con estos casos, procedimientos y componentes de prueba como entrada, los ingenieros de pruebas de integracin y de sistema evalan cada construccin y detectan cualquier defecto que encuentren en ellos. Las fallas sirven como realimentacin tanto para otros flujos de trabajo, como el de diseo y el de implementacin, como para los ingenieros de pruebas a fin de que lleven a cabo una evaluacin sistemtica de los resultados de las pruebas. 3.1. Planificar pruebas

30

Aqu se produce la planificacin general del proceso de pruebas. Se especifican estimaciones de los requerimientos de recursos humanos y sistema necesarios, as como la determinacin de una estrategia adecuada.

El propsito principal de este flujo es: Identificar los objetivos y entregables del esfuerzo de pruebas. Identificar una buena estrategia de utilizacin de recursos. Definir los lmites y alcances del proceso. Delinear el mtodo que ser usado. Definir el modo y criterio con el que el proceso ser seguido y evaluado.

Cuando preparan el plan de prueba los ingenieros de prueba se mueven sobre un rango de valores de entrada. El modelo de casos de uso y los requisitos adicionales ayudan a decidirse por un tipo adecuado de pruebas y a estimar el esfuerzo necesario para llevarlas a cabo. El diseador de pruebas usar tambin otros artefactos de entrada, como por ejemplo el modelo de diseo. Los diseadores de pruebas desarrollan una estrategia de prueba para la iteracin, es decir, deciden que, y cuando ejecutar los tipos de prueba y determinar si el esfuerzo de prueba tiene xito. En el siguiente ejemplo se define una estrategia de prueba de sistema para una ltima iteracin en la fase de elaboracin. Al menos el 75 por ciento de las pruebas deber estar automatizado. El resto podr ser manual. Cada caso de uso ser probado para su flujo normal y para tres flujos alternativos. Criterio de xito: 90 por ciento de los casos de prueba pasados con xito. No habr ningn defecto de prioridad medio-alta sin resolver. El desarrollo, realizacin y evaluacin de cada caso procedimiento y componente de prueba lleva algn tiempo y cuesta dinero. Sin embargo, ningn sistema puede ser probado completamente, por tanto, deberamos identificar los casos, procedimientos y componentes de prueba con un mayor retorno a la inversin en trminos de mejora de calidad. El principio general consiste en desarrollar casos y procedimientos de prueba con un solapamiento mnimo para evaluar los casos de uso ms importantes y tambin los requisitos que estn asociados a los riesgos ms altos. 3.2. Disear prueba

31

Los propsitos de disear las pruebas son: Identificar y describir los casos de prueba para cada construccin. Identificar y estructurar los procedimientos de prueba especificado cmo realizar los casos de prueba. Diseo de los casos de prueba de integracin Los casos de prueba de integracin se utilizan para verificar que los componentes interaccionan entre s de la forma apropiada despus de haber sido integrados en una construccin. La mayora de los casos de prueba de integracin pueden ser derivados de las realizaciones de casos de uso-diseo, ya que las realizaciones de casos de uso describen cmo interaccionan las clases y los objetos, y por tanto cmo se relacionan tambin los componentes entre s. Los ingenieros de pruebas deben crear un conjunto de caso de prueba que hiciera posible alcanzar los objetivos establecidos en el plano de prueba con un esfuerzo mnimo. Para esto, los diseadores de prueba intentan encontrar un conjunto de caso de prueba con un solapamiento mnimo, cada uno de los cuales procura un camino o escenario interesante a travs de una realizacin de caso de uso. Diseo de los casos de prueba del sistema Las pruebas de sistemas se usan para verificar que el sistema funciona correctamente como un todo. Cada prueba de sistema prueba principalmente combinaciones de caso de uso instanciados bajo condiciones diferentes. Estas condiciones incluyen diferentes: configuraciones hardware (procesadores, memoria principal, disco duro, etc.), diferentes niveles de carga del sistema, diferentes nmeros de actores y diferentes tamaos de la base de datos. Cuando se desarrollan los casos de prueba de sistema los diseadores de prueba deberan dar prioridad a las combinaciones de los casos de uso que: se necesitan que funcionar en paralelo. Posiblemente funcionen en paralelo. Probablemente se influencian mutuamente si se ejecutan en paralelo. Involucran varios procesadores. Usan frecuentemente recursos del sistema, como procesos, procesadores, bases de datos y software de comunicaciones, quizs en formas complejas e impredecibles. Pueden encontrarse, por lo tanto, muchos casos de prueba de sistema considerando los casos de uso, especialmente considerando sus flujos de eventos y sus requisitos esenciales, como los requisitos de rendimiento. Diseo de los casos de prueba de regresin Algunos casos de prueba de construcciones anteriores se adoptan para pruebas de regresin en construcciones subsiguientes, aunque no todos son adecuados. Para ser adecuados y contribuir a la calidad del sistema deben ser suficientemente flexibles y ser resistentes a cambios en el software que est siendo probado. La flexibilidad requerida en un caso de prueba de regresin puede suponer un esfuerzo de desarrollo extra, lo que significa tener cuidado y convertirlos en caso de prueba de regresin nicamente cuando el esfuerzo merezca la pena. Identificacin y estructuracin de los procedimientos de prueba Los diseadores pueden trabajar cada caso de prueba y sugerir procedimientos de comprobacin para cada uno. Intentamos emplear procedimientos de prueba existentes tanto como sea posible, lo que significa que podemos necesitar modificarlos de forma que se utilicen para especificar cmo realizar un caso de prueba nuevo o cambiado. Adems estos profesionales tambin intentan crear procedimientos de prueba que puedan ser reutilizados en varios casos de prueba. Esto les permite usar un conjunto reducido de procedimientos de prueba con rapidez y precisin para muchos casos de prueba. En el siguiente se muestra un ejemplo de procedimiento de prueba. El subsistema de servicios Cuentas proporciona funcionalidad para mover dinero entre cuentas. Esta funcionalidad est involucrada en varias realizaciones de casos de uso, como las de Pagar Facturas y Transferencias entre Cuentas. Un procedimiento de prueba llamado Verificar Transferencia entre Cuentas especificar cmo probar el movimiento de dinero entre cuentas, por lo

32

cual toma como parmetros de entrada dos identidades de cuentas y una cantidad a transferir, y valida la transferencia preguntando por el saldo de las dos cuentas involucradas antes y despus de transferir. Los diseadores de prueba crean 8 casos de prueba para el caso de uso Pagar Factura y 14 casos de uso para el caso de uso Transferencia entre Cuentas. El procedimiento de prueba Verificar Transferencia entre Cuentas especifica cmo se realizan parte de todos esos casos de prueba. 3.3. Implementar prueba El propsito de la implementacin de las pruebas es automatizar los procedimientos de prueba creando componentes de prueba si eso es posible, pues no todos los procedimientos pueden ser automatizados. Los componentes de prueba se crean usando los procedimientos de prueba como entrada: cuando usamos una herramienta de automatizacin de pruebas realizamos o especificamos las acciones como se describen el los procedimientos de prueba. Estas cciones son entonces grabadas dando como salida un componente de prueba; por ejemplo, generando un script de prueba en Visual Basic. Cuando programamos los componentes de prueba explcitamente usamos los procedimientos de prueba como especificaciones iniciales. Observe que dicho esfuerzo de programacin podra requerir personal con buenas habilidades programadoras. Los componentes de prueba emplean a menudo grandes cantidades de datos de entrada para ser probados y producen tambin muchsimos datos de salida como resultado de las pruebas. Es til visualizarlos de forma clara e intuitiva de manera que puedan especificarse correctamente y los resultados de las pruebas sean interpretados. Utilizamos para ellos hojas de clculo y bases de datos. 3.4. Realizar pruebas de integracin En esta actividad se elaboran las pruebas de integracin necesarias para cada una de las construcciones creadas en una iteracin y se recopilan los resultados de las pruebas. Las pruebas de integracin se llevan a cabo en los siguientes pasos: realizar las pruebas de integracin relevantes a la construccin llevan a cabo los procedimientos de prueba manualmente para cada caso de prueba o ejecutando cualquier componente de prueba que automatice los procedimientos de prueba. Comprobar los resultados de las pruebas con los resultados esperados e investigar los resultados de las pruebas que no coinciden con los esperados. Comunicar de los defectos a los ingenieros de componentes responsable de los componentes que se cree contiene lo fallos. Informar de los defectos a los diseadores de prueba, quienes usarn los defectos para evaluar los resultados del esfuerzo de prueba. 3.5. Realizar prueba de sistema El propsito de la prueba de sistema es realizar las pruebas de sistema necesarias en cada iteracin y recopilar los resultados de las pruebas. La prueba de sistema puede empezar cuando las pruebas de integracin indican que se han alcanzado los objetivos de calidad de integracin fijados en el plan de prueba de la iteracin actual; por ejemplo, el 95 por ciento de los casos de prueba de integracin se ejecutan con el resultado esperado. La prueba de sistema se elabora de forma anloga a la forma en que se realiza la prueba de integracin. 3.6. Evaluar prueba El propsito de la evaluacin de la prueba es valorar los esfuerzos de prueba en una iteracin. Los diseadores de pruebas evalan los resultados de la prueba comprobando los resultados obtenidos con los objetivos esbozados en el plan de prueba. stos preparan mtricas que les permiten determinar el nivel de calidad del software y qu cantidad de pruebas es necesario. En concreto, el ingeniero de prueba observa dos mtricas:

33

Complecin de la prueba, obtenida a partir de la cobertura de los casos de prueba y de la cobertura de los componentes probados. Esta mtrica indica el porcentaje de casos de prueba que han sido ejecutados y el porcentaje de cdigo que ha sido probado. Fiabilidad, la cual se basa en el anlisis no solo de las tendencias en los defectos detectados y sino tambin en las pruebas que se ejecutan con el resultado esperado. Para determinar la fiabilidad del sistema, los diseadores de pruebas crean diagramas de las tendencias de las fallas, donde representan la distribucin de tipos especficos de defectos -como defectos nuevos o fatales- a lo largo del tiempo. La prueba puede crear tambin diagramas de tendencias que representan el porcentaje de pruebas ejecutadas con xitos -es decir, ejecuciones de pruebas que generan los resultados esperados- a lo largo del tiempo. Las tendencias de los defectos siguen a menudo patrones que se repiten en varios proyectos. Por ejemplo, normalmente el nmero de defectos nuevos generados cuando se prueba un sistema se incrementa fallas rpidamente tan pronto como comienza la prueba, despus se mantiene estable durante un tiempo y finalmente empieza a caer lentamente. Por tanto, comparando la tendencia actual con tendencias similares en proyectos anteriores es posible predecir el esfuerzo necesario para alcanzar un nivel de calidad aceptable. Basndose en el anlisis de la tendencia de los defectos, los diseadores de pruebas pueden sugerir otras acciones, como por ejemplo: realizar pruebas adicionales para localizar ms defectos, si la fiabilidad medida sugiere que el sistema no est suficientemente maduro. Relajar el criterio para las pruebas si los objetivos de calidad para la iteracin actual se pusieron demasiado altos. Aislar las partes del sistema que parecen tener una calidad aceptable y entregarlas como resultado de la iteracin actual. Las partes que no cumplieron los criterios de calidad han de ser revisados y probados de nuevo. Los diseadores de prueba documenten la complecin de la prueba, su fiabilidad y sugieren acciones en una descripcin de la evaluacin de la prueba. 4. Artefactos 4.1. Artefacto modelo de pruebas El modelo de pruebas describe principalmente cmo se evalan los componentes ejecutables -como las construcciones- en el modelo de implementacin con pruebas de integracin y de sistema. El modelo de pruebas puede describir tambin la forma en que han de ser probados aspectos especficos del sistema; por ejemplo, si la interfaz de usuario es utilizable y consistente o si el manual de usuarios del sistema cumple con su cometido. El modelo de pruebas es una coleccin de casos de prueba, procedimientos de prueba y componentes de prueba. Observe que si el modelo de prueba es grande, es decir, si contiene una gran cantidad de casos de prueba, procedimientos de prueba y componentes de prueba, puede ser til introducir paquetes en el modelo para manejar su tamao.

34

4.2. Artefacto caso de prueba Un caso de prueba especifica una forma de probar el sistema, incluyendo la entrada o resultado con la que se ha de probar y las condiciones bajo las que ha de probarse. Un caso de prueba puede derivarse de, y por tanto puede seguir la traza de, un caso de uso en el modelo de casos de uso o de una realizacin de caso de uso en el modelo de diseo. En la prctica, lo que se prueba puede venir dado por un requisito o coleccin de requisitos del sistema cuya implementacin justifica un ensayo que es posible realizar y que no es demasiado caro. Los siguientes son casos de prueba comunes. Un caso de prueba que especifica la forma de comprobar un caso de uso o un escenario especfico de un caso de uso. Un caso de prueba de este tipo incluye la verificacin del resultado de la interaccin entre los actores y el sistema, que se satisfacen las precondiciones y post condiciones especificadas por el caso de uso, y que se sigue la secuencia de acciones especificadas por el caso de uso. Advierta que un caso de pruebas basado un caso de uso especifica tpicamente una prueba del sistema como caja negra, es decir, una prueba del comportamiento observable externamente del sistema. Un caso de prueba que especifica cmo ensayar una realizacin de caso de usodiseo o un escenario de la misma. Un caso de prueba de este tipo puede incluir la verificacin de la interaccin entre los componentes que implementan dicho caso de uso. Observe que los casos de prueba basados en una realizacin de caso de uso tpicamente especifican una prueba del sistema como caja blanca, es decir, una evaluacin de la interaccin interna entre los componentes del sistema. Ejemplo caso de prueba Los ingenieros de pruebas sugieren un conjunto de casos de prueba para comprobar el caso de uso Pagar Factura en el que cada caso de prueba verificar un escenario del caso de uso. Uno de los casos de prueba propuesto es el pago de una factura de 300 pesos por un pedido de una bicicleta de montaa. Los ingenieros denominan a este caso de uso Pagar 300-Bicicleta de Montaa. Para ser completos, el caso de prueba ha de especificar la entrada, el resultado esperado y otras condiciones para la verificacin del escenario del caso de uso. Algunos casos de uso pueden ser parecidos y diferenciarse nicamente en un solo valor de entradas o resultado. Esto se da a veces para casos de prueba que verifican diferentes escenarios del mismo caso de uso, por lo que puede ser apropiado especificar los casos de uso en forma de tabla, donde cada caso de prueba est representado por una fila y cada rango de valores de entrada y resultado se representa por una columna. Una tabla de este tipo proporciona no solo una buena visin general de casos de prueba similares sino tambin una entrada utilizable en la creacin de procedimientos de prueba y componentes de prueba. Cmo inferir casos de prueba Considere el siguiente diagrama de actividades de un caso de uso X que forma parte de un sistema (1, 2, 3... son actividades cualesquiera que forman parte del caso de uso X). Este diagrama de actividades muestra el curso normal del caso y los alternativos al especificar las salidas de las alternativas o rombos.

35


bsico):

Los siguientes son conjuntos de caminos independientes (los cuatro forman un conjunto

Camino A: 1, 2, 12 Camino B: 1, 2, 3, 4, 5, 6, 11, 2, 12 Camino C: 1, 2, 3, 4, 7, 9, 10, 11, 2, 12 Camino D: 1, 2, 3, 4, 7, 8, 10, 11, 2, 12 Fjese que el camino 1, 2, 3, 4, 5, 6, 11, 2, 3, 4, 7, 9, 10, 11, 2, 12 no se considera independiente porque es una combinacin de caminos ya definidos y no introduce ninguno nuevo. Cada uno de estos caminos muestra un escenario del caso del uso X. Ahora debemos disear casos de prueba para forzar la ejecucin de estos caminos, de esta forma podemos decir que cada instruccin de cdigo se habr ejecutado al menos una vez en las pruebas, as como tambin se habrn ejecutado las instrucciones de las salidas verdadero y falso de las decisiones. Se realiza luego un conjunto de casos de prueba para cada escenario (mnimamente se realiza al menos un caso de prueba para cada uno de esos escenarios).

36

Cada uno de estos casos de prueba se ejecuta, se documenta y se comparan los resultados obtenidos con los resultados esperados.

La especificacin de un caso de prueba debe incluir: Un identificador nico del caso de prueba. Los responsables del mismo. Referencias a documentos fuente, por ejemplo, una especificacin de requerimientos que contiene el caso de uso. La configuracin de software a probar: opciones de sistema, subsistemas, etc. Especificacin de las entradas: el valor preciso de cada entrada, propiedades adicionales de dicha entrada si fuera necesario (por ejemplo formatos, tiempos de espera, etc.) Especificacin de las salidas: el valor esperado de la salida, atributos adicionales si fuera necesario (por ejemplo tiempos de respuesta, etc.) Requerimientos sobre el ambiente de prueba: configuracin del hardware para la prueba, detalle del software necesario para la prueba (sistema software a probar, software especfico para realizar la prueba), recursos especiales, por ejemplo, la presencia de un usuario o una persona especfica. Especificacin del procedimiento de prueba. Precondiciones (condiciones que deben cumplirse antes de ejecutar este caso de prueba, por ejemplo, la ejecucin correcta de tal grupo de pruebas, la existencia de determinado objeto, etc.). Otros casos de prueba Se pueden especificar otros casos de prueba para probar el sistema como un todo. Por ejemplo: Las pruebas de instalacin verifican que el sistema puede ser instalado en la plataforma del cliente y que el sistema funcionar correctamente cuando sea instalado. Las pruebas de configuracin verifican que el sistema funciona correctamente en diferentes configuraciones; por ejemplo, en diferentes configuraciones de red. Las pruebas negativas intentan provocar que el sistema falle para poder as revelar sus debilidades. Los ingenieros de pruebas identifican los casos de prueba que intentan utilizar el sistema en formas para los que no ha sido diseado, por ejemplo, empleando configuraciones de red incorrectas, capacidad de hardware insuficiente o una carga de trabajo imposible de sobrellevar. Las pruebas de tensin o de estrs identifican problemas con el sistema cuando hay recursos insuficientes o existe competencia por los recursos. 4.3. Artefacto procedimiento de prueba Un procedimiento de prueba especifica cmo realizar uno a varios casos de prueba o partes de estos. Por ejemplo, una instruccin para un individuo sobre la forma ha de realizar un caso de prueba manualmente, o una especificacin de cmo interaccionar manualmente con una herramienta de automatizacin de pruebas para crear componentes ejecutables de prueba. El cmo llevar a cabo un caso de prueba puede ser especificado por un procedimiento de prueba, pero es a menudo til reutilizar un procedimiento de prueba para varios casos de prueba y reutilizar diferentes mtodos de prueba para un caso de prueba. Ejemplo procedimiento de prueba Se necesita un procedimiento de prueba para que un individuo lleve a cabo el caso de uso Pagar 300-Bicicleta de Montaa discutido en el ejemplo anterior. La primera parte del

37

procedimiento de prueba se especifica como sigue el texto entre corchetes no tiene que incluirse en la especificacin ya que ya est detallado en el caso de uso: Caso de uso: Pagar 300-Bicicleta de Montaa. Seleccione el men Hojear Facturas de la ventana principal. Se abre la ventana de dilogo Consultar Facturas. En el campo Estado de la Factura, seleccione Pendiente y pulse el botn Consultar. Aparece la ventana Resultados de la Consulta. Verifique que la factura especificada en el caso de uso [ID 12345] est en la lista en la ventana Resultados de la Consulta. Seleccione la factura a pagar especificada pulsando el botn dos veces. Aparece la ventana Detalles de Factura para la factura seleccionada. Verifique los siguientes detalles: el Estado es Pendiente; la Fecha de Pago est vaca; el Identificador de Confirmacin de Pedido coincide con el identificador en el caso de uso [ID 98765]; la Cantidad de la Factura coincide con la descripta en el caso de prueba [300 pesos]; y el nmero de cuenta es el mismo que el especificado en el caso de prueba [22-222-2222]. Seleccione la opcin Autorizar Pago para iniciar el abono de esta factura. Aparece la ventana de dilogo para el Pago de Factura. Etc. Se especifica cmo se lleva a cabo a travs de la interfaz de usuario el camino completo del caso de uso Pagar Factura dando ciertas entradas al sistema, e indicando qu es necesario verificar en las salidas del sistema. Observe que este procedimiento de prueba se aplica tambin para otros casos de uso similares en los que se utilizan distintos valores de entrada y resultado, es decir, los valores entre corchetes son diferentes. Tambin que el procedimiento de prueba es similar a la descripcin de flujo de eventos del caso de uso a Pagar Factura, aunque el mtodo de prueba incluye informacin adicional, como los valores de entrada del caso de uso a emplear, la forma en la que estos valores han de ser introducidos en el interfaz de usuario y lo que hay que verificar. Los procedimientos pueden ser: Procedimientos de instalacin de software y hardware. Procedimientos de control. Procedimientos de finalizacin, reseteos de estados, limpieza de resultados. Procedimientos de supervisin de la ejecucin de la prueba. Procedimientos de medicin de resultados de salida. 4.4. Artefacto componente de prueba Un componente de prueba automatiza uno o varios procedimientos de prueba, o parte de ellos. Los componentes de prueba se desarrollan utilizando un lenguaje de guiones o un lenguaje de programacin, o siendo grabados con una herramienta de automatizacin de prueba. Los componentes de prueba se utilizan para probar los componentes en el modelo de implementacin, proporcionando entradas de prueba, controlando y monitorizando la ejecucin de los componentes a probar informando de los resultados de las pruebas. En ingls, los componentes de prueba son a veces llamados test drivers, test arneses y test scripts. 4.5. Artefacto plan de prueba El plan de prueba describe las estrategias, recursos y planificacin de la prueba. La estrategia de prueba incluye la definicin del tipo de pruebas a realizar para cada iteracin y sus objetivos, el nivel de cobertura de prueba y de cdigo necesario y el porcentaje de pruebas que deberan ejecutarse con un resultado especfico. 4.6. Artefacto defecto Un defecto es una anomala del sistema, como por ejemplo un sntoma de un fallo software o un problema descubierto en una revisin. Se utiliza para localizar cualquier cosa que los desarrolladores necesitan registrar como sntoma de un problema en el sistema que ellos deben controlar y resolver.

38

4.7. Artefacto evaluacin de prueba Una evaluacin de prueba es una valoracin de los resultados de los esfuerzos de prueba, tales como la cobertura del caso de prueba, la cobertura de cdigo y el estado de los defectos. 5. Trabajadores 5.1. Diseador de pruebas Un diseador de pruebas es responsable de la integridad del modelo de pruebas, asegurando que el mismo cumple con su propsito. Los diseadores de pruebas tambin planean las pruebas, lo que significa que deciden los objetivos apropiados y la planificacin de las pruebas. Adems, los diseadores de pruebas seleccionan y describen los casos y los procedimientos de prueba correspondiente que se necesitan, y son responsables de la evaluacin de las pruebas de integracin y de sistema cuando stas se ejecutan. Observe que los diseadores de pruebas realmente no ejecutan las pruebas, sino que se dedican a la preparacin y evolucin de las mismas. Otros dos tipos de trabajadores, los ingenieros de pruebas de integracin y los ingenieros de prueba de sistema, son los encargados de llevarlas a cabo.

5.2. Ingeniero de pruebas de integracin Los ingenieros de pruebas de integracin son los responsables de hacen las pruebas de integracin que se necesitan para cada construccin producida en el flujo de trabajo de la implementacin. Se realizan para verificar que los componentes integrados en una construccin funcionan correctamente juntos. Por esto, se derivan a menudo de los casos de prueba que especifican cmo probar realizaciones de casos de uso-diseo. El ingeniero de pruebas de integracin se encarga de documentar los defectos en los resultados de dichas pruebas. 5.3. Ingeniero de pruebas de sistema Un ingeniero de pruebas de sistema es responsable de realizar las pruebas de sistema necesarias sobre una construccin que muestra el resultado (ejecutable) de una iteracin completa. Las pruebas de sistema se llevan a cabo principalmente para verificar las interacciones entre los actores y el sistema. Por esto, las pruebas de sistema se derivan a menudo de los casos de prueba que especifican cmo probar los casos de uso, aunque tambin se aplican otros tipos de pruebas al sistema como un todo. El ingeniero de pruebas de sistema se encarga de documentar los defectos en los resultados a las pruebas de sistema. Debido a la naturaleza de las pruebas de sistema, los individuos que actan como ingenieros de pruebas de sistema necesitan saber mucho sobre el funcionamiento interno del sistema. Por el contrario, stos deberan tener familiaridad con el comportamiento observable externo del sistema. Por tanto, algunas pruebas de sistema pueden ser realizadas por otros miembros

39

del proyecto, como los especificadores de casos de uso, o incluso por una persona externa al proyecto, como usuario de versiones beta.

UNIDAD N4 UTILIZANDO PUDS

El PUDS es un proceso de desarrollo de software que transforma requerimientos de usuarios en un producto software a travs de actividades que realizan trabajadores en un proyecto. El PUDS se apoya en tres pilares: los casos de uso, la arquitectura y el concepto de iterativo e incremental. Dirigido por Casos de uso La tcnica de casos de uso permite validar los requerimientos con el cliente y facilitar la comunicacin de dichos requerimientos en el equipo que participa en el proyecto. Existen entonces dos objetivos fundamentales: encontrar los verdaderos requisitos y representar los mismos de un modo adecuado para los usuarios, clientes y desarrolladores. Los CU dirigen el proceso de desarrollo en su totalidad. Los desarrolladores crean un modelo de anlisis que utiliza el modelo de casos de uso como entrada y que es diferente del modelo de diseo porque es un modelo conceptual en lugar de ser un esquema de la implementacin. Cada caso de uso en el modelo de casos de uso se traduce en una realizacin de caso de uso en el modelo de anlisis. Tomando los casos de uso uno a uno, los desarrolladores pueden identificar las clases que participan en la realizacin de aquellos. As obtenemos un conjunto de clases que juntas realizan los casos de uso. Luego los desarrolladores disean las clases y las realizaciones de casos de uso para aprovechar al mximo las tecnologas y productos a utilizarse. A continuacin se implementan las clases diseadas mediante un conjunto de archivos a partir de los cuales se pueden generar (ejecutables, DLLs, JavaBeans, componentes ActiveX, pginas web, etc.). Finalmente, durante el flujo de trabajo de prueba, los ingenieros corroboran que el sistema implementa la funcionalidad descrita en los distintos casos de uso, y de esta forma se satisfacen los requerimientos para los que fue construido. As los casos de uso guan al proceso unificado, lo hemos visto slo con una iteracin. Este mismo proceso se repite de manera iterativa e incremental a medida que avanzamos en el proceso de desarrollo. Los casos de uso son un mecanismo para materializar la relacin de trazabilidad a travs de todos los modelos. Un caso de uso en el modelo de requisitos es trazable a su realizacin en el modelo de anlisis, y as sucesivamente a travs de cada uno de los modelos del UP. Esta relacin es fundamental para mantener la integridad de los modelos en el tiempo cuando se presentan cambios que implican actualizaciones en varios de ellos.

Centrado en la arquitectura La arquitectura describe los cimientos del sistema que son necesarios como base para comprenderlo, desarrollarlo y producirlo. En la fase de elaboracin se construye una arquitectura slida

40

para que a partir de la misma podamos arrancar con la construccin de la totalidad del sistema sin tropiezos posteriores. A la hora de ir pasando por las distintas fases del proyecto los desarrolladores utilizarn la arquitectura como gua general para situarse correctamente en el lugar en donde estn parados y usarn los distintos diagramas ms detallados para realizar su trabajo, incluyendo aquellos casos de uso importantes en este contexto. La descripcin de la arquitectura tiene cinco vistas, una para cada modelo: 1. Casos de uso 2. Anlisis 3. Diseo 4. Despliegue 5. Implementacin Una vista arquitectnica es una descripcin simplificada (una abstraccin) de un sistema software desde una perspectiva particular que incluye ciertas particularidades y omite u oculta otras que no son relevantes para esta perspectiva. En la descripcin de la arquitectura no se pretende cubrir absolutamente todo, no debera inundar con detalles minuciosos. Hay mucha informacin que no es necesaria tener en cuenta a la hora de describir la arquitectura. Por ejemplo, slo el 10 % de las clases de un sistema son relevantes para la arquitectura, el 90 % restante no es significativo porque no es visible a todo el sistema. Objetivos de la definicin de la arquitectura: Permite comprender el sistema: El sistema debe ser comprendido por todos los integrantes del equipo de proyecto. Permite manejar la complejidad: usualmente se trata de sistemas con funcionalidades complejas, que operan en entornos tecnolgicamente complejos, que combinan computacin distribuida, productos y plataformas comerciales diferentes y reutilizan componentes y marcos de trabajos, que se realizan en lugares geogrficamente alejados entre s que deben ser coordinados y ensamblados. Permite a los integrantes del equipo de proyecto comprender y acordar qu se est haciendo: el equipo debe conocer el progreso de la definicin de la arquitectura. Organizar el desarrollo: a medida que crece la organizacin del proyecto, crecen proporcionalmente los esfuerzos para coordinar las actividades de los miembros del equipo. Fomentar la reutilizacin: la reutilizacin es una de las ventajas principales de esta metodologa, para ello se debe conocer el dominio del problema y qu componentes admite la arquitectura. Los componentes de software reutilizables estn diseados y probados para ser utilizados o ensamblados, lo cual reduce los tiempos y los costos, a la vez que aumenta la calidad disminuyendo la posibilidad de defectos. Hacer evolucionar el sistema: en cada iteracin se produce un incremento del sistema que estamos construyendo. Es deseable que dicho sistema sea fcil de modificar y permita la implementacin de nuevas funcionalidades, es decir, que sea flexible a los cambios.

Proceso Iterativo e incremental El PUDS avanza poco a poco en el refinamiento de casos de uso, se avanza por etapas. Es lo que diferencia al PUDS de otras metodologas de desarrollo tradicionales en las cuales el desarrollo tambin se realiza por etapas, pero las mismas se van realizando en serie, una detrs de la otra sin posibilidad por ejemplo de recibir retroalimentacin en alguna y volver para atrs para modificar funcionalidad. Se cumplen las etapas, se van cerrando y se avanza a la siguiente. En nuestro caso la base es que el proceso sea realmente iterativo e incremental.

41

El concepto de iteracin tiene asociado el de versin de sistema, es decir, en cada iteracin se obtiene una versin operativa del sistema software que estamos construyendo. Este sistema va creciendo incrementalmente a travs de las diferentes iteraciones, los modelos van evolucionando a travs de las mismas. Se divide el proyecto en un nmero de mini proyectos, siendo cada uno de ellos una iteracin. Cada iteracin est compuesto por todas las fases de un proyecto de software, es decir que cada una de ellas sera como un mini proyecto hecho con una metodologa tradicional, como la de cascada. Se debe manejar con mucho cuidado el hecho de poder avanzar y recibir retroalimentacin y retroceder, ya que si tomamos esto como moneda corriente podemos caer en un terreno donde nos mantengamos siempre en un mismo lugar sin percibir avance alguno. Cada iteracin debe planificarse para controlar el proyecto. El Plan de la iteracin es un plan que incluye un conjunto secuencial de actividades, tareas, recursos asignados, objetivos, criterios de evaluacin (en funcin de los objetivos) de la iteracin en cuestin. Ser importante al final de la iteracin medir aspectos tales como el grado de terminacin de la funcionalidad planificada, los niveles de calidad alcanzados, adecuacin a las normas y estndares vigentes en caso de ser necesario. El concepto de iteracin reduce, al principio del ciclo de vida, los riesgos que pueden amenazar el progreso del desarrollo. Las versiones internas tras las iteraciones posibilitan la retroalimentacin de los usuarios y esto lleva a su vez a una correccin temprana de la trayectoria del proyecto.

Para resumir, los principales objetivos de un desarrollo iterativo e incremental son: Atenuar los riesgos. Obtener una arquitectura robusta. Gestionar requisitos cambiantes. Permitir cambios tcticos. Conseguir una integracin continua. Conseguir un aprendizaje temprano. El UP entrega las 6 mejores prcticas El proceso unificado describe cmo implementar efectivamente las seis mejores prcticas para el desarrollo de software, las mismas son:

Ventajas y errores al utilizar el proceso unificado

Ventajas de utilizar esta metodologa

Prioriza la identificacin y gestin de riesgos en etapas tempranas del desarrollo. Enfatiza la construccin temprana de una arquitectura cohesiva y robusta que ser probada en las primeras iteraciones. Permite identificar requerimientos en forma incremental. Aplica el desarrollo evolutivo e incremental. Genera artefactos bien definidos, con vocabulario comn. Es fcil de combinar con tcnicas de otros mtodos. Es fcil de personalizar, alienta versiones light mnimas.

42

Permite trabajar con plantillas estndar. Puede escalar a proyectos grandes o pequeos. Ampliamente adoptado, por lo tanto, muchos recursos de consultora y capacitacin. Cada iteracin finaliza con un entregable del producto. Superponer las ideas de cascada en las fases iterativas. Realizar iteraciones demasiado largas. Cometer errores al definir la visibilidad de los atributos y las operaciones. Las iteraciones no son fijas, por lo que dependen de la planificacin y el seguimiento de la

Errores ms comunes al utilizar esta metodologa

misma.

Crear muchos artefactos innecesariamente, lo que aumenta la complejidad sin motivo. Dificultad en la planificacin predictiva. El equipo debe realizar muchas actividades y genera muchos artefactos, porque no se ha definido correctamente el proceso. Necesidad de utilizar herramientas CASE.

2.-Fases e iteraciones
Este concepto es el primer paso para dividir el trabajo en partes manejables. PUDS contempla cuatro fases atendiendo al momento en que se realizan: Inicio Elaboracin Construccin Transicin Cada una de las fases se divide en una o ms iteraciones. Cada una de las cuatro fases de un proyecto finaliza con un hito. Cada hito puede incluir muchos objetivos, incluso la toma de decisiones clave para avanzar con la prxima iteracin. 2.1 Planificacin de las fases Antes de comenzar a trabajar en un proyecto debemos planificar el proyecto y realizar un Plan de proyecto. En cada fase planificaremos cada iteracin a travs del Plan de iteracin. Estos planes se van completando con mayor detalle a medida que se avanza en el proyecto. En esta planificacin debemos incluir mnimamente la forma evaluar cada iteracin, la forma de gestionar los riesgos y la manera de asignar los recursos necesarios para llevar a cabo las actividades. El PUDS nos dice qu hacer en cada fase, los planes llevan estas indicaciones a trminos especficos para un proyecto en particular. Se planifica: El tiempo que insumir cada fase, incluyendo su fecha de finalizacin. Los hitos principales que indican la finalizacin de una fase para pasar a la siguiente. Las iteraciones que se realizarn en cada fase. 2.2 Planificacin de las iteraciones La cantidad de iteraciones que se realizarn en cada fase depende del sistema que estamos construyendo, de su complejidad y tamao. La duracin de cada iteracin podr variar entre una semana y tres meses. Es aconsejable que las actividades dentro de la iteracin sean unidades asignables, controlables y posibles de medir. Por cada iteracin planificamos: El tiempo que llevar cada iteracin, con su fecha de finalizacin. El contenido de la iteracin, es decir, qu funcionalidades (expresadas en casos de uso) se implementarn en la misma, qu riesgos estarn presentes (o al menos potencialmente) y cul ser la estrategia de mitigacin, los subsistemas que se implementan (total o parcialmente). Los hitos secundarios que indicarn la finalizacin de la iteracin.

43


2.3 Evaluacin

Esta planificacin de la iteracin se ir refinando a medida que nos acerquemos a dicha iteracin. Los criterios de evaluacin seguramente se planificaron con anterioridad en funcin de los objetivos. Se trata de parmetros o caractersticas que mnimamente se deben cumplir. Se establecen criterios para cada fase y para cada iteracin dentro de cada fase. Se trata de un momento en el que se verifica la satisfaccin de dichos criterios o requisitos. Por lo anterior, se deduce que los criterios deben poder ser observados de alguna manera por el responsable, es decir, el jefe de proyecto. Esta evaluacin permite: Evaluar la iteracin actual, por ejemplo, si el proyecto se mantiene dentro de los costos y tiempos planificados, si se logran los objetivos de calidad definidos, etc. Actualizar el plan de la siguiente iteracin. Los resultados de la evaluacin se registran en un documento que crea el jefe de proyecto. Este documento se distribuye a los involucrados y se archiva, es decir, no sufre modificaciones a lo largo del tiempo. La prxima evaluacin generar un nuevo documento de registro de resultados.

3 Flujos de trabajo
3.1 Flujos de trabajo fundamentales Cada iteracin puede ser considerada como un pequeo proyecto en s mismo, y constituye una pasada por los cinco flujos de trabajo fundamentales del PUDS. Los flujos de trabajo fundamentales son: Requisitos Anlisis Diseo Implementacin Prueba

3.2 Dominio del problema y de la solucin En la actividad de modelado de negocio se trabaj con los objetos del negocio, es decir, con el dominio del problema. En el flujo de requerimientos se comenz a trabajar con clases de software. Estas con una relacin de traza con los objetos identificados en el dominio en la etapa anterior. En el flujo de trabajo de anlisis se comenz a trabajar con clases de fabricacin pura, es decir, creadas para la construccin de la solucin, o sea, ya en el dominio de la solucin. El resultado de este flujo fue un modelo conceptual y lgico.

44

En el flujo de diseo se continu trabajando en el dominio de la solucin para lograr el sistema software. 3.3 Flujos de trabajo y modelos Cada flujo de trabajo obtiene una salida, que es un modelo que lleva el mismo nombre que el flujo. La clave en la configuracin del proceso es qu incluir dentro del modelo, es decir, qu diagramas utilizar en cada flujo de trabajo. Este es un aspecto configurable del proceso, ya que dependiendo del proyecto, del conocimiento del dominio, de la complejidad, etc. se seleccionarn los diagramas que se construirn.

UNIDAD N5 IMPLEMENTACION DEL CAMBIO

1.-Creacin del conocimiento con t.i. y ventaja competitiva

David Smith postula cuatro niveles de desarrollo organizacional en la creacin del conocimiento: o Compartir conocimiento, o Nivelacin, o Creacin de conocimiento y o Competir con conocimiento. Cada uno de estos niveles otorga a la empresa facilidades y ventajas, y si dicha empresa es capaz de avanzar a la etapa siguiente, ser capaz de alcanzar nuevas capacidades que le otorguen grandes ventajas sobre sus competidores. Resolver los problemas y encontrar las oportunidades subyacentes en cada uno de estos estados involucra tres elementos convergentes: Procesos cognitivos: Estos incluyen la identificacin, la adquisicin, el mapeo, el almacenaje, el acceso, la distribucin, la nivelacin y el uso del conocimiento. Facilitadores tecnolgicos: Sistemas de informacin, recuperacin de documentos, herramientas de grupo, intranet corporativa, sistemas de base de conocimiento, etc. Alineacin organizacional: Los lderes son parte crtica del alineamiento, junto con las recompensas, roles, estructuras mentales, estructura y apertura. La tecnologa, no es nunca por s misma la solucin mgica a ninguna problemtica. Slo resulta valiosa ante fines concretos. Debemos saber para qu queremos utilizar tal o cual tecnologa, y asegurarnos de que cumple nuestras expectativas de uso y calidad antes de realizar cuantiosas inversiones en ella. Considerar los siguientes aspectos como premisa indispensable al enfrentar un proceso de cambio organizacional implementando tecnologa de informacin:

45

Crear conocimiento es el postulado fundamental en la implementacin de tecnologas de informacin. Involucrar a la mayor cantidad de personas posible en la reingeniera y otros programas de cambio. Hacer del cambio constante parte de la cultura. Contarle a la mayor cantidad posible de personas sobre todos los aspectos, con la mayor frecuencia posible y preferiblemente en persona. Hacer uso amplio de la motivacin y del reconocimiento positivo a los miembros involucrados en el proyecto. Trabajar dentro de la cultura de la empresa, no alrededor de sta.

2. Adquisicin de hardware, software y servicios Implementar determinada T.I. podra requerir de la incorporacin de hardware, software y/o servicios. El proceso de adquisicin de recursos y equipo computacional es complejo. Las decisiones relacionadas con la adquisicin de estos recursos deben considerar factores tecnolgicos y financieros. El proceso se inicia con la determinacin de los requerimientos de cmputo, hasta la administracin de la conversin de programas y la transicin y traslado de datos al nuevo sistema computacional. Es importante conocer los sntomas que se observan en las organizaciones, y que constituyen un detonante del proceso de cambio de equipo, a fin de que el administrador de los recursos de hardware se prepare para el manejo del proyecto: Problemas de servicio con el proveedor actual. El equipo computacional actual es obsoleto. Saturacin y falta de capacidad del equipo computacional Necesidad de incorporar nuevos sistemas de aplicacin a la organizacin Equivocada decisin durante el proceso de seleccin del equipo actual. Existencia de requerimientos de competitividad que no pueden ser logrados con la tecnologa actual. Existe la necesidad de cambiar la filosofa de operacin de los sistemas actuales. Las etapas para llevar a cabo el proceso de innovacin tecnolgica de recursos computacionales son: Determinacin de los requerimientos. Es necesario especificar las necesidades del nuevo equipo a fin de transmitirlas de manera clara a los proveedores, para lo cual es obligatorio:
Un conocimiento de la organizacin.

El primer paso es tener un conocimiento profundo de la organizacin o la entidad de negocios que recibir el servicio del equipo que ser adquirido.
Plan de desarrollo de aplicaciones.

Se debe contar con un plan de desarrollo de aplicaciones a corto, mediano y largo plazo que operarn en el nuevo sistema. El horizonte del proyecto se define como el lapso de tiempo futuro que se considera en un anlisis.
Filosofa de operacin o tipo de solucin requerida

El plan deber incluir aspectos tecnolgicos requeridos para el desarrollo de nuevas aplicaciones, tales como bases de datos, cdigos de barras, sistemas por lotes o en lnea, ya que estas especificaciones pueden modificar de manera sensible los requerimientos y restricciones a considerar en el nuevo equipo. La filosofa de operacin que se desea con el nuevo equipo requiere un anlisis del tipo de solucin que se implantar con l. Esta solucin puede incluir equipos grandes, arquitecturas clienteservidor, estaciones de trabajo y PCs entre otras. Recursos que deben estimarse Capacidad de cmputo expresada. Por ejemplo: nmero de instrucciones por segundo. Capacidad de almacenamiento en RAM. Por ejemplo: tamao en Gigabytes

46

Capacidad de almacenamiento secundario, expresada en Megas, Gigas Terabytes. Capacidad total de impresin requerida, expresada como lneas de impresin por minuto. Cantidad de terminales requeridas para la captura o consulta de informacin. Hardware especializado para llevar a cabo funciones especiales: Terminales inteligentes, concentradores, ruteadores, etc. Infraestructura de redes: Tarjetas de red, medios de transmisin, etc.

Requerimientos obligatorios Conjunto de caractersticas que deben estar, de forma obligada y necesaria, presentes en el equipo o solucin presentada por el proveedor: Costo total del equipo o el presupuesto mximo autorizado. Tiempo mximo de entrega del equipo requerido. Compatibilidad con el lenguaje computacional actual, minimizando el esfuerzo de conversin. Apoyo del proveedor durante la conversin de aplicaciones, si existe. Caractersticas mnimas requeridas de rendimiento de los equipos. Requerimientos opcionales Constituyen el conjunto de caractersticas que son de gran ayuda y utilidad si se encuentran presentes en el equipo, en caso contrario, no necesariamente la propuesta del proveedor debe ser descartada. Existencia de usuarios con configuraciones similares y que se encuentran en localidades cercanas para tener un soporte mutuo. Disponibilidad de algn sistema de aplicacin o paquete ya desarrollado para asegurar una implantacin rpida y exitosa. Alto grado de satisfaccin de los usuarios actuales. Requerimientos futuros Deben tenerse en cuenta situaciones como: Crecimiento del negocio por arriba o por abajo del porcentaje estimado. Fusiones o compra de nuevos negocios. Rediseo o cambios importantes de las aplicaciones actuales. 2.1. Evaluacin y seleccin Evaluacin tcnica de las propuestas Es el proceso mediante el cual el administrador del proyecto define y evala las caractersticas y los factores tcnicos de los equipos disponibles. El resultado de esta evaluacin tcnica, sumado al resultado de la evaluacin econmica y financiera, constituye la plataforma de decisin del equipo y de la solucin a adquirir. 2.2. Elaboracin de una Requisicin de Propuesta (RFP Request For Proposal) Una vez que se han terminado las estimaciones de los requerimientos del equipo nuevo que se va a adquirir, es necesario elaborar una solicitud o requisicin de propuesta, documento que define los requerimientos de la organizacin sobre el equipo o la red requerida. Tiene varias funciones: Sirve como una propuesta del sistema que invita a los proveedores a participar en el concurso. Establece los primeros puntos de evaluacin y negociacin entre los proveedores de soluciones y la organizacin. Obliga al administrador del proyecto a formalizar el proceso de determinacin de los requerimientos de equipo. Constituye un documento que describe claramente las prioridades tcnicas del sistema. Se recomienda incluir en su estructura:

47

o Datos generales del responsable del proyecto. Fecha lmite para recibir la propuesta del proveedor. Fecha lmite para que el proveedor realice las presentaciones y/o demostraciones del equipo propuesto. o Bases y lineamientos generales que sern utilizados para comparar los diferentes equipos. o Breve descripcin de la situacin actual de la compaa y de la funcin de informtica dentro de la misma. Requerimientos del sistema computacional Se puede incluir la siguiente informacin: o Requerimientos del equipo actual versus del equipo propuesto. o Requerimientos obligatorios y opcionales. o Informacin ms detallada de las pruebas de benchmark o pruebas de rendimiento o que sern efectuadas a las soluciones propuestas que estarn concursando. o En trminos generales, deber incluirse toda la informacin relevante. Formato de propuesta Es importante definir estndares de las propuestas de los diferentes proveedores, para facilitar la evaluacin tcnica y financiera de las mismas, y por ende, de la decisin final. El formato de propuesta puede variar de una empresa a otra,pero incluye: Sistema o solucin configurada. Con la descripcin tcnica detallada de la solucin propuesta y las capacidades de crecimiento del sistema. Debe contener manuales tcnicos de hardware y del software configurado, as como diagramas esquemticos de la configuracin propuesta. Requerimientos de instalacin. Se debe recordar que hay soluciones que implican costosos requerimientos de instalacin. Debe incluir: o Espacio fsico que ocupa el equipo. o Instalaciones elctricas y equipos reguladores de voltaje. o Temperatura ambiental y equipos de aire acondicionado. o Requerimientos especiales tales como piso falso, equipo de control de humedad, etc. Asistencia del proveedor. Aspecto tan importante como el producto, e incluye: Asistencia para el entrenamiento del personal en el nuevo equipo y calendario de cursos, incluyendo su costo. Personal de asistencia para hardware, software y en general, para el mantenimiento del equipo. Inventario de equipos de respaldo compatibles con el equipo configurado en la propuesta. Apoyo y experiencia para convertir las aplicaciones y los programas de aplicacin al nuevo equipo. Informacin de costos. Debe incluirse toda la informacin econmica y financiera de las propuestas. Ello comprende precios, plazos de pago y opciones de compra disponibles por parte del proveedor, y en general, todos los datos requeridos para desarrollar la evaluacin econmica del proyecto de inversin. Condiciones del contrato: se especifican en formatos fijos que el proveedor anexa a las propuestas, los cuales comnmente son elaborados por el departamento jurdico de la compaa. Nivel o grado de cumplimiento: Es importante insistir a los proveedores que esta informacin se incluya en la propuesta entregada en forma expresa y por separado. Apertura de concurso de proveedores Una vez elaborado el RFP, es necesario abrir formalmente el concurso de los proveedores. Durante esta fase del proceso es importante elaborar un documento que contenga todas las especificaciones, ya descritas y darlo formalmente a cada uno de ellos. Se recomienda que la entrega se efecte en una reunin por separado con cada proveedor, recalcando la importancia de cumplir con el formato especificado. o o

48

 Es importante considerar e invitar a todos los proveedores posibles. Descarte de propuestas Se descartan las propuestas que no cumplen con los requisitos obligatorios. Hay que recordar que si la invitacin a los proveedores fue exhaustiva, es de esperarse que la cantidad de propuestas recibidas tambin sea elevada. El anlisis y evaluacin de todas puede resultar lento y costoso. 2.3. Factores a evaluar La evaluacin se realiza exclusivamente sobre las soluciones que satisfacen los requerimientos obligatorios y que cumplen mejor las especificaciones opcionales. Se clasifican en: Factores de hardware. Son las caractersticas que ofrecen los componentes fsicos de la solucin. Por ejemplo: capacidades y velocidades de los diferentes componentes. Factores de software. Se refiere al software interno o de sistemas, el cual se compone de programas de control,
los que incluye el sistema operativo, software de comunicaciones y administrador de base de datos. Adems se consideran paquetes especiales, tales como simuladores, anlisis financieros, programacin lineal, control de proyectos, anlisis estadsticos y paquetes que se enfocan a resolver problemas funcionales a los usuarios, tales como contabilidad, cuentas por pagar, y facturacin, entre otros. Se debe dar gran peso a la posibilidad y facilidad de que todo el software que se desarrolle sea abierto o transportable. Factores de proveedor. El soporte es uno de los criterios ms importantes para tomar una decisin de compra, as tambin como el precio y el rendimiento. Aspectos a analizar son: 1.- Generalidades del proveedor. Toda aquella informacin relacionada con la imagen que ste tiene en el mercado local, regional y mundial, considerando aspectos tcnicos, de mercado y financieros, de tal manera que aseguren la permanencia y continuidad del proveedor. Ellos incluyen: Representacin mundial y regional del proveedor Tiempo de entrega del equipo y futuras ampliaciones Profesionalismo y preparacin de los vendedores Situacin econmica y financiera Calidad de la documentacin y manuales disponibles

2.- Apoyo a la capacitacin:

Es el apoyo que brinda en la capacitacin al personal tcnico y usuarios con el uso de los recursos de hardware y software propuestos. Incluye la capacitacin: al personal de las reas de investigacin y soporte tcnico en el rea de anlisis y programacin a operadores capacitacin a usuarios

3.-Mantenimiento de hardware y software.

Consiste bsicamente en la capacidad de un proveedor para proporcionar un soporte y servicio adecuado, para asegurar el funcionamiento continuo o ininterrumpido del sistema. Deben considerarse aspectos como: Calidad y cantidad de personal capacitado de tiempo completo disponible en hardware y software. Tiempo promedio que tarda el proveedor en atender las fallas reportadas. Tiempo o porcentaje de sistema funcionando, que es el tiempo que trabaja el sistema sin que ocurra algn problema. Tiempo promedio que el sistema permanece cado durante cada falla. Existencia de una sucursal cercana con partes y repuestos para responder con mayor oportunidad a fallas.

49

Existencia de horario extendido, 7 das a la semana, 24 horas diarias para atender

fallas.

4.- Equipos de respaldo.

Disponibles por parte del proveedor u otros usuarios. Estos equipos pueden garantizar la operacin de la empresa del cliente durante fallas prolongadas. Pueden incluir: Cantidad de equipo de respaldo existente. Facilidad de trasladar procesos a los equipos de respaldo. Grado de satisfaccin de estos usuarios en relacin con el proveedor.

5.- Apoyo durante la conversin de aplicaciones. Se refiere a la asistencia que el proveedor pueda proporcionar al cliente durante el proceso de conversin y traslado de las aplicaciones y programas al nuevo equipo. Algunos aspectos a tomar en cuenta son: Los antecedentes que tiene el proveedor en el apoyo a otros clientes en conversiones similares a las requeridas. Facilidad de iniciar la conversin de aplicaciones antes de la llegada del equipo, a fin de reducir el tiempo y costo de la operacin paralela de ambos equipos.

2.4. Mtodos de evaluacin tcnica Pueden aplicarse en forma individual o alternada, y complementariamente. Mtodo de mezcla de instrucciones: para comparar velocidades del procesador de diversos equipos se puede escoger un conjunto de instrucciones representativas y ms utilizadas por los programas de usuario y sacar un promedio ponderado del tiempo de ejecucin de ellas. Adems, se debe asignar un peso a cada instruccin de acuerdo con la frecuencia del uso de sta en los programas. Mtodo de Kernel: un kernel es un problema simple y representativo de las aplicaciones tpicas a computarizar por el nuevo equipo; mide el tiempo que emplea en ejecutar esta aplicacin cada uno de los equipos que se comparan. Mtodo de simulacin: consiste en hacer uno o varios programas utilizando tcnicas y lenguajes de simulacin con el fin de imitar el funcionamiento de un sistema computacional. Se definen parmetros como tiempo de ejecucin, capacidad de memoria principal, acceso a dispositivos de entrada/salida, demanda de usuarios en terminales, entre otros. Y se generan diferentes escenarios y corridas para cada uno de los equipos. Mtodo de benchmark: sirve para comparar el rendimiento de uno o varios programas de aplicacin en diferentes o igual plataforma de hardware. Existen revistas especializadas que peridicamente publican evaluaciones de comparaciones tcnicas de equipo computacional. Mtodo de factores ponderados: consiste en asignar un peso a cada uno de los factores de hardware, software y del proveedor descritos, y calificar cada equipo propuesto de acuerdo con la medida en que cumple con el factor considerado. El equipo o la propuesta que obtiene el mayor puntaje se considera el ganador. 2.5. Evaluacin financiera Es el proceso mediante el cual el administrador del proyecto define y evala las caractersticas y los factores econmicos de los equipos a considerar. 2.6. Alternativas de adquisicin y financiamiento Renta Es el proceso por el cual el usuario renta el equipo del proveedor por un perodo definido como obligatorio, al trmino del cual suelen presentarse tres alternativas: Cancelar el contrato y devolver el equipo al proveedor Renovar el contrato de renta, negociando si es posible un descuento sustancial. Ejercer la opcin de compra del equipo. El alquiler de computadoras tiene algunas ventajas con respecto a la adquisicin del equipo: No implica un desembolso inicial de dinero. El proveedor es responsable por el mantenimiento del equipo. No es una opcin obligatoria en el largo plazo. Evita la obsolescencia y es ms fcil hacer un cambio por un equipo posterior. Existe una ventaja fiscal por ser un gasto deducible para pago de impuestos. Algunas desventajas son:

50

Es ms costosa si es a largo plazo. Est sujeta a incremento por parte del proveedor.

Compra Una segunda opcin es la compra de un equipo computacional. Las ventajas son: Resulta ms barato cuando se requiere por largos perodos. No existen incrementos de los pagos. Al final del perodo el equipo tiene un valor de recuperacin. Algunas posibles desventajas son: Obsolescencia. Error en la seleccin del equipo. Desembolso considerable de dinero. Incertidumbre sobre el valor de reventa o cada en desuso total. 2.8. El mtodo del costo / rendimiento Este mtodo propone calificar y clasificar a los sistemas ofrecidos segn la relacin costo / rendimiento. De la aplicacin de este mtodo resulta como mejor oferta aquella que, en conjunto, es potencialmente ms capaz como consecuencia de promediar y compensar el ndice de potencialidad con el costo de implementacin. De esta manera resultar recomendada, siempre que se clasifique y pondere con "criterio", la que mejor se ajuste a las necesidades y posibilidades de la empresa.

Fase 1: verificacin de requisitos mnimos Esta fase comn a todos los procedimientos de evaluacin de ofertas, tiene como finalidad la verificacin de que todas las propuestas cumplan las condiciones mnimas establecidas en el pliego de especificaciones tcnicas, donde se determinan los requerimientos mnimos que debern ser atendidos. Estos requerimientos mnimos deben ser desdoblados considerando: exigencias que constituyen el objeto principal de la contratacin y que estn definidas en trminos precisos, expresados en magnitudes cuantificadas y cuantificables. Pueden citarse para este grupo: o Parmetros de seleccin de hardware o Parmetros de seleccin de software o Soporte de la firma oferente o Pruebas y demostraciones especificaciones que no constituyen el objeto principal de la contratacin, pero que han sido expresamente manifestados y que por sus caractersticas no son deducibles de la oferta. Por ejemplo: o Compatibilidad con otros equipos y dispositivos. o Posibilidades de ampliacin. o Adaptacin de procesos, etc. Hecho este anlisis se determinan, a partir de las ofertas aceptadas en el acto de apertura, las propuestas que cumplen con los requerimientos mnimos exigidos. Los remanentes sern considerados en detalle en la prxima fase. Fase 2: ponderacin y clasificacin Este mtodo utiliza cuadros comparativos (grillas) de distintos niveles de consolidacin, donde se reflejan ponderaciones (P) y calificaciones (CAL) absolutas y relativas para los distintos parmetros de seleccin. Los cuadros reflejan conjuntos de tems de importancia relativa equivalente. De este modo se considera cada conjunto como un todo, que a la vez consolida un conjunto de niveles inferiores e integra un conjunto de nivel superior. En el mismo la informacin est dispuesta tabularmente, hallando en las lneas horizontales as distintas caractersticas a evaluar (FACTOR), y en las columnas las propuestas, existiendo adems columnas para las calificaciones y ponderaciones.

51

Las ponderaciones representan el peso asignado a cada una de las caractersticas evaluada en los distintos niveles, teniendo en cuenta los criterios de evaluacin fijados con anterioridad en el pliego, y que debieran expresar acabadamente las necesidades de la empresa contratante. Las calificaciones son elementales a nivel de cada caracterstica evaluada, y absolutas o relativas para cada oferta en cada cuadro. Las calificaciones elementales asumen valores entre 0 y 3. Para un determinado factor se dar la calificacin 3 a la oferta que presente mayores prestaciones, y proporcionalmente a esas prestaciones se asignarn valores a las ofertas restantes. A los atributos de tipo cualitativo (monitores, memoria cache, etc.) dicha calificacin asume el valor 0 o 3 en funcin de poseer o no la caracterstica considerada. Las calificaciones absolutas se obtienen como resultado de la sumatoria de las ponderaciones por las calificaciones elementales de cada oferta; en tanto que las relativas -tiles para un cuadro de nivel superior - como un porcentaje de la calificacin mxima. Se obtiene la relacin costo/rendimiento para cada propuesta, a partir de la cual se establece un ranking de las propuestas recibidas, considerndose como ms adecuada aquella que estando dentro de las posibilidades presupuestarias, haya obtenido el menor cociente.

2.9. Conceptos sobre benchmark

52

1- Punto de referencia de cota conocida desde el cual pueden efectuarse mediciones. 2. Punto que sirve de referencia para medir cotas, ensamblar rganos, etc. El termino benchmark, que a menudo se confunde con la funcin afn de demostracin, se caracteriza por 4 funciones o elementos esenciales: Medicin del rendimiento de los sistemas; Programas del usuario, proporcionados por un cliente o presunto cliente como especificacin o como codificacin real; Fase de ajuste, cuyo objeto es optimizar el rendimiento del sistema; Comparacin del rendimiento optimizado de un sistema de un proveedor con el de un sistema competitivo, o con otro sistema del mismo proveedor. 2.10. Tipos de benchmark Terico: Sirve para medir tiempos casi en forma exclusiva, es decir, mide velocidades. Consiste en programas que estn escritos en un lenguaje de aplicacin de alto nivel y que realiza en forma simple y nica un solo tipo de tarea. Las pruebas bsicamente son para el procesador, sus recursos (memoria, UAL), y los distintos perifricos: pantallas, discos, impresoras, etc. Los programas usan los recursos del sistema de acuerdo a ciertos parmetros especificados en tiempo de ejecucin. No hace nada productivo con estos recursos, sino que los ejercita a fin de efectuar mediciones genricas. Por ejemplo, se le podra pedir que lea 1000 registros de un archivo en disco, ejecute 100000 adiciones de punto flotante e imprima 5000 lneas, y que luego indique el tiempo total requerido por este benchmark artificial. Ventajas: es rpido, simple, fcil y equitativo porque se usan los mismos programas en distintos equipos. No slo se prueba el equipo en s, sino la eficiencia en la administracin de los recursos por parte del S.0. y la eficiencia del compilador. Su costo es muy bajo, ya que incluso hay proveedores que tienen disponible este software. No requiere desarrollos ni adecuacin, ni costo de conversin ni capacitacin. Con estas pruebas no slo se valoriza el hardware, sino tambin el software, ya que esta es una muy buena oportunidad para evaluar el software, los compiladores, editores, etc. Inconvenientes: no puede evaluar los componentes complejos del procesamiento, ni tampoco las vinculaciones y/o interacciones entre programas, o entre programas y el S.O. Real: Consiste en la prueba completa de la totalidad los sistemas de aplicacin del cliente, con todos sus programas. Para ello es imprescindible que exista la facilidad de transmisin, ya sea va magntica y/o comunicaciones. A posteriori se debern recompilar las fuentes y reorganizar las bases de datos, sobre todo los ndices. Una vez hecho esto se toman los tiempos de cada uno de los programas durante su ejecucin. Es un conjunto de programas tomados de la carga de mquina del usuario y transformados en un modelo adecuado de la carga de mquina total. A pesar de los problemas existentes en cuanto a representatividad, existe un consenso general de que a los efectos de la seleccin de un equipo de computacin, el benchmark real es la herramienta preferida para la medicin de performance. Ventajas: Tiene la propiedad de evaluar en forma completa los recursos del equipo y su sistema operativo.

53

Evala en forma equiparable, los programas que se usan en un equipo actual. Sirve para verificar las diferencias entre los distintos compiladores para el mismo lenguaje, y comparar aquellos. Da una idea del costo que significa la conversin. Inconvenientes: es lento, costoso y a veces suele ser demasiado complicado llevarlo a cabo, sobre todo cuando no existe la posibilidad de traslacin de datos entre un equipo actual y aquel al cual se quiere hacer las pruebas. Slo prueba los programas en la forma en la que se usan actualmente, sin posibilidad de aprovechar los recursos nuevos o diferentes que puede haber entre los distintos equipos, y/o sistemas operativos, y/o lenguajes.

Optimizado: Consiste en una prueba de los sistemas que se posee pero haciendo uso de los nuevos recursos que tiene el S.O. y/o equipo, o los compiladores, o los nuevos lenguajes. Estos recursos no han sido contemplados o aprovechados por el sistema habida cuenta de la inexistencia de los mismos en la instalacin. Esta prueba es fundamental para poder comparar las distintas formas de manejar los datos y editar la informacin. Adems, sirve para comparar el tiempo y el costo de desarrollar esas modificaciones en los sistemas para adecuarlos a esas nuevas posibilidades. Ventajas: es imprescindible para poder comparar realmente las grandes diferencias en cuanto a prestaciones y sus ventajas entre los distintos equipos o S.O. Brinda la posibilidad de poder evaluar el costo de estos cambios y sus beneficios, tanto para los usuarios de las aplicaciones como para quienes las desarrollan. Inconvenientes: requiere ms tiempo, esfuerzo y costo que incluso el benchmark real. No todos los proveedores estn dispuestos a realizar estas pruebas, y a veces los resultados son contrapuestos; esto obliga a que se deban realizar los tres tipos de prueba, evaluar los resultados, y luego una ponderacin que se otorga a cada uno de ellos al hacer el polinomio de calificacin.

3. Lanzamiento de un sistema de informacin 3.1. Contrataciones Lista de actividades que podran desarrollarse: Definicin de necesidades de adquisicin o arrendamiento de hardware, software y / o servicios de proveedores. Definicin de factores de evaluacin de hardware: desempeo, costo, confiabilidad, disponibilidad, compatibilidad, modularidad, tecnologa, ergonoma, conectividad, tamao, configuracin, costo y soporte. Definicin de factores de evaluacin de software: eficiencia, flexibilidad, seguridad, conectividad, lenguaje, documentacin, plataforma de procesamiento, costo, soporte y otros factores de inters. Definicin de factores de evaluacin de servicios: disponibilidad, trayectoria profesional de los consultores, certificacin y reputacin del oferente a otras firmas, costos y otros factores de inters. Redaccin de los pliegos de especificaciones tcnicas de la contratacin. Lanzamiento de la contratacin. Evaluacin de ofertas: Pruebas y ensayos Sobre los dispositivos de hardware y sistemas operativos. Sobre los aplicativos de software Sobre el funcionamiento concurrente de hardware, sistemas operativos y aplicativos.

54

Grillas comparativas de caractersticas costo y rendimiento (benchmark). Adjudicacin de la contratacin al proveedor. 3.2. Documentacin El desarrollo de una buena documentacin para el usuario es una parte importante del proceso de lanzamiento de una aplicacin. El manual del usuario de cada aplicacin, debe incluir: Disposiciones generales. Formularios. Objetivos. Instructivos. Polticas. Flujogramas de navegacin Descripcin de la aplicacin. Reportes. Flujo general de trabajo. Informacin sobre reportes. Muestra del reporte. Descripcin de procedimientos. Descripcin del reporte. Pantallas Glosario de trminos. 3.3. Capacitacin de usuarios La participacin en los sistemas informticos y su aceptacin por el personal es la parte ms importante y difcil de la implementacin. Despus de una capacitacin prctica apropiada, los usuarios deben visualizar los beneficios del sistema implementado. Es necesario definir un programa estructurado para el desarrollo de recursos humanos a fin de aumentar la conciencia, evaluar las necesidades de adiestramiento e incluir a los miembros del personal en todos los aspectos del diseo e implementacin de sistemas con el objetivo de lograr una comprensin de las metodologas y la tecnologa de los sistemas de informacin. Las acciones prcticas en lo referente al establecimiento de un programa para el desarrollo y la capacitacin de recursos humanos incluyen: Asegurar, cuanto antes, la identificacin y la seleccin de los miembros del personal que participan en todos los niveles de implementacin y operacin de los sistemas con el objetivo de recibir capacitacin pertinente, terica y prctica, en los sistemas de informacin y en la tecnologa de sistemas. Considerar los temas asociados con el entorno de la organizacin en el cual se implantarn y utilizarn los sistemas. Disear estrategias de capacitacin para los sistemas de informacin, las cuales tengan en cuenta los temas asociados con su desenvolvimiento, el entorno orgnico en el cual se prev su funcionamiento y las circunstancias particulares de la organizacin. A continuacin se recomiendan normas sobre las estrategias para capacitacin de usuarios de sistemas informticos: Identificar los grupos destinatarios sobre la base de las funciones de los usuarios. Analizar los requisitos previstos de desempeo de los usuarios en relacin con el sistema nuevo mediante un modelo participativo que abarque todas las categoras y funciones. Evaluar las necesidades de capacitacin, incluido el nivel actual de comodidad y conocimiento de las tecnologas que se van a emplear. Elaborar programas de capacitacin para satisfacer las necesidades identificadas de los grupos destinatarios. Establecer una red de puntos focales para la capacitacin, los cuales toman en cuenta los requisitos y las iniciativas de las unidades de la organizacin. Una estrategia de capacitacin para las formas modernas de procesamiento y anlisis de informacin debe abarcar a todos los participantes y tener carcter interdisciplinario, sin dejar de considerar las necesidades particulares de los diferentes grupos funcionales y profesionales. Cada organizacin debe elaborar su propia estrategia para la capacitacin inicial y continua en los sistemas de informacin, la cual tiene en cuenta, por un lado, el desarrollo general de los sistemas de informacin y, por otro, el entorno particular de cada sistema implementado. Para ello se debe: Llevar a cabo la capacitacin en un entorno multidisciplinario. Utilizar herramientas didcticas tecnolgicas avanzadas siempre que sea posible. Proporcionarse capacitacin en el trabajo a todos los niveles para satisfacer los requisitos cotidianos.

55

Vincular la educacin y la capacitacin con las experiencias prcticas para lograr la motivacin de los usuarios. Prestar mucha atencin de acuerdo con el grupo destinatario para evitar el uso excesivo de jerga tecnolgica y complejidad de conceptos. Definir los niveles mnimos de capacidad. Proveer de recursos para respaldar la preparacin de material de enseanza y para permitir la adaptacin del material de capacitacin a fin de satisfacer las necesidades de grupos destinatarios de distintos niveles. En la capacitacin debe incluir conocimientos de computacin bsica y prctica, capacitacin especfica en las aplicaciones, desempeo y funciones individuales en la operacin del sistema. Probar los programas de capacitacin antes del uso a gran escala. La metodologa de presentacin permitir la interaccin de los participantes. La capacitacin se realizar lejos de las distracciones del ambiente de trabajo cotidiano y lo ms cerca que sea posible a la implementacin real. Las actividades del grupo ayudarn a reducir la formulacin tediosa de algunos temas tcnicos. Las situaciones simuladas, las presentaciones grupales o individuales determinarn en qu medida los participantes lograron el nivel de conocimiento o el dominio de las aptitudes indicadas por los objetivos. Evaluar la eficacia de los programas de capacitacin mediante la satisfaccin y la retroalimentacin de los usuarios, la retroalimentacin de los administradores, la situacin previa y posterior a la evaluacin, y la frecuencia y el tipo de llamadas solicitando asistencia durante el uso de los sistemas, resulta imprescindible como etapa final. 3.4. Implantacin A los fines de la puesta en marcha del sistema pueden seguirse cuatro mtodos de conversin: Paralela: el sistema antiguo y el nuevo operan hasta que el equipo de desarrollo de proyectos y la gerencia de usuarios finales acuerden cambiarse por completo. Durante este tiempo es cuando deben compararse y evaluarse las operaciones y los resultados de ambos sistemas. Los errores pueden identificarse y corregirse, y los problemas operacionales pueden solucionarse antes de que abandonen el sistema antiguo. Beneficios similares se generan a partir del uso de una conversin piloto. Por fases: se convierten slo partes de una nueva aplicacin o slo unos cuantos departamentos, sucursales o plantas a la vez. Esto permite que tenga lugar un proceso de implementacin gradual dentro de una organizacin. Piloto: un departamento u otro sitio de trabajo actan como lugar de prueba. En este sitio puede probarse un sistema nuevo hasta que las personas encargadas del desarrollo consideren que puede implementarse en toda la organizacin. Desmontes repentinos (sustitucin)

3.5. Mantenimiento de S.I. Una vez que el sistema se encuentra implementado comienza el mantenimiento.

56

Es la supervisin, evaluacin y modificacin de sistemas de informacin operacionales para realizar los mejoramientos necesarios o deseados. Un nuevo sistema genera el fenmeno curva de aprendizaje. El personal que lo opera y utiliza cometer errores simplemente porque no est familiarizado con l y aunque estos errores generalmente disminuyen a medida que se adquiere experiencia con el sistema, estos sealan reas donde se lo podra mejorar. El mantenimiento es tambin necesario para otras fallas y problemas que surgen durante la operacin de un sistema. La actividad incluye tambin un proceso de revisin despus de la implementacin, para garantizar que los sistemas recientemente implementados satisfagan los objetivos de desarrollo de sistemas que se les han establecido. Los errores en el desarrollo o el uso de un sistema deben corregirse mediante el proceso de mantenimiento. Este incluye una auditora o revisin peridica de un sistema, con el fin de asegurarse de que este operando en forma apropiada y de que este logrando sus objetivos. La auditoria es para supervisar continuamente el nuevo sistema en busca de problemas potenciales o cambios necesarios. El mantenimiento incluye la realizacin de modificaciones a un sistema debido a cambios en la organizacin o el entorno empresarial. Por ejemplo, una nueva legislacin tributaria, las reorganizaciones de empresas y las nuevas incursiones empresariales usualmente requieren que se realice una variedad de cambios en los sistemas de informacin.

57