ELEMENTOS INVOLUCRADOS EN EL DESARROLLO DEL PROYECTO

Personas Proceso Producto Tecnologa

Elaborado por M. en H.D. Jos David Chvez Corts

Personas
Aprovechar el talento Asignacin de tareas Escalamiento Profesional Equilibrio del equipo Organizacin del equipo Motivacin

Elaborado por M. en H.D. Jos David Chvez Corts

Proceso
Evitar la Repeticin de trabajo Deteccin de errores (control de calidad) Bases del Desarrollo Planificacin del ciclo de vida Gestin de Riesgos en la planificacin Orientacin al cliente (soft. A a la medida)

Elaborado por M. en H.D. Jos David Chvez Corts

Producto

Tamao del producto Caractersticas del producto

Tecnologa
Sinergia

Elaborado por M. en H.D. Jos David Chvez Corts

Proceso
Planificacin excesivamente optimista Gestin de riesgos insuficientes Fallo en los contratos Falta de planificacin No respetar la planificacin Escatimacin en las actividades iniciales Deficiencias en el diseo Falta de control de calidad Falta de control del proyecto Atraso de actividades Programacin a destajo

Elaborado por M. en H.D. Jos David Chvez Corts

Tecnologa
Tecnologa desconocida Cambio de Herramientas en el proyecto Control de Versiones Control del cdigo fuente

Elaborado por M. en H.D. Jos David Chvez Corts

BASES DEL DESARROLLO

Bases de Gestin Bases Tcnicas Bases de Control de Calidad

Elaborado por M. en H.D. Jos David Chvez Corts

CICLO DE VIDA DEL SOFTWARE

Todo proyecto de ingeniera tiene fines ligados a la obtencin de un producto, proceso o servicio que es necesario generar a travs de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestin del proyecto. Al conjunto de las fases empleadas se le denomina ciclo de vida.
Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupacin temporal de tareas impone requisitos temporales correspondientes a la asignacin de recursos (humanos, financieros o materiales).
Elaborado por M. en H.D. Jos David Chvez Corts

FASES DE UN PROYECTO DE SOFTWARE

Ingeniera de Requisitos o Requerimientos Anlisis Diseo Desarrollo Construccin Pruebas Implementacin Mantenimiento

Elaborado por M. en H.D. Jos David Chvez Corts

MODELOS DE CICLO DE VIDA

Un modelo de ciclo de vida de software es una visin de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las fases involucradas y los criterios de transicin asociadas entre estas fases.
Un modelo de ciclo de vida del software:
Describe las fases principales de desarrollo de software. Define las fases primarias esperadas de ser ejecutadas durante esas fases.

Ayuda a administrar el progreso del desarrollo, y

Provee un espacio de trabajo para la definicin de un detallado proceso de

desarrollo de software.

Elaborado por M. en H.D. Jos David Chvez Corts

MODELO EN CASCADA
Ventajas
Diseo

Ingeniera de Requisitos Anlisis

Desarrollo de Documentacin en cada Fase. Generacin de un sistema fiable. Planeacin del proyecto de forma adecuada. Costo bajo. Desarrollo de Sistemas Robustos y Pequeos. Desventajas

Desarrollo

Pruebas

Implementacin

Mantenimiento

Planificacin inadecuada. Inflexible en el cambio de Requerimientos. Dividir el proyecto en ms fases. Falta de Gestin de Riesgos. Identificacin parcial de los requerimientos. Alto costo al haber equivocacin en las Fases de Ingeniera de Requisitos, Anlisis y Diseo cuando se est en la fase de Desarrollo. Falta de Visibilidad de los Progresos.

Elaborado por M. en H.D. Jos David Chvez Corts

MODELO DE DESARROLLO EVOLUTIVO

Especificacin y Anlisis

Diseo y Desarrollo

Validacin

Implementacin

Ventajas Flexible en el cambio de requerimientos. Facilidad en la modificacin del sistema. Gestin de Riesgos medio. Desventajas El desarrollo de la documentacin no es rentable por el cambio de versiones. Costos altos por el exceso de cambio de Requerimientos. La estructura se vuelve inestable por el cambio excesivo de Requerimientos. Desarrollo de Sistemas pequeos.
Elaborado por M. en H.D. Jos David Chvez Corts

MODELO DE ENTREGA POR ETAPAS

Ventajas
Ingeniera de Requisitos Anlisis

Diseo

Entrega de partes del proyecto. Generacin de un sistema fiable. Costo bajo. Desarrollo de Sistemas Robustos y Pequeos. Visibilidad del Progreso. Gestin de Riesgos medio.
Etapa 1: Diseo, Desarrollo, Pruebas, implementacin

Desventajas
Planificacin inadecuada. Inflexible en el cambio Requerimientos. Identificacin parcial de requerimientos. de los

Etapa 2: Diseo, Desarrollo, Pruebas, implementacin

Etapa n: Diseo, Desarrollo, Pruebas, implementacin

Elaborado por M. en H.D. Jos David Chvez Corts

MARCO TERICO
INGENIERA DE REQUISITOS
La Ingeniera de Requisitos, es una accin de la Ingeniera del Software que comienza con durante la actividad de comunicacin y contina en la actividad del modelado.
La ingeniera de Requisitos tiende un puente hacia el diseo y el

Desarrollo.

La Ingeniera de Requisitos proporciona el mecanismo apropiado para

entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solucin razonable, especificar la solucin sin ambigedades, validad la especificacin y administrar los requisitos conforme stos se transforman en un sistema operacional.

Elaborado por M. en H.D. Jos David Chvez Corts

MODELO EN ESPIRAL

Ventajas

Flexible en el cambio de Requerimientos. Generacin de un sistema fiable. Facilidad en la modificacin del tamao del sistema. No requiere de una Planificacin total. Visibilidad del Progreso. Gestin de Riesgos alta.
Desventajas Costo alto al no llegar al objetivo final debido a su flexibilidad.
Elaborado por M. en H.D. Jos David Chvez Corts

ELABORACIN

La Elaboracin es una accin del Modelado del Anlisis y se compone de una serie de tareas de modelado y refinamiento de escenarios del usuario que describen la forma en que el usuario final interactuar con el sistema, actividades y clases.

NEGOCIACIN

El cliente y el desarrollador entran en un proceso de negociacin, en el cual se le debe pedir al cliente un balance de la funcionalidad, el rendimiento y otras caractersticas del sistema frente al costo y el tiempo de entrega. El objetivo de la negociacin es desarrollar un plan de proyecto que satisfaga las necesidades del cliente al mismo tiempo que refleja las restricciones de tiempo, recurso humano y presupuesto a las que est sometido el equipo de software.

VALIDACIN

Al crear cada elemento del Modelo de Anlisis, ste se examina para conocer su consistencia, sus omisiones y ambigedades. A los requisitos que representa el modelo, el cliente les da jerarqua y se agrupan en paquetes de requisitos que se implementan como incrementos de software y se le entregan.

Una Revisin del Modelo de Anlisis se enfoca en las siguientes preguntas:

Cada requisito es consistente con el objetivo general del sistema/producto?

Todos los requisitos han sido especificados con el grado apropiado de abstraccin? El requisito es necesario en realidad o representa una caracterstica agregada

irrelevante para el objetivo del sistema?

Cada requisito est limitado y no es ambiguo? Algunos requisitos entran en conflicto con otros? El modelo de requisitos refleja de manera apropiada la informacin, la funcin y el comportamiento del sistema que ser construido?

GESTIN DE REQUISITOS

Es un conjunto de actividades que ayudan al equipo del proyecto a identificar, controlar y rastrear los requisitos y los cambios a stos en cualquier momento mientras se desarrolla el proyecto.

DIAGRAMA DE CASOS DE USO

Los objetivos de los casos de uso son los siguientes: Capturar los requisitos funcionales del sistema y expresarlos desde el punto de vista del usuario ( EL QU Y NO EL CMO). Guiar todo el proceso de desarrollo del sistema de informacin.

Puede ser desde una simple descripcin textual que recoja un requisito funcional a
una especificacin del caso de uso, e incluso un conjunto de diagramas.

Especificacin de un Casos de Uso

Se puede completar la descripcin definiendo cules son las precondiciones y postcondiciones del sistema, es decir, qu condiciones deben cumplirse para que se realice un caso de uso y cules son aquellas condiciones que se cumplen posteriormente al caso de uso. Una excepcin se utiliza para describir funcionalidades indeseadas o excepcionales de un paso a causa de una condicin no cumplida. Tambin se pueden enumerar los diferentes escenarios del caso de uso o subflujos si los tuviese y dar una breve descripcin de ellos. Los escenarios son los distintos caminos por los que puede evolucionar un caso de uso, dependiendo de las condiciones que se van dando en su realizacin.

Elementos del Casos de Uso

Actores. Un actor es algo o alguien que se encuentra fuera del sistema y que interacta con l. En general, los actores sern los usuarios del sistema y los sistemas externos al que se est desarrollando. Si se habla de usuarios, un actor es el papel que puede llevar a cabo en cuanto a su forma de interactuar con el sistema, es decir, un nico actor puede representar a muchos usuarios diferentes y de la misma forma, un usuario puede actuar como actores diferentes.

Nombre del Actor

Casos de uso. Un caso de uso representa el comportamiento que ofrece el sistema de informacin desde el punto de vista del usuario. Tpicamente ser un conjunto de transacciones ejecutadas entre el sistema y los actores. Para facilitar la comprensin de los casos de uso del sistema de informacin en el anlisis, es posible agruparlos en paquetes segn funcionalidades semejantes o relacionadas.
Verbo + sustantivo o adjetivo

Elementos del Casos de Uso

Paquete.- El objetivo de estos diagramas es obtener una visin ms clara del sistema de informacin orientado a objetos, organizndolo en subsistemas, agrupando los elementos del anlisis, diseo o construccin y detallando las relaciones de dependencia entre ellos.
Paquete

Relacin de Casos de Uso

La relacin entre un actor y un caso de uso es una relacin de comunicacin, que indica que un actor interviene en el caso de uso. Normalmente, el actor aporta informacin para la realizacin de un caso de uso o recibe informacin como resultado de la realizacin del mismo, por ello, esta relacin puede ser unidireccional o bidireccional, aunque generalmente se muestra como bidireccional, ya que no es necesario especificar en detalle estas relaciones.

La relacin entre casos de uso es una relacin unidireccional. Esta relacin puede
presentar uno de los dos siguientes tipos: usa o include y extiende.

Relacin include o usa

La asociacin de dependencia estereotipada con <<incluir>> o <<usa>> se emplea para evitar describir el mismo flujo de eventos repetidas veces, aportando un mecanismo de factorizacin que permite ubicar comportamiento comn en un nico caso de uso aparte que ser compartido por todos aquellos casos de uso en los que originalmente se encontraba expresada la porcin de pasos comn. Semnticamente se debe interpretar que el caso de uso base "incluye" la funcionalidad expresada en el caso de uso comn (por esa razn la flecha de la asociacin de dependencia apunta al caso de uso comn, puesto que el caso de uso base "depende" del aqul porque necesita su funcionalidad para poder completarse). Por ejemplo, si los casos de uso A y B presentan una parte comn, sta se puede sacar a un tercer caso de uso C. Entonces, habr una relacin usa del caso de uso A al C y otra del B al C.
A B

<<include>>

<<include>>

Relacin extend
Cuando una condicin en el curso normal de un caso de uso "A" implica la ejecucin de un conjunto de pasos que se llevan a cabo en forma excepcional o que corresponden al tratamiento de un error, estos pasos excepcionales se deben agrupar y modelar como un nuevo caso de uso, caso de uso "B". De esta manera, el caso de uso base "A" ser extendido por el caso de uso excepcional "B". Entre los casos de uso "A" y "B" existir una asociacin de dependencia estereotipada como <<extender>>, lo que significa que la funcionalidad del caso de uso "B" "extiende" la funcionalidad del caso de uso "A" en tanto y en cuanto en el caso de uso "A" se cumpla la condicin que implica la ejecucin del caso de uso "B". Y la asociacin de dependencia debe apuntar al camino base (contrariamente a lo que sucede en la asociacin de inclusin) debido a que el caso de uso "B" depende de que se cumpla con una condicin en "A" para poder llevarse a cabo.

<<extend>>

Cmo se puede observar, la funcionalidad que estamos modelando con una asociacin de extensin podra modelarse perfectamente tambin como un subflujo, por lo que se ha decidido establecer las siguientes reglas prcticas: Un subflujo es, conceptualmente, diferente a una excepcin, por lo que su tratamiento debera ser diferente: los subflujos son parte del camino base y las excepciones son tales, como su nombre lo indica. La funcionalidad de las excepciones debera tratarse como un caso de uso que extiende al caso de uso base, pero en algunas oportunidades esta funcionalidad excepcional es tan pequea (en cuanto al nmero de pasos) que no sera conveniente, desde un punto de vista meramente prctico, destinar un caso de uso entero a esa pequea porcin de funcionalidad, describindose, entonces, en la seccin destinada a los subfujos dentro del documento que contiene la descripcin del caso de uso base. Este criterio prctico ser adoptado siempre que la excepcin cuente con ms de 10 pasos o que la excepcin posea nuevas excepciones. Es importante aclarar que las condiciones anteriores no representan una regla absoluta y automtica ya que si el subflujo cumple con una o dos de las condiciones anteriores y el subflujo no puede considerarse, por el nivel de abstraccin y criterio personal, un nuevo caso de uso extendido, puede dejarse como subflujo.

Identificacin de casos de uso

Cules son las principales tareas o funciones que sern realizadas por el actor? Cul es el sistema de informacin que el actor adquiere, produce o cambia? Qu actor informar al sistema de los cambios en el entorno externo? Qu informacin necesita el actor sobre el sistema?

Flujo de Datos
El diagrama de flujo de datos (DFD) permite al ingeniero del software desarrollar los modelos del mbito de informacin y del mbito funcional al mismo tiempo. A medida que se refina el DFD en mayores niveles de detalle, el analista lleva a cabo implcitamente una descomposicin funcional del sistema. Al mismo tiempo, el refinamiento del DFD produce un refinamiento de los datos a medida que se mueven a travs de los procesos que componen la aplicacin.

DIAGRAMA DE ACTIVIDADES

Un diagrama de actividades muestra el flujo secuencial de las actividades. El diagrama de actividades es utilizado tpicamente para describir las actividades realizadas en una operacin (mtodos), aunque puede tambin ser utilizado para describir procesos (casos de uso).

Elementos y Notacin de los Diagrama de Actividades

Estado de Actividad.- Una actividad es la especificacin de una secuencia parametrizada de comportamiento. Una actividad se representa con un rectngulo con las puntas redondeadas adjuntando todas las acciones, flujos de control y otros elementos que constituyen la actividad.
Actividad

Transicin.- Una lnea con terminacin de punta de flecha representa la transicin de una actividad a otra. Nodo Inicial.- Representa el inicio del proceso o de la operacin del flujo de las actividades, y se representa por un gran punto negro.

Nodo Final.- Representa el final del flujo de las actividades, y se representa por una diana.

Decisin.- Punto donde una secuencia de actividades realizar una decisin. Se representa por un rombo y la condicin se indicar entre corchetes junto a la ruta correspondiente.
[Falso] [Verdadero]

Bifurcacin o Rutas concurrentes.- El flujo de una actividad se puede separar en varas rutas que se ejecuten al mismo tiempo y luego se una en un momento. Se representa con una barra horizontal o vertical dependiendo de la orientacin del diagrama.

Calles.- Se aplican cuando en un proceso se requiere identificar quien tiene la responsabilidad en el proceso. Se representa como calles horizontales o verticales.

IDENTIFICACIN DE CLASES

Entidades externas.- Aquellas que producen o consumen informacin que usar un

sistema basado en computadora (otros sistemas, dispositivos, personas). Cosas.- Aquellas que son parte del dominio de la informacin del problema (reportes, despliegues). Sucesos o eventos.- Aquello que ocurre dentro del contexto de la operacin del sistema (una transferencia de propiedad, serie de movimientos de un robot). Papeles.- Roles que desempea una persona (gerente, arquitecto). Unidades Organizacionales.- Relevantes para una aplicacin (periodo, grupo, divisin). Sitios.- Aquellas que establecen el contexto del problema y la funcin global del sistema (puerto de carga, el piso de manufactura, almacn). Estructuras.- Que definen que clases de objetos relacionadas (computadoras, vehculos).

Especificacin de atributos
Los atributos son las caractersticas o propiedades que definen a la clase, lo cual clarifica qu significa la clase en el contexto del espacio y problema. Definicin de Operaciones Las operaciones definen el comportamiento de un objeto y cambian, de alguna manera, los atributos de dicho objeto. Aunque existen muchos tipos diferentes de operaciones, stas pueden clasificarse en tres grandes categoras:

Operaciones que manipulan, de alguna manera, datos (pro ejemplo agregar, eliminar, modificar, seleccionando). Operaciones que realizan algn clculo. Operaciones que monitorizan un objeto frente a la ocurrencia de un suceso de control.

TIPOS DE CLASES

Clases de Entidad.- Tambin llamadas clases de modelo o negocios, se extraen de manera directa del enunciado del problema. De manera tpica, estas clases representan clases que se almacenarn en una base de datos y que persisten en una aplicacin.

Su simbologa es:

TIPOS DE CLASES

Clases de Frontera o Interfaz.- Se utilizan para crear la interfaz (por ejemplo, pantallas interactivas, formularios, API, reportes impresos) que el usuario ve y con la cual interacta cuando se utiliza el software.
Su simbologa es:

TIPOS DE CLASES

Clases de Control. Se disean para: 1) manejar la creacin o actualizacin de los objetos de entidad; 2) manejar la inmediatez de objetos de frontera conforme stos obtienen la informacin de objetos de entidad; 3) manejar la comunicacin compleja entre conjuntos de objetos; 4) manejar la validacin de datos comunicados entre los objetos o entre el usuario y la aplicacin; 5) buscar la referencia de un objeto concreto, conociendo alguno de los valores de sus atributos; 6) Crear/modificar varios objetos para no tener que acceder a las clases entidad directamente desde las clases frontera o interfaz; 7) Definir clculos/procesos relacionados con la lgica del negocio.

DIAGRAMA DE CLASES

Un diagrama de clases es un tipo de modelo esttico, el cul describe la vista esttica del sistema. Aunque tiene similitudes con un modelo de datos, las clases no solo muestran la estructura de la informacin, sino que describen tambin el comportamiento. Elementos
Los diagramas de clases estn compuestos por los siguientes elementos: Clase.- que contiene atributos mtodos y visibilidad. Relaciones.- Asociacin, Herencia, Dependencia, Agregacin, Composicin, Realizacin. Multiplicidad. Roles o Papeles.

Clase

Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto es una instancia de una clase). En la Seccin Superior: Contiene el nombre de la Clase, la primera letra del nombre de la clase debe ser en Maysculas. En la Seccin Intermedia: Contiene los atributos que caracterizan a la Clase (pueden ser private, protected o public). El nombre de las variables deben ser acorde al dato que van a alojar y deben escribirse con minsculas.

En la Seccin Inferior: Contiene los mtodos u operaciones, los cuales son la forma como interacta el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Actividades en Fase de Anlisis

Atributos Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que definen el grado de comunicacin y visibilidad de ellos con el entorno, estos son: public (+, ): Indica que el atributo ser visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. private ( -, ): Indica que el atributo slo ser accesible desde dentro de la clase (slo sus mtodos lo pueden acceder). protected (#, ): Indica que el atributo no ser accesible desde fuera de la clase, pero si podr ser accedido por mtodos de la clase adems de las subclases que se deriven (en la herencia).

Actividades en Fase de Anlisis

Mtodos Los mtodos u operaciones de una clase son la forma en como sta interacta con su entorno, stos pueden tener las caractersticas: public (+, ): Indica que el mtodo ser visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. private (-, ): Indica que el mtodo slo ser accesible desde dentro de la clase (slo otros mtodos de la clase lo pueden acceder). protected (#, ): Indica que el mtodo no ser accesible desde fuera de la clase, pero si podr ser accedido por mtodos de la clase adems de mtodos de las subclases que se deriven (ver herencia).

Relaciones

Asociacin La relacin entre clases conocida como Asociacin, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relacin fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

Asociaciones Reflexivas
En ocasiones, una clase establece una asociacin consigo misma. Esto ocurre cuando una clase tiene objetos que pueden jugar diversos papeles.
Persona +Alumno +Profesor

Relaciones
Herencia o Generalizacin Indica que una subclase hereda los mtodos y atributos especificados por una SuperClase o clase principal, por ende la Subclase o clase secundaria, adems de poseer sus propios mtodos y atributos, poseer las caractersticas y atributos visibles de la SuperClase (public y protected).

Relaciones
Dependencia

Representa un tipo de relacin muy particular, en la que una clase es instanciada (su instanciacin es dependiente de otro objeto/clase). El uso ms particular de este tipo de relacin es para denotar la dependencia que tiene una clase de otra.

Relaciones
Agregacin

En ocasiones una clase consta de otras clases. Este es un tipo especial de relacin conocida como agregacin. Los componentes y las clases que constituyen son una asociacin que conforma un todo.
Gabinete

CdRom

Unidad de Disco

Relaciones
Composicin

Forma de agregacin con fuerte pertenencia y que designa una relacin en la que un elemento se compone de otro u otros.

Relaciones
Realizacin o Interfaz

Es un conjunto de operaciones que especifica cierto aspecto de la funcionalidad de una clase, y es un conjunto de operaciones que una clase presenta a otras. Coleccin de operaciones que se utiliza para especificar un servicio de una clase o componente.

Multiplicidad
Representa la cantidad de objetos de una clase que se relacionan con un objeto de la clase asociada. Los tipos de multiplicidad que hay son: Uno a uno (1 1). Uno a muchos ( 1 *). Uno a Uno o ms ( 1 1*). Uno a n donde n es un nmero cualquiera ( 1 n).

Estilos Arquitectnicos
Arquitecturas orientadas a objetos Los componentes de un sistema encapsulan los datos y las operaciones que se deben realizar para manipular los datos. La

comunicacin y la coordinacin entre componentes se consigue a

travs del paso de mensajes.

DIAGRAMA DE COMPONENTES

Un diagrama de componentes representa la separacin de un sistema de software en componentes fsicos (por ejemplo archivos, cabeceras, mdulos, paquetes, etc.) y muestra las dependencias entre estos componentes. Muestra la organizacin y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.
UN DIAGRAMA DE COMPONENTES INTERFACES Y RELACIONES. CONTIENE COMPONENTES,

Representacin de un componente
El smbolo principal de un diagrama de componentes es un rectngulo que tiene otros dos sobrepuestos de su lado izquierdo. Debe colocar el nombre del componente dentro del rectngulo.
Clase.java

Tipos de Componentes Componentes de distribucin.- Son aquellos que conforman el fundamento de los sistemas ejecutables (por ejemplo, DLL, ejecutables, controles ActiveX). Componentes para trabajar en el producto.- Son los que crean los componentes de distribucin (archivos de bases de datos y de cdigo). Componentes de ejecucin.- se crean como consecuencia de un sistema en ejecucin. Por ejemplo: objetos que se instancian a partir de una dll. Estereotipos para Componentes executable: especifica un componente ejecutable en un nodo. library: especifica una biblioteca de objetos. table: especifica una tabla de una BD. file: especifica un componente que contiene un documento con cdigo fuente o datos. document: especifica un componente que representa un documento.

DISEO DE INTERFAZ

El diseo de la interfaz describe la manera de comunicarse el software dentro de s mismo, con sistemas que interoperan dentro de l y con las personas que lo utilizan. Una interfaz implica un flujo de informacin (por ejemplo, datos y/o control) y un tipo especfico de comportamiento. Por tanto, los diagramas de flujo de control y de datos proporcionan gran parte de la informacin que se requiere para el diseo de la interfaz. El diseo de la Interfaz de usuario requiere el estudio de las personas y el conocimiento tecnolgico adecuado. Quin es el usuario? Cmo aprende a interactuar con un nuevo sistema de cmputo? Cmo interpreta la informacin que produce el sistema? Qu espera del sistema?

DISEO DE INTERFAZ

El diseo de la interfaz describe la manera de comunicarse el software dentro de s mismo, con sistemas que interoperan dentro de l y con las personas que lo utilizan. Una interfaz implica un flujo de informacin (por ejemplo, datos y/o control) y un tipo especfico de comportamiento. Por tanto, los diagramas de flujo de control y de datos proporcionan gran parte de la informacin que se requiere para el diseo de la interfaz. El diseo de la Interfaz de usuario requiere el estudio de las personas y el conocimiento tecnolgico adecuado. Quin es el usuario? Cmo aprende a interactuar con un nuevo sistema de cmputo? Cmo interpreta la informacin que produce el sistema? Qu espera del sistema?

LOOK & FEEL

El objetivo del Look & Feel es generar un bosquejo de las ventanas y elementos grficos que la componen del sistema o del sitio web para que el usuario final apruebe dicha interfaz.

Los tipos de pruebas que deben realizarse son: Pruebas Unitarias. Pruebas de Integracin. Pruebas del Sistema. Pruebas de Implantacin. Pruebas de Aceptacin. Pruebas de Regresin.

PRUEBAS UNITARIAS

Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente una vez que ha sido codificado. Existen dos enfoques principales para el diseo de casos de prueba: Enfoque estructural o de caja blanca. Se verifica la estructura interna del componente con independencia de la funcionalidad establecida para el mismo. Por tanto, no se comprueba la correccin de los resultados si stos se producen. Ejemplos de este tipo de pruebas pueden ser ejecutadas todas las instrucciones del programa, localizar cdigo no usado, comprobar los caminos lgicos del programa, etc. Enfoque funcional o de caja negra. Se comprueba el correcto funcionamiento de los componentes del sistema de informacin, analizando las entradas y salidas y verificando que el resultado es el esperado. Se consideran exclusivamente las entradas y salidas del sistema sin preocuparse por la estructura interna del mismo.

PRUEBAS DE INTEGRACIN

El objetivo de las pruebas de integracin es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactan correctamente a travs de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados en las verificaciones correspondientes.

PRUEBAS DEL SISTEMA

Las pruebas del sistema tienen como objetivo ejercitar profundamente el sistema comprobando la integracin del sistema de informacin globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de informacin con los que se comunica.
Pruebas funcionales. Dirigidas a asegurar que el sistema de informacin realiza correctamente todas las funciones que se han detallado en las especificaciones dadas por el usuario del sistema. Pruebas de comunicaciones. Determinan que las interfaces entre los componentes del sistema funcionan adecuadamente, tanto a travs de dispositivos remotos, como locales. Asimismo, se han de probar las interfaces hombre/mquina. Pruebas de rendimiento. Consisten en determinar que los tiempos de respuesta estn dentro de los intervalos establecidos en las especificaciones del sistema. Pruebas de volumen. Consisten en examinar el funcionamiento del sistema cuando est trabajando con grandes volmenes de datos, simulando las cargas de trabajo esperadas.

PRUEBAS DEL SISTEMA

Pruebas de sobrecarga. Consisten en comprobar el funcionamiento del sistema en el umbral lmite

de los recursos, sometindole a cargas masivas. El objetivo es establecer los puntos extremos en los cuales el sistema empieza a operar por debajo de los requisitos establecidos. Pruebas de disponibilidad de datos. Consisten en demostrar que el sistema puede recuperarse ante fallos, tanto de equipo fsico como lgico, sin comprometer la integridad de los datos. Pruebas de facilidad de uso. Consisten en comprobar la adaptabilidad del sistema a las necesidades de los usuarios, tanto para asegurar que se acomoda a su modo habitual de trabajo, como para determinar las facilidades que aporta al introducir datos en el sistema y obtener los resultados. Pruebas de operacin. Consisten en comprobar la correcta implementacin de los procedimientos de operacin, incluyendo la planificacin y control de trabajos, arranque y rearranque del sistema, etc. Pruebas de entorno. Consisten en verificar las interacciones del sistema con otros sistemas dentro del mismo entorno. Pruebas de seguridad. Consisten en verificar los mecanismos de control de acceso al sistema para evitar alteraciones indebidas en los datos.

PRUEBAS DE IMPLANTACIN

El objetivo de las pruebas de implantacin es comprobar el funcionamiento correcto del sistema integrado de hardware y software en el entorno de operacin, y permitir al usuario que, desde el punto de vista de operacin, realice la aceptacin del sistema una vez instalado en su entorno real y en base al cumplimiento de los requisitos no funcionales especificados.

PRUEBAS DE ACEPTACIN

El objetivo de las pruebas de aceptacin es validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptacin, desde el punto de vista de su funcionalidad y rendimiento. Las pruebas de aceptacin son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecucin y aprobacin final corresponden al usuario. Estas pruebas van dirigidas a comprobar que el sistema cumple los requisitos de funcionamiento esperado, recogidos en el catlogo de requisitos y en los criterios de aceptacin del sistema de informacin, y conseguir as la aceptacin final del sistema por parte del usuario.

PRUEBAS DE REGRESIN

El objetivo de las pruebas de regresin es eliminar el efecto onda, es decir, comprobar que los cambios sobre un componente de un sistema de informacin, no introducen un comportamiento no deseado o errores adicionales en otros componentes no modificados. Las pruebas de regresin se deben llevar a cabo cada vez que se hace un cambio en el sistema, tanto para corregir un error como para realizar una mejora. No es suficiente probar slo los componentes modificados o aadidos, o las funciones que en ellos se realizan, sino que tambin es necesario controlar que las modificaciones no produzcan efectos negativos sobre el mismo u otros componentes.

Actividades en Fase de Anlisis

Ingeniera de Requisitos (Documento de Requerimientos). Gestin de Riesgos. Diagrama de Casos de Uso. Diagrama de Actividades.

Elaborado por M. en H.D. Jos David Chvez Corts

Actividades en Fase de Diseo

Diagrama de Clases. * Diagrama de Objetos. Diagrama de Actividades* Diagrama de Secuencias. Diagrama de Colaboracin. Diagrama de Estados. Diagrama de Componentes.* Diagrama de Distribucin o Despliegue. Diseo de Interfaz Grfica (Look & Feel) Mapa de Navegacin. Manual de Usuario. Manual Tcnico. Manual de Instalacin.

Elaborado por M. en H.D. Jos David Chvez Corts